Ten Years as a CCIE: The Foundation Matters More Than the Number

When I was early in my career, I thought of CCIEs almost like monks who had dedicated themselves completely to their craft.

They seemed to operate at a different level.

There were people I deeply respected who could look at a difficult networking problem, strip away the noise, and somehow get to the heart of it faster than everyone else in the room.

One of those people was Sean Orta, an OG CCIE who became something of a technical oracle in my mind. I used to joke that when I needed to think through something difficult, I was going to "consult the Ortacle."

The joke was lighthearted, but the respect behind it was very real.

I did not pursue the CCIE because I thought it represented the end of a journey. I pursued it because I wanted to become worthy of being in the room with people like that.

I wanted the depth.

I wanted the discipline.

I wanted to understand networking well enough that when the obvious answer was wrong, I had the foundation to keep digging.

At the same time, I never believed that earning a CCIE suddenly made someone an expert at everything.

My certification was in Routing and Switching. It did not make me a wireless expert. It did not make me a security expert. It did not make me a collaboration expert.

And even within networking, there was always another layer to learn.

That was part of the appeal.

The CCIE was never going to be the destination. It was going to be one part of a much longer journey.

Ten years later, that is still how I see it.

I am proud to have been a CCIE for a decade, but the most valuable thing was never the number.

It was the foundation.

A foundation of knowing your craft, being willing to tackle difficult problems, learning from failure, and eventually helping other people become great at the job too.

First, Get Good at the Job

There is a tendency in career conversations to rush toward leadership.

How do I become a manager?

How do I become a director?

How do I get a seat at the table?

Those are reasonable questions. But I think we sometimes skip over something important.

First, get really good at the job.

For me, networking became that foundation.

I wanted to understand why things worked, not just which commands made them work. I wanted to understand how routing protocols made decisions, how traffic actually moved through a network, how failures propagated, and why a design behaved differently at 2:00 in the morning than it did on a whiteboard.

The CCIE forced me to develop that depth.

More importantly, it gave me confidence that when I encountered something I did not understand, I could probably figure it out.

That mindset turned out to be far more valuable than any specific technology I learned along the way.

Technical expertise became the foundation for the journey, not the destination.

Fundamentals Travel Well

Technology has changed dramatically during my decade as a CCIE.

Platforms I spent countless hours learning are now obsolete or well on their way there. Entire architectural approaches have changed.

Over the years, my work expanded from traditional routing and switching into wireless, data centers, security, SD-WAN, cloud connectivity, SASE, automation, APIs, and increasingly AI-enabled operations.

I was a beginner in many of those areas at some point.

That matters because being highly skilled in one discipline can create a dangerous illusion that expertise transfers automatically.

It does not.

Being a routing and switching CCIE did not make me a wireless engineer. Understanding BGP did not mean I understood RF. Knowing spanning tree did not teach me application security. Passing a difficult certification did not somehow eliminate the need to be humble when walking into a new technical domain.

What did transfer were the fundamentals.

Break the problem apart.

Understand the system.

Question assumptions.

Follow the control plane.

Follow the data plane.

Know what normal should look like before trying to understand abnormal.

And when you do not know something, keep digging until you do.

The technologies change.

That way of thinking travels surprisingly well.

Take Bigger Swings

My career since earning the CCIE has involved a series of increasingly large leaps of faith.

Changing companies.

Taking on technologies I did not yet understand deeply.

Moving from individual contributor roles into leadership.

Taking responsibility for increasingly large environments.

And eventually helping lead a network transformation spanning approximately 16,500 retail locations.

Every step increased the consequences of being wrong.

That last point is important.

It is relatively easy to talk about taking risks after everything works.

It is much harder when you are in the middle of it.

The store network transformation became one of the defining experiences of my career. The goal was to modernize connectivity, security, wireless capabilities, and the overall network architecture across an enormous distributed environment.

On a PowerPoint slide, that sounds straightforward.

At 16,500 locations, nothing is straightforward.

A design can work perfectly in the lab and fail because of an edge case you discover only after thousands of deployments.

A process that seems reasonable with ten sites can collapse under the weight of ten thousand.

An operational assumption can survive for years until automation suddenly exposes how inconsistent the environment really is.

And sometimes, despite having smart people, good technology, and a solid plan, you simply get something wrong.

