The moment

I was in a cab leaving a client site when it hit me, and I couldn't shake it for the entire ride back.

We'd just finished presenting the results of an eighteen-month transformation program with a beautiful deck, clear metrics, success stories from pilot teams, and the executive sponsor had thanked everyone for their hard work. There was polite applause, some nodding, and then everyone filed out to their next meeting.

But on my way out, I'd stopped by the coffee machine and overheard two people from one of the "successful" pilot teams talking. "So are we actually doing any of that, or...?" one of them said. "I mean, maybe? Jenkins mentioned it in the standup last week. But nobody's really tracking it anymore." The other one laughed, not bitter, just knowing. "Yeah, figured. Remember the agile thing from two years ago?"

I got in that cab and couldn't shake it because we'd spent eighteen months on this, built new processes, trained hundreds of people, changed the org structure, and the metrics said it worked. And two people at a coffee machine had just told me the truth that it was already dying, quietly, while everyone pretended it was still alive. This wasn't the first time I'd seen this happen, but it was the first time I really let myself feel how much we were all pretending.

We measured the launch, not the landing

The transformation hadn't failed because people didn't try. It failed because the organization had an immune system, and we never designed for that. We built beautiful new ways of working and then dropped them into an environment that was architecturally incompatible with what we were asking people to do.

The old systems were still there, the old incentives, the old decision structures, the old rhythms. And slowly, quietly, they pulled everything back. Not because anyone decided to abandon the change, but because the organizational architecture underneath made the old way easier than the new way. The system won, like it always does.

I remember sitting in the presentation earlier that day, watching the slides go by showing adoption rates climbing, engagement scores improving, efficiency gains validated. All true, all measured carefully. But nobody had measured whether the new ways of working could survive contact with the daily reality of how decisions got made, resources got allocated, and performance got evaluated. We'd measured adoption but we hadn't measured whether it could last.

The pilot teams loved the new approach because we'd created protected space for them with different rules, different reporting, different expectations. But when we scaled, we didn't scale the protection, we scaled the methodology. And the methodology, no matter how good, couldn't survive in an environment designed for something else.

Same story, different company

I've been at this for almost thirty years, and somewhere in the last decade I started seeing the same thing everywhere I looked. A manufacturing company spends millions redesigning their supply chain, and six months later they're back to the old ways because "the new system didn't account for how things actually work here." A tech company launches an innovation program, and twelve months later the innovation team is frustrated because "nobody in the business wants to adopt anything we build." A professional services firm restructures around clients instead of service lines, and eighteen months later the old service line leaders are back in charge because "the clients don't actually work that way."

Different industries, different challenges, same pattern. We design the change but we don't design the conditions that would allow the change to hold. I started tracking this more carefully, not just in my own work but in every transformation story I heard, and the pattern was consistent. Initial success in pilots, excitement about scaling, then a slow, quiet dissolution that nobody wanted to name out loud.

Sometimes it took six months, sometimes eighteen, but the timeline was predictable. About two-thirds of the way through the planned timeline, momentum would start to fade. People would still talk about the transformation in meetings, but in practice old patterns would creep back in. By the end you'd have transformation theater, the language of change without the reality of it, and everyone would move on to the next thing, leaving behind another set of trained people wondering why their hard work didn't stick.

The gravitational field of daily reality

Here's what I've learned sitting in those cabs, walking out of those buildings, watching those transformations quietly dissolve. You can't bolt new ways of working onto old organizational architecture because the architecture will win every time. Not because people are resistant, not because leaders don't commit, not because the methodology was wrong, but because the daily reality of how decisions get made, how resources get allocated, how information flows, how performance gets measured, all of that creates a gravitational field. And unless you redesign that architecture, everything eventually gets pulled back.

I've watched companies spend millions on agile transformations without changing how they do annual budgeting, and the agile rituals die within six months. I've watched organizations launch innovation programs while keeping incentive structures that only reward quarterly delivery, and the innovation becomes theater. I've watched leaders champion collaboration while maintaining decision structures that require fifteen approvals, and the collaboration turns into coordination fatigue. The change work was good, but the architecture was incompatible.

