{"id":913,"date":"2026-10-22T18:40:00","date_gmt":"2026-10-22T18:40:00","guid":{"rendered":"https:\/\/flyaiaa.com\/blog\/?p=913"},"modified":"2026-10-22T18:40:00","modified_gmt":"2026-10-22T18:40:00","slug":"devexops-one-week-audit","status":"publish","type":"post","link":"https:\/\/flyaiaa.com\/blog\/devexops-one-week-audit\/","title":{"rendered":"A One-Week DevExOps Audit You Can Actually Run"},"content":{"rendered":"

Here is a reassuring thought: you can learn more about your engineering team’s real working conditions in five days of looking than in a year of guessing. No new tooling, no consultants, no big programme. This is a one-week audit built on DevExOps<\/strong> thinking \u2014 the practice of running developer experience as a loop of measuring, prioritising, fixing and verifying. The label itself is editorial rather than official; this DevExOps field summary<\/a> is a good starting read. Grab a notebook and a calendar, and let’s walk the week together.<\/p>\n

Before Monday: One DevExOps Question, Decided<\/h2>\n

Audits fail when they try to measure everything, so pick a single question with a decision attached. Good ones look like: “Why do small fixes take two weeks to reach the live site?” or “Why is our newest engineer still unproductive after a month?” The question needs a decider \u2014 someone with the authority to act on the answer. If you cannot point to that person by name, park the audit and go and find them first. An audit nobody will act on is a very polite waste of five days.<\/p>\n

Monday: Time the Inner Loop<\/h2>\n

The inner loop is edit, build, test, debug \u2014 the cycle your developers live in hundreds of times a week. Today you simply time it. A benchmarking stopwatch such as hyperfine gives you honest build numbers in minutes, but even a kitchen timer beats folklore.<\/p>\n

Write down three numbers: typical build time, slowest common build time, and how often a day’s work gets interrupted by a rebuild. Ask two engineers to run the same measurement on their own machines too, because the spread between laptops is often its own small scandal. You are not fixing anything yet. You are giving the team’s chief complaint a number, which is the difference between an argument and a project.<\/p>\n

Tuesday: Read the CI Queue by Hour<\/h2>\n

Today belongs to the continuous integration system. Pull the queue times \u2014 how long a job waits before a machine picks it up \u2014 and break them down by hour of day. The pattern usually surprises someone. A queue that looks calm on average may fall apart at eleven each morning when every scheduled job collides with the morning push.<\/p>\n

Two reading rules, borrowed straight from the discipline: never trust a median alone, and note the ninetieth percentile beside it. The typical wait might be four minutes; the unlucky tenth might be forty. Your engineers live somewhere in that tail, and so does your release schedule.<\/p>\n

Wednesday: Follow a Pull Request Around<\/h2>\n

Pick one real change from last sprint and follow it like a parcel tracking number. When was it opened? When did a reviewer first actually look \u2014 not a bot, a human? How long between look and comment? How long from approval to merge, and merge to live?<\/p>\n

This exercise finds the silent waits. Often one person is receiving most review requests because of what they own, and answering them a day late \u2014 not from neglect, just arithmetic. If that pattern shows up, the eventual fix is a review rota and a gentle nudge bot, both cheaper than the delays they replace.<\/p>\n

Thursday: Walk a New Hire’s First Week<\/h2>\n

Take the onboarding paperwork and walk it step by step, ideally with the most recent joiner. Count every access request, every “ask Priya for the sandbox password”, every installation step that says “see wiki (outdated)”. Note the day their first change actually merged.<\/p>\n

Days-to-first-merged-change is one of the most honest numbers in the whole field, because nothing about it can be gamed and everybody remembers it vividly. Eleven of twenty-three days being access tickets is common, and every one of those days is a hiring investment idling in the hangar.<\/p>\n

Friday: Ask the People, Kindly<\/h2>\n

The week so far measured machines. Today is for perceptions, and the discipline insists you collect both because each catches what the other misses. Three light instruments work well:<\/p>\n