The Thursday CAB and the 23-Day Lead Time
Northwind Mutual, a life insurer, runs 14 application teams. A one-line pricing fix enters the change advisory board queue on Monday and is approved - or bounced - at the Thursday CAB meeting. Median lead time from code complete to production is 23 days, of which only 6 are actual build and test work. A 9-person Ops team deploys for all 14 teams and maintains a 40-page runbook. Last quarter 31% of production changes caused an incident, and mean time to restore was 7 hours. Dev calls Ops slow and bureaucratic; Ops says Dev throws untested code over the wall. In response the release manager added a second approval gate and a mandatory 10-day soak in pre-production. Nobody has measured how often the soak period has actually caught a defect.
1. Separate cause from consequence in this setup: which symptoms are the structural cause, which are downstream effects, and which proposed action treats only a symptom?
Read the worked answer
The structural cause is the handoff boundary plus the queue it creates. Dev finishes work and Ops, a separate 9-person team, decides when it ships. The weekly CAB cadence turns every change into a waiting item, and the 40-page runbook is evidence that operational knowledge lives on one side of the wall.
The numbers confirm this: 23 days of lead time against 6 days of actual work means roughly 17 days are queue. That is the wall of confusion measured, not described.
Downstream effects are the 31% change failure rate and the 7-hour restore time. Both are what you get when changes are large (they wait, so people bundle more into each one), when the person who wrote the code is not the person who fixes it at 3 a.m., and when verification happens far from the commit.
The second approval gate and the 10-day soak treat the symptom - perceived riskiness - by adding more waiting. Neither adds information about the change, and the soak is unmeasured, so it is delay with no proven detection value.
2. Evaluate the release manager's two measures using DevOps reasoning about lead time, batch size and feedback. What would you do in the first 90 days instead?
Read the worked answer
Second approval gate. A gate adds queue time and no information. Worse, it changes behaviour: because approval is expensive, teams bundle more work into each submission, so batch size grows. Bigger batches are harder to verify and harder to localise when they fail, which pushes the change failure rate up, which then justifies more gates. That is a reinforcing loop in the wrong direction.
Ten-day soak. This deliberately delays feedback by ten days. Feedback that arrives ten days after the commit teaches almost nobody anything, and an unmeasured soak cannot even be shown to work - if it rarely catches a defect, it is pure delay.
First 90 days: instrument lead time and the share of it spent waiting; replace CAB approval with automated policy plus peer review for low-risk changes on one pilot team; give that team pager duty for its own service; review the last ten incidents blamelessly; convert the most-used runbook pages into automated checks. Expect lead time to fall first, change failure rate later.
3. Would buying a modern CI/CD toolchain and a deployment tool fix Northwind's problem? Answer using the CALMS dimensions.
Read the worked answer
Automation alone would not fix it, and CALMS shows why the other letters are load-bearing.
Culture: the setup is a blame split - Dev says Ops is slow, Ops says Dev is careless. A tool does not change who is accountable for production. Until the team that writes the code also carries the pager, the wall survives the pipeline.
Automation: yes, a pipeline is necessary. It makes verification fast and repeatable and it removes the manual deployment step. Necessary, not sufficient.
Lean: the binding constraint is the queue, not the tooling. If the CAB still meets weekly and Ops still owns the deploy button, an automated artifact simply waits in a different queue.
Measurement: nothing here is measured - not lead time, not change failure rate, not soak effectiveness. Without that, nobody can tell whether the tool helped or hurt.
Sharing: the runbook encodes knowledge Ops will not give up. Tools help only when that knowledge is shared and automated.
A pipeline is a good second step. The first is removing the handoff and the queue.