Nobody at the academy called it DevOps on day one. On day one, Priya from the front desk was on the phone again, apologising to an instructor whose double-booked simulator slot had just collapsed into a scheduling clash. The app behind the mess — SkyDesk, the little booking tool three staff members had built in their spare time — was loved and feared in equal measure. This is the story of what happened over the six months after someone finally asked why, told here in case your own team recognises the opening scene. The names have been changed with affection, and the details are as accurate as memory and sticky notes allow.
Week One: The Whiteboard Told the Truth
The academy’s IT lead, Marcus, did something unusual for a first meeting: nothing. He put a whiteboard in the staff room and asked everyone to add a sticky note whenever SkyDesk misbehaved, for one full week. By Friday there were forty-one notes. Release anxiety dominated — the app was only updated during half-term because nobody trusted the process — and half the notes described the same three problems: slots vanishing, slow searches, and a “weird flag nobody dares remove”. That week of listening became the case study’s most repeated lesson: watch before you fix. Marcus later admitted he had arrived with a three-month plan and threw most of it away on Thursday, because the notes described problems he had not thought to ask about. He also did something the team still teases him about: he added the first note himself, describing an outage he had caused two years earlier. Permission, it turns out, is set by whoever goes first.
The Turning Point: Five Letters, Read Slowly
Marcus had been reading about CALMS — Culture, Automation, Lean, Measurement, Sharing — and mapped each letter onto the whiteboard evidence. Culture: the person who broke the booking rules last spring had been quietly frozen out of deployments, so nobody reported near-misses anymore. Automation: there was none; updates were manual file copies. Lean: work arrived in giant batches at half-term. Measurement: nobody knew how often the app actually failed. Sharing: build knowledge lived in one head, which was on holiday during the worst outage. Five letters, five honest gaps. The team picked two — sharing and measurement — because those needed no budget, only agreement, which happened to be the scarcest resource at the academy that term. Choosing two was not timidity. Every framework version of this story says the same thing — a team that changes five things at once learns nothing about which one worked.
Month Two: The First Scary, Wonderful Weekly Release
Sharing came first. The three builders taught two front-desk staff how deployments worked, wrote the steps on the wall beside the whiteboard, and agreed that anyone could trigger an update with a second person watching. Measurement came next: a simple counter of failures per week, reviewed over coffee, no names attached. Then, in week six, came the experiment — release one small improvement every Friday instead of everything at half-term. The first Friday release, a fix to the reminder emails, shipped in nine minutes and broke nothing. Priya described the mood as “strangely anticlimactic”. That is precisely the point: a good release should be the least interesting thing that happens all week. There was also cake. The team insists this was coincidence; the repeatable pattern of cake on release days suggests otherwise, and nobody has been willing to run the control group.
The Parts That Did Not Work
An honest account owes you the failures. The attempt to automate the simulator-usage report was abandoned entirely; the report’s logic turned out to live in one instructor’s head, and writing it down became a three-week detour nobody had budgeted. The first attempt at a blameless review failed in a different way — everyone was so polite that nothing was learned, and Marcus had to explain that blameless does not mean silent. And the team never did solve the shared-calendar confusion with the ground-school office, which was a people problem wearing a software costume. Six months of practice bought them a system that fails rarely and recovers fast. It did not buy them an organisation where every problem is a technical one, and it was never going to.
The DevOps Dip Nobody Warns Them About
Month three was harder, and any honest case study has to say so. Automating the release steps meant writing checks for the scheduling rules, and writing checks exposed how many undocumented quirks the app carried. Progress slowed while the team cleaned up its own past — the J-curve that delivery researchers describe, where small victories give way to a flat stretch that feels like going backwards, until the real climb starts. There was a tense meeting around week ten when someone suggested going back to half-term releases. What saved the effort was a promise made in month one: the dip was expected, it had a name, and it had an agreed maximum length. They agreed to hold until the end of the quarter. The climb began two weeks later, which nobody would have seen if they had quit on schedule.
Month Six: What DevOps Practice Changed
By month six the sticky notes had thinned to a handful a week. The visible changes were modest and real: problems reported in the morning were usually fixed by the afternoon; a bad update in March was reversed in under half an hour because the undo steps had actually been rehearsed, twice, on a quiet Thursday; and the infamous weird flag had been safely removed once automated checks could prove nothing depended on it. Nobody had been hired. Nothing expensive had been bought. The DORA framework the team later discovered — the measures for how fast work ships, how often, how quickly things recover, how rarely releases misfire, and how little gets redone — would have given their coffee-counter numbers a fancier home, but the behaviours came first, as they usually do. The tools they eventually adopted would have meant nothing to a team that had not first agreed to share its failures. The counter also caught something nobody planned for: weeks with zero failures began feeling unremarkable, which is the entire achievement in one sentence. The fuller framework behind their experiment, from the history to the measures, is collected in the Ops Atlas DevOps reference page, which Marcus taped to the staff-room door.
The quietest change was the most telling. Students stopped hearing “the system is down” from the front desk, and started hearing “done”. Priya kept the counter running anyway, on the principle that trust is easier to keep than to rebuild.
What SkyDesk Would Tell Your Team
- Watch for a week before changing anything; the sticky notes are your real backlog.
- Start with sharing and measurement — they cost nothing and open the door to the rest.
- Shrink the release until it is boring; boring is what dependable feels like.
- Name the dip in advance so nobody panics in week ten.
- Rehearse the undo, because an unpractised rollback is a story, not a plan.
- Keep reviews blameless, or people will stop telling you about the near-misses.
Marcus’s own addition, taped under the list: slow is fine, hidden is not.
That is the whole case study. A fragile app, five letters, one agreed dip, six months. The academy still calls it “the SkyDesk fix”, which Marcus finds funny, since the software changed less than the people did.