Two hospital IT leads I know answered the same question in opposite ways last month. Asked how the work feels for their developers, one shrugged and said they fix things when people shout. The other opened a notebook of build times, review waits, and a short survey summary. The second team has started practising DevExOps \u2014 running developer experience as a measured, owned operation instead of a pile of complaints \u2014 and the contrast between the two habits says a lot about where hospital engineering is heading. This post puts both approaches side by side.<\/p>\n
Consider how each team deals with the oldest grievance in software: the build that crawls.<\/p>\n
Team one hears a developer grumble, promises to look into it, and moves on. Nothing is written down, so nothing can be compared. Next quarter the same grumble returns, phrased more bitterly, and the lead concludes the person is simply negative. Eventually the developer stops reporting friction at all \u2014 which the lead then reads as proof that things have improved. Anecdote in, anecdote out, and no way to argue with either.<\/p>\n
Team two does something almost boring by comparison. It notes how long the waits actually last, checks whether the pain is shared across the team or peculiar to one laptop, names a person who owns the pipeline, agrees in advance what counts as better, and rechecks the same number a few weeks after the fix ships. That is the DevExOps loop in miniature: spot the friction, measure it with surveys and system data together, route it to its owner, then verify the result against a threshold chosen before anyone touched anything.<\/p>\n
The field underneath the label is real even when the label is young. Developer experience describes how developers feel about, think about, and value their work. A widely cited 2023 framework from Kit Noda, Nicole Forsgren, Margaret-Anne Storey, and colleagues groups it into three dimensions: feedback loops, cognitive load, and flow state. A test suite that takes forty minutes to say “no” is a feedback loop problem. A billing integration that only two sleep-deprived people understand is cognitive load. An afternoon shredded by pings and approval gates is flow state, quietly cancelled.<\/p>\n
Worth remembering: those authors are explicit that this is not mainly a tools story, and that psychological safety shapes the answers you will ever hear. A team that fears blame will report a happy queue time and a miserable truth.<\/p>\n
Most engineering time splits into an inner loop \u2014 edit, build, test, debug \u2014 and an outer loop of pull requests, CI, review, and deployment. The work itself rarely hurts; the waits between steps do. Forty seconds of compile is a shrug. Twelve minutes of queue before your test run even starts, three times an hour, is a day that ends with nothing merged and everyone drained.<\/p>\n
Team one experiences those waits as weather. Team two treats them as inventory: countable, ownable, reducible. The difference in mood is not softness. A developer who can see that the review queue empties by mid-morning plans her afternoon around it. A developer who only knows that reviews “take forever” plans nothing, checks the queue compulsively, and blames herself for the stall.<\/p>\n
Friction is rarely the work. It is the waiting around the work \u2014 and waiting can be counted.<\/p><\/blockquote>\n
What Cardiac Rehab Gets Right That Software Teams Should Copy<\/h2>\n
Hospital readers will recognise the pattern instantly, because medicine solved this decades ago. Look at the way cardiac rehabilitation supports recovery after heart surgery<\/a>: clinicians record a baseline, agree on milestones, intervene, and then measure against the same yardstick \u2014 not a nicer-sounding one. Nobody discharges a patient because the physiotherapist felt optimistic.<\/p>\n
DevExOps borrows the same discipline. The verification threshold gets written down before the fix, not after, because a target invented at the end always fits the result. And because engineering teams are small, the numbers need humility: our fact sheet’s worked example has a 14-person team where an 18% change could plausibly sit anywhere between 6% and 44%. The honest responses are to watch direction across two cycles, pool small teams, or roll changes out in stages \u2014 and to expect regression to the mean to flatter any dramatic before-and-after story.<\/p>\n
There is a second borrowing worth making. Just as recovery programmes for heart failure are chosen on published criteria rather than brochure mood, developer-experience instruments should be picked for stability: a short survey you can repeat unchanged, plus telemetry from the systems themselves. Reading how to choose between hospitals for heart failure recovery programmes<\/a>, you are seeing the shape of a good measurement plan \u2014 defined terms, consistent repeat, comparison that means something.<\/p>\n
Side by Side: the Two Habits Compared<\/h2>\n
\n
- Input:<\/strong> Team A collects whatever complaint spoke loudest this week. Team B pairs a stable survey with system telemetry, so perception and measurement check each other.<\/li>\n
- Ownership:<\/strong> Team A’s fixes go to whoever complains hardest. Team B’s findings land with the person who owns the tooling, agreed in advance.<\/li>\n
- Success test:<\/strong> Team A declares victory when the room feels lighter. Team B set its threshold before the fix and verifies against it.<\/li>\n
- Disagreement:<\/strong> When Team A’s survey says all is well, it moves on. When Team B’s survey and its queue data disagree, it treats the contradiction itself as a finding worth investigating.<\/li>\n
- Memory:<\/strong> Team A starts from zero every quarter. Team B accumulates a baseline, so this year’s decisions rest on last year’s evidence.<\/li>\n<\/ul>\n
DevExOps Compared With Tools-First Shopping<\/h2>\n
A third approach deserves its own line, because it is the most common of all: buying something. A dashboard or an AI assistant arrives, a demo wows the leads, and twelve months later nobody can say what improved. The comparison here is uncomfortable but fair \u2014 without a baseline and a threshold you cannot tell a tool that helped from a tool that merely installed. Measurement discipline is what turns spending into investment, and it is also what protects developers from being judged by the same numbers, which the SPACE researchers warned against years ago: activity metrics must never be used to reward or penalise individuals.<\/p>\n
There is a quieter benefit too. Follow-up matters in both worlds. Cardiac patients do not heal at discharge; teams do not heal at the retrospective. Clinicians keep early gains from evaporating with scheduled rechecks, described plainly in this guide to telehealth follow-up after heart surgery<\/a>. Engineering teams keep theirs with a standing telemetry review on the calendar. Same instinct, different ward.<\/p>\n
DevExOps or Gut Feel: Which Side Fits You?<\/h2>\n
Neither habit is shameful; they suit different moments. Fixing by ear works while a team is small enough that a retrospective catches everything and everyone trusts the room. The measured loop starts earning its keep when tooling is shared across teams, when an investment needs a baseline to justify it, or when complaints contradict each other and someone has to arbitrate with evidence. If no decision-maker will act on the findings, or trust is too thin for honest survey answers, fix those first \u2014 measuring into a void helps nobody.<\/p>\n