The software crew at Meridian Flight Academy is five people keeping a scheduling, logbook and billing platform alive for forty instructors and a few thousand students. Late last spring, their release calendar had quietly collapsed: changes that took two days to write took three weeks to reach the flight line. Their lead, a former charter dispatcher named Priya, had neither budget for new tools nor patience for another theory. What she ran instead was a single quarter of DevExOps — measure how the work actually feels and actually flows, prioritise the worst frictions, hand each fix to a named owner, and verify the result with the same numbers. This is that quarter, told plainly, because almost every small team will recognise it.
Where the DevExOps Story Starts: Stop Guessing
Priya’s first move was not a tool purchase. It was a decision to replace adjectives with timestamps. The team argued constantly about what was slow — the build, the reviews, the staging environment, the third-party payments sandbox — and arguments without data end when the loudest voice gets tired.
She picked one question a decider could act on: why does a small change take three weeks to reach production? The academy’s operations director cared about that number, which mattered; a question with an interested executive behind it becomes a finding with a budget, while a question without one becomes a slide.
One honest caveat she noted in her opening memo: DevExOps is a working label, not a certified standard — no canonical definition exists. Her summary of the practice came from the Ops Atlas entry on DevExOps, and she kept the caveat in the memo so nobody later sold the directors a “certified framework”.
Week One: Counting Instead of Arguing
The crew spent a week wiring up measurements they mostly already had:
- Build duration for the main platform, recorded per run.
- CI queue time by hour of day — which turned out to be the quiet scandal of the quarter.
- Review response time, from pull request opened to first substantive comment.
- Onboarding trail: the steps a new hire walks from contract to first merged change.
Alongside the timestamps they ran a short survey — the same five questions they agreed to repeat each quarter, so answers would stay comparable. Two questions later earned their keep: “In the last week, how often did waiting interrupt something you were doing?” and “Is there a tool you quietly avoid?”
Priya was careful about trust here. Survey answers were collected at team level, never individual, and she said so in writing before the first round. People answer honestly only when they believe the numbers will not be used against them — the same reason crews file safety reports without fear of blame.
What the Numbers Said
The findings were unglamorous and useful.
First, the CI queue. Median wait looked fine — three minutes. But the ninetieth percentile was thirty-one, and the queue-by-hour chart showed the cause: every instructor-facing job scheduled itself for nine in the morning, exactly when developers pushed their changes. The medians had been hiding the whole story.
Second, reviews. One senior engineer was receiving sixty percent of review requests because he owned the payments module, and his median response was two days. Nobody had chosen that policy; it had simply accumulated.
Third, onboarding. The last two hires had taken nineteen and twenty-three days to merge anything, and eleven of those days were access requests — accounts, VPN tokens, sandbox credentials — processed one polite email at a time.
Fourth, the survey contradicted the logs on one point: everyone insisted the staging environment was slow, while the timestamps showed it answered in under a second. Priya refused to referee. The disagreement itself went on the list, and a day of paired debugging later found the real culprit — a monitoring agent on a developer laptop, not the environment at all.
Assigning Owners Like a Pre-Flight Checklist
The team turned four findings into four owned actions, and the format mattered more than any tool. Each row read: finding, owner, success bar, check date. Nothing went on the list without a name beside it. Two rows nearly died there — the sandbox latency nobody wanted to own and a documentation wish with no sponsor — and Priya shelved both rather than teach the team that surveys float into a void.
The fixes were correspondingly unheroic. The queue problem needed one person to stagger the scheduled jobs, an afternoon of work once someone was actually assigned. Reviews needed a rota and a nudge bot that commented politely after four working hours. Onboarding needed a single checklist page and pre-approved account templates — and anyone who has ever followed a cockpit layout guide as a beginner knows what a good checklist does for a newcomer’s first week: it turns a mystery into a sequence.
The DevExOps Verification Problem Nobody Warns You About
Here is where the quarter got instructive. Six weeks in, review response time had halved and onboarding had dropped to six days. The queue fix looked good too. But Priya had written the success bars before the fixes — “a first substantive review comment inside four hours, in nine cases from ten” — so the improvements were checkable rather than vibes.
She still would not declare victory in week six, for reasons worth borrowing. A five-person team produces wobbly statistics; one holiday week can swing everything. Her rules: a result only counts once a second quarter confirms the direction, and she reminds herself that the month after a terrible one tends to improve on its own. The cruise happened to coincide with their worst quarter in a year, so some of the “improvement” was just the weather changing back.
Where the Team Landed
By the end of the quarter: changes reached production in four to six days, reviews averaged under three hours, and the newest hire merged code on day five. The monitoring-agent mystery was solved and, satisfyingly, confirmed by the same two instruments that had caught the contradiction — logs and a follow-up survey question that everyone answered with relief.
Two lessons survived contact with reality. First, the division of labour works: the DevExOps loop diagnoses and verifies, while the engineers themselves ship the repairs — the queue change was twenty lines of configuration, and no framework did it for them. Second, most of the gains came from reading the instruments they already owned. The team’s build tooling was rebuilt the following quarter, but that is another story — and a good reminder that understanding the engine comes before any performance tuning. The cabin can wait; the frame that keeps the measurements honest cannot, which is exactly how Priya justified spending the whole quarter on the structure holding everything together before touching a single feature.
