Flight training teaches a specific, portable skill: taking something experienced pilots do intuitively and turning it into checks, numbers and teachable sequences. A remarkably similar skill is now in demand on the software side of aviation-adjacent businesses, and it goes by the working name DevExOps — running developer experience as an operations discipline, with the same loop a good instructor applies to a student: observe, measure, correct one thing at a time, then re-check. For engineers and team leads wondering which capabilities will matter over the next few years, this one deserves a line on the personal syllabus.
Why DevExOps Belongs on Your Skills List
Start with the honest framing. The label is young and editorial — no official certification or canon exists, and this structured DevExOps introduction is a reasonable first reading. The underlying research, though, is established enough to build a career on. The 2021 SPACE work showed that productivity spans five dimensions, that serious programmes cover at least three — including one developers report themselves — and that activity counts must stay away from individual rewards. The 2023 DevEx framework then organised the field around three lenses: the pace at which work answers back, the mental weight of the task, and the room a person has to concentrate.
Companies noticed. Once platform teams, CTOs and engineering managers had to justify tooling budgets with evidence, someone had to own the measuring — designing fair surveys, reading percentile data correctly, and telling the difference between a real improvement and a lucky quarter. That someone is increasingly a named role, and the people doing it are conspicuously promotable because they sit at the junction of data, empathy and money.
The Skill Set, Item by Item
- Instrument design. Knowing which numbers describe waits — build durations, CI queue times, review response — and their limits. Medians alone mislead under skew; percentiles are the honest pair.
- Survey craft. Writing short, repeatable questions; holding wording steady between rounds so answers compare; reading response rates as a trust gauge, not a vanity metric.
- Experiment sense. The humility to demand a confirming second cycle, pool comparable teams, or stage a change with a control group before declaring victory.
- Data ethics. Reporting at team level, keeping small groups anonymous, and defending a written rule that none of this feeds performance reviews.
- Operational patience. Running the loop quarterly rather than heroically — a rhythm skill, closer to scheduling proficiency checks than to firefighting.
Notice what is absent: there is no requirement to be the best coder in the room. Instructors are rarely the smoothest stick-and-rudder pilots on the field; they are the ones who can see what a student is doing wrong and turn it into one correctable item at a time. The measurement role rewards the same turn of mind.
The Evidence Habit That Separates Professionals
Most teams already sense where they hurt. What they lack is evidence that survives budget season, and building it has a known shape. Pair two instruments: surveys capture how the work feels, system logs capture how it flows, and each keeps the other honest — when the two disagree, treat the disagreement as a finding rather than an embarrassment, because it usually marks an intermittent spike or a broken expectation that neither instrument alone would reveal.
Then insist on thresholds written before fixes start. “Review turnaround under four hours at nine in ten” can be graded next quarter; “morale improves” cannot. And keep a rough ladder in mind that the field uses for maturity: a team that runs on anecdotes, then one with a baseline, then one with a working loop, then one where the loop is integrated with planning, and finally one that adapts before problems shout. Knowing where you stand on that ladder is itself a career skill, because it tells you which advice to ignore.
Building DevExOps Skills Deliberately
You can practise on your own team without permission or budget. Trace one change end to end and timestamp every wait. Walk a new joiner’s first weeks and count the days to their first merged change. Read your CI queue by hour. Run a five-question survey and repeat it next quarter with identical wording. Publish results at team level and give every finding a named owner or retire it openly. Six weeks of that is a portfolio piece no certificate matches.
Treat learning it the way you would treat any structured training investment: sequence the fundamentals before the fancy stuff, and price the whole path, not just the first lesson. The same logic aviators apply when hunting ways to cut the cost of learning to fly works here — spend where feedback is fastest. Likewise, understanding how flying hours drive cost mirrors how repeated cycles, not one-off heroics, build competence; and the people who plan ahead with tools like a scholarship guide tend to reach their rating. In software the rating is credibility: two quarters of honest numbers that moved.
What interviewers actually probe
Expect questions with no textbook answers: “Your survey says builds are fine but engineers disagree — what next?” (treat the clash as a finding, hunt the intermittent spike), “Leadership wants one score for the board” (explain what gaming does to it, and offer separate team-level measures instead), or “How small a group before you suppress results?” If a candidate answers those with nuance — percentiles over medians, confirmation cycles over single quarters, written data-use promises over vibes — they have done the work, whatever their CV says.
Where It Leads
The role compounds. A lead who can diagnose waits becomes the person platform groups trust with budgets, the one vendors cannot dazzle, and the natural owner when leadership finally asks why delivery slipped. Titles vary — developer productivity engineer, DX lead, engineering analyst — but the substance is the same, and hiring panels increasingly test for it directly. There is also a clean division of labour worth understanding early: the measurement discipline diagnoses and verifies, while platform teams and engineers ship the actual fixes. Knowing which side of that line you are on — and respecting the other — is what keeps the work credible.
And the door swings both ways. Aviators who learn the software loop bring something rare to it: an instinct for checklists, for blameless reporting, and for teaching one correction at a time. The cockpit and the build pipeline are further apart in vocabulary than in values. Learn the vocabulary; the values you may already have.
One caution closes this out. Skills on a syllabus decay without practice, and this one decays fastest when the organisation measures without acting. If you take the role, secure the decider before the dashboard — it is the difference between a career-making discipline and a hobby with spreadsheets.
