From the Engine Room to the Eng Team: What the Navy Taught Me About Leadership

I spent four years as an Electrician's Mate aboard the USS Kitty Hawk (CV-63). My job was keeping the electrical systems running on a nuclear-powered aircraft carrier — a floating city with 5,000+ people depending on the lights staying on.

It's been almost two decades since I left the Navy, but the lessons from that engine room show up in my engineering leadership every single day.

Systems Don't Care About Your Feelings

On a carrier, when an electrical system fails, nobody asks whose fault it is. The first question is always: what's the impact radius, and how do we restore service? Blame is a luxury you can't afford when the flight deck needs power.

This translates directly to incident response in software engineering. When production goes down, the instinct to figure out "who did this" is natural but counterproductive. The priority is always: assess impact, communicate status, restore service, then do the postmortem.

I run blameless postmortems on my team. Not because I read about it in a Google SRE book (though I did), but because I learned it standing in a dark engine room at 2am wondering why bus transfer panel 3 was showing a ground fault.

Checklists Beat Heroics

The Navy runs on procedures. Every maintenance action has a written procedure. Every evolution has a checklist. It's not because sailors are dumb — it's because human memory is unreliable under stress, and complex systems have failure modes you can't predict.

In engineering management, I apply this same philosophy:

• Deployment runbooks — even for "simple" deploys
• Incident response playbooks — so the on-call engineer isn't improvising at 3am
• Onboarding checklists — so new team members get consistent ramp-up

These feel bureaucratic until the day they save you. And they always save you eventually.

Train for the Worst Case

Aboard ship, we ran drills constantly. Fire drills. General quarters. Man overboard. Damage control. The point wasn't to practice for likely scenarios — it was to build the muscle memory that kicks in when your conscious brain is too stressed to think clearly.

For engineering teams, the equivalent is:

• Game days where you intentionally test failure scenarios
• On-call rotations that expose everyone to production realities
• Architecture reviews that specifically ask "what happens when this fails?"

You don't rise to the level of your ambitions in a crisis. You fall to the level of your training.

Respect the Watch

In the Navy, "standing the watch" means you're responsible for your area for a set period. When you take the watch, you own everything that happens. When you hand it off, you give a thorough brief so the next person has full context.

This is essentially what good on-call looks like. It's also how I think about code ownership, sprint commitments, and engineering handoffs. Every handoff is a watch turnover — the quality of the brief determines the quality of what comes next.

The Parallel Is Real

I didn't take a straight path from the engine room to the engineering org chart. But the core principles are identical: build reliable systems, train your team, document your procedures, respond to failures without ego, and always — always — keep the lights on.