Before you touch a single pipeline, decide two things: which piece of software you will practise on, and who will watch the clock. DevOps adoption fails most often not from wrong tools but from trying to change everything at once with nobody keeping score. This plan takes ninety days and one value stream — for the sake of a concrete example, imagine an airline booking platform: search, seat selection, payment, confirmation. The same sequence works for a crew-scheduling tool or an academy’s own student portal. Follow the steps in order; each one assumes the previous, and the clock is not a metaphor. Write the start date down.
Days 1–30: See and Stabilise
- Name the value stream. Write down every step a change takes from idea to live, including the queues where work waits. Most teams discover the wait, not the work, consumes the calendar.
- Record the baseline. Measure the panel of delivery signals — the wait from commitment to production, release cadence, recovery speed, the rate at which changes misfire, and rework, added in 2024. These are the DORA measures. No targets yet. Numbers first.
- Stabilise the worst failure. Pick the single most frequent production complaint and fix its cause properly rather than patching symptoms. Trust in the process starts here.
- Write the rollback, do not just plan it. Document how to undo the last deployment, including the database caveat: never roll back past an irreversible migration.
- Declare every deployment. Each release gets an identifier and a named owner, logged where anyone on call can find it at 2 a.m.
Nothing in this first month is glamorous. That is deliberate. Reliability work at an airline-operations standard is boring by design, and boring is what passengers experience as dependable. Resist the temptation to skip ahead to automation; automating an unstable process only produces faster chaos.
Days 31–60: Automate the DevOps Path
- Build once. The artefact that passes testing must be the same artefact that reaches production — one build, promoted forward, never rebuilt per environment.
- Automate the booking path’s tests first. Fare calculation, seat maps and payment callbacks get automated checks before cosmetic pages do. Highest-risk code earns the first robots.
- Run one rollback drill. Undo the most recent real deployment against the clock. One published account describes a 190-minute rollback triggered by a payment error, never having been drilled; a practised crew completed the identical reversal in about twenty minutes. Your first drill will feel closer to the first figure. That is the point.
- Compress feedback to roughly ten minutes. If the pipeline takes an hour to judge a change, engineers context-switch and quality drifts. Split the suite; run the fast part always, the slow part nightly.
- Introduce a feature flag on one new feature. Deploy the fare-prediction banner dark, then turn it on for a small percentage of sessions — a canary. Practice decoupling “shipped” from “visible”.
Days 61–90: Govern and Spread
- Replace manual sign-off with automated evidence. Every permission trimmed to what the task needs, OIDC credentials that expire within minutes rather than long-lived keys, and expand-and-contract schema migrations so the database always supports both old and new code during a change.
- Start quarterly sampling. Pull about ten random changes each quarter and trace each from request to production. Gaps in the trail become backlog items, not blame.
- Hold the first blameless review. Inside five working days of the next incident, ask what made the failure easy, not who caused it. Write down the systemic answer.
- Teach one neighbouring team. Adoption data favours this over mandates by a wide margin — in one published comparison, a coached pilot reached 4.25 on a five-point scale, while a central toolchain push managed 2.40 and an organisation-wide decree 2.50.
- Publish a one-page summary of the quarter. Metrics, incidents, fixes, next quarter’s single priority. Neighbouring teams copy what they can read in five minutes; they ignore what they cannot.
What Good Looks Like at Day 90
Treat the measures as instruments, the way a pilot reads a panel rather than a single gauge. The idea-to-live wait should have shrunk visibly — weeks to days is common for a first quarter. Release frequency should have risen without a rise in the misfire rate; if failures climb with frequency, the tests from days 31–60 need reinforcing. Recovery should now be measured in the minutes a drill produced. Rework tells you whether speed is real or borrowed: fast delivery that must be redone is not fast, it is deferred rework wearing a confident outfit. A fifth number, less discussed, is the ratio of emergency to planned releases; if the emergencies shrink while the planned work holds steady, the pipeline is earning trust rather than borrowing it.
Expect resistance in the middle. Automation raises the quality bar before it raises the pace, and the resulting slump — the J-curve — has ended more transformations than any technical failure. Agree at the start how long an acceptable dip may run, write it down, and refer to it when someone proposes reverting in week six. Also write down what will count as success at day ninety; a plan without a finish line drifts into a permanent initiative, which is how most of them die.
Four Ways Teams Wreck the Ninety Days
A plan deserves a list of its known failure modes.
- Skipping the baseline. Without day-zero numbers, every later claim about improvement is a story rather than a measurement.
- Automating a broken process. If the release steps themselves are unsound, faster execution only reaches the wrong destination sooner.
- Turning the metrics into a scoreboard. The moment engineers believe the numbers judge individuals, the numbers stop describing the system and start describing what people think you want to hear.
- Declaring victory at day ninety. The first quarter proves the method on one service; it does not transform an organisation. Teams that stop at the finish line slide back within two quarters.
Each failure mode has the same antidote: write the commitment down before the quarter starts, and let anyone on the team point at it when pressure arrives.
Where the DevOps Road Goes Deeper
The skills overlap heavily with reliability engineering; this practical SRE skills guide covers the operational half, while this explainer on AIOps shows where automated analysis fits once monitoring matures. For a domain example of machine assistance in aviation maintenance contexts, see AI applied to aircraft engine health monitoring — the pattern of sensors, thresholds and early warnings maps neatly onto deployment monitoring. For the complete reference behind the frameworks named here, the full DevOps explainer on the Ops Atlas consolidates the definitions, the history and the research findings in one place.
Ninety days from now the platform will not be transformed. It will be stabilised, automated and governed — which is what transformed actually means when you inspect it closely. The day-91 conversation is short: pick the next value stream, and run the same ninety days again, a little faster and with fewer surprises. One scheduling note from teams that have run this plan: pick the quarter without your peak season. The days-31-to-60 stretch asks engineers to hold a higher quality bar while output is temporarily flat, and doing that during your busiest booking window converts a normal dip into a crisis of confidence. Off-peak first quarters are the closest thing this plan has to a cheat code. The second run takes less courage, which is how you know the first one mattered.