Seventeen certifications sounds like a hobby that got out of hand. Looked at chronologically, it's something else: a record of every time my job quietly changed underneath me, and the study that let me change with it. This article is the honest version of that record — including which credentials paid for themselves within a quarter, and which mattered mostly as forcing-functions to study things I was avoiding.

1. Read the stack as layers, not trophies

My certifications cluster into five layers, and the order tells the story of a career: infrastructure (MCSA, MCTS, MCITP, MCSE, CCNP, OCP), delivery (PMP, PMI-ACP, PRINCE2, CSM, ITIL), security & audit (CEH, CHFI, CISA, CISM, CRISC), and architecture (TOGAF) sitting on top. Each layer answered a question the previous one created:

  • Building systems raised the question: who keeps all this delivering on time?
  • Delivering projects raised: who is accountable when this gets attacked or audited?
  • Owning security raised: who decides how all of it should fit together in the first place?

A certification is worth the paper when it changes the questions you're able to ask — not just the answers you can recite.

Working note — how the five layers were counted

The five-layer grouping maps one-to-one to the domain bands on the Credential Rule: Delivery (5), Security & Audit (5), Architecture (1), Infrastructure (5) and Data (1) — seventeen ticks total. Retired credentials stay in the ledger with their original issue context rather than being deleted, so the count reflects what was actually sat, not only what is currently active.

2. The infrastructure years: Microsoft, Cisco, Oracle

The Microsoft track (MCSA → MCTS → MCITP → MCSE) gets dismissed today as legacy alphabet. I'd push back: those exams forced a systematic tour of identity, storage, networking and directory services that most engineers now absorb in fragments. When I debug a modern Entra ID conditional-access problem, I'm still drawing on Active Directory mental models earned two exam generations ago. Platforms age; models compound.

CCNP did the same for networks — subnetting, routing protocols and spanning-tree pain that make today's cloud VNets and service meshes feel familiar rather than magical. And OCP (Oracle) taught the discipline every developer eventually needs: respect for the database as a system with its own physics, not a magic JSON drawer.

3. The delivery turn: PMP, PRINCE2, ACP, CSM, ITIL

The move from "senior engineer" to "the person answerable for the outcome" is the hardest transition in a technical career, and it's the one certifications helped me with most. Four lessons that survived contact with real projects:

  1. PMP taught vocabulary, not method. Its real gift is a shared language — critical path, risk register, earned value — that lets you negotiate with sponsors, vendors and auditors precisely. You'll rarely run a textbook PMBOK project; you'll daily use its words.
  2. PRINCE2 taught governance. Its insistence on a continued business justification — should this project still exist? — kills zombie projects that agile rituals happily keep sprinting.
  3. ACP and CSM taught humility. Agile certifications are entry tickets, not mastery. Their value was forcing me, a plan-driven PM, to sit with the empirical worldview until it stopped feeling like chaos.
  4. ITIL taught the day after go-live. Projects end; services run for a decade. Incident, problem and change as distinct disciplines is the single most reused idea from my entire stack.

4. Security and audit: the ISACA trio plus EC-Council

CEH and CHFI came first — the attacker's mindset and the investigator's discipline. Then the ISACA trio (CISA, CISM, CRISC) reframed everything: security is not a technical property; it's a governance outcome. CISA taught me to think like the auditor across the table (evidence, not assurances). CISM moved me from "how do we block this?" to "who owns this risk and did they accept it knowingly?". CRISC connected both to enterprise risk language a board actually understands.

If you work anywhere near regulated industries, this trio changes your seniority ceiling more than any technical certification — because it lets you translate between the server room and the boardroom without losing meaning in either direction. I've written a full comparison in Mapping the ISACA Triangle.

5. The architecture view: TOGAF

TOGAF is the most criticised credential I hold and the one I defend most carefully. No, nobody executes the ADM cycle by the book. Yes, the framework is bureaucratic at full strength. But TOGAF gave me the one thing nothing else in the stack did: a disciplined way to connect business capability to technology change — to say "this system exists because that capability needs it" and mean something checkable. In the AI era, where every board wants transformation and every vendor sells inevitability, that discipline is the difference between a strategy and a shopping list. Longer thoughts in Does TOGAF Still Matter?.

6. Building your own stack, deliberately

What I'd tell my younger self, or anyone assembling their own stack:

  • Certify behind your curiosity, ahead of your role. The best time for each of mine was when the subject had just become 20% of my job and was heading for 50%.
  • Pick one anchor per layer. One delivery credential, one security, one architecture — depth of practice beats breadth of laminate.
  • Let the study be the product. The exam is a deadline; the transformed mental model is the deliverable. If you brain-dump your way through, you've paid full price for the receipt and thrown away the goods.
  • Renew intentionally. Every renewal cycle, ask whether that layer still earns its place. Retiring a credential you've outgrown is also a form of professional judgement.

The alphabet after a name is just the table of contents. The book is what you did with each chapter — and this site is where I'm writing mine in public. Questions about any specific path? Ask me directly; certification-path questions get priority replies.