Two DevOps Kickoffs Compared: Cheerful Roadmap vs Pre-Mortem

Two companies hired consultants in the same month to move their delivery pipelines to a new platform. Both had similar budgets, similar-sized teams and a similar deadline. One kicked off with a cheerful all-hands and a roadmap full of green arrows. The other began with an unusual afternoon: the consultant asked everyone to assume the transformation had already gone badly and to say why. Months later the contrast between the two was striking, and it had little to do with technology. This piece compares the two starts, because the difference is a lesson in DevOps consulting that fits on a single page.

Company A: the confident kickoff

Company A’s leadership wanted momentum. The kickoff had a slide with the target state, a timeline and a list of benefits. The consultants were skilled, the sponsors were enthusiastic, and nobody said a negative word, partly because a negative word at that meeting felt like volunteering to be the problem.

The trouble arrived in small pieces. The team that owned the old build servers was never really asked what those servers did beyond the obvious. One of them quietly produced a nightly report that a finance analyst used. When the servers were retired, the report disappeared, and nobody connected the two events for weeks. Meanwhile, a few engineers believed the migration deadline was fixed by a compliance date, while managers believed it was a soft target. By the time those beliefs collided, the schedule had no slack left.

None of this was dramatic. It was the ordinary friction of a plan whose assumptions were never said aloud.

Company B: the kickoff that began with failure

The consultant at Company B opened by handing out cards and saying: “Imagine it is the end of next year. This transformation failed. Write the reasons in the past tense.” She gave them six minutes. Then she read the cards aloud, without names, and the room fell silent, and the silence was productive.

The cards were specific. “The old servers did jobs nobody documented.” “Two teams thought they owned deployment approvals.” “We trained people after cutover, not before.” “Our best engineer, the only one who knew the legacy scripts, left.” “The budget covered the platform and not the months of parallel running.” That last card became a line item before the end of the week.

Side by side

• What was surfaced: Company A learned about hidden duties of old systems after retiring them; Company B found them while the old systems were still running.
• Who spoke up: At A, the loudest voices were sponsors. At B, anonymous cards gave the quiet engineers an equal say.
• How risks were treated: At A they lived in individual heads. At B they sat on one page every item carries a responsible person and a deadline.
• The budget: A funded the new platform. B funded the platform and the overlap period, because the pre-mortem exposed the gap early. For anyone sizing a programme like this, the guide to putting together a transformation budget is a useful companion.
• The mood: A felt hopeful and was later startled. B felt slightly sober at the start and rarely startled afterwards.

Why the quieter start won

It would be easy to say Company B simply had a better consultant. The real difference was structural. A pre-mortem converts private worry into shared information at the exact moment when changing the plan is cheap. It also changes the social rules: raising a risk stops being criticism and becomes the assignment.

Company A did eventually run a review, a few months in, when problems were already visible. That review was useful, but it was a post-mortem in the ordinary sense, held when the cost of every fix had grown. Company B’s version cost one afternoon and some index cards.

A note from the security side

Teams that harden delivery pipelines already think this way, and their writing is worth a skim even if security is not your brief. The blog at DevSecOps Now comes from a DevSecOps site and concentrates on securing CI/CD pipelines, which is another way of asking where a delivery path could break before you trust it.

Borrowing the format for your own engagement

You do not need a consultant to do this, though one can facilitate. A workable agenda fits an afternoon:

1. Open with the goal of the transformation in two sentences.
2. Hand out cards and ask for failure stories, in the past tense, written silently.
3. Read the cards aloud without names and cluster them.
4. Vote for the three clusters that would hurt most.
5. Assign an action, an owner and a date to each, and agree when the group will look at the page again.

It also helps to keep the output next to your engagement plan. The article on how a good consulting engagement moves from early discovery to handing skills to your staff describes where such a page naturally fits, since early assessment is when the cards are freshest.

When a pre-mortem is not enough

It will not catch everything. People cannot imagine failures they have no experience of, so a group of newcomers will produce a thin list. Mix in someone who has lived through a messy migration, or invite an outsider for an hour. Also expect some cards to be wrong; the purpose is to find the few that are right early enough to matter.

Finally, remember that a pre-mortem gives you a list, not a guarantee. The value comes from what you do with the list, which is why every card needs an owner.

The one-line takeaway

Both companies wanted the same thing. One planned for success and was surprised; the other planned for failure and was mostly calm. If you are about to begin a transformation, spend the first afternoon on the second approach.

Kabir Malhotra