Architecture Decisions That Outlive Teams

In 2004, I watched a team of very smart people build something very stupid.

They were designing a content management system for Nike's growing ecommerce operation. The requirements were reasonable. The budget was adequate. The timeline was aggressive but plausible.

The problem was architectural.

They decided to build everything from scratch. Custom CMS. Custom checkout. Custom inventory logic. Custom everything.

Their reasoning was familiar: "Off‑the‑shelf won't meet our needs." "We need to differentiate." "We'll move faster if we control the stack."

I was junior enough to stay quiet. Senior enough to know it was wrong.

Three years later, that system was replaced. The team that built it had scattered. The documentation was incomplete. The technical debt was staggering.

The successors—people the original team never met—spent eighteen months unwinding what had taken three years to build.

That experience rewired how I think about architecture.

**The Two Audiences**

Every architecture decision has two audiences.

The first is the current team. They need to ship. They need velocity. They need to feel smart and capable.

The second is the future team. You will never meet them. They will never thank you. But they will inherit every shortcut, every clever hack, every "we'll fix it later" that you leave behind.

Most organizations design for the first audience.

The durable ones design for both.

This is not about writing perfect code. Perfect code doesn't exist. It's about recognizing that software outlasts people, and decisions compound in ways you cannot fully control.

**What I Learned at Microsoft**

At Microsoft, the stakes were higher.

Not because the code was more important—but because the number of future teams was larger. Everything we built would be touched by dozens of people across multiple years and multiple continents.

The question was no longer "Can we build this?"

The question was "Can someone we've never met understand this well enough to change it without breaking everything?"

That question changes how you approach every decision:

You document not just what, but why.

You choose boring technology because boring means more people understand it.

You resist the temptation to be clever because clever is just hard to debug at 2 a.m.

You name things consistently, even when inconsistent naming would ship faster today.

These disciplines feel like friction in the moment. They feel like overhead. They are overhead—invested now to pay dividends later.

**What I Got Wrong**

Early in my career, I thought architecture was about technical elegance.

I admired systems that were beautiful. Clean abstractions. Elegant patterns. Code that felt like poetry.

That admiration was not entirely wrong. Beauty in systems often correlates with durability.

But I missed something important:

The most durable systems are not the most beautiful. They are the most replaceable.

The goal is not to build something that lasts forever. The goal is to build something that can be replaced piece by piece without grinding the business to a halt.

That insight came from watching too many teams trapped by their own cleverness. They had built something so perfect that changing it felt like sacrilege. So they didn't change it. And the business outgrew them.

Better to build something ugly that can evolve than something beautiful that can't.

**The CEO Lens**

When I became CEO, architecture stopped being about technology.

It became about organizational design.

The same principles apply:

Every structure you create has two audiences: the people who work inside it now, and the people who will inherit it later.

The most durable organizations are not the most elegantly designed. They are the most adaptable.

You build in replaceability. You create room for successors. You resist the temptation to make yourself indispensable.

This is hard. Ego fights it. Fear fights it. The urgency of today fights it.

But the companies that last are the ones where the founders and CEOs built systems that could function without them.

**What I Carry Forward**

I no longer admire architecture for its own sake.

I admire architecture that:

• Creates clarity. Someone six months from now should understand why a decision was made.

• Enables replacement. No single component should be too painful to change.

• Respects its successors. The people coming after you are not less capable. They just know different things. Build for their context, not yours.

• Aligns incentives. Structure follows strategy. If the structure fights the strategy, the strategy loses.

These are not technical principles. They are human principles expressed through systems.