Fast in no particular direction
Most engineering organizations I have seen up close were busy. Genuinely, visibly busy. Standups were full, sprints were packed, everyone was shipping something. And yet the same work kept circling back, and nobody could quite say why the quarter felt like wading.
From the inside, the pattern shows up in three shapes. The first is rework: a feature gets built, then rebuilt, because the goal it was chasing moved, or was never stated plainly enough to hit. The second is the hedged design. When no one has said which future we are building for, careful engineers build for all of them at once, and you pay for four possible systems to avoid committing to one. The third is the escalation that arrives dressed as a technical argument but is really a question about who decides. Two good engineers disagree, neither has the authority to close it, so it climbs the ladder looking for someone who does.
The thread running through all three is the same: nobody set a direction clear enough to work from. That is what a direction problem looks like when you are standing in it, and you cannot sprint your way out of it. Adding people or hours only makes the rework more expensive.
Three clarities
When I say clarity, I mean three specific things, and they fail independently.
Intent is the first: why this, and why now. I mean the reason underneath the ticket, the thing a team can reason from. When a team genuinely understands the why, they make a hundred small calls a week the way I would have, without asking, because they share the goal. When they don’t, every one of those calls is a coin flip or a question in my inbox.
Ownership is the second: for each system and each meaningful decision, one accountable name. When responsibility for something important is shared, it tends to become nobody’s the moment it matters. This is the quiet cost behind most escalations; they are ownership gaps wearing a technical costume.
Architecture is the third, and it is the one people most often mistake for a document. Architecture is not a diagram; it is the set of decisions you have already made so nobody has to remake them every sprint. A direction earns its keep when it is sturdy enough to say no with, when “that doesn’t fit how this system is meant to work” is a sentence anyone on the team can say and defend. That is what I mean by architecture that enables change: a spine clear enough that people can tell what belongs and what does not.
Clarity is a leadership deliverable
For a long time I thought clarity was a condition you either had or lacked. Moving from writing code, to leading a team, to directing an organization across three companies taught me it is something you manufacture, and that manufacturing it is most of the real work of leading.
It is unglamorous work. You write things down, because a decision that lives only in your head is not a decision the team can use. You decide visibly, so people see the call and the reasoning behind it, and can apply that reasoning next time without you. And you repeat yourself well past the point of boredom, because the message you are sick of sending is the one half the team is hearing for the first time.
The hardest correction was learning to stop measuring busyness. As an individual contributor, output was a fair proxy for value, and I carried that instinct into leadership, quietly scoring people by how occupied they looked. It is a bad measure. A team can be fully utilized and pointed slightly wrong, and the more effort they pour in, the further off course they drift. What I owe them is a clear direction worth their effort.
Velocity as a byproduct
Clarity is where durable speed actually comes from, and it compounds. When intent is shared and ownership is settled, the decisions that used to need a meeting get made in a pull-request comment instead. That happens dozens of times a week, quietly, and over a couple of quarters the gap in throughput is wide. No one is typing faster. Far less motion is wasted going sideways.
I will keep the honest example structural rather than dressed up as a war story, because that is what it actually is: the same pattern, again and again. The decisions that got cheap were the ones sitting downstream of a why everyone finally understood. Once the goal was unambiguous, a whole class of “should we even do this” questions stopped reaching me at all. Ambiguity carries the mirror cost. It is a tax you pay on every decision, and you pay it without ever seeing the line item.
AI raises the stakes on all of this rather than lowering them. A fast code generator pointed in no particular direction produces the wrong thing faster and with more confidence, which is why I argue that AI-enabled engineering is an org redesign that reshapes who owns what and who gets to decide. The clearer your intent, ownership and architecture, the more that speed lands somewhere you actually meant to go.
Velocity was never something to chase directly. A clear organization produces it on the way to somewhere it chose. Make the direction unmistakable first, and speed stops being a target you aim at and becomes a symptom you enjoy.