Yesterday's Feature Is Today's Bug

On building IT strategy that outlasts the people who built it.

---

There's a phrase I keep coming back to in my work as an engineering leader: "Yesterday's feature is today's bug."

It started as a way to describe something familiar to every software team. That moment when you realize the thing you built on purpose, the thing you celebrated at launch, is now the thing causing problems. Not because someone made a mistake. But because the context around it changed.

The more I've sat with this idea, the more I've realized it applies far beyond software. It describes something fundamental about how technology strategy works inside organizations, and what it means to build something that actually lasts.

---

The Revolving Door Is a Feature, Not a Bug

Leadership transitions are inevitable. CIOs move on. CTOs get promoted or recruited away. New VPs come in with fresh mandates and fresh eyes. If you've been in technology long enough, you've lived through at least one of these moments where someone new walks in and the first question they ask is some version of "why are we doing it this way?"

It's easy to feel defensive in that moment. Your team built that thing. You made that call. It worked.

But here's the reframe I've come to believe: the revolving door of leadership isn't a threat to good strategy. It's a test of it. If your IT strategy can't survive a leadership transition, it probably wasn't a strategy. It was a preference. Someone's aesthetic. A personality expressed as architecture.

When a new leader looks at your platform and asks hard questions, that's not an attack. That's the system working. Fresh eyes see what familiarity hides. And if your strategy is sound, if it's built on real outcomes and real principles, it will hold up under scrutiny. It might even get better because of it.

---

Build on Principles, Not Personalities

The most durable IT strategies I've seen share something in common: they're anchored to outcomes, not opinions.

Not "we do it this way because the last CTO liked it." But "we do it this way because it reduces toil, increases deployment frequency, and keeps our teams safe." Security. Developer experience. Reliability. Speed. These aren't preferences, they're compasses. And compasses don't need to be re-validated every time someone new joins the executive team.

When I think about the work my teams are doing right now, pipeline-first delivery, cloud migration, platform consolidation, I try to ask myself a simple question: Is this rooted in a principle, or a personality? If I left tomorrow, would the team know why they're doing what they're doing? Would the next leader be able to pick this up and run with it?

That's the standard I'm working toward. Not a strategy that makes me look good. A strategy that keeps working after I've moved on.

---

Design for Succession

This one is uncomfortable to sit with, but it's important.

The best engineering leaders build platforms that outlast them. They write things down. They invest in documentation, architecture decision records, runbooks. Not because they're bureaucrats, but because they're thinking about the person who comes next. They build teams that don't depend on any one person, including themselves.

If you're building monuments to yourself, you're building tomorrow's technical debt.

Succession isn't just a talent management conversation. It's an architectural philosophy. It means asking: if I walked out the door tomorrow, what would break? And then going and fixing that. Not because you're leaving, but because fragility is fragility, regardless of who holds the seat.

---

Use the Quote as a Diagnostic, Not a Verdict

When a new leader looks at your roadmap and labels something a bug, something the last team called a feature, the instinct is to defend it or bury it. Neither is right.

The better move is to ask: what changed?

Was it the customer need? The competitive landscape? The organization's risk tolerance? The technology itself? Sometimes the answer is that the new leader just has a different aesthetic, and that's worth acknowledging. But often, something real did change, and the "bug" label is a signal worth paying attention to.

"Yesterday's feature is today's bug" isn't a verdict on the past. It's a prompt to understand the present. Context drift is real. The best thing you can do as a leader is build a culture where that conversation can happen honestly. Without blame, without defensiveness, with genuine curiosity about what's actually true right now.

---

What Durable Strategy Actually Looks Like

So what does it look like in practice to build IT strategy that can survive the revolving door?

It looks like documenting why, not just what. It looks like measuring outcomes and being honest when they're not being achieved. It looks like building platforms your teams can own, not just use. It looks like creating space for new leaders to contribute and challenge and improve, without feeling like they're tearing something down.

And maybe most importantly, it looks like letting go of the idea that your strategy is yours.

The best thing any of us can build is something that keeps getting better after we're gone. That's not a small ambition. That's the whole job.

---

Yesterday's feature is today's bug. And that's okay. What matters is that you built something worth improving.