People assume the pilot-to-tech story is a neat pivot: discipline transfers, clouds are easy, you become a thought leader by Tuesday. That was not my experience. I flew for Lufthansa. I left that career for personal reasons, not because I had a master plan to monetize a conference talk. I landed in DevOps because operations felt familiar in temperament and completely foreign in tooling.

People working together with laptops

Photo by fauxels on Pexels

I am still learning Kubernetes. I expect to be learning it for years. This post is what I wish someone had told me early: honest, technical, without the “you’ve got this warrior” LinkedIn tone.

What carried over (less than the posters suggest)

Flying taught me habits that help on bad days:

Brief before action. What are we changing, what could go wrong, what is rollback.

One lever at a time. Change one variable, observe, resist heroic multi-fixes.

Checklists under stress. Structure when adrenaline wants improvisation.

Crew resource management. Speak up, listen, assign roles, do not talk over the person executing.

Respect for procedure without worship. Manuals help until reality diverges; then you think.

What did not carry over:

The depth of domain knowledge. I had years of aircraft systems, regulations, company procedures. In Kubernetes I was a student again at the bottom of a steep curve.

The career ladder. Aviation had a clear path. Tech had titles that meant different things at every company.

Confidence from repetition. I had thousands of hours. My first kubectl mistakes were embarrassing in boring ways — wrong namespace, typo in a label selector.

If you are transitioning from another field: your old job is input, not a brand. The useful parts show up in how you work, not in metaphors you paste into slide decks.

Year one felt like instrument training in fog

Everything was symbols without context.

Pods, Deployments, Services — I could memorize definitions and still not understand why my app was not reachable. CRDs appeared like new chart symbols mid-route. Helm felt like a flight management system I was allowed to touch but not fully taught.

I studied the way I studied for type ratings: structured, repetitive, with checkrides I set for myself.

What helped technically:

A small home lab. minikube, then kind, then a cheap cloud cluster I was willing to break. Breaking teaches faster than reading.

One book, end to end. I picked a Kubernetes book and finished it instead of collecting tabs. Which book matters less than completion.

Official docs for concepts, not blogs for defaults. Blogs age. Core docs on Pods, Services, and controllers still anchor me.

kubectl explain. Underrated. Still use it.

What helped psychologically:

Admitting “I don’t know” in standup. Faster than bluffing through a retro.

Finding one patient mentor. Not a guru — a colleague who answered dumb questions without making me feel dumb.

Writing notes in my own words. If I could not explain a ReplicaSet without jargon, I did not understand it yet.

Year two was OpenShift and real production

Textbook clusters lie politely. Production clusters have quotas, network policies, legacy ingress, secrets sync delays, and team politics about who owns the platform namespace.

I touched OpenShift at work — Routes instead of only Ingress, SCCs, operator-driven installs. The Kubernetes core was the same; the guardrails differed. That confused me until I separated “upstream concept” from “vendor packaging.”

Production taught lessons no lab does:

Readiness vs liveness is not academic. Wrong probes take services out during slow starts or keep broken Pods in rotation.

Resource limits bite. OOMKilled looks like mystery crashes until you look.

GitOps is policy and workflow, not magic. Controllers reconcile; humans still merge bad YAML.

Incidents are collaborative. My CRM habits helped. My lack of deep Linux networking hurt. I leaned on teammates instead of performing captain energy.

I also learned to document while calm. Runbooks, postmortem notes, “here is how our Helm values actually work.” Aviation had manuals; I tried to write the pieces I wished existed when I was new.

What I deliberately did not do

Chase every certification at once. Certs have value; stacking them as procrastination from building does not.

Pretend aviation analogies in public posts. Some fit. Many are stretch. I use them sparingly because I respect both fields.

Compare myself to engineers who started at twenty. Different path, different timeline. Comparison stole months of peace.

Say “passion” when I meant “curiosity mixed with frustration.” Honest language kept me going.

Skills I am still building

Being transparent about gaps keeps me humble and hireable:

Linux internals and networking. tcpdump still feels like a foreign language I am slowly speaking.

Service meshes. Touched Istio in exercises; not daily driver depth.

Observability stacks. I can use dashboards; designing SLOs and useful alerts is ongoing.

Terraform and cloud IAM at scale. Enough to be dangerous; not enough to be architect.

Go. Reading controller code slowly; writing small tools poorly but functionally.

Kubernetes is a platform on platforms. You do not finish it. You deepen in the slices your job touches and keep peripheral vision on the rest.

How the career transition actually felt

Lonely sometimes. Aviation had crew. Early DevOps days had Slack and imposter syndrome.

Financially and identity-wise, starting over stung. “Pilot” was a clear identity. “Platform engineer learning the ropes” was accurate and unglamorous.

Rewarding when something clicked. The first time I traced a failing deploy from Ingress to a misconfigured probe myself — not heroically, just correctly — I felt the same quiet satisfaction as a clean approach in marginal weather. Small proof that the learning loop worked.

I did not become a influencer. I became employable, then useful on a team, then someone newer people could ask without me deflecting to buzzwords.

Advice I give cautiously

Because everyone’s constraints differ:

Optimize for teams that teach. Brand names matter less than review culture and psychological safety.

Build a portfolio of problems solved, not repos of hello-world. Write up one incident you understood, one automation you owned, one doc you improved.

Translate old skills without forcing metaphors in interviews. Say “I am good under time pressure and structured communication” before you say “I treat Pods like aircraft.”

Protect sleep. Tired learning sticks poorly. I know this from aviation; I ignored it in bootcamp culture anyway. Regret followed.

Stay kind to past self. The pilot years were not wasted. They were a different chapter.

Kubernetes specifically vs “DevOps” broadly

DevOps is a job shape: delivery, reliability, collaboration, tooling soup. Kubernetes is one orchestrator among options, dominant in many shops, absent in others.

I focused on Kubernetes because that is where my roles pointed. If you transition and your target runs managed PaaS or serverless, depth there beats shallow k8s trivia. Principles transfer: idempotency, observability, rollback, least privilege.

If you are Kubernetes-bound like I was:

Learn the control plane concepts — etcd’s role, scheduler basics, controller loop mental model — even if you are not installing clusters. It explains symptoms.

Learn Helm or Kustomize early enough to see how teams package reality.

Do at least one painful upgrade or migration in a lab. Version skew teaches humility.

What I would tell past-me

You are not behind forever. You are behind today, which is normal.

Ask for the diff review. Offer to take notes on incidents. Visibility beats silent struggling.

Your aviation background is not a marketing hook unless you make it one. It is a work style. That is enough.

Keep a learning log. Dates, errors, fixes. Future you will need patterns.

Do not wait until you feel expert to help the next newcomer. Explaining what you learned last week solidifies it.

Closing

I flew airliners for Lufthansa. Now I work with clusters, pipelines, and incidents. The path was not a montage. It was courses, mistakes, patient colleagues, and a lot of evenings reading docs.

If you are crossing from aviation — or from nursing, or music, or anything with its own deep craft — you do not need to become a guru. You need to become competent in small verified steps, and honest about what you do not know yet.

Kubernetes will still be here tomorrow, still evolving, still humbling. That is partly why I stay interested. The runway is different. The need for careful preparation is not.