Rob Barrett

Find the real constraint.

A missed deadline is a symptom. The useful question is what keeps producing it. Start with the people doing the work, the decisions around them and the commercial commitments they are trying to meet.

Prototype approach detail. The activities below are suggested starting points, to be agreed around the business and its constraints; they are not a fixed assessment or promised timetable.

Follow one piece of real work.

From the original request to something a customer can use.

Choose a recent change that mattered to the business. Reconstruct how it was selected, who made the decisions, where it waited and what happened after release. Include the abandoned work and interruptions that competed with it.

A board report, a delivery plan and an engineer’s account may describe different versions of the same problem. Those differences are useful evidence. Test them against the work rather than choosing the most confident explanation.

The starting question is specific: what is preventing this business outcome, and what would we expect to see if our explanation were true?

Look across the whole system.

Each lens tests a different explanation. A slow release might involve tightly coupled software, unclear approval rights, competing commitments or several of these together.

People: can someone take the work all the way through?

Talk to engineering, product, operations and the people relying on the result. Ask who owns the outcome, who can make a decision and where work depends on a particular person.

Suggested activity: walk through the same recent change with people on either side of a handover. Compare their understanding of responsibility, available capacity and what “done” means.

Incentives: what does the organisation actually reward?

Compare stated goals with the behaviour encouraged by targets, reporting and escalation. Teams may be asked to protect reliability while being recognised only for shipping more features.

Suggested activity: examine a recent conflict between local targets. Ask what choice each team was encouraged to make, and who had authority to resolve the conflict.

Architecture: which boundaries make change difficult?

Follow the services, data and operational dependencies touched by the chosen change. Connect technical friction to its consequence: coordinated releases, difficult recovery, recurring incidents or expensive maintenance.

Suggested activity: review a system sketch alongside a recent release or incident. Check the drawing against the actual path to production. Identify which dependencies genuinely constrain the business before proposing replacement technology.

Flow: where does work wait, return or disappear?

Distinguish time spent working from time waiting for a review, environment, decision or another team. Look for excessive work in progress and repeated rework before interpreting a full backlog as a shortage of engineers.

Suggested activity: trace a small sample of completed and stalled changes using existing delivery records. Note queues, interruptions and returns to earlier steps. Treat incomplete records as a limit on confidence.

Priorities: do commitments fit the available choices?

Bring customer promises, commercial deadlines, maintenance and operational risk into the same conversation. Ask which commitments are fixed, which are assumptions and what stops when something urgent arrives.

Suggested activity: compare the current plan with actual work in progress. Identify who can change priorities and where the team is carrying incompatible expectations.

Make the explanation testable.

Discovery should narrow the uncertainty enough to support a choice.

Illustrative example, not a client story: releases are repeatedly late, so the initial request is to hire more developers. A review finds completed changes waiting for a shared approval.

That makes approval capacity a candidate constraint. It does not prove the team has enough capacity everywhere else. Check whether the queue recurs, why approval is needed and whether the reviewer is waiting on missing information.

A bounded next step could clarify approval criteria for one type of low-risk change. Review waiting time alongside rework and incidents. If work starts accumulating elsewhere, update the explanation before extending the change.

Leave with a shared account of the problem.

A useful discovery output is concise enough for the team and decision-makers to challenge together. Depending on the scope, it could capture:

  • The business outcome and commitments at risk.
  • The likely constraint, supported by observed work.
  • Alternative explanations and evidence still missing.
  • Dependencies, decision rights and operational safeguards.
  • A decision to make next, with an owner.

Enough confidence to decide

Move forward when the people involved recognise the problem, the evidence supports a plausible explanation and the remaining unknowns are visible. More investigation is useful only if it could change the next decision.

Existing incidents or urgent commitments may need action while discovery continues. Agree those immediate responsibilities explicitly, rather than letting the assessment become another queue.

Next: make the choices visible