{"id":11613,"date":"2026-10-22T07:30:00","date_gmt":"2026-10-22T07:30:00","guid":{"rendered":"https:\/\/www.cotocus.com\/blog\/?p=11613"},"modified":"2026-10-22T07:30:00","modified_gmt":"2026-10-22T07:30:00","slug":"devexops-in-plain-words","status":"publish","type":"post","link":"https:\/\/www.cotocus.com\/blog\/devexops-in-plain-words\/","title":{"rendered":"DevExOps in Plain Words"},"content":{"rendered":"

Here is a scene from almost every office: the standup runs fine, the tickets move, nobody complains officially \u2014 and yet everyone stays late and ships slowly, and nobody can say exactly why. If that sounds familiar, the idea behind DevExOps will make sense to you in one line. It means treating the way your developers work as something you can see, measure and improve on purpose, rather than something everybody quietly endures.<\/p>\n

DevExOps in One Paragraph<\/h2>\n

The word itself is newer than the practice. It has never been defined in any standard or paper, and the Ops Atlas write-up of DevExOps<\/a> is refreshingly blunt about that: the term is a handle, not a product or a certificate. What it names is a habit \u2014 notice what grinds engineers down, get evidence instead of opinions, put a name and a date on each repair, and check afterwards whether the repair worked. The subject it studies is real even if the label is young: developer experience is simply how the work feels and how well it goes for the people doing it, day after day. You do not need to buy anything to begin. You need to decide to look.<\/p>\n

Two Loops and the Traffic Between Them<\/h2>\n

Picture the day as a pair of loops. The small one is the work itself: typing the change, running it, fixing what broke, over and over, hundreds of times a week. The big one is everything that happens after: the change goes up as a request, waits for the pipeline, waits longer for a reviewer, and eventually rolls out. Here is the part worth underlining \u2014 the misery is rarely inside either loop. It pools in the traffic between them, the stretches where nothing moves and a person’s attention quietly dies. A ten-minute build is workable. A pull request that waits nine hours for a first glance is where the day actually disappears, even though no task on the board ever recorded those hours.<\/p>\n

That is why the useful question is almost never “are people working hard?” It is “where does the work sit still?” Waiting is invisible in every plan built from task estimates, which is exactly why it survives year after year and outlives most of the tools meant to fix it.<\/p>\n

Two Gauges That Keep Each Other Honest<\/h2>\n

So how do you see waiting? With two gauges, and you want both. The first is a short survey \u2014 a handful of questions, asked the same way every few months, that captures how the work actually feels to the people doing it. Keep the wording identical between rounds; the value comes from comparing, and a reworded question breaks the comparison. The second is the data your systems already produce: pipeline timings, review waits, build durations. Each gauge has a famous weakness. Surveys drift with mood, and with who happened to have a rough sprint. Dashboards count minutes but know nothing of misery. Run them side by side and something useful happens: when the two disagree, believe neither and investigate both. If the queue times look fine but everyone says reviews crawl, the sting probably hides in a gap nobody measured \u2014 like the days before anyone even opened the request.<\/p>\n

The DevExOps Numbers Worth Watching<\/h2>\n

You do not need a wall of dashboards. Four reads carry most of the weight:<\/p>\n