The Architect's Vanity: How I Engineered My Own Technical Debt

Hervé Hildenbrand

04 Jun 2026 — 3 min read

I spent six months reading RFCs to build a global RSVP-TE backbone only I could safely operate.

The engineers who replaced me ripped it out in a week.

And they were right.

We usually blame technical debt on rushing, budget pressure, poor documentation or laziness. The most dangerous debt I ever created came from the opposite place: ambition.

I have a name for it now: Architectural Vanity.

It's the debt you create when you build the network you want to play with instead of the network the business actually needs.

The 20Gbps Elephant

This was the early 2010s. I was managing a global backbone across three continents wrestling with 20Gbps elephant flows between our European and Asian hubs.

I was convinced standard IGP routing was too blunt an instrument. I wanted surgical control.

So I merged the networks into a single IGP and layered MPLS RSVP-TE on top. I spent months reading RFCs, building the design and hand-crafting Label Switched Paths to steer traffic across specific intercontinental links.

The deployment was flawless. The routing tables were a masterpiece.

That was the problem.

The LSPs came up, traffic moved exactly where I steered it, and the business outcome was almost invisible. I had built a complex traffic-engineering system that performed roughly like a much simpler design would have.

Only with more moving parts, more operational risk, and a much higher dependency on me.

The Aftermath

There was no automation. Every change required careful manual work. Every failure scenario required someone who understood not just the design, but the intent behind every exception.

That someone was me.

When I moved to another role, reality set in fast. The engineers who inherited the network didn't inherit a clean platform. They inherited a system that was technically elegant and operationally fragile.

It wasn't the asset I'd imagined. It was an architecture whose safety depended entirely on its author.

So they did the right thing.

They stripped it back to something defensible. They traded my engineered perfection for something more valuable: survivability.

At the time it stung. Looking back they were obviously correct.

The Vanity Test

Before your next major design, ask yourself three uncomfortable questions.

The Bus Factor: If you leave tomorrow, does the architecture remain a business asset, or does it become an operational liability?

The Motive: Are you solving a real business constraint, or are you giving your own technical curiosity production privileges?

The 3 AM Rule: Can a competent mid-level engineer troubleshoot this during an incident without calling you?

If the answer is no, you may not be building resilience. You may be building dependency.

The Lesson Applied

That failure changed how I approach architecture. You can see it in my most recent project: a multi-site EVPN/VXLAN fabric.

Ten years ago, I would have locked myself in a room, written every line of configuration, and made every technical decision myself.

This time I did something harder.

I defined the intent, the business constraints, and the architectural boundaries. Then I let the engineers building the fabric own the technical decisions.

Not without supervision.

They still had to understand the design at the level where it actually fails: oversubscription ratios, BGP timers, failure domains, rollback plans. But the decisions were theirs.

My job wasn't to disappear from the technical layer. It was to stay close enough to challenge the design, catch weak assumptions, and protect the intent without becoming the only person who could operate the result.

That's harder than building it yourself.

When you build it yourself, you control the complexity. When you delegate it, you have to understand the complexity well enough to supervise it, and resist the urge to take it back.

The business didn't need my masterpiece. It needed a resilient platform and a team that could run it without me.