Because in both aviation and tech, launching is just the start. The real story begins when you’re dodging headwinds, fixing mid-air glitches and landing safely — even if the runway’s shorter than you expected.
Threat and Error Management: From “Oops” to Ownership
Aviation’s Threat and Error Management (TEM) is like a code review for your flight plan. It’s not about pointing fingers; it’s about seeing trouble before it turns into a mayday call.
Threats: Like a last-minute spec change that hits your sprint like a crosswind gust at short final. Or that new compliance checklist that feels like a NOTAM you didn’t check until you were wheels-up.
Errors:
- Slips: Typing
git pushwithout checking the branch, like switching to tower frequency when you’re talking to ground. - Lapses: Forgetting to test an API limit, like skipping a fuel check before departure.
- Mistakes: Choosing a “fast” feature toggle that ends up like deploying a 737’s landing gear on a Cub — too much for the mission.
- Violations: Sneaking in an unreviewed feature on a Friday night deploy, like ignoring the METAR and hoping for VFR in a thunderstorm.
- Latent errors: That tribal knowledge nobody documented, like an unmarked water hazard on a grass strip you’ll only find out about on landing.
- Active errors: That gut feeling when you know your plan’s off, like hearing “caution wake turbulence” and seeing a 747 rotate ahead of you.
- Undesired States: Rushing a launch because “we’ll fix it live,” like pulling a steep approach to a short runway because the dinner’s getting cold at home.
From “May I?” to “I Intend To…”
Pilots don’t ask permission to land; they declare intent: “I intend to land runway 27.”
In engineering? It’s moving from “Should I do this?” to “I intend to ship this feature. Here’s why it matters; here’s the plan, and here’s how we’ll pull up if needed.”
Because asking permission is like circling the runway, waiting for a controller who’s already gone home. Declaring intent — while listening to input — means you’re flying the mission, not just hoping the wind will carry you.
Cross-Checks: Because Even Mavericks Don’t Fly Alone
Even solo pilots cross-check:
- Airspeed indicator (like your load test reports).
- Altimeter (like your product partner’s “Are we still on target?”).
- The outside world (like user feedback before launch).
In engineering:
- That senior dev asking “Have you checked performance at scale?” — like a co-pilot calling out “Airspeed’s good. Sink rate’s okay.”
- Your product partner’s “But what about the user’s perspective?” — like listening to ATIS before you join the pattern.
- Your own gut-checks. If it feels wrong, it probably is — like seeing your VSI pegged at -1,000 and realizing you’re a little steep on final.
Aviation One-Liner:
There’s no prize for getting there first if you’re not sure where “there” is. The same applies in code. If you don’t check your heading, you’re just building fast in the wrong direction.
Build Clarity, Not Just Checklists
A checklist without understanding is like having a GPS with no idea where you’re going.
- Make sure everyone knows why you’re building it, not just what you’re building.
- Don’t treat retros and demos like box-ticking. Use them to calibrate your flight plan.
- Don’t be the pilot who “hand flies” the whole flight just to show off. Empower your team to take the yoke and find their own smooth landing.
Real-world parallel:
That time you let a junior dev take the lead on a feature and they absolutely nailed it? That’s what real pilot training looks like — confidence from practice, not just a checklist.
Post-Flight (and Post-Deploy) Debriefs: Hindsight is 20/20, so Use It
Pilots know that the best flights end with a debrief. The same applies in code:
- Celebrate the perfect landings — like a deploy that goes live without a glitch.
- Dig into the rough patches — like a go-around that taught you something new.
- Turn “I almost crashed” into “Next time, I’ll…” — because those war stories make the next flight smoother.
Aviation One-Liner:
A smooth landing is one you can walk away from. A great landing is one where you can reuse the plane. Same for deploys: Don’t just aim for working — aim for reusability and clarity.
A Few More Real-World Parallels for the Checklist:
- Refactoring? It’s like an engine overhaul. Sure, it’s expensive, but flying on a half-working engine isn’t leadership, it’s luck.
- Feature toggles? Like variable geometry wings. Cool if you understand them, terrifying if you don’t.
- Tech debt? Like hidden corrosion in the airframe. Out of sight, but one day it’ll come back to bite you at altitude.
- User feedback? Like the wind sock at the airfield. Ignore it and you’ll land crosswind every time.
The Final Call to Action: Fly the Whole Flight
Whether it’s a code release or a solo hop over the Alps, real leadership means:
- Owning the plan.
- Owning the outcomes.
- Owning the debrief.
- And knowing that every flight — every feature — is a chance to learn, adapt and build a smoother approach for next time.
Because in the end, it’s not about showing off your taildragger skills or how many branches you can juggle in Git. It’s about making sure everyone on board — and everyone in your repo — gets there safely, learns something new and is ready for the next leg.
Here’s to safe deploys, smooth landings and leadership that never just flies along — it flies the whole flight.
Even the best flights need a good checklist and a willingness to go around if it’s not quite right.