At one company, they'd invested heavily in moving to cross-functional teams, trained everyone in new ways of working, created new spaces, changed the language. But they kept the functional reporting structure, kept functional budgets, kept functional performance reviews. So people went to their cross-functional team meetings and then went back to their functional managers to get their real work done and their performance evaluated.

The cross-functional work became extra, additional, something you did when you had time, which meant it never got time. Not because people didn't believe in it, but because the architecture made functional work mandatory and cross-functional work optional. The incentives were clear, and the architecture spoke louder than the training ever could.

When I stopped pretending

That cab ride was the moment I stopped pretending we could work around this. I'd spent years helping organizations transform, designing better methodologies, building stronger cultures, aligning leadership. All important, all necessary, but not sufficient. Because if the organizational architecture underneath doesn't support what you're trying to create, you're just building beautiful things that can't survive contact with daily reality.

That's when I started working differently, not starting with the transformation program but starting with the architecture. What needs to be true about how this organization makes decisions for this change to hold? What needs to be true about how we allocate resources? About how we measure what matters? About the rhythms that sustain momentum? Design those conditions first, then the change has somewhere to land.

The first few times I proposed this approach, it didn't go well. Leaders would get uncomfortable and ask, "You're saying we need to change everything before we can change anything?" Not exactly, but also, kind of yes. If you're asking people to work in cross-functional teams but you haven't changed functional budgets or performance reviews, you're not really asking them to work differently, you're asking them to pretend. If you're launching an innovation program but your incentive structure only rewards quarterly delivery, you're not creating space for innovation, you're creating space for innovation theater.

The architecture has to match what you're trying to build, or it won't hold. Some leaders got this immediately, usually because they'd lived through a transformation that dissolved and were honest enough to admit why. Others pushed back hard because acknowledging that the architecture is the problem means acknowledging that success required changing things they'd built or inherited, things that felt foundational. I get it, it's uncomfortable. But it's the conversation that matters, the one where you stop pretending the issue is execution and start admitting it's conditions.

Not redesigning everything, just the conditions

I know how this sounds, like I'm saying we need to redesign everything before we can change anything, but that's not it. What I'm saying is if you're going to spend eighteen months transforming how people work, spend at least some of that time redesigning the architecture that shapes whether those new ways of working can actually stick. Otherwise you're setting people up to do hard work that won't last, and you'll end up in a cab one day, overhearing the truth you already knew but didn't want to admit. The change didn't fail because people didn't try, it failed because we never designed the conditions that would let it survive.

I think about those two people at the coffee machine more than I probably should. They weren't cynical, they weren't resistant, they'd actually tried to make the transformation work. But they'd learned through experience that organizational memory is short and architectural gravity is strong. They'd seen the agile thing come and go, they'd seen the customer-centric thing come and go, they'd seen the innovation thing come and go. Not because the ideas were bad, but because nothing about the underlying architecture changed, and they were smart enough to recognize the pattern.

That's what broke my heart sitting in that cab. Not that the transformation was dying, but that good people had learned not to invest themselves fully in change because they'd seen too many changes dissolve. We weren't just failing to transform organizations, we were teaching people that transformation doesn't stick.

What I carry with me now

That cab ride changed how I think about transformation work. Not that I have all the answers now, but I ask different questions. Not "what do we want to transform?" but "what about how we're currently organized makes that transformation impossible?" Not "how do we implement the new model?" but "what architectural changes would allow the new model to hold?"

They're harder questions. They take longer. They make people uncomfortable because they require admitting that the problem might not be execution, it might be the conditions we've created.

But I'd rather have that honest conversation than watch another group of talented people pour themselves into change work that can't survive because we never designed the architecture to hold it.

The transformation work is still important. The methodology still matters. The culture work is still essential. But I've learned the hard way that none of it holds without the architecture to support it.

That's what that cab ride taught me, finally, after all those years of building beautiful things that quietly dissolved. The change doesn't fail in the workshop. It fails in the daily physics of organizational life. Unless you redesign the physics first.

This is part of my ongoing exploration of The Possibility Principle of Design. If you've overheard your own version of that coffee machine conversation, you already know the truth. Transformation theater isn't a training problem. It's an architecture problem.