The pager went off at 03:12 on a Tuesday, and by 03:15 Rhea had already guessed which service it was. Meridian Signal, the small AIOps vendor where she led platform engineering, sold anomaly detection that watched other companies’ IT estates. That night, its models had flagged a “novel behavioural pattern” which turned out to be their own new release, clogging their own ingestion queue. Twenty-two engineers woke up. Six knew how to revert. The incident became the story the team still tells, and the reason they finally gave DevOps an honest hearing.

Life before DevOps: six-week releases and tribal knowledge

Nothing about Meridian was reckless. The code was careful, the models were good, the customers were patient. But a release took six weeks to travel from a developer’s branch to the production cluster, deployments needed two specific people in the room, and the rollback procedure lived partly in a wiki nobody updated and partly in one architect’s head. Alert noise made it worse: so many threshold alarms fired that real signals drowned, which is an ugly irony for a company whose product is signal.

The first honest measurement hurt. When the team finally baselined its delivery metrics, lead time sat at forty-one days, deployment frequency at roughly one release every six weeks, and time-to-restore was anybody’s guess, because recovery had never once been timed. Change failure rate was easier: about one release in three needed a hotfix. None of these numbers was shameful for a company of Meridian’s size, and that was the uncomfortable part. The team had assumed its problems were personal. The metrics said otherwise. They were ordinary, structural and — more encouraging still — exactly the kind that respond to DevOps practice rather than to heroics or headcount.

The word DevOps finally arrives in a retro

At the blameless post-incident review — held, as their new process required, within five working days — someone finally said the quiet part out loud: the problem was not effort but the road between finished code and running software. Rhea spent an evening with a detailed DevOps encyclopedia entry and came back the next morning with a single slide. The discipline, she reported, was none of the things vendors sell: no tool, no job title, no separate team, no product — just a way of organising delivery so builders and operators pursue shared goals with shared tooling and constant feedback, moving changes to users fast, safe and on repeat.

“So it’s culture,” said Marcus, the on-call lead. “Culture with deadlines,” Rhea said.

The experiment: three ways to change a company

Meridian considered three routes, the same three most teams consider. Buy a shiny toolchain centrally and mandate its use. Issue an organisation-wide DevOps mandate from the top. Or pick one value stream — the ingestion pipeline that had burned them — and pilot there with an enabling coach. The published adoption research gave them reason to choose the third: the pilot route scored 4.25 of 5 in effectiveness, while a central toolchain-first push managed 2.40 and the organisation-wide mandate 2.50. The numbers matched their instincts. Tooling alone had already failed them twice.

The pilot worked like this. One value stream — ingestion — got an enabling coach two days a week. The team mapped how a change actually travelled, queue by queue, and were genuinely surprised to find the code spent most of its life waiting. They collapsed the branch model back to a single trunk, folded a four-step approval gate into one automated gate with a proper audit trail, and agreed that every commit would earn build-and-test feedback inside ten minutes. Nobody worked longer hours. The coach’s main contribution, Marcus admitted later, was asking why each waiting step existed and declining to accept “it always has” as an answer.

The dip nobody had budgeted for

The first fortnight felt wonderful. The pilot group merged small changes daily, and the team celebrated their first same-day deployment with cake. Then came the dip. As automation tightened, test expectations rose, and the pipeline that had cheerfully shipped untested code began refusing work that used to sail through. Throughput fell. Two engineers asked, only half-joking, whether the old way might return.

What saved them was a promise made on day one: the team had put it in writing beforehand that a performance dip was acceptable for three weeks. When the J-curve arrived on schedule — quick wins first, then the slump while automation raises the bar — nobody panicked, because the dip had a name and an expiry date. By week five, feedback on any commit landed in under ten minutes, and lead time had started falling for real.

What actually changed on the wall

Ask Marcus what shifted and he points at the board by the coffee machine:

• Trunk-based development, with branches that live hours, not weeks.
• One build per change, promoted unchanged from staging to production.
• Feature flags, so dark launches and instant toggles replace emergency redeploys.
• Canary releases for the models, scored on live traffic before full rollout.
• Five metrics reviewed weekly: lead time, shipping frequency, restore time, failure share, and rework rate — that fifth measure entered the DORA set in 2024.

Just as instructive was what Meridian refused to do. They did not create a permanent “DevOps team” that would own deployments on everyone’s behalf — the most reliable anti-pattern in the field, since it rebuilds the old silo under a new name. They did not turn the fresh metrics into a leaderboard, because the moment numbers become targets, teams optimise the number instead of the outcome. And when the next incident arrived, they resisted the reflex to bolt on approvals; heavyweight change boards are what the DORA research associates with worse performance, not better. Governance went into the pipeline instead, where it runs in seconds and never gets tired.

The night it paid off

Eight weeks in, a release did the same thing the Tuesday incident had done, but this time the deployment carried an identifier and a named owner, the rollback had been drilled twice, and no irreversible migration had run. Recovery took nineteen minutes. The next morning’s review produced no villains and three pipeline fixes. If you want the same arc for your team, the beginner’s DevOps roadmap lays out the sequence, bringing AIOps into an IT team covers the monitoring half, and this guide to real-time problem solving is the one Rhea made every new hire read.

Rhea’s summary, delivered over terrible coffee: the models never fixed the pipeline, and the pipeline never fixed the culture. The team did both, in ninety days, one rehearsed Tuesday at a time.