The team in the old Salt Lake office was not failing, which is what made the whole thing hard to talk about. Releases went out. Customers stayed. Nobody screamed. And yet Sandeep, the tech lead, could not shake the arithmetic he did on the metro ride home one evening: nine engineers, and somehow the work of about six was reaching production. Where were the other three engineers? Not absent \u2014 just swallowed. His search for them is a good story about the modern workplace, and about the discipline now called DevExOps, which turned out to be the difference between complaining about lost days and actually getting them back.<\/p>\n
The symptoms were familiar to anyone who has worked near software. Changes that took an afternoon to write took a week to land. Reviews began conversations three days late. The test system queued work the way the Howrah booking counters once queued passengers \u2014 everyone waiting, nobody sure why. Sandeep’s first instinct was the instinct most leads have: hold a meeting, ask for effort, tighten something. Happily, a colleague talked him out of it. Priya, who had seen this film before, suggested the radical alternative of counting before blaming.<\/p>\n
What she proposed was the loop at the heart of DevExOps \u2014 treat the lost time as a measurable defect, not a mood. Find where the days actually went. Measure each wait two ways: what the systems recorded, and what the team felt. Give whatever turned up to a named owner with a number to hit. Then verify, against that number, whether the days came back. Before any of it, she insisted on a promise in writing: results would be discussed for teams, never persons; tiny groups would stay out of every report; and nothing collected would drift into appraisals. The promise cost one lunchtime and bought the honest answers that made everything else possible.<\/p>\n
Three weeks of quiet measurement produced a portrait nobody expected and nobody could argue with:<\/p>\n
Notice what was absent from the list: laziness, missing skill, too many meetings. The days had not been stolen by people. They had been taxed, patiently, by waits.<\/p>\n
Each finding went to the person who actually controlled it, with a target agreed before any repair began. The queue went to the platform engineer, who sliced the data by hour and found the afternoon cliff \u2014 a scheduled job quietly strangling capacity \u2014 and moved it. Reviews went to Sandeep himself, who built a rota so pager duty and reviewing stopped colliding, plus a gentle nudge when a request crossed the team’s stated limit. The unplanned-work tax got a standing triage hour, so interruptions queued instead of landing on whoever was mid-thought. And the newcomer’s ordeal became a scripted setup with a rewritten guide, tested on the next starter before being declared done.<\/p>\n
The division of labour stayed clean throughout: the diagnosis and the later verification belonged to the loop, while the repairs belonged to the platform engineer and the teams. Nobody had to grade anybody. The clocks did the grading, and the clocks held no grudges.<\/p>\n
Ninety days later, the same measures ran again \u2014 the same ones, because fresh instruments make comparisons fiction. Median review response fell to six hours; the target had been eight, so that one passed. The queue cliff vanished entirely. Days-to-first-change dropped to nineteen against a target of fifteen \u2014 an improvement, a real one, and officially a miss. Priya put the miss on the same slide as the wins, in the same font, and reported everything to the engineering team before any summary went upward. That order \u2014 teams first, leadership after \u2014 is not ceremony. It is the difference between people who use measurements and people who are measured by them.<\/p>\n
The arithmetic Sandeep did on the metro now has answers. Roughly the work of two engineers came back, not by adding effort but by deleting waiting \u2014 the equivalent of hiring, without a single desk moved. The deeper change is harder to number: arguments in that office now end with “what does the data say” instead of “who is to blame.” Teams elsewhere who want the production-side craft that pairs with this story can read about keeping production services dependable<\/a>, and the fixes for manual pipeline grind are catalogued in the piece on cutting manual pipeline work with smart automation<\/a>. Engineers eyeing the career behind such work \u2014 instrumentation, surveys, statistics \u2014 will find the full-stack DevOps engineer roadmap<\/a> a fair map of the ground to cover.<\/p>\n A first quarter answers one question well and raises others honestly. Sandeep’s group spent part of its second one on lighter instruments. Transactional prompts \u2014 a single question fired the moment a change merges or a build fails \u2014 began catching annoyances the same afternoon they appeared, instead of at the next survey. Experience sampling, the random mid-morning ping asking what working on, got trialled for a fortnight and kept, carefully, because there is a short distance between a gentle prompt and a poke. Neither instrument replaced the quarterly survey; both shortened the distance between a problem happening and the team hearing about it, which is the entire competitive advantage of a measurement culture over a rumour mill.<\/p>\n You do not need a programme to start; you need one honest count. Pick the wait that annoys your team most. Time it for three weeks, ask one matching survey question, agree in advance what “fixed” will mean, and let one owner prove it. If your group is small enough that a candid huddle covers everything in an hour, keep the huddle and skip the formality \u2014 but keep the counting, because counting is the whole secret. And if you want the full method behind Sandeep and Priya’s quarter, the DevExOps notes in the Ops Atlas<\/a> lay out the cycle and its ethics rules in full. The three engineers Sandeep was hunting were never missing. They had been waiting in queues, all along, in plain sight \u2014 and waiting, unlike talent, is something a team can simply decide to stop.<\/p>\n","protected":false},"excerpt":{"rendered":" Nine engineers, the work of six, and a metro-ride question: how one team counted its lost days, owned the waits, and got two engineers back.<\/p>\n","protected":false},"author":6,"featured_media":631,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[496],"tags":[],"class_list":["post-630","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technology"],"_links":{"self":[{"href":"https:\/\/kolkataorbit.com\/blog\/wp-json\/wp\/v2\/posts\/630","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/kolkataorbit.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/kolkataorbit.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/kolkataorbit.com\/blog\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/kolkataorbit.com\/blog\/wp-json\/wp\/v2\/comments?post=630"}],"version-history":[{"count":1,"href":"https:\/\/kolkataorbit.com\/blog\/wp-json\/wp\/v2\/posts\/630\/revisions"}],"predecessor-version":[{"id":681,"href":"https:\/\/kolkataorbit.com\/blog\/wp-json\/wp\/v2\/posts\/630\/revisions\/681"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/kolkataorbit.com\/blog\/wp-json\/wp\/v2\/media\/631"}],"wp:attachment":[{"href":"https:\/\/kolkataorbit.com\/blog\/wp-json\/wp\/v2\/media?parent=630"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/kolkataorbit.com\/blog\/wp-json\/wp\/v2\/categories?post=630"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/kolkataorbit.com\/blog\/wp-json\/wp\/v2\/tags?post=630"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}The Questions the Team Asked Next<\/h2>\n
The Moral for Busy Teams<\/h2>\n