The DevOps Centre of Excellence That Reviews Everything
Meridian Bank created a 12-person DevOps Centre of Excellence (CoE) 18 months ago. The CoE built a shared Jenkins/Argo CD pipeline and supports three pilot teams. Results are mixed: those teams deploy about 2.5 times more often than before, but the change failure rate is 22% and mean time to restore is nine hours. The change advisory board (CAB) still meets weekly and requires 15 working days' lead time for any production change; 70% of releases need a CAB exception. The CoE writes all pipeline templates and reviews every pull request that touches deployment configuration. Two pilot teams have started a shadow wiki titled 'how we actually deploy', updated only after hours. The CIO wants to roll the model out to all 14 delivery teams next quarter and asks you whether the pilots 'prove DevOps works here'.
1. Is the pilot evidence sufficient to scale to 14 teams? Assess it using outcome measures and justify your verdict.
Read the worked answer
Not sufficient, and not because 'DevOps doesn't work here'. The pattern is automating delivery without changing the constraint above it.
- The metrics are a balanced set, not a menu. 2.5x deployment frequency with 22% change failure rate and nine-hour MTTR means throughput rose while the system's ability to absorb change did not. Scaling that to 14 teams multiplies blast radius, not value.
- Lead time is still 15 days of CAB. If the pipeline is fast but the approval queue is not, the pilots never exercised the genuinely risky part of the change process. There is no evidence about how teams behave when they can deploy on demand.
- A 70% exception rate means the standard change process is unusable. The 'control' the organisation cites is fictional; scaling it scales workarounds and exception debt.
- The shadow wiki is the strongest signal in the data. Teams are solving a problem the CoE owns, covertly. That is knowledge not flowing through the intended channel, and it will not survive a 14-team rollout.
The pilots prove a pipeline can be built, not that the organisation can absorb it. Treat the three teams as a learning cohort, add two or three more deliberately, and gate further expansion on change failure rate and MTTR holding steady or improving for a full quarter.
2. What organisational changes would you make to address the CoE bottleneck and the shadow wiki, and what risk does each carry?
Read the worked answer
Two structural problems: central control of the means of production (CoE writes every template, reviews every deployment pull request), and change control disconnected from actual risk.
- Platform as a product, not a gatekeeper. Move from 'CoE builds, teams consume' to a platform team publishing versioned, self-service golden paths with policy-as-code. Risk: teams can now break things without a CoE review. Mitigate with safe defaults, automated policy gates, and templated but extensible pipelines. The CoE's review role must become an API, not a queue.
- Risk-tiered change management. Classify by blast radius and reversibility: standard changes (feature-flagged deploys, config, routine non-destructive migrations) auto-approved with automated evidence; CAB retained for irreversible or regulator-relevant changes. Risk: auditors may reject it, so map each class to a written control and get compliance sign-off before announcing it.
- Make the shadow wiki redundant rather than forbidden. Publish a 'how we deploy' contract and let the teams who wrote the wiki own the documentation. Banning it drives knowledge further underground and destroys your best source of truth about what actually happens.
- Treat headcount as a constraint signal. Twelve CoE staff serving three teams is not a platform; it is a bottleneck with a large budget. Reduce human review to automated checks so the group can serve 14 teams without growing.
The failure mode to avoid is announcing self-service while still requiring CoE sign-off, which combines the worst of both models.
3. Sequence the next six months. What happens first, and what numbers gate each step?
Read the worked answer
Months 1-2 - Evidence and change control. Run a review of the pilot's change-failure incidents and classify each by whether the CAB or the pipeline would have caught it. That answer determines whether the CAB buys any safety at all. In parallel, measure lead time end to end (approved idea to production), not just deploy frequency. Do not announce a 14-team rollout yet.
Months 2-3 - Redesign change classes. Propose three classes with automated evidence attached and get risk and compliance to sign off in writing. Nothing else works until this lands, because self-service without a legal change path is theatre.
Months 3-4 - Publish the platform. Release versioned self-service pipeline templates with policy-as-code, and retire CoE pull-request review for teams that pass the automated gates. Onboard three more teams chosen deliberately: one willing, one sceptical, one high-risk.
Months 4-6 - Extend to eight teams, not 14. Add in cohorts of three, gated on change failure rate below 15% and MTTR below four hours sustained for a quarter, plus a falling CAB exception rate.
Throughout, report the four delivery metrics alongside two adoption-health indicators: CAB exception rate and the number of shadow processes discovered. Define the expansion gate in numbers before anyone is promised a date.