Back pain and developer frustration have something in common: both start as a nag you ignore, and both end up costing far more than they would have if you had counted them early. That is roughly the pitch behind DevExOps, the practice of running developer experience the way an ops team runs anything else — measured, owned, and checked after the fix. Instead of another abstract essay, here is a concrete list of the eight waits that eat a developer’s week, what each one sounds like in the wild, and how the loop turns each into somebody’s named job.
DevExOps Starts Where the Waiting Starts
A working day splits into two loops. The inner one is just you and the machine, cycling through writing, compiling, running tests, and poking at bugs. The outer one involves everyone else: opening a pull request, waiting on CI, nudging a reviewer, shepherding a deploy. The work inside either loop rarely causes misery. It is the dead time between steps that does — and because dead time belongs to nobody in particular, it survives for years until someone makes it measurable and assigns it an owner. That pairing of measurement plus ownership is the whole trick.
Eight Waits Worth Counting
1. The queue in front of your tests
Your checks take four minutes; getting a slot takes twenty-five. Look at queue time for CI, and read both the median and the 90th percentile — medians hide the poor soul whose afternoon dies in the tail. Skewed systems skew hard. The fix is usually capacity or trimming what runs per commit, and neither gets funded until the tail number is on a dashboard somebody checks.
2. The silent review wait
A change that took two hours to write sits a day and a half waiting for a human glance. Track review response time as its own number, separate from CI, because no pipeline metric will ever expose it. It is also the wait most sensitive to kindness: rotating a duty roster, or simply agreeing what “urgent” means, halves it without any tooling at all.
3. The build on your own laptop
The inner loop’s biggest offender. When a local build crosses about ten minutes, developers context-switch while it runs and never fully return. Log local build time occasionally; it drifts upward silently, like a mattress acquiring a valley. Nobody decides to make it worse — a hundred harmless commits each add four seconds.
4. The first-week maze
Count the days from a newcomer’s start to their first merged change. It is the single most honest number for how tangled your tooling is, and new joiners are the only people who still remember which steps are ridiculous. Teams are routinely shocked to find a five-day number they assumed was one. Every confusing step it exposes is one your veterans have simply learned to stop seeing.
5. The environment dance
Local installs, dev containers, or a cloud workspace — each option trades setup pain against cost and drift. A four-core cloud workspace runs roughly $45 per developer per month, which is trivial next to the salaries of people waiting on it, but only if the numbers justify the switch for your shape of work.
6. The interrupts nobody books
Tally unplanned work per engineer per week. A team that spends three days of every five firefighting is not slow because of skill; it is slow because its calendar is a casualty ward. The tally alone usually triggers the useful conversation — which incidents were preventable, and which owner keeps inheriting them.
7. The verdict that lands late
Feedback loop length — how long until the system tells you that you are wrong — decides how many mistakes stack up before anyone notices. Shorten it and quality improves without anyone trying harder.
8. The question nobody asks
Cognitive load: how much of the system lives in two heads, how many logins a deploy needs, how many pages of tribal README. Nobody files a ticket for this, which is exactly why it needs a survey question instead.
DevExOps in Practice: From List to Ledger
Collecting these is simpler than it sounds. Benchmark the inner loop directly with a stopwatch tool such as hyperfine, so build times are facts rather than feelings. Break CI queue time down by hour to find the 11am crush instead of guessing at it. Add gentle review nudges before anyone has to chase a colleague publicly. Run an onboarding audit once a quarter by sitting with whoever joined most recently and writing down every step that made them sigh.
Then do the one thing that separates this from list-making: before each fix, write down the number you expect it to move and by how much. After the fix, check that same number. A pre-set threshold keeps the win honest — and keeps you from celebrating a coincidence, since small teams produce noisy numbers and random noise loves to flatter a dramatic before-and-after story.
One more habit makes the ledger stick: read the findings out to the teams before they go anywhere near a leadership deck. The moment developers see their complaints turn into named work with a date on it, survey responses get braver and the loop starts feeding itself. The moment findings vanish into a slide, responses dry up, and no sample size will rescue them.
Why the Survey Rides Alongside the Numbers
Telemetry tells you where the waits are; only people can tell you which ones hurt. A short, stable survey — repeated every three to six months, not reinvented each time — captures the parts no pipeline can see. Three numbers tell you whether the survey itself is healthy:
- the share of answers landing in the top two boxes — the favourable band — instead of an average;
- the response rate, because a weak one puts a warning label on everything else;
- the wording, which must stay untouched between runs, or the trend line measures the edit rather than the team.
One caution from the research community: never let any of this drift into judging individuals. The moment a queue metric turns into a personal scorecard, the data starts lying to you, and it will keep lying for years.
A Note on the Word Itself
You will not find DevExOps in a textbook; the honest references say outright that no established definition exists yet, and treat it as a working label for the measure-then-fix loop described above. That suits us fine. Labels matter less than habits, and the habit here is old-fashioned: notice the nag, count it, treat it, recheck it.
Readers of a spine hospital’s blog will recognise the shape immediately. You try sensible options first — the equivalent of trimming queue time with an hour-by-hour analysis — the way back pain treatment options are weighed before surgery is ever considered. You escalate deliberately, knowing when back pain genuinely needs specialist hospital care rather than another week of home remedies. And you commit to fixes with your eyes open, asking the key questions before choosing a hospital for long-term back care the same way a team should ask who owns a fix and how success will be verified.
If the list above matched your own week a little too well, the next step is small: pick two waits, baseline them this month, and give each an owner and a threshold. For the full metric set, the research citations, and the survey question wording, this DevExOps reference page from the Ops Atlas covers in an afternoon what took this post eight sections — and it is honest about how young the field still is.