I don’t talk about my pilot years much at work, but they still shape how I react when something breaks in production.

View above the clouds from an aircraft window

Photo by Oskar Kadaksoo on Unsplash

Briefings matter

Before a flight you’d talk through what could go wrong and who does what. Before a deploy I try to do something similar, even informally: what’s changing, how do we roll back, who watches the metrics. It doesn’t need a slide deck — it needs five minutes of attention.

One change at a time

In an aircraft you isolate failures; in a cluster I try the same. Change one variable, look at evidence, resist the urge to restart everything at once. I’ve been wrong plenty of times; the habit at least makes the wrongness easier to undo.

Still learning the tech part

Aviation didn’t teach me Helm or CRDs. It taught me temperament — which helps when you’re on a bridge call and the logs are noisy. The technical skills are what I practice every day now, and they’re the part that still feels hardest and most interesting.

If you’re coming from another field into DevOps: your old discipline isn’t a gimmick. It’s just one input. The rest is showing up, documenting what you learn, and not pretending you’ve seen every failure mode.