Five people in Patna run a travel-planning site for Bihar under the name Tirhut Trails, and until this year their week had a fixed shape: build features from Monday to Thursday, then lose Friday and half of Monday to waiting. Waiting for the site to assemble itself, waiting for someone to glance at the code, waiting for the release window. When a friend finally asked what they intended to do about it, the founder said they had drifted into DevExOps — running developer experience as a loop of measure, prioritise, verify — mostly by accident and mostly out of stubbornness.
The Route Was Fine; the Waiting Wasn’t
Anyone who has planned a road trip knows the difference between an itinerary and a journey. The itinerary lists places. The journey gets judged by the two hours lost at a toll plaza and the forty minutes at a booking counter. Software work behaves the same way. The steps — writing a change, assembling the site, getting another pair of eyes on it, pushing it live — are the places. The queues between the steps are where the day quietly disappears, and that is where DevExOps looks first: not at what developers do, but at what developers wait for.
The team drew up an inventory of their waits and pinned it to the wall.
- How long from “I saved my work” to a running site they could click around.
- How long a finished change sat before anyone responded to the review request.
- How long the automated checks held a piece of work that was ready to ship.
- How many days a new hire needed before their first real change went live.
Complaints That Cancelled Each Other Out
What pushed them to act was a peculiar, circular argument. One developer insisted the tooling was miserable; another said things were fine and the complainer was imagining it. Both were persuasive, neither had evidence, and the same argument restarted every few weeks. That pattern — contradictory complaints with no referee — is one of the classic moments to bring in DevExOps. A pointer to the Ops Atlas entry on DevExOps gave them the referee’s rulebook: ask the people, watch the system, and treat any disagreement between the two answers as a finding in its own right.
So they ran a short survey — a handful of questions, repeated every few months rather than every week — and at the same time pulled the timestamps their tools were already recording. The questions were worded to avoid traps: not “is the tooling good?” but “in an ordinary week, how often does a wait break your concentration?” Answers were collected without names, tagged only by role, with a written promise that the responses would never wander into any conversation about anyone’s performance. The survey said the assembly step hurt most. The timestamps said review silence hurt most. Both were right, for different people, and that contrast taught them more than either number alone could.
A False Start Worth Admitting
Their first instinct, months earlier, had been the reflex most small teams share: buy something. A faster laptop appeared, and for about ten days the assembly step felt quicker. By the third week the queue had simply moved — the site assembled fast and then sat longer in front of the reviewer, because nobody had actually identified what was slow. That episode is the reason the eventual DevExOps cycle began with measurement rather than shopping. A wait is rarely where it appears to be, and a purchase that has not been aimed at a measured bottleneck is a guess wearing a receipt.
The DevExOps Rule: One Problem, One Owner, One Number
A list of five grievances is not a plan. They picked the assembly wait — not because it was the largest, but because it had an obvious owner: the colleague who maintained the build scripts. Before touching anything, they wrote down what success would look like. Not in averages, which flatter; at the slow end, which stings. Their line: by quarter’s end, a saved change should start returning useful feedback within ten minutes even on the worst day of the week, not merely on a good one.
“Writing the number down before we fixed anything felt bureaucratic for about a day,” the founder admits. “Then it saved us three separate arguments, because nobody could move the goalposts after the fact.”
The fix itself was unglamorous. They trimmed what got rebuilt on each save and moved the heaviest checks to run in parallel rather than in a line. It cost two weeks of evenings. Nobody was hired; nothing was bought.
Did the DevExOps Fix Actually Work?
Here the team learned the subtlest lesson of the year: improvement has to be proved, not felt. A bad week after a good one makes any change look magical; a good week after a bad one does the same in reverse. Things bounce back on their own often enough that one before-and-after comparison proves very little. So they agreed to judge direction across two cycles, using identical measures both times, before declaring victory in either direction.
They also set one rule with real teeth: numbers get discussed at the level of the team, never the person. Nobody’s name sits next to a wait time. That single sentence, written into the working agreement before any data existed, is what let people answer the survey honestly instead of strategically.
What a Small Team Keeps
A year in, the ritual is lighter than it sounds. Every three months: one question set, one look at the timestamps, one long-standing argument settled by evidence, and at most two fixes — each with a named owner and a threshold recorded in advance. As they run it, DevExOps builds nothing itself. It diagnoses and verifies; the team ships. The rest of the week goes into what visitors actually see: the long-form guides that are the site’s stock in trade, from a walkthrough on renting quality vehicles to discover amazing sights across Japan to a slow-food circuit of claypot curries and handcrafted confections around historic Bihar.
The founder’s summary of the whole exercise fits in one line: “We stopped arguing about whether the work felt slow and started asking where the queue was. The queue is always somewhere.” For readers planning their own trips with the team’s guides — including their practical note on the documents needed to pick up rental vehicles across Asian markets — none of that machinery is visible. That invisibility is the point. The smoother the behind-the-scenes week, the smoother everything published from it.
