Northbridge Freight: doubling deployment frequency without adding people
Northbridge Freight runs a 1,200-person logistics business on a customer portal and driver app built by a 90-person IT group. After a digital-native competitor began releasing weekly, the board mandated that deployment frequency double within two quarters with no extra headcount. Current performance: quarterly releases, 74 days from approved idea to production, a 22% change failure rate, nine-hour mean time to restore, and 96% staff utilization. Twelve approval gates sit between a change request and production, and the shared test environment is booked in two-week slots. The CIO proposes a 'fast-track' that skips security review for changes teams label low-risk, plus 10% overtime. Engineering managers support the mandate but say they are already at capacity, and that every gate exists because of a past audit finding.
1. The board's mandate is to double deployment frequency. Using high-velocity IT concepts, explain why the current operating model cannot meet it by adding effort, and why utilization is the wrong target.
Read the worked answer
The mandate conflates speed with flow. High-velocity IT is about delivering value quickly, relentlessly, with precision and acceptable risk under VUCA conditions - not about squeezing more activity out of the same process. At 96% utilization the constraint is queueing, not effort: by Little's law, lead time rises with work in progress, and a 74-day lead time against hours of actual work means most elapsed time is waiting for approvals and test slots. Large batch sizes, forced by twelve gates and two-week test bookings, also explain the 22% change failure rate and nine-hour recovery. Adding overtime raises utilization further, increases WIP and error rates, and makes the system more fragile, not faster. The competitor's weekly releases come from smaller changes and automated controls, not from a harder-working version of this model.
2. Evaluate the CIO's two proposals against high-velocity IT principles and recommend the first three actions.
Read the worked answer
Both proposals fail the same test: they treat speed and risk as a trade-off instead of designing controls into the flow. Skipping security review does not remove risk, it defers it to production where it is more expensive and harder to see. The high-velocity approach is proportionate, automated control: pre-authorize low-risk standard changes behind automated tests, security scanning, peer review, feature flags and one-click rollback, and keep human review for genuinely high-risk change. The overtime proposal compounds the utilization problem and raises ethical and wellbeing concerns; it also reduces the learning capacity needed to improve. Recommended first actions: map the change path with the people who work in it, separating touch time from wait time; cut batch size with trunk-based development and an automated test pipeline; decouple deploy from release using flags. Replace utilization on the board dashboard with lead time, deployment frequency, change failure rate and MTTR.