{"id":1762,"date":"2026-10-22T09:50:00","date_gmt":"2026-10-22T09:50:00","guid":{"rendered":"https:\/\/devopsschool.org\/blog\/?p=1762"},"modified":"2026-10-22T09:50:00","modified_gmt":"2026-10-22T09:50:00","slug":"devexops-team-habits","status":"publish","type":"post","link":"https:\/\/devopsschool.org\/blog\/devexops-team-habits\/","title":{"rendered":"Nine Habits of Teams That Practice DevExOps"},"content":{"rendered":"

Walk into two engineering teams on a Tuesday and they can look identical: same standup, same board, same hum of keyboards. Come back in a quarter and one has shipped calmly while the other has burned out two people. The difference is rarely talent. It is a set of small, repeatable habits \u2014 the daily-life version of DevExOps, which the short DevExOps primer in the Ops Atlas<\/a> describes as a loop of noticing friction, measuring it, fixing it and checking the fix. Here are nine habits the calm teams share, described the way you would actually spot them.<\/p>\n

What DevExOps Looks Like in Daily Life<\/h2>\n

Before the list, one grounding thought. The research behind all this \u2014 the three-part model researchers published in 2023, the SPACE work before it \u2014 keeps returning to the same trio of concerns: whether answers come back while you still remember the question, whether a task demands the whole whiteboard of your mind, and whether hours pass without a single interruption. Tools matter less than those three. Every habit below is really a way of defending one of them, which is why none of them requires a budget approval to start.<\/p>\n

1. They ask the crew, not just the logs<\/h3>\n

Every quarter, the same handful of questions goes out, worded identically, and the answers are compared with last round’s. Nothing fancy. The habit is the rhythm and the repetition, because comparable answers are the only kind that can show a trend.<\/p>\n

2. They read the tail, not just the average<\/h3>\n

A healthy-looking average wait can hide a tail where every tenth change sits for a working day. These teams publish two figures for every wait \u2014 the typical case and the unlucky tenth \u2014 because the gap between them is where resignations begin.<\/p>\n

3. They time the corridors<\/h3>\n

They know the day is lost between steps, not inside them, so they measure the gaps: minutes a push idles before the pipeline picks it up, hours a request sits before a human answers it, how many minutes a clean local build really needs. When something claims to be faster, they clock it with a stopwatch utility before and after, and let the numbers argue.<\/p>\n

4. They treat contradiction as information<\/h3>\n

When the survey says reviews drag and the timings say otherwise, these teams refuse to pick a winner. A gap between the answers people give and the figures the machines log usually means there is a wait nobody thought to measure \u2014 often the silent stretch before a reviewer even opens the request.<\/p>\n

5. They write the pass mark first<\/h3>\n

Before any fix ships, somebody writes down what success must look like: which number moves, by how much, measured the same way the problem was found. Judging a fix by a target invented afterwards is how teams congratulate themselves for noise.<\/p>\n

6. They put a name on every repair<\/h3>\n

Findings without owners are wishes. The calm teams end each diagnosis with three or so chosen fixes, each carrying one person’s name and one date. Nobody “picks it up when there’s time”, because there is never time, and everyone knows it.<\/p>\n

7. They keep it safe to tell the truth<\/h3>\n

Results get published for teams and roles, never for individuals; any slice of respondents too thin to stay anonymous gets folded into a bigger number; and a written promise \u2014 no survey answer ever reaches an appraisal \u2014 ships before the first question does. The habit survives contact with reality because the team watches the promise being kept.<\/p>\n

8. They spend money where the queue is<\/h3>\n

Budget follows evidence. If the rented cloud machines would genuinely buy back waiting hours, the case writes itself \u2014 figure on roughly forty-five dollars a month for every engineer equipped that way. If the queue is really a review rota, a laptop upgrade is a bribe paid to avoid the actual problem.<\/p>\n

9. They know when to stop<\/h3>\n

The rarest habit of all. When the whole crew fits around one table and a conversation would settle it, they skip the machinery. When no decision-maker will act on findings, they stop collecting them. And when trust has broken down, they repair that first, because surveys run in suspicion return fiction with excellent formatting.<\/p>\n

The Rhythm Behind the Habits<\/h2>\n

None of this runs on improvisation. These teams work to a steady beat: instruments collect continuously, the perception survey returns every few months, and the full loop \u2014 collect, rank, assign, fix, re-check \u2014 closes once a quarter. Between beats, small things happen; nobody waits for a ceremonial review to clear a jammed queue or fix a flaky job. The quarterly closure is for verdicts, not for permission.<\/p>\n

Two rules keep the rhythm honest. Thresholds are written down before a change ships, so the verdict cannot be reshaped around whatever the numbers happened to do afterwards. And a first small fix is deliberately scheduled early in the cycle \u2014 something modest, visible, and certain \u2014 so everyone watches the loop terminate in an improvement they can feel. Momentum, these teams learned, is not built by grand plans; it is built by proof that following through is standard procedure.<\/p>\n

Failure gets the same filing as success. When a remedy ships and the follow-up measurement shows the wait barely moved, the outcome is recorded, not forgotten. Six months later, when a newcomer proposes the same confident remedy, the team can point at the entry and spend the afternoon on something that might actually work instead. Over a year, that archive of honest verdicts becomes the most persuasive document the group owns \u2014 stronger than any slide, because every line in it survived a re-measurement.<\/p>\n

Where DevExOps Habits Take a Team<\/h2>\n

None of these habits is dramatic, which is exactly the point \u2014 the calm team did not find a silver bullet, it installed nine small reflexes and let them compound. Two boundaries keep the compounding honest: the loop’s job is finding problems and verifying cures, while the building itself stays with the teams and the platform folks; and a single quarterly cycle, finished properly, beats an ambitious programme that never ends its first lap. If you are building the surrounding skills these habits sit on, three reads fit naturally: sharpening DevOps problem-solving and critical thinking<\/a>, a candid look at what certifications are actually worth<\/a>, and a practical beginner’s portfolio roadmap with projects and structure<\/a> for proving the skills on paper.<\/p>\n","protected":false},"excerpt":{"rendered":"

What engineering teams actually do differently, habit by habit, when they take DevExOps seriously – from reading the tail of the queue to writing pass marks first.<\/p>\n","protected":false},"author":5,"featured_media":1763,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[489],"tags":[],"class_list":["post-1762","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops-careers"],"_links":{"self":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts\/1762","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/comments?post=1762"}],"version-history":[{"count":1,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts\/1762\/revisions"}],"predecessor-version":[{"id":1788,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts\/1762\/revisions\/1788"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/media\/1763"}],"wp:attachment":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/media?parent=1762"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/categories?post=1762"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/tags?post=1762"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}