We certainly did.

The J-Curve Is Real

One of the things that experience taught me was how real the J-curve can be during transformation.

When an organization begins changing something fundamental, performance does not always immediately improve.

Sometimes it gets worse first.

Meaningful transformation often gets harder before it gets better.

The old environment might have been imperfect, but everyone understood it.

People knew the workarounds.

Operational procedures had grown around its limitations.

Teams knew which strange behaviors could safely be ignored and which ones meant something was truly broken.

Then you replace it.

Suddenly there are new technologies, new processes, new dependencies, new responsibilities, and new failure modes.

For a period of time, the organization can feel like it is moving backward.

That is the bottom of the J.

And it can be an uncomfortable place to lead from.

During the store transformation, there were periods where we were learning at the same time we were deploying.

There were mistakes.

There were operational challenges.

There were moments when metrics did not necessarily tell the story we wanted them to tell.

There were plenty of opportunities to question whether moving as aggressively as we were moving was the right decision.

But we kept going.

The primary transformation, originally envisioned as a multi-year program, was ultimately completed across the enterprise footprint on a much more aggressive timeline.

Looking back, I do not think the lesson is that we executed everything perfectly.

We did not.

The lesson is that we learned faster than the problems could defeat us.

At sufficient scale, success is rarely the absence of failure.

Success is building an organization capable of recognizing failure, learning from it, correcting course, and continuing forward.

Failing at Scale Is Different

One of the uncomfortable realities of leadership is that the size of your failures tends to grow with the size of your responsibilities.

As an individual engineer, I could make a mistake that affected a device.

Later, I could make one that affected a site.

Eventually, the decisions involved hundreds, thousands, or potentially tens of thousands of locations.

That does not mean standards should become lower.

It means the systems surrounding decisions have to become better.

Testing.

Automation.

Telemetry.

Change controls.

Rollback strategies.

Canary deployments.

Post-incident reviews.

And perhaps most importantly, a culture where people can say, "This did not work," without spending the next several hours trying to explain why it was someone else's fault.

The goal is not to create an organization where nobody makes mistakes.

I am not sure that organization exists.

The goal is to create one where mistakes become information.

That was one of the most important lessons I took away from operating at much larger scale.

Scale Changes the Definition of Good Engineering

Earlier in my career, I often evaluated solutions primarily on whether they were technically correct.

As my responsibilities grew, I learned that technically correct is only the starting point.

A beautiful architecture across five devices can become an operational nightmare across five thousand.

At enterprise scale, good engineering includes a much broader set of questions.

Can we deploy this consistently?

Can we automate it?

Can someone other than the person who designed it understand it?

Can an operations team troubleshoot it at 2:00 AM?

Can we upgrade it safely?

What happens when one dependency fails?

What happens when several dependencies fail at once?

Can we observe what it is doing?

Can we explain the risk to someone who does not know what BGP is?

And perhaps most importantly, does the additional complexity create enough business value to justify itself?

That last question took me longer to appreciate than I would like to admit.

Engineers naturally value technical elegance.

Organizations value outcomes.

The two can align, but they are not automatically the same thing.

The goal is not to build the most technically impressive network.

The goal is to build the network the organization needs.

The MBA Challenged the Engineer in Me

Years after earning the CCIE, I made another deliberate decision to put myself somewhere I would not be the expert.

I went back to school for an Executive MBA at William & Mary.

In some ways, the experience reminded me of being earlier in my technical career.

There were entire disciplines where I had significant gaps.

Finance.

Economics.

Strategy.

Marketing.

Organizational behavior.

Change management.

I could not troubleshoot my way through a discounted cash flow model with show commands.

And that was exactly the point.

The experience reinforced something I had already started learning through leadership.

The technically best answer is not always the best answer for the business.

Engineers are trained to optimize systems.

Businesses require leaders to optimize across competing constraints.

Capital matters.

Timing matters.

Organizational readiness matters.

Customer impact matters.

Risk tolerance matters.

People matter.

One of the themes I kept returning to during the MBA was change.

Technology organizations often talk about managing change as if our job is primarily to make sure changes are approved safely.

But transformation is different.

Transformation is about managing risk while deliberately moving an organization from one state to another.

That requires technical judgment.

