When the engineering group at Meridian Aero Parts \u2014 a mid-sized supplier of aircraft components \u2014 decided to run one full quarter of DevExOps, the plan fit on a single sheet of paper. Nobody built a dashboard palace. Nobody hired a consultancy. A twelve-person team that maintains the company’s inventory and procurement software agreed to treat its own working conditions with the same rigour the company applies to certified hardware: identify the defect, document the standard, repair it, and inspect the repair. This is the record of those ninety days, told as it unfolded, because the sequence is the lesson.<\/p>\n
The quarter began with governance, which sounds dull and turned out to be decisive. The VP of engineering agreed to act as the decider \u2014 the person who would hear findings and commit resources against them. Before any data was touched, the team wrote a one-page data-use policy. It committed to three things: results would be reported for teams and personas, never individuals; any group smaller than five would be suppressed from every report; and nothing collected would ever reach a performance review. The policy took an afternoon. It bought the cooperation that made every later number trustworthy.<\/p>\n
The decider then posed the quarter’s question, and the team insisted it be written as a sentence: why do changes that take hours to write take days to land?<\/em><\/p>\n The instrumentation phase used two instruments on purpose. System timers recorded the waits the pipeline could see: how long a commit waited for CI to start, how long a pull request waited for its first review, and how many days passed between a new joiner’s start date and their first merged change. Alongside the timers, a short perception survey went out \u2014 eleven questions, the same set the team agreed to reuse every quarter, with answers scored so the share of favourable responses could be tracked honestly. Persona interviews filled in what neither instrument could see: the release manager’s Tuesday ritual, the contractor who tested on a laptop older than some apprentices.<\/p>\n Three weeks of collection produced a baseline nobody had possessed before:<\/p>\n Analysis was done by team and by persona, never by individual, and it produced three findings the decider accepted. Each finding received exactly one owner, and the division of labour stayed clean: the DevExOps loop diagnosed and would later verify, while the platform engineers and the affected teams shipped the actual repairs.<\/p>\n The first finding was review latency, worst on the two teams whose reviewers also carried production support. The fix was a review rota plus gentle review nudges when a request sat beyond the team’s stated target. The second finding came out of the onboarding audits: a new joiner’s first week was consumed by hand-assembling a development environment, guided by instructions nobody had corrected since the previous decade. The fix was a scripted setup and a rewritten guide, tested by walking the next new starter through it. The third finding was the unplanned-work tax, attacked not with heroics but with a standing triage hour that stopped every interruption from landing on the person mid-flow.<\/p>\n Every fix carried a threshold agreed in advance. Review latency had to fall below eight hours at the median within the cycle. Days-to-first-merged-change had to drop under fifteen. Nothing was declared successful in advance; the numbers would say so or not.<\/p>\n The timers could never have found everything on their own. The quarterly survey, kept deliberately short and scheduled to repeat every three to six months, gave the friction a shape that system data lacked. Two lighter techniques earned a place in the next quarter’s plan after the team read about them: transactional prompts, which ask a single question immediately after a specific event such as a merged change or a failed deploy, and experience sampling, which pings a short question at random moments to catch friction while it is still fresh. Both respect the same rule the policy already established \u2014 answers aggregate to teams, individuals stay unnamed \u2014 and both promise to shorten the distance between a problem occurring and the team hearing about it. The interviews added the colour: the Tuesday release ritual nobody enjoyed, the contractor testing on hardware older than the interns.<\/p>\n Verification reused the same measures that produced the baseline \u2014 different instruments would have made the comparison fiction. The results, checked against the pre-declared bars: median review latency fell to six hours, clearing its threshold. Days-to-first-merged-change fell to nineteen, an improvement that missed its bar, and the readout said exactly that, in public, without spin. The unplanned-work share dropped by a third, though on a team this size everyone understood the confidence interval was wide and the direction would need to hold again next cycle before anyone celebrated.<\/p>\n Order mattered here too. The readout went to the engineering teams first, in their own retrospective, before any leadership summary existed. The teams saw the missed threshold as information rather than indictment, which is precisely the reaction a measurement culture needs to survive.<\/p>\n People outside software sometimes assume engineering will resist this kind of inspection. Meridian’s quality department understood it instantly, because inspection against a documented standard is how the company already thinks about aircraft fasteners and hardware<\/a>: a part either meets its certified specification or it does not, and nobody argues with the gauge. A review wait that misses its threshold is the same conversation. The gauge is not the enemy of the part.<\/p>\n Ninety days did not transform the company. It did something better: it established that the team’s time is measurable, that friction has owners, and that a fix is not a fix until a threshold says so. The next quarter already has its question. For engineers elsewhere who want to build the surrounding skills, the advice on growing an engineering career<\/a> pairs well with the operational depth in this guide to intelligent IT operations<\/a>. The working definition of the method itself, including its full quarterly cycle, lives in the Ops Atlas notes on DevExOps<\/a> \u2014 the reference this account follows.<\/p>\n","protected":false},"excerpt":{"rendered":" A fictional parts-supplier engineering team runs one full DevExOps quarter: policy, baseline, owned fixes, and a verification some readers won’t expect.<\/p>\n","protected":false},"author":6,"featured_media":855,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[597],"tags":[],"class_list":["post-854","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-aviation"],"_links":{"self":[{"href":"https:\/\/planespart.com\/blog\/wp-json\/wp\/v2\/posts\/854","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/planespart.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/planespart.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/planespart.com\/blog\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/planespart.com\/blog\/wp-json\/wp\/v2\/comments?post=854"}],"version-history":[{"count":1,"href":"https:\/\/planespart.com\/blog\/wp-json\/wp\/v2\/posts\/854\/revisions"}],"predecessor-version":[{"id":874,"href":"https:\/\/planespart.com\/blog\/wp-json\/wp\/v2\/posts\/854\/revisions\/874"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/planespart.com\/blog\/wp-json\/wp\/v2\/media\/855"}],"wp:attachment":[{"href":"https:\/\/planespart.com\/blog\/wp-json\/wp\/v2\/media?parent=854"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/planespart.com\/blog\/wp-json\/wp\/v2\/categories?post=854"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/planespart.com\/blog\/wp-json\/wp\/v2\/tags?post=854"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Days 16 to 45: The DevExOps Instruments Go Live<\/h2>\n
\n
Days 46 to 75: Owners, Fixes, and Onboarding Audits<\/h2>\n
What the Survey Side Contributed<\/h2>\n
Days 76 to 90: DevExOps Verification, Then Readouts<\/h2>\n
What a Parts Company Recognised Immediately<\/h2>\n
The Quarter, Compressed<\/h2>\n
\n
Why the Story Matters Beyond Meridian<\/h2>\n