Ask a pilot what happens in the hour before departure and you will hear very little about flying. You will hear about checking. Fuel quantities get cross-fed aloud, control surfaces sweep through their full travel while a second voice reads the numbers back. Nothing in that ritual assumes the aircraft is broken; it exists because memory is a poor place to store critical steps.
DevExOps applies the same discipline to a machine most companies fly daily without ever opening a panel: the working environment of their engineers. The label itself is young. As the Ops Atlas entry on DevExOps explains, no formal published definition exists yet — it is an editorial name for a loop, not a shrink-wrapped tool. The recipe is short: locate the friction, put numbers on it, give each repair a specific human who answers for it, then check the outcome against a target you wrote down before anyone touched anything. Beneath the label sits a field with a decade of research behind it. Developer experience describes the whole texture of an engineer’s working day — what it feels like from the inside, how much mental effort it burns, and whether the person living it still believes the work matters.
Why Software Teams Skip the Walk-Around
Launch crews never skip inspection because a launch is expensive and visible. Software teams skip it because friction arrives quietly and gets normalised one slow day at a time. A build that took two minutes last year takes eleven now, and nobody files a complaint because eleven minutes still feels survivable. Reviews sit for a day, then two, and the team adapts by stacking up context switches instead of asking why. By the time somebody says the quiet part aloud — usually in an exit interview — the decay has been running for quarters.
Aviation answers this with a checklist run every single time, precisely because the failure it prevents is rare. That is the mental model worth borrowing: routine verification of things that rot slowly.
The rot spreads further than people expect, too. A faster laptop buys three good weeks and then the queue upstream eats the gain. A cache hides a slow database until the cache goes cold. Even genuine repairs decay, because the codebase keeps growing underneath them. An organisation that never inspects is not standing still — it is gliding, and gliding only feels like progress while there is still altitude.
DevExOps, Read Back as a Checklist
Stripped of jargon, the loop is short enough to memorise. Six checks, in order:
- Walk the waits. An engineer’s day runs on two clocks: a tight one spent writing, building, testing and debugging, and a wide one where a change goes up for review, clears CI and rolls out. Damage rarely sits inside a step; it pools in the gaps between them.
- Ask the crew. A short survey every three to six months captures what telemetry cannot: whether the work still feels worth doing.
- Read the gauges. CI queue times, review response times, build durations — numbers pulled from systems people already use, not from a new form they must fill in.
- Cross-check both instruments. When the survey and the telemetry disagree, that disagreement is itself a finding, not noise to wave away.
- Name an owner. A finding without a person attached is a wish, not a work item.
- Verify, never assume. Re-measure with the same instruments and compare against the threshold you wrote down before touching anything.
Two Instruments, One Truth
The pairing matters more than either half. Surveys on their own drift with mood and memory; dashboards on their own count activity without ever asking whether the activity felt worthwhile. Run together, each keeps the other honest. If engineers insist reviews are slow while the response-time numbers look healthy, something interesting is happening — perhaps the wait that stings is the untracked one before a reviewer even opens the request. Treated seriously, a contradiction between instruments is the cheapest research result you will ever get.
Collection technique decides whether either instrument stays useful. Keep the survey short and identical between rounds so answers can be compared across quarters. Catch pain in the moment with a single-question prompt that appears when a build fails or a pull request sits unreviewed past a day. A few random experience samples through the week fill in the texture between surveys. And slice the CI queue by hour before spending money — a morning stampede has a very different cure from an all-day crawl.
Small Samples Tell Tall Tales
Honesty about numbers is part of the discipline. On a team of fourteen, an 18% favourable response could plausibly mean anything from 6% to 44% once sampling noise is counted. That spread is not a reason to quit measuring; it is a reason to measure with humility. Ask whether the direction holds across two consecutive cycles. Pool results across a few teams before drawing conclusions. Roll each change out to one group first. And keep regression to the mean in mind — teams often improve right after any attention arrives, which will happily hand an inactive fix all the credit.
What the Audit Must Never Count
Every checklist carries items that end the flight if they fail. Here, ethics is one of them. Report at the level of teams and personas, never individuals. Suppress any group too small to be anonymous — under roughly five people. Write down, before the first question goes out, that none of this data feeds performance reviews; the moment engineers suspect otherwise, the answers become theatre. Regulators take this seriously as well: the EU AI Act classes workplace performance monitoring as high-risk, with obligations arriving in December 2027 but already shaping how vendors build.
When DevExOps Should Stay Grounded
Checklists also tell you when not to fly. If the whole group fits around one table, a retrospective will do; a measurement programme is ceremony at that size. If no named decision-maker will act on what you find, you are gathering evidence for a shelf. If trust is too low for honest answers, repair that first, or the numbers will lie politely. One division of labour deserves stating too: DevExOps diagnoses and verifies, while the platform group and the teams themselves ship the actual repairs.
That is the entire audit — inspect routinely, trust two instruments over one, and accept only a pre-committed threshold as the verdict. The habit travels beyond software, and the comparison is instructive: see how space missions are planned, then read a dedicated space mission safety checklist guide alongside it. For the IT-operations cousin of the same idea, this simpler take on AIOps and modern IT operations is a good next stop.