Blocked on one architect: repairing feedback loops and the tail
A nine-person team split across Porto and Manila has a well-shaped board, respected WIP limits and sensible policies. The problem is not the board. Fourteen items are flagged blocked, with an average blocker age of 12 working days. Most wait on one solutions architect, who is also the only approver for security review. The daily standup runs 25 minutes and consists of walking every card. Replenishment happens when the product manager remembers to do it. No operations review exists; the retrospective is monthly and produces actions that recur. Measuring from commitment, p85 lead time is 55 working days against a published SLE of 40 days at 85%, and 22% of items breach. Two high-value customers have noticed. Leadership's proposed fix is to add a second architect.
1. Which feedback loops are missing or mis-cadenced, and what decision does each one own in this situation?
Read the worked answer
The board is fine; the decision system around it is not.
- Daily standup - misused. Twenty-five minutes walking every card produces status, not decisions. It should be a flow and blocker conversation: what is at risk today, what needs an owner, what gets escalated. Any item blocked more than three days should leave that meeting with a named owner and a date, or be escalated.
- Replenishment - ad hoc. A weekly, 30-minute cadence that selects from Ready against real capacity and in a written order. Right now input is governed by whether the product manager remembers, which makes commitment dates arbitrary and feeds the 22% breach rate.
- Risk review - missing. Items needing architect or security input should be reviewed two to three weeks before their commitment, not discovered when they block. This loop is precisely what turns a 12-day blocker age into a planned queue.
- Service delivery review - missing. Monthly, with the two affected customers: are we meeting 55 days or the 40-day SLE, and does the class of service match what they need? The breach should be visible and discussed before it becomes a complaint.
- Operations review - missing. Monthly, over flow metrics, blockers, dependencies and policies. The single-architect dependency is a systemic constraint; it will never be fixed inside a standup or a retrospective.
Adding the second architect without these loops just gives the queue two bottlenecks and the same 12-day blocker age.
2. The leadership proposal is to hire a second architect. How would you respond, and what would you do instead or first?
Read the worked answer
Treat it as a hypothesis to be tested with data, not rejected out of hand - but do not start there.
First, quantify the load. How many items a week need architect input, what is touch time versus wait time, and what proportion of the 12-day blocker age is queue rather than work? If the architect spends two hours a week on actual review, a second hire adds cost without removing the wait, because the wait is created by batching, undefined readiness and no priority rule.
Cheap interventions, in order:
- Limit the architect's own WIP to three items and have them work reviews rather than also carrying delivery work.
- Define readiness for review - design note, interfaces, test approach - so submitted items can be decided in one pass instead of three.
- Introduce a fixed twice-weekly review slot with a WIP-limited queue, so the wait becomes bounded and predictable.
- Delegate: write the criteria under which a senior engineer can approve without architect involvement, keeping the architect for exceptions.
Measures to judge them by: average blocker age for architect-dependent items (target under 3 days), blocked time share of lead time, flow efficiency, and p85 lead time. Because this is a tail problem, p85 should move before p50 does. If after six weeks blocker age is still above eight days and the architect's true touch time is genuinely the constraint, the second hire is justified - with a business case rather than a complaint. Meanwhile, recalibrate the published SLE to the data (55 days at p85) and set an improvement target, rather than leaving a 40-day promise the system cannot keep.
3. Design the improvement experiment to close the gap to the SLE. State the measure, the cadence and the decision rule.
Read the worked answer
Hypothesis. If architect and security review run to a fixed twice-weekly slot with a definition of ready and a delegated approval path for standard cases, average blocker age for those items falls from 12 to under 4 working days within six weeks, and p85 lead time falls from 55 to under 45 days within ten weeks, with no change to WIP limits.
Why this framing. The gap to the SLE lives in the tail: 22% of items breach, and blocked time is concentrated on one dependency. Reducing it lowers lead time at constant WIP, which raises throughput by Little's law. Hiring a person is a capacity bet; reducing waiting is a flow bet, and it is cheaper and faster to test.
Measures. Leading, weekly: blocker age by dependency, number of items in the review queue, percentage of submissions meeting the definition of ready. Lagging, monthly: p50, p85 and p95 lead time, throughput, flow efficiency, breach rate against the SLE.
Cadence. Weekly standup checks the leading indicators and clears anything blocked over three days; monthly operations review examines the distribution and decides whether to continue, adapt or stop. Keep the board policies frozen for the duration so the effect is attributable.
Decision rule, agreed in advance. If blocker age is below 4 days and p85 below 45 days by week ten, standardise the policy and move to the next constraint. If blocker age has fallen but p85 has not, the tail has another source - check readiness upstream and item size. If neither has moved and touch-time data shows the architect genuinely overloaded, fund the second role with evidence in hand.