When the Expiry Emails Stop Hurting
If you’ve been in this industry long enough, you know the ritual.
The email arrives:
“Dear Candidate, your certification will expire in 120 days. Please schedule your recertification exam…”
At the beginning of your career, that email sparks urgency. You print blueprints, book labs, buy practice exams, and block weekends. The certification means something big: entry into a specific tribe, validation that you belong.
I went through that cycle many times. Years of it.
I recertified over and over.
But at some point, something shifted.
I looked at one of those emails, and instead of feeling pressure, I felt… tired. Not tired of learning, I never stopped learning, but tired of the treadmill. Tired of the idea that every few years, someone somewhere expected me to prove, via a multiple-choice exam or lab scenario, that I still knew what I’d been doing every single day in production.
I caught myself asking:
“What exactly am I trying to prove at this point? And to whom?”
By then, I had decades of real experience behind me:
Different industries and verticals: banks, enterprises, ISPs, data centers, big techs.
Architectures that moved real money, supported real operations, kept real businesses alive.
Projects with CAPEX and OPEX numbers that made people sit up straight in meetings.
And yet, some automated system somewhere would happily mark me as “expired” if I didn’t sit a specific exam on time.
One day, I simply decided: Enough.
I stopped renewing. One by one, the badges went from “Active” to “Expired,” and you know what happened?
Nothing.
The routers didn’t explode, the MPLS cores didn’t melt, and my career didn’t collapse.
I just kept working, building, troubleshooting, and learning… exactly as before.
Big Tech Reality: Impact Over Acronyms
If you’ve ever worked in FAANG-style companies, you know how irrelevant certifications become in that environment.
Nobody cared what logo I had on a piece of paper.
What they cared about was:
Can you understand complex, distributed systems?
Can you reason clearly about failure domains, blast radius, and availability?
Can you design changes that scale from one site to hundreds?
Can you collaborate, write, document, and lead?
I’ve seen people with spectacular certification stacks join such companies and struggle badly. Memorized commands and lab muscle memory don’t help much when the problems look like:
“How do we design this control plane so that a partial region failure doesn’t cascade into global instability?”
“How do we push a million config deltas this week while keeping error rates close to zero?”
“How do we reduce MTTR for this class of incidents by 80% over the next quarter?”
One story stuck with me: a double CCIE who, on paper, was a superstar.
On the ground, he didn’t clear the bar during probation.
Not because he didn’t know BGP or MPLS; he did, and quite well.
But because certification-acquired knowledge alone wasn’t enough.
These companies evaluate:
How you think.
How you handle ambiguity.
How you react under pressure.
Whether you can actually deliver outcomes aligned with their culture and expectations.
In that world, certifications are background noise. Your track record, your judgment, and your behavior are the only real currency.
That experience hardened a belief I already had:
Continuous learning matters.
Expiry dates on certificates do not.
Outside the Bubble and Where the Badge Still Opens the Door
But let’s not pretend FAANG is the whole industry.
Step outside that bubble, into telcos, integrators, large enterprises, government, consulting, and the game changes again.
Suddenly, certifications often become:
Checkboxes on RFPs: “Must provide two CCIEs and one CCDE assigned to the project.”
Partner program requirements: “To reach Gold/Platinum status, your company must maintain X number of certified professionals.”
HR filters: “Applications without XYZ certification will not be considered.”
I’ve seen companies refuse to even speak to highly capable, really competent engineers because their CV lacked a particular acronym, while happily interviewing far weaker candidates who had it.
Do I think this is ideal? No.
Do I think it’s a reality in large parts of the market? Yes.
Moreover, here's what I think:
In some environments (hyperscalers, strong engineering cultures), certifications barely register.
In others, their absence can quietly block you from even being considered, no matter how strong your real-world experience is.
It’s irrational, but you ignore it at your own cost.
Learning Without Expiry and My Three Decades of Staying Sharp
Through all of this, there’s something I have never stopped doing: learning.
I’ve been around long enough to remember:
The early days of the commercial Internet.
Protocols and architectures that are now considered “legacy” (but are still running in dark corners somewhere).
The rollout of MPLS, TE, VPLS, and L3VPNs.
The SDN wave, EVPN, segment routing, and route reflectors at a massive scale.
The rise of cloud, automation, telemetry, and intent-based networking.
At no point did I say, “Okay, I’m done. I know enough.”
Even when I stepped away from the cert treadmill, I never stepped away from the RFCs, books, courses, bootcamps, deep research, PoCs, labs, design reviews, and war-room incidents that teach you more in 24 hours than any exam ever will.
Teaching actually amplified that.
I’ve delivered a ton of official courses over the years, including vendor training, advanced workshops, and design bootcamps. But I’ve always seen myself as an engineer first, instructor second.
I teach what I actually do:
The protocols I operate.
The architectures I design.
The migrations I execute.
The failures I’ve personally caused and fixed.
Every time I teach, I learn.
Students ask uncomfortable questions, someone challenges an assumption, and I am forced to explain a trade-off I'd normally make on autopilot.
That’s when you realize: “Oh, I need to go deeper here. I’ve been glossing over this detail.”
No exam registration required.
“Why Don’t You Have CCDE?”
Now we get to the question that changed my mind.
Recently, someone close to me, someone who knows my background and my work, asked:
“Given everything you’ve done… why don’t you have the CCDE?”
My first reaction was honest and a little defensive:
“Because it doesn’t change what I can design.”
“Because I’ve already delivered architectures on the scale and complexity that CCDE problems describe.”
“Because my value isn’t defined by a Cisco logo.”
All of that is true.
I’ve designed and deployed systems that saved multi-millions in CAPEX and OPEX, improved resiliency, simplified operations, and delivered solid ROI. None of those wins required a CCDE number next to my name.
But the question stayed with me, and after the emotional reaction faded, a more rational one emerged:
“It might not change who I am as an engineer…
but could it change which doors open?”
That’s a different lens.
Seeing Certifications as Signal, Not Identity
Earlier in my career, certifications were a huge part of my professional identity. I don’t think I’m alone in that:
“I am a CCNP.”
“I am a CCIE.”
Those badges felt like tribes. You’d go to events and meet “one of us.” You’d share lab stories and war tales with people who had gone through the same hell.
As you gain experience, that framing stops working.
You start thinking more in terms of:
“These are the kinds of systems I’ve built.”
“These are the environments I’ve operated in.”
“These are the business outcomes I’ve consistently delivered.”
In that world, a certification becomes metadata:
useful, but not central
a signal, not your identity
I’ve come to believe this:
Certifications should validate and structure the learning you are already doing.
They should unlock opportunities, projects, contracts, roles, that align with your trajectory.
They should reassure stakeholders who don’t yet have direct experience working with you.
They should not be:
The only thing you’ve got going for you.
A substitute for curiosity or hands-on work.
A reason to stop learning once you “pass.”
When I looked at CCDE through that lens, and not as a badge to feel good about, but as a signal and a tool, the equation somewhat changed.
Why CCDE, Why Now
So why pick up the CCDE now, after years of letting other certs expire?
A few reasons.
1. CCDE is about how you think, not which command you type
CCDE is explicitly a design certification.
It tests:
How you gather and interpret requirements.
How you handle conflicting constraints (cost vs. availability, performance vs. complexity).
How you choose between architectures, given specific trade-offs.
How you reason about operations, migrations, and risk.
That aligns perfectly with where I live professionally today: architecture, strategy, trade-offs, and large-scale designs.
I’m not studying CCDE to learn how to think about networks. I already do that every day.
I’m studying it to sharpen that thinking and force myself to revisit and formalize patterns I may currently use instinctively.
2. It’s a key for certain markets and contracts
Like it or not, there are clients, partners, and opportunities where CCDE means something before they ever meet you:
RFPs that explicitly list it as a desired or mandatory credential.
C-level stakeholders who use it as a proxy for “this person understands design, not just CLI.”
Consulting engagements where having CCDE in the proposal simplifies the perception battle.
I already know how to do the work.
CCDE simply makes it easier for some people to believe that before we’ve built trust.
In business terms, that’s a good return on investment.
3. It’s an opportunity to formalize decades of experience
When you’ve been doing something for a long time, much of your judgment is implicit. You just “know” that one design is safer than another, or that one migration path is suicidal.
Preparing for CCDE forces me to:
Name those instincts.
Map them to formal patterns and design models.
Examine edge cases I haven’t hit yet, but will.
It’s like refactoring old, battle-hardened code: you keep the logic but structure it better, document it, and remove the weird hacks.
That’s valuable at any stage of a career.
How I’m Approaching CCDE as a Senior Engineer (Designing the Journey)
I’m not 22, living in a lab for six months to chase a first big badge.
My life doesn’t revolve around the exam calendar.
So my approach to CCDE has to be different.
Here’s what it looks like for me:
Start from reality, not from the exam.
I map scenarios I’ve already dealt with: ISP cores, DC fabrics, L3VPN overlays, peering and transit, multi-region clouds, onto the CCDE blueprint. Where are the overlaps? Where are the gaps?Use work as practice.
Every design review, every customer discussion, every article I write becomes training material. When we debate options internally, I intentionally frame the conversation like a CCDE question: requirements, constraints, options, pros/cons, recommendation.Read with a design lens.
When I pick up the CCDE Official Cert Guide on the Kindle (right after a bite of Murgh Jalfrezi), I’m not memorizing tables. I’m looking for patterns, phrasing, and blind spots: “How would I have approached this differently? Why did they model it this way?”Leverage teaching.
When I teach advanced design topics, I use those sessions to test my own reasoning. If I can’t explain a trade-off simply, I probably don’t understand it deeply enough, regardless of what the exam might say.
In other words, I’m not pausing my career to chase CCDE.
I’m weaving CCDE into a career that’s already in motion.
How You Might Think About Certifications in Your Own Career
This isn’t an argument for or against certifications.
It’s an argument for being intentional with them.
Here’s a way to think about it, depending on where you are.
Early career
Certifications can be powerful:
They structure your learning.
They give you confidence.
They help you get noticed in a stack of CVs when you don’t have experience yet.
If you’re just starting, getting something like a CCNA/CCNP or equivalent can absolutely move you forward. Just don’t let the badge become the destination. It’s a stepping stone.
Mid-career
This is where you need to start being selective:
Avoid chasing every new badge because “everyone else is.”
Choose certs that align with the type of work you actually want: design, operations, automation, cloud, security.
Ask yourself honestly: “Is this certification going to help me get better at my craft or open meaningful opportunities, or am I just afraid of falling behind?”
You might let some things expire, and that may be exactly the right call.
Senior/principal level
At this point, certifications are tools, not milestones.
You use them when:
A particular credential unlocks a market, contract, or role you care about.
It forces you to formalize skills you already practice and maybe fill strategic gaps.
It supports the brand you’re building as a consultant, architect, or leader.
You don’t use them:
To prove you’re “still relevant.” Your work and impact should do that.
Because you’re afraid of the word “expired” in a database somewhere.
In short:
Early on, certifications can help you become someone.
Later on, they can help the world recognize who you already are.
The Plate, the Kindle, and the Principle That Never Expires
So here we are.
A plate, some Murgh Jalfrezi, and a Kindle showing the CCDE Official Cert Guide.
To some people, that picture says: “He’s chasing another cert.”
To me, it says something different:
After three decades in this field, I still care enough to sit down, learn, and be tested, not because I need to prove my worth, but because I see an opportunity to grow, refine, and open new doors.
Certifications expire. Logos change. Partner programs come and go.
The only thing that doesn’t expire is the mindset you bring to your craft.
For me, long before it was printed on any office wall, the principle was simple:
Learn and Be Curious.
I carried it through legacy protocols, big iron routers, MPLS backbones, early cloud, hyperscale designs, and now into a world of automation and AI.
Letting certs lapse never meant I stopped learning.
Starting CCDE now doesn’t mean I finally took learning seriously.
It just means that, at this moment, there’s a particular intersection of what I know, what I want to do next, and how the market thinks, and CCDE happens to sit right there.
If you’re wondering whether you should pursue or renew a certification, maybe the real question isn’t:
“Do I need this badge?”
It’s:
“Given where I am and where I want to go,
is this certification a distraction, or is it a lever?”
If it’s a distraction, let it go. Your curiosity and your work will carry you. If it’s a lever, grab it with both hands and pull.
As for me?
The journey won’t be easy. It never is. But it will be brilliant.
And yes, this time, the main course is CCDE.
The Murgh Jalfrezi comes second. 😅
Leonardo Furtado