Agility, Constraints

Over the last 15 years, I have seen many companies integrate some concepts drawn from the Agile Manifesto and movement. I have often seen the old habits of the rigid structure of accountability being repackaged and rebranded to fit decade-old habits and cravings of managers and traditionally trained founders.

The result is packaged training and certifications of all sorts, with names often starting with the letter "S". The result is also poor, limited except in disgruntled talent who flee to other pastures.

So, as young tech leads, first-time, defacto CTOs what path could you take to get started organising your engineering team?

Your basic intent should be organized around two things: limpid communication and limpid honesty.

Those two should be applied to two things: needs and constraints. And you should revisit those frequently.

Limpid

limpid, adjective: completely clear and transparent

It isn't easy to be honest about our goals and context, but it's terribly necessary.

Too often, we face an HIPPO moment or hiding away from the terrible truth that our way of mainly working adds up to theatre and pantomime.

Communication is blurry, with pieces of context unsaid or half said, expectations left to the realm of imagination.

To move on, to scale our organisation in a sane way (for our customers, our employees, and ourselves), we have to rely instead on limpid communication and honesty. We have to be clear and transparent about where we want to go, where we are, and which direction we currently face.

Not brutal

There is no need to be brutal when communicating. Being limpid doesn't mean you can't be empathic towards your customers and colleagues. Choose your words, and the setting. Be clear about what you mean. Don't leave things half-hanging in the air. Give context to the piece of information you deliver, and ensure the vocabulary you use is the one your audience is familiar with.

Agile?

Plenty of "Agile" methodologies and their adoption within a team or company are more akin to a "cargo cult" than actual integration of the concepts at the core of the Agile manifesto.

A cargo cult is an indigenist millenarian belief system, in which adherents perform rituals which they believe will cause a more technologically advanced society to deliver goods. – https://en.wikipedia.org/wiki/Cargo_cult

If you read the Agile manifesto or the gentle introduction to Extreme Programming (and its core values), you will see how both boil down to very little: communication, small iteration, and honesty.

Allen Holub has managed to put it nicely in a tweet in early 2022:

But he still found the need (or requests) to clarify this through a blog post (that he keeps on updating).

In practicality

So instead of doing this big rumble and pompous stuff, you need to keep it simple, lean, and honest.

Work small,
Talk to each other,
Make people lives better
– Allen Holub

Talk to your customers, talk to the users of what you are building or aiming to build, and speak to your colleagues.

The point of the talking is to understand each person's context and the constraints with which you will work.

Both context and constraints will tell you what to work on next. But don't think, "oh it will also tell me what to work on after that bit". It might give you hints about that, but by the time you finish that first block of work, the next item to work on might be totally different. Keep it simple.

Deadlines

Deadlines should be seen as additional context or constraints.

What I consider one key learning for myself over the last 10 years is: constantly under promise and over-deliver. Doing the opposite is simply setting yourself for failure.

As such one should be very careful about accepting deadlines. Again, this is something that can be addressed by communication and with honesty.

One priority

As you might gather from reading "Essentialism: The Disciplined Pursuit of Less" by Greg McKeown there cannot be multiple priorities. There is one spot at the top of the list, not two.

That is your main constraint: you can only do one thing at a time. If you are not honest about this and don't communicate clearly about this you will fail.

Summing it up

Talk to your users, your peers, and your colleagues and figure out what is the next thing that needs to be done.

From there two strategies:

• gather just enough context to get the first imperfect version out of the door in as little time as possible
• gather all information you can to figure out the best possible version you can do in a relatively short amount of time (2 to 6 weeks usually)

And then?

Then you pick up your notebook, and your pen, swallow your pride, let users use the product, and ask them what they think.

This will give you an honest answer to "what next?".

Remember: limpid communication and limpid honesty.

If you like this approach, you can join a 2 week cohort based class for Tech Leads and CTOs, you can talk to me during our weekly office hours, or start a multi day assessment with a first introduction call.