When a project slips, the first question is almost always technical. What is blocking it, who is stuck, do we need another pair of hands.
Sometimes that is the right question. In my experience it usually is not.
What slipping usually looks like up close
Work sat waiting for a decision nobody realised was needed. A requirement meant one thing to the client and another to the person building it, and the gap surfaced at review rather than at kickoff. Something was flagged on a Tuesday in a channel the person who could act on it does not read. Two people solved the same problem in different directions because neither knew the other was on it.
None of those are engineering failures. They are coordination failures, and they are wearing engineering’s clothes because engineering is where they eventually become visible.
Why we look at the wrong thing
Because engineering is measurable and coordination is not. Tickets have states. Builds have durations. You can point at a branch.
The three days a decision spent waiting for someone to notice it was needed do not appear anywhere. There is no field for it. So when the retrospective asks what went wrong, the honest answer — “the work was fine, the space around the work was slow” — has nowhere to be written down, and something more tractable gets written instead.
Then the fix matches the diagnosis. More capacity, better estimates, a stricter definition of done. And the same thing happens again next quarter, because the actual bottleneck was never named.
The test I use
When something has slipped, walk it backwards and mark every point where the work was not being worked on. Waiting for a reply. Waiting for access. Waiting for a decision. Waiting for someone to read a message.
Then compare that total against the time the work was genuinely in progress and genuinely hard.
If the waiting is bigger — and it often is — then hiring another developer will not help. You have a communication problem with an engineering symptom, and the two need different fixes.
This is not an argument against good engineering
Bad architecture is real and it is expensive. Technical debt is real. Some things slip because the problem was genuinely harder than anyone thought, and that is a legitimate answer.
The argument is narrower: before you conclude the engineering is the problem, check how much of the elapsed time the engineering was even happening. That number is usually available, nobody usually looks at it, and it changes what you do next.
Turn repetitive project work into repeatable AI workflows.
Download the free AI Project Delivery Starter Kit — practical templates to improve reporting, meetings, and project communication.