When Delivery Slows and the Cause Sits Upstream

← Playbooks

Playbook · Recurring decision delay · Organisations × Technology

Delivery delay is often the visible end of an unresolved decision. This is a way to check whether that is what you are looking at before changing how the team works.

This is reusable guidance, not a record of what happened and not a procedure. It is a starting point for a situation that recurs in different forms — useful while its conditions hold, and worth abandoning where they do not.

The situation

A roadmap keeps slipping. The engineering work does not look unusually hard, estimates were not obviously wrong, and the team is not idle — yet dates move anyway, and each explanation is local to the week it happened.

The question

Is the constraint the execution of the work, or the resolution of the decisions the work depends on?

Conditions

What needs to be true, or examined, before this approach applies.

• Delay repeats across different teams and different kinds of work, rather than sitting with one team.
• Work has started before its surrounding decisions were named, owned or dated.
• Rework is visible — direction reversed after implementation began.
• There is somewhere decisions can actually be recorded and returned to.

Signals

What is worth paying attention to.

• How often direction is revisited after implementation starts.
• Whether pending decisions have a named owner, or only a discussion thread.
• How much of a delivery meeting is spent re-establishing context.
• Where work waits: on capacity, on dependency, or on an answer.

Decisions

What may need to be decided, and by whom.

• Which decisions genuinely need to precede work, and which can be taken during it.
• Who owns each pending decision by name, not by function.
• What the organisation does when a decision is not taken in time.
• Whether decision resolution is a distinct cadence or an item inside delivery meetings.

A first useful move

Write down the decisions that current work is waiting on, with an owner and a date beside each. The list alone usually shows whether the constraint is decisions or capacity — and it is worth doing before changing anything about process.

Not yet

Do not restructure teams, change methodology or add reporting yet. All three are expensive, all three are hard to reverse, and none of them resolves an unmade decision.

The trade-off

Separating decision work from delivery work makes accountability visible, which some organisations experience as exposure rather than clarity. Named ownership can slow decisions in the short term while people become willing to hold them.

Assumptions

What this rests on, and what would change it.

What informed this

Repeated observation across delivery environments, and the reasoning recorded in the observed situations linked below. What informed this guidance is a pattern, not a measured effect — no controlled comparison exists.

What would change this approach

This reads differently if decision authority sits outside the organisation, if the team is small enough that decisions and delivery share the same people, or if delay concentrates in a single technical dependency. In those cases the constraint may be real capacity or real ownership, and the approach here would mislead.

Where this stops being useful

It stops being useful once decisions are consistently named and owned and delay continues. At that point the question is genuinely about capability, architecture or capacity, and this guidance has nothing further to offer.

Related

Related reading

Industry

• Retail
• D2C
• Enterprise SaaS
• Consumer Technology

Knowledge · Architecture

• Separating decision cadence from delivery execution

Evidence · Observed Situation

• When every team had a dashboard and no team had a decision
• When the platform was the reason decisions felt expensive
• When unrelated frustrations turned out to share one structural cause

The situations linked above informed this guidance. They do not establish that it transfers to another environment — that remains a question about the specific organisation.

Knowledge →Work with Cralgo →