The Insurer That Bought a Toolchain Instead of a Culture

Reasoning. Tools do not create collaboration; they automate whatever process exists. If the current process is a six-day approval queue between two floors, GitLab and Kubernetes will produce a faster, more reliable handoff, not a shared ownership model. The organisation will get automated gates with the same trust deficit baked in - and will conclude DevOps "didn't work" when lead time barely moves.

The two threatening signals.

1. The post-incident outcome. A report that stops at "operator error" is a finding about the system's design, not the person. The misconfigured connection pool was reachable, untested and undetected - that is a guardrail and observability gap. Moving the engineer off the team converts one incident into an organisation-wide lesson: concealment is safer than disclosure. With 60% of staff already saying they would not report a mistake, this single action outweighs the entire tool budget.
2. The CAB as the only trust mechanism. A weekly board exists because the organisation does not believe changes are safe by default. Buying CI/CD without replacing that control produces a pipeline that terminates in a Tuesday meeting.

Secondary but material: 22% operations attrition destroys the tacit knowledge that makes a 9-hour restore possible at all.

Conclusion. Fund the tools, but sequence culture first: the 90-day plan must change how incidents are reviewed and how change risk is classified before or alongside the first pipeline. A useful test - if the CTO cannot say what behaviour will be different on day 90, the purchase is a distraction.

Sequencing principle. Start with the interventions that unlock disclosure, then the ones that remove structural blockers, then the ones that build new habits. Doing them in the reverse order means the new habits are built on a foundation that punishes honesty.

Days 1–30 - Make it safe to speak.

• Rewrite the post-incident template: contributing factors, detection gaps, why the guardrail did not exist. Explicitly prohibit naming individuals as causes. Re-run the payments outage review under the new template and publish it.
• Indicator: percentage of reviews containing a contributing-factor analysis rather than a named person (target 100%).
• Publish a written "no blame for error, accountability for concealment" statement signed by the CTO.
• Indicator: pulse-survey question "I would report a mistake I made" - baseline 40%, target 65% at day 90.

Days 31–60 - Remove the structural blocker.

• Introduce risk-tiered change classification: low-risk changes (config, flag flips, tested code behind a flag) are approved by peer review at merge time; only high-risk changes go to a board. This is the control that makes a pipeline meaningful.
• Indicator: median lead time from merge to production for low-risk changes.
• Embed one operations engineer into each product squad, with on-call shared both ways. Indicator: share of changes reviewed by someone who also carries the pager.

Days 61–90 - Build the habit.

• Run a value-stream mapping on one service end to end, and start one team on a real pipeline as a reference implementation, not a pilot that gets abandoned.
• Indicator: deployment frequency and change failure rate for that one team.

Why this order. Disclosure without a removal of the CAB creates frustration; removing the CAB without disclosure creates unmanaged risk; a pipeline without either creates expensive theatre.

Critique. A single composite score is attractive to a board and corrosive to the programme, for three reasons.

1. It is gameable. Any weighted index invites optimisation of the inputs - running more pipelines, writing more tests, closing tickets - rather than outcomes. The moment a score becomes a target, it stops measuring anything.
2. It hides the trade-off. The four DORA measures behave as two pairs: deployment frequency and lead time measure speed; change failure rate and time to restore measure stability. A team can raise a composite score by deploying more often while change failure rate climbs. The composite cannot show that, and the trade-off is precisely the interesting conversation.
3. It implies a destination. Maturity models rank organisations against someone else's baseline. The useful question is not "how mature are we" but "is our delivery capability improving against our own trend, and where is the constraint".

What to report instead.

• The four DORA measures as a trend over at least four quarters, per value stream, with the teams' own baselines - never as a cross-team league table, which produces sandbagging.
• One or two outcome measures the board actually cares about (e.g. availability against an agreed SLO, or time to deliver a customer-visible change).
• The culture indicators, because they predict the rest: incident-reporting willingness, on-call attrition, share of changes reviewed by a peer who also carries the pager.

If a single number is politically unavoidable, report the trend and direction of a deliberately narrow measure (e.g. lead time for low-risk changes) and publish the component data alongside it. Refuse to compare the insurer's score to an industry benchmark derived from a different context.