{"id":1157,"date":"2026-10-22T08:40:00","date_gmt":"2026-10-22T08:40:00","guid":{"rendered":"https:\/\/cotocus.cn\/blog\/?p=1157"},"modified":"2026-10-22T08:40:00","modified_gmt":"2026-10-22T08:40:00","slug":"where-devexops-is-heading-next","status":"publish","type":"post","link":"https:\/\/cotocus.cn\/blog\/where-devexops-is-heading-next\/","title":{"rendered":"Where DevExOps Is Heading Next"},"content":{"rendered":"<p>In 2019 a team lead I knew tried to argue for build servers by taping a printout of failed pipelines to the office wall. The argument worked, eventually, but notice what it took: one irritated human, a wall, and a coincidence of timing. Five years later the same case gets made with paired charts \u2014 one from the survey, one from the pipeline \u2014 and a threshold written down before the change. That shift, from anecdote to instrument, is the whole story of DevExOps so far, and the next chapter is already visible in the research.<\/p>\n<h2>DevExOps: A Young Term for an Old Concern<\/h2>\n<p>Start with honesty about vocabulary. DevExOps has no settled definition in any published standard; as the <a href=\"https:\/\/www.xopsschool.com\/devexops\/\">Ops Atlas explains in its framing of DevExOps<\/a>, the word operates as an editorial handle for something teams were already groping towards \u2014 treating the developer&#8217;s working life as something you observe, measure and repair on a rhythm, instead of complaining about it annually. The concern itself is ancient. What is new is the expectation that it responds to evidence. That expectation is the trend line every other development in this piece hangs from.<\/p>\n<h2>The Research Catching Up With the Practice<\/h2>\n<p>The academic scaffolding arrived in a burst. SPACE, published in 2021, named five dimensions of productivity and gave teams a rule of thumb that still holds: combine at least three of them, and make one of them a perceptual measure taken from people rather than logs. Two years later the framework by Noda, Storey, Forsgren and Greiler focused the lens, describing the work through three windows \u2014 the tempo at which a change tells you it works, the share of your own memory a task occupies, and the stretches of an afternoon that stay unbroken. The same authors flagged something organisations still ignore: none of this is chiefly a procurement exercise, and a person&#8217;s sense of safety on the team shapes every answer you collect. Google&#8217;s GSM and QUANTS programmes, and LinkedIn&#8217;s Developer Productivity and Happiness work shared openly in 2023, handed practitioners ready-made question banks \u2014 a team starting today can borrow validated wording instead of inventing a questionnaire overnight. Notably, these frameworks agree with one another more than they disagree, a sign the field is converging rather than fragmenting. Then 2025 brought DX Core 4 \u2014 worth reading, published by a firm that sells measurement, and best cited with that caveat attached.<\/p>\n<h2>From Anecdote to Instrument<\/h2>\n<p>Practice followed the papers with a lag, and the shape of that catch-up is telling. Early adopters bolted on a survey and called it done; the discomforting lesson, learned repeatedly, was that perception without telemetry drifts, and telemetry without perception goes numb. The stable configuration that has emerged pairs them: a short questionnaire on a fixed rhythm standing beside wait data pulled from the pipelines and repositories that already exist. Teams now watch how quickly the pipeline answers a push, read both the middle of that distribution and its unhappy tail, track the gap between a request and a human response, and count the days a newcomer needs before landing a first accepted change. Alongside the waits sit two quieter gauges: how much of a week is eaten by work nobody scheduled, and how the survey answers sit \u2014 what portion of them land in the top two bands, weighed against how many people bothered to respond. None of this required new tooling to buy \u2014 only the decision to look, which turned out to be the expensive part all along.<\/p>\n<h2>The Ladder Most Organisations Are Climbing<\/h2>\n<p>Listen to a company for ten minutes and you can place it on the ladder \u2014 though in my experience most organisations place themselves one rung higher than the evidence supports. The complaints-only stage argues from whatever hurt last week. The baselined stage has numbers but no rhythm. The looping stage runs measure-fix-verify each quarter and knows what its last repair achieved. The integrated stage folds this evidence into ordinary planning, so a queue-time chart sits next to the cost report without ceremony. The adaptive stage, still rare, retunes its own instruments as the organisation shifts. Moving up a rung is unglamorous work: the complaints-only team starts by instrumenting one wait; the baselined team books the same retrospective slot every quarter; the looping team writes its thresholds down before touching anything. Progression up this ladder is the quietest but most consequential trend in the field \u2014 and unlike tool migrations, nobody buys their way up it.<\/p>\n<h2>The Missteps That Keep Repeating<\/h2>\n<p>Every trend piece owes you the failure modes, because they are stubbornly consistent. The single blended &#8220;experience score&#8221; keeps returning because executives ask for it; it keeps failing because it erases the contradictions that point at real causes. Borrowed targets travel the same road \u2014 the famous consultancy figure claiming that seven out of every ten working minutes go to inner-loop effort never had a source and still anchors decks. Rewarding activity counts guarantees the counts inflate. And briefing leadership before the teams who answered the questions burns trust that takes years to rebuild, in an arena where every future survey depends on that trust surviving.<\/p>\n<h2>Where DevExOps Goes From Here<\/h2>\n<p>Three currents look likely to shape the next few years. Regulation is arriving: the EU treats workplace performance tracking as a high-risk activity, with its principal obligations landing in December 2027, and works councils and data authorities elsewhere are already asserting themselves \u2014 measurement programmes will need written use policies as a matter of course. The vendor question will sharpen too, as more frameworks ship from companies with something to sell, making independent references and self-set baselines more valuable, not less. Even the AI debate is turning into a measurement debate: a controlled trial in which experienced developers ran 19% slower with assistants while estimating they were 20% quicker is the sharpest reminder yet that gut feel reads both ways. And the boundary of the work will settle where it belongs: the loop finds problems and checks repairs, while the platform group and delivery teams do the building. Teams that respect that boundary tend to keep their measurement programmes; teams that blur it tend to rediscover why engineers stop answering surveys.<\/p>\n<p>For readers tracing the same evolution from the operations side, three pieces pair well with this one: a look at <a href=\"https:\/\/cotocus.cn\/blog\/reliability-reviews-as-a-regular-part-of-the-software-development-lifecycle\/\">reliability reviews inside the development lifecycle<\/a>, a <a href=\"https:\/\/cotocus.cn\/blog\/working-with-xops-tools-a-practical-learning-exercise-for-beginners\/\">beginner&#8217;s exercise in working with xOps tools<\/a>, and these <a href=\"https:\/\/cotocus.cn\/blog\/simple-strategies-for-managing-infrastructure-with-devops-consulting-services\/\">strategies for managing infrastructure with consulting support<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>DevExOps has moved from anecdote to instrument in a few years. A look at the research timeline, the ladder teams climb and the missteps that repeat.<\/p>\n","protected":false},"author":4,"featured_media":1158,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[330],"tags":[],"class_list":["post-1157","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/cotocus.cn\/blog\/wp-json\/wp\/v2\/posts\/1157","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cotocus.cn\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cotocus.cn\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cotocus.cn\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/cotocus.cn\/blog\/wp-json\/wp\/v2\/comments?post=1157"}],"version-history":[{"count":1,"href":"https:\/\/cotocus.cn\/blog\/wp-json\/wp\/v2\/posts\/1157\/revisions"}],"predecessor-version":[{"id":1164,"href":"https:\/\/cotocus.cn\/blog\/wp-json\/wp\/v2\/posts\/1157\/revisions\/1164"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cotocus.cn\/blog\/wp-json\/wp\/v2\/media\/1158"}],"wp:attachment":[{"href":"https:\/\/cotocus.cn\/blog\/wp-json\/wp\/v2\/media?parent=1157"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cotocus.cn\/blog\/wp-json\/wp\/v2\/categories?post=1157"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cotocus.cn\/blog\/wp-json\/wp\/v2\/tags?post=1157"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}