The Pilot That Stayed a Pilot
A bank's DevOps programme has run for 14 months across a scope of 40 teams. A central platform team built a Kubernetes-based pipeline; six teams use it, the rest still deploy through the old release process. The programme reports two success measures: pipeline adoption at 15%, and 3,200 builds per month. Nobody measures lead time for changes. Developers say the pipeline requires a 40-field YAML file and takes three weeks to onboard. There is one DevOps coach for all 40 teams, and the two DevOps engineers sit in the central platform team rather than with delivery teams. Security review happens outside the pipeline and takes nine days. Management now wants to mandate the pipeline for every team by Q4.
1. Diagnose what is actually limiting adoption, and explain why a Q4 mandate is likely to produce compliance rather than improvement.
Read the worked answer
Adoption at 15% after 14 months is a fit problem, not a motivation problem. The evidence: a 40-field YAML file and three weeks to onboard mean the cost of adopting exceeds the benefit for most teams. One coach for 40 teams means the human channel for learning is saturated. Two DevOps engineers centralised in the platform team means the people who built the pipeline never feel the friction of using it. The nine-day security review outside the pipeline guarantees that even a fully automated deploy still waits, so the pipeline cannot deliver the lead-time win that would justify adopting it.
A mandate changes none of this. It changes the metric: teams will produce the YAML and run builds to demonstrate compliance while the real release path stays as it was. Adoption goes to 100% on paper, lead time does not move, and the programme now has evidence that "DevOps doesn't work here" - which is the opposite of the truth. Mandates also poison the ground for the next attempt, because teams learn that the new thing is an audit obligation.
2. What would you change over the next two quarters? Give the sequence, who owns what, and how security fits in.
Read the worked answer
Stop reporting build counts. Replace with lead time for changes and deployment frequency, even if sampled from six teams at first. If you cannot show a lead-time improvement, you have no case.
Fix onboarding before expanding. Templates and self-service defaults so a team can ship a trivial service in under a day, with sensible values pre-filled rather than 40 required fields. Target: onboarding cost below one day.
Move the engineers. Embed at least two DevOps engineers with delivery teams for a quarter, rotating, so the platform team receives real feedback instead of requests.
Bring security into the pipeline. SAST, dependency scanning and policy-as-code as automated gates, with a security engineer assigned to the platform team. Measure the share of changes that reach production without a manual security review. Nine days is a flow problem for security as much as for Dev.
Then scale to twelve teams, chosen by willingness and pain, with the coach attached to them rather than spread thin.
Sequence matters: usability first, then security, then expansion, then the mandate - by which point it should be unnecessary.
3. Which of the programme's reported successes are DevOps in substance and which are branding? Judge both metrics.
Read the worked answer
"3,200 builds per month" is branding. It is an activity metric with no defined relationship to value. A team can triple it by running nightly builds of untouched branches, or by splitting one pipeline into twelve, and nothing improves for users. It measures the platform team's output, not the bank's flow.
"Pipeline adoption 15%" is closer to real but still incomplete. It counts teams using a tool, which is a means. If those six teams deploy no faster and recover no quicker, adoption is a fact about tooling, not about DevOps. Adoption should always be reported alongside an outcome for the adopters - otherwise it invites the mandate that just failed.
DevOps in substance here would be: lead time from commit to production, deployment frequency, change failure rate, MTTR, and the degree to which teams can self-serve an environment or a deploy without a ticket. Those are the measures that tell you whether the wall between build and run has actually come down.
A useful test for any reported metric: could it improve while the customer experience stays identical? If yes, it is a programme metric, not a DevOps result.