Northline Retail: the CAB queue is the constraint

Start with the constraint, not with the CAB itself. The symptom mix (18-day queue, 25% emergency changes, 61% change-related incidents) points to two linked problems: risk assessment is centralised and manual, and deployment and release are coupled, so every batch carries forced risk.

First 60 days:

1. Map the change value stream end to end - from commit to customer-visible outcome - and measure lead time, flow efficiency and % complete-and-accurate at each step. This converts opinion into a baseline the CTO can hold you to.
2. Split the change model by risk, not by habit. Define standard changes that are pre-authorised (routine config, feature flags behind toggles) with automated checks as the control; keep a normal path only for genuinely novel, high-blast-radius changes; keep emergency for real emergencies and track emergency rate as a health metric.
3. Decouple deploy from release so small batches can ship daily while features stay dark until business readiness.

Sequence matters: automating a pipeline before the risk model is split just accelerates bad batches. Agree the target metrics with the CTO on day one, because this will look worse before it looks better.

Abolishing it addresses the wrong thing. The CAB exists to answer one question: who has the authority to accept this risk, and on what evidence? Removing the forum does not remove the question - it just pushes the decision somewhere unrecorded, which is worse for audit and for learning.

The defensible move is to redistribute authority rather than delete it:

• Delegate change authority to the teams closest to the work, with defined limits (e.g. a team lead may approve changes to their own services up to a stated blast radius).
• Replace review with automation and peer review where the evidence is machine-checkable: tests, security scanning, canary analysis, feature flags.
• Reserve the CAB for cross-service, irreversible or regulatory changes - likely a small fraction of 47 per week.
• Define an escalation route for the residual judgement calls.

Risk to flag explicitly: delegated authority without a rollback capability is just distributed blame. If median recovery is 6 hours, teams cannot safely self-approve; recovery time is the enabling precondition, so shrink it in parallel. Also check with audit early - delegated authority must still leave evidence, and retrofitting that later is painful.

Use a small set that captures both speed and stability, because improving one at the expense of the other is the classic failure mode here:

• Lead time for changes (commit to production) - the 18-day queue should fall.
• Deployment frequency - the CTO's headline goal, but meaningless alone.
• Change failure rate - the 61% figure, tracked as a proportion of all changes.
• Failed deployment recovery time - replacing the 6-hour median.
• Emergency change proportion - a direct read on whether the normal path is usable; if this stays at 25%, the redesign has failed regardless of deployment frequency.

How they mislead: deployment frequency can be inflated by counting trivial config pushes; change failure rate can be gamed by classifying failures as incidents rather than change-related, or by shrinking what counts as a change; recovery time improves if teams roll back fast and never diagnose, which hides defects rather than fixing them. Countermeasures: define each metric's counting rules in writing with the teams, pair every speed metric with a stability metric, sample-audit the classification monthly, and review trend plus distribution, not averages. A rising emergency-change rate alongside good deployment numbers is the tell that the change model is still hostile.