This article continues the idea from our previous piece on why adding more engineers does not necessarily make software delivery faster, where we explored how increasing headcount often raises coordination costs instead of improving throughput when the system itself is already constrained.
The original article: More Engineers Don’t Make Software Faster
The core argument in that piece was simple: software delivery does not scale linearly with team size. Once coordination, alignment, and decision-making become the limiting factors, adding more engineers tends to amplify existing friction rather than remove it. More people do not automatically translate into faster delivery if the system around them is already slow.
The natural follow-up question is what actually does slow teams down if engineering capacity is not the main constraint.
When software projects fall behind schedule, the instinct is usually to look at development. If delivery is slow, it must be because engineering is slow. Maybe the team is not strong enough, maybe there are not enough engineers, or maybe estimation was wrong.
After seeing enough real projects, this explanation starts to feel incomplete.
Development is rarely where most time is lost. The actual coding is often a relatively small part of the overall timeline. A feature that takes a few days to implement can easily take weeks to reach production. The gap between those two moments is where most of the real delay accumulates.
The time does not disappear. It is consumed by everything around the code: waiting for decisions, clarifying requirements, adjusting scope, updating designs, revisiting priorities, and going through feedback cycles that were not fully aligned from the start.
None of these steps feel like “blockers” in isolation. Each one is usually justified. But together they create a system where work constantly starts and stops instead of moving smoothly from idea to production.
From the outside, software delivery looks like a structured process. A feature is planned, designed, implemented, tested, and released. In practice, it behaves much less like a pipeline and much more like a queue.
Work enters the system and then waits. It waits for someone to make a decision. It waits for clarification on requirements. It waits for design updates after scope changes. It waits for QA validation on edge cases that were not discussed early enough. It waits for feedback that arrives after priorities have already shifted.
The actual engineering work happens in short bursts between these waiting periods. The rest of the time, nothing is technically broken, but nothing is moving either.
This is why teams can feel fully utilized while still delivering slowly. Engineers are busy, calendars are full, tickets are moving, but progress is fragmented. High activity does not necessarily mean high throughput.
When this becomes visible, the typical response is to scale the team. If delivery is slow, adding more engineers should help.
But if the bottleneck is not engineering capacity, adding more engineers does not remove it. It only increases the number of people waiting in the same queues.
In systems where decisions are slow, priorities are unstable, or requirements are unclear, engineering speed is not the limiting factor. The limiting factor is how quickly the organization can make, communicate, and stabilize decisions.
As a result, larger teams often do not deliver faster outcomes. They simply introduce more coordination overhead into an already constrained system.
Most companies track engineering metrics carefully. Velocity, throughput, sprint completion, deployment frequency — all of these are commonly used to measure performance.
What is rarely measured is decision latency: how long it takes to make and confirm decisions that unblock work.
Yet this is often the dominant source of delay.
A single unanswered question can block multiple engineers and downstream processes at the same time. A delayed scope decision can invalidate days of engineering work. A postponed prioritization call can result in teams building the right thing at the wrong time.
Unlike technical failures, these delays do not produce alerts or errors. Nothing breaks. Instead, work simply pauses.
Over time, these pauses accumulate and turn into systemic slowness that is difficult to trace back to a single cause.
The fastest teams are not necessarily the ones that write code faster. In many cases, they are not dramatically better at implementation than others.
What distinguishes them is the absence of unnecessary stops. Questions are resolved quickly. Ownership is clear. Priorities remain stable long enough for execution to complete. Decisions are made close to the moment they are needed, not weeks later in separate alignment cycles.
As a result, work flows continuously instead of being constantly interrupted.
This shifts the way speed should be understood. Engineering velocity is often treated as an execution problem, but in reality it is mostly a flow problem.
It is tempting to think of software delivery as a function of engineering capacity or technical skill. But most organizations are not limited by how fast they can build software.
They are limited by how quickly they can decide what to build, and how consistently they can maintain those decisions long enough for execution to finish.
Once viewed this way, the bottleneck becomes much clearer. It is not coding speed. It is not tooling. It is not even engineering efficiency.
A company does not move at the speed of its developers.
It moves at the speed of its decisions.
And the teams that appear fast are rarely writing code faster than everyone else. They are simply spending less time waiting for permission to continue working.
If this is true, the obvious question is why so many organizations end up in this state.
The answer is rarely intentional. Most companies don’t choose slow decision-making. It emerges naturally as teams grow, stakes increase, and more people become involved in each decision.
Every additional stakeholder adds context that needs to be aligned. Every unclear ownership boundary adds another layer of validation. Every attempt to reduce risk introduces another approval step.
Over time, decision-making stops being a single step and becomes a process of its own. And once that happens, engineering can no longer outrun it.
Most software problems are not execution problems. They are waiting problems.
Waiting for decisions. Waiting for alignment. Waiting for someone to confirm what should already be clear. Waiting for priorities to stop changing long enough for real work to finish.
And the longer you look at software delivery, the more obvious it becomes that most of the time is not spent building anything at all — it is spent moving work through a system of approvals, context switching, and re-validation.
In that sense, speed is not about how fast teams can write code. It is about how little time they spend waiting between steps.
Because once the waiting disappears, the execution part is usually already fast enough.
