When a delivery problem is an operating-model problem
Before asking a team to move faster, find out what the work is waiting for.
Unpublished prototype draft. Prepared for editorial review; this is general guidance, not a client case study or a promised engagement outcome.
A missed release is visible. The decisions that made it likely are often scattered across the business: a priority changed without another being removed, an approval sat with someone who had no time to review it, or a shared team accepted more requests than it could finish.
It is tempting to describe all of this as an engineering delivery problem. Sometimes that is accurate. An unreliable build, insufficient testing or difficult code can be the immediate constraint. But changing the delivery process will achieve little if the organisation keeps making incompatible commitments upstream.
The operating model is the practical arrangement through which work gets chosen, funded, owned, decided and supported. It exists whether or not anyone has drawn it. When that arrangement repeatedly prevents capable people from completing useful work, delivery is showing you an organisational constraint.
Ownership has to reach the outcome
Assigning a ticket creates task ownership. It does not necessarily create ownership of the result. A feature can be correctly implemented, reviewed and deployed while the customer problem remains unresolved because nobody owns the path across product, engineering, operations and support.
Look for the point at which responsibility changes hands. Who notices if the work stops there? Who can bring the right people together? Who decides whether the remaining effort is still worth doing? If every team has completed its part but the outcome is still missing, the boundary between teams deserves attention.
A named owner helps only if the role comes with usable authority and capacity. Making someone accountable for a date while allowing several other people to add scope, change priorities or withhold essential resources creates responsibility without control.
For a meaningful piece of work, write down the outcome, the person accountable for it, the resources they can call on and the decisions they can make. Also state the boundary: a product owner may choose scope within a budget but need a separate decision to change a contractual commitment. Clear boundaries are more useful than an instruction to “take ownership”.
The delay may be between the tasks
A team can be busy while very little reaches completion. The missing time may sit in review, approval, environment access, release coordination or an unresolved question. None of those queues disappears because the implementation estimate becomes more accurate.
Trace a recent piece of work from request to usable result. Separate time spent actively changing it from time spent waiting. Record why it waited, rather than treating every day outside development as the same kind of delay. Was the request incomplete? Was a reviewer unavailable? Did a commercial decision remain open?
Then examine how work enters the system. If every stakeholder can mark a request urgent, the team has no reliable way to protect the work already in progress. Starting another item can make everyone feel responsive while increasing the number of unfinished commitments.
The response might be a shared order of priorities, a limit on concurrent work, protected review capacity or an explicit rule for emergencies. These are management choices. A new board in a tracking tool can make the queue visible, but somebody still has to decide what will wait.
A dependency is a design choice to manage
Some dependencies are necessary. A shared platform can prevent duplicated effort; specialist security review can protect the business. The problem is an essential dependency treated as though it were free, immediately available and outside anyone’s delivery plan.
For the next important outcome, map the teams, systems and approvals it depends on. Distinguish a genuine prerequisite from a habit. Does this team need to approve every change, or only changes that cross a particular risk boundary? Is the shared component essential, or could a simpler interface let the work proceed independently?
There are several legitimate responses. Remove the dependency by changing the design. Reduce it through a stable interface or self-service capability. Keep it, but agree capacity and sequencing with its owner. Each option has a cost: duplication, platform investment or continued coordination. Make that trade-off explicit rather than hoping a new reporting cadence will resolve it.
Changing the organisation chart is a larger intervention. It may help when teams repeatedly need the same capabilities to complete their work. It can also move the boundary without removing the constraint. Understand the recurring pattern before rearranging the people around it.
Decision rights have to work under pressure
“We need better communication” can mean that nobody knows who is allowed to decide. More meetings then circulate the uncertainty instead of resolving it. Consultation, approval and notification become interchangeable, and a decision returns to the same group whenever someone objects.
For a recurring decision, define four things: who decides, whose input is needed, the constraints on the choice and when an unresolved issue must be escalated. Use a real decision to test the arrangement. An abstract responsibility matrix can look complete while leaving a difficult trade-off untouched.
Consider a hypothetical release with an unresolved operational risk. Engineering can explain the failure mode and mitigation; the commercial owner can explain the consequence of delay. The person accepting the residual risk needs the authority to accept its business consequences. That decision should not fall by default to whoever happens to press the release button.
Record the choice and the reason for it, including what would cause it to be revisited. This gives people permission to act within agreed limits and prevents the same debate restarting without new evidence. Escalation remains available for decisions beyond those limits, rather than becoming the route for every ordinary choice.
Change one constraint before launching a programme
A useful diagnosis should lead to something smaller and more testable than “improve collaboration”. Choose a recurring blockage, agree a plausible explanation and change the arrangement that produces it.
- Take a real slice of work. Select a recent stalled item and a comparable piece about to start. Include the people who requested, built, reviewed and supported it.
- Name the constraint. Describe the observed wait or conflict. Separate evidence from interpretation: “approval waited for an unavailable owner” is more useful than “governance is slow”.
- Agree one intervention. For example, delegate a bounded approval, reserve shared-team capacity or require a displaced priority whenever urgent work enters.
- Choose an owner and review point. Make the trial long enough to observe relevant work. Agree what would justify keeping, adjusting or stopping it.
Measure the intended effect and the possible cost. If approval is delegated, look at waiting time and whether risk remains adequately reviewed. If concurrent work is reduced, look at completion and the age of queued requests. Faster movement is not useful if failures, support burden or unfinished customer outcomes simply appear elsewhere.
Avoid treating a single improvement as proof that the whole system is fixed. Work differs in complexity and urgency, and changes in demand can distort comparisons. Combine the measures with a direct conversation about what happened and why.
Keep the technical explanation in view
Not every delivery problem requires an operating-model change. If the work repeatedly fails at the same fragile integration, investigate the integration. If recovery is slow because nobody can reproduce a fault, improve observability and diagnosis. Organisational language should not become a way to avoid a concrete engineering problem.
Often the explanations connect. A fragile component may persist because no team has permission to prioritise maintenance. A testing bottleneck may reflect both poor automation and a funding model that rewards starting features over finishing them safely. Addressing only one side leaves the other ready to recreate the problem.
The practical test is whether people have the ownership, capacity and authority to turn an agreed priority into a supported outcome. If they do, improve the engineering where it needs improvement. If they do not, asking for greater effort will leave the constraint intact.
Start with one unfinished commitment. Find where it waits. Make the next decision possible.