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. No one made a mistake. 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 lasts.
The revolving door is a feature, not a bug
Leadership transitions are inevitable. CIOs move on, CTOs get promoted or recruited away, and 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, and it worked.
I've come to see the revolving door of leadership as a test of good strategy. 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 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 are anchored to outcomes rather than opinions. "We do it this way because the last CTO liked it" won't survive a transition. "We do it this way because it reduces toil, increases deployment frequency, and keeps our teams safe" will. Security, developer experience, reliability, and speed are compasses. 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. I want a strategy that keeps working after I've moved on, even if it never makes me look good.
Design for succession
The best engineering leaders build platforms that outlast them. They write things down. Documentation, architecture decision records, and runbooks all read as bureaucracy right up until the person who comes next needs them. 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 is an architectural philosophy as much as a talent management conversation. It means asking: if I walked out the door tomorrow, what would break? Then you go fix it, whether or not you're leaving, 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, and both skip the real question: what changed?
Was it the customer need, the competition, the organization's risk tolerance, or 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" is a prompt to understand the present. Context drift is real. The best thing you can do is build a culture where that conversation happens honestly, with genuine curiosity instead of blame or defensiveness.
What durable strategy looks like
Building an IT strategy that can survive the revolving door comes down to a few habits. It starts with documenting the why behind a decision, not just the what. You measure outcomes, and you're honest when they aren't being achieved. Your teams own the platforms they work on. New leaders get room to contribute and challenge and improve without feeling like they're tearing something down.
Maybe most important of all is 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 the whole job.
