What Losing Communications at Sea Taught Me About Leadership

When I was in the Navy, I thought technical skill was everything.
Know the systems. Know the diagrams. Know how to fix the problem.

That was the job.

Then one day, 200 miles from land, we lost satellite communications—and I learned that wasn’t even close to the truth.

The Problem

We were deployed on the USS Blue Ridge, operating in open water with nothing around us.

No nearby ships. No land. No backup.

Then communications went down.

No signal. No clear cause. Just silence.

Out there, communications aren’t a convenience. They’re how people stay safe. They’re how operations function. They’re how you avoid turning a bad situation into a dangerous one.

For a moment, nobody knew why it happened.

Because when there’s no obvious answer, the instinct is to look for the smartest person in the room and wait.

That’s not what happened.

What Most Engineers Get Wrong

A lot of engineers believe success comes from being the one who knows the most. The one who can solve the problem alone. The one who doesn’t need help.

That mindset works in small environments. It completely breaks down in real systems.

Modern systems—whether it’s a Navy communications platform or a cloud architecture in Azure—are too complex for one person to fully understand.

And yet, engineers still try to operate like they’re supposed to.

They hoard knowledge. They avoid asking questions. They hesitate to teach because they don’t feel “ready.” That’s not strength.

That’s isolation.

Lessons From Experience

About thirty of us started working the problem. No single leader directing every move. No single expert with the answer. Just people doing what engineers do:

Checking manuals
Tracing cables
Testing components
Comparing observations

Then someone noticed something subtle.

We were near the equator. The satellite was directly overhead. The dish was rotating to track it—and every rotation was slowly wrapping a cable around its base.

Eventually, the cable pulled itself loose.

That was it.

The problem was simple.

Finding it wasn’t.

And that’s the point most people miss.

Strength Is Not What You Think

We’re taught that strength means independence.

Handle it yourself. Figure it out. Don’t rely on anyone.

That idea doesn’t survive contact with reality. Not in the military. Not in engineering.

Not in life.

After I left the Navy and moved into cloud engineering, I saw the same pattern everywhere:

Complex Azure environments
Terraform deployments across multiple regions
Networking configurations layered with security and compliance

No single engineer understands all of it. And then life added another layer.

I was diagnosed with Multiple Sclerosis.

That changes how you think about strength very quickly. Because the version of strength that says “push through” stops working.

What replaces it is something better.

Something more honest.

Strength is not independence. Strength is interdependence.

What This Looks Like in Engineering

If you’re working in DevOps or cloud engineering today, you already know the reality:

Infrastructure is defined in code
Systems span multiple services, regions, and teams
Failures are rarely isolated

And yet, teams still struggle with the same issues:

Knowledge silos
Poor documentation
Engineers afraid to admit they don’t know something

That’s not a technical problem. That’s a leadership problem. Because leadership isn’t about having all the answers.

It’s about creating an environment where answers can be found.

Practical Advice

If you want to grow as an engineer—and eventually as a leader—this is what actually matters.

Share What You Learn
- Don’t wait until you’re an expert. You won’t feel like one anyway. Write it down. Post it. Teach it. That’s how you get better.
Ask Questions Earlier
- The longer you wait, the more expensive the mistake becomes. Good engineers ask questions. Great engineers ask them sooner.
Break Down Silos
- If you’re the only one who understands a system, that’s not job security. That’s risk. Make yourself replaceable. That’s how you become valuable.
Build in Public
- Whether it’s Azure deployments, Terraform modules, or troubleshooting guides—share it. Someone else is dealing with the same problem. Be the person who helps them solve it.
Teach What You Know
- Teaching forces clarity. If you can’t explain it simply, you don’t understand it well enough. And when you teach, you multiply your impact.

The Bigger Picture

That moment on the ship wasn’t about a cable.

It was about how people work together under pressure.

No one person saved the day.

The team did.

That lesson carried through everything:

My time in the Navy
My work in cloud engineering
My role as an Azure trainer
My life after being diagnosed with MS

The systems we build today are more complex than anything we’ve worked on before.

But the principle hasn’t changed.

We don’t solve hard problems alone.

What You Should Do

Start small.

Document one thing you learned this week
Share it with someone else
Ask one question you’ve been avoiding
Help one person who’s stuck
Teach something—even if it’s basic

Do that consistently, and everything changes.

Final Thoughts

The future of engineering isn’t built by individuals trying to prove how much they know.

It’s built by teams willing to share, teach, and grow together.

Strength is not independence. It’s interdependence.

And if you understand that, you’re already ahead of most engineers.