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 — the daily-life version of DevExOps, which the short DevExOps primer in the Ops Atlas 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.
What DevExOps Looks Like in Daily Life
Before the list, one grounding thought. The research behind all this — the three-part model researchers published in 2023, the SPACE work before it — 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.
1. They ask the crew, not just the logs
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.
2. They read the tail, not just the average
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 — the typical case and the unlucky tenth — because the gap between them is where resignations begin.
3. They time the corridors
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.
4. They treat contradiction as information
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 — often the silent stretch before a reviewer even opens the request.
5. They write the pass mark first
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.
6. They put a name on every repair
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.
7. They keep it safe to tell the truth
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 — no survey answer ever reaches an appraisal — ships before the first question does. The habit survives contact with reality because the team watches the promise being kept.
8. They spend money where the queue is
Budget follows evidence. If the rented cloud machines would genuinely buy back waiting hours, the case writes itself — 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.
9. They know when to stop
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.
The Rhythm Behind the Habits
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 — collect, rank, assign, fix, re-check — 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.
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 — something modest, visible, and certain — 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.
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 — stronger than any slide, because every line in it survived a re-measurement.
Where DevExOps Habits Take a Team
None of these habits is dramatic, which is exactly the point — 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 candid look at what certifications are actually worth, and a practical beginner’s portfolio roadmap with projects and structure for proving the skills on paper.