It also requires trust, communication, sequencing, organizational alignment, and sometimes the willingness to keep moving when you are somewhere near the bottom of the J-curve.

Technical leadership lives at the intersection of engineering depth and business judgment.

The Hardest Problems Eventually Stop Being Technical

At some point in a technology career, the hardest problems change.

Designing a resilient network is difficult.

Getting the funding, organizational alignment, staffing, vendor commitments, security approvals, change windows, and executive support necessary to actually implement it can be much harder.

The technology becomes one variable among many.

That realization changed how I think about leadership.

My job is no longer to personally solve every difficult technical problem.

In fact, if every difficult problem requires me to solve it, then I have probably created an organization that does not scale very well.

The goal is to create teams capable of solving problems without me.

That requires teaching.

Coaching.

Creating standards.

Asking good questions.

Giving people room to make decisions.

Allowing them to occasionally get those decisions wrong.

And then helping them understand why.

Earlier in my career, being the person who knew the answer felt valuable.

Today, helping ten other people become capable of finding the answer is much more valuable.

That may be one of the biggest changes in how I define technical leadership.

Be Good, Then Help Other People Be Good

I still believe strongly in technical excellence.

Leadership is not a substitute for competence.

Communication is not a substitute for understanding the technology.

And a title does not automatically make someone's judgment better.

There is enormous value in being good at your craft.

But over time, the responsibility changes.

First, become good at the job.

Then help someone else become good at it.

Teach them why.

Let them challenge you.

Give them increasingly difficult problems.

Let them see how you think through ambiguity.

Let them make decisions.

And eventually, give them a problem that they can solve better than you can.

That is success.

The people I respected most early in my career were not impressive simply because they knew more than I did.

They made me want to know more too.

Looking back, that may be what I was really saying when I joked about consulting the Ortacle.

I respected the mastery.

But I also respected the willingness to share it.

Ten years later, I increasingly believe that expertise reaches its highest value when it becomes transferable.

Technical Credibility Still Matters

None of this means technical depth becomes irrelevant as you move into leadership.

I think the opposite is true.

Technical credibility remains one of the most useful tools I have.

It allows me to ask better questions.

It helps me determine whether a constraint is real or assumed.

It lets me challenge a vendor when something does not sound quite right.

It helps me evaluate technical risk.

And when an engineer brings me a difficult problem, I can usually follow the conversation deeply enough to understand why the problem matters.

The difference is that I no longer need to prove that I can solve every problem myself.

That may be one of the more important transitions from engineer to leader.

Knowing when to go deep is valuable.

Knowing when not to is equally valuable.

Expertise Should Be a Foundation, Not an Identity

I am proud to be a CCIE.

But I have never wanted CCIE to become my professional identity.

A certification captures something you accomplished at a particular moment.

A career is a much longer story.

If the most impressive thing I could say about myself today was something I accomplished ten years ago, I would consider that a problem.

The value of expertise is what it allows you to build afterward.

For me, that has meant increasingly larger systems, larger teams, larger transformations, and larger risks.

It has meant getting things wrong.

It has meant changing direction.

It has meant walking into situations where I did not know all the answers.

It has meant trusting people.

It has meant convincing other people to trust me.

It has meant becoming a student again and again.

And sometimes it has meant taking a leap before knowing exactly how we were going to land it.

The foundation made those leaps possible.

Ten Years Later

If I could talk to the engineer who was working toward his CCIE more than ten years ago, I think I would tell him something pretty simple.

You are right to respect the people who have mastered their craft.

Learn everything you can from them.

Get good at the job.

Really good.

But never mistake expertise in one discipline for expertise in all of them.

Stay curious enough to become a beginner again.

Take the opportunities that feel slightly larger than you are ready for.

Expect that some of your biggest successes will spend time looking like failures.

When you reach the bottom of the J-curve, learn faster.

Do not confuse complexity with excellence.

Remember that technology exists to create outcomes for people and businesses.

And as your career progresses, spend less time proving how much you know and more time helping other people become great at what they do.

The CCIE helped teach me how to be a better engineer.

The decade since has taught me that being a great engineer is only the beginning.

The real opportunity is to take that foundation, continue building on it, and eventually use it to help an entire organization become better.

Ten years later, that means much more to me than the number ever could.