It usually arrives in a board meeting, or a leadership offsite, or a Slack message at 11pm. Some version of: “the engineering team is slow.”
I have heard it at companies with twelve engineers and companies with a hundred and twenty. It is almost never true, and it is almost always pointing at something real.
What makes it worth taking seriously is not the accusation. It is that a reasonable, well-intentioned person looked at the system, could feel that something was wrong, and reached for the only explanation visible from where they were standing. That is what symptoms do. They tell you the truth about where someone is standing, not about where the problem is.
Four things usually sitting underneath it
Too much work in progress and nobody with the authority to say no. A roadmap that nobody owns the removals on. A commercial model and a product plan that were never reconciled, so sales keeps promising things engineering never agreed to build. Or decision rights that were never written down, which means the organization keeps changing shape and keeps getting slower each time.
None of those is an engineering problem. All of them present as one.
Why the complaint lands on engineering
Engineering is the most measurable function in the building. Tickets, velocity, deploys, cycle time: all visible, all countable, none of them causal. When a system is underperforming and one part of it is instrumented, that part gets blamed. It is the streetlight effect with a Jira licence.
The functions where the constraint actually lives are usually the least instrumented ones. Nobody measures how long a decision waits. Nobody measures how many things are in flight per engineer. Nobody measures the gap between what was sold and what was planned. So those never appear in the conversation, and the one thing that does appear takes the weight.
How I actually pull this apart
Three questions, in this order, and the order matters.
How many things is each team carrying right now? Not assigned. Carrying. Including the thing they were asked to look at on Tuesday, the escalation from last month that never formally closed, and the integration somebody promised a customer. In most stalled organizations this number is between four and seven, and the honest answer surprises the leadership team more than anything else I ask.
What was removed from the roadmap in the last two quarters? If the answer is nothing, the roadmap is not a plan. It is a queue with a nice presentation layer, and the team’s real prioritization is happening invisibly, at the individual level, under stress.
Who decided the last thing that got built, and how long did that decision take? Decision latency is the metric almost nobody tracks and the one that best predicts whether a company is about to plateau. If the answer involves three people, two meetings and a fortnight, you do not have a delivery problem.
What to do about it
Cut work in progress before doing anything else. It is the cheapest intervention available and it is reversible. Halving the number of concurrent initiatives typically produces a visible change within a sprint or two, and the change is almost never explained by anyone working harder.
Then give someone the job of removal. Not prioritization. Removal. Prioritization is what everyone already thinks they do; it produces an ordered list where nothing ever leaves. Someone needs to be accountable for what gets stopped, and to have air cover when they stop it.
Then write down who decides what. Most organizations have never done this, and the ambiguity is expensive in a way that is invisible until you cost it.
Notice that none of those three is a reorganization. Reorganization is what companies reach for when they can feel a constraint but have not located it, and it reliably buys six months of disruption and the same underlying problem in a new arrangement.
The part that is uncomfortable to say out loud
In a meaningful minority of the cases I have worked on, the decision queue terminates at the founder or the CEO. Not because they are doing anything wrong. Because the thing they are good at, holding the whole system and deciding quickly, stops being available once the system outgrows one head.
That is a throughput observation, not a criticism of judgment. But it is the single hardest sentence to say to the person who hired you, and being willing to say it is most of what you are actually being paid for.
This first appeared on Medium, 11 March 2024. Read the original.
