The Innovation Theatre Problem

Most large organisations have innovation programmes. They have dedicated teams, quarterly hackathons, innovation budgets, and Chief Innovation Officers. And they produce almost nothing.

I've been in these meetings from both sides: as a senior executive at a Fortune 500 company where innovation was treated as a department, and as an advisor and operator building ventures where innovation is survival. The gap between what these programs promise and what they deliver isn't a failure of effort. It's a structural contradiction.

Here's what's actually happening in most organisations: innovation has been isolated from real decision-making power. You celebrate the ideas. You run the hackathon. You pick a winner. And then you ask the winner to present to the steering committee. That's when reality collides with the programme. Because the committee controls the budget. The committee controls the timeline. The committee controls whether you need six approvals or sixty to change anything.

The second problem is that we celebrate ideation instead of execution. "We had 150 ideas submitted!" Yes. And how many shipped? We treat the quantity of ideas as the metric of innovation success, when the actual metric is: did this change the business? Did this solve a real problem faster or better than it was being solved before?

Third, and most damaging: these programmes create the appearance of entrepreneurial culture without creating the conditions for it to actually take hold. You can't build a culture of transformational thinking on Tuesdays at the hackathon while everything else in the organisation runs on the approval architecture of a company where change takes eighteen months. The people watching aren't stupid. They see the contradiction. And they stop believing.

Innovation Theatre
  • Ideas evaluated in a vacuum from decision-making
  • Celebration of quantity over execution
  • Innovation isolated to a dedicated function
  • Long approval chains for implementation
  • New ideas compete with old processes
Real Innovation Culture
  • Ideas tested against market reality immediately
  • Obsession with getting to execution fast
  • Innovation embedded in how all decisions happen
  • Permission architecture designed for speed
  • New ideas replace old processes actively

What the AI Era Actually Demands

I want to be direct about this: AI doesn't make innovation easier. It accelerates the cost of slow thinking.

Most organisations are approaching AI as a tool to be deployed. You get some training. You identify some processes where you could use a language model. You run a pilot. You hope the results justify the investment. That's a tools-based approach, and it will deliver incrementally better outcomes. But it's not what the AI era demands.

What it actually demands is a fundamental shift in operating tempo and decision-making architecture. The environment is changing faster. Not slightly faster—orders of magnitude faster. A market window that used to last three years now lasts eighteen months. A capability that took two years to build can now be built in two months. An assumption that was true last quarter might be false this month.

The organisations winning in this environment aren't the ones with the best AI models. They're the ones that can operate faster than their environment changes. They assume that the plan from three months ago is partly wrong. They're already testing the next version. They move capital and people away from what's not working without needing a committee to bless it.

In the AI era, speed of learning compounds faster than speed of execution. If your decision-making architecture requires approval at every stage, you'll always be learning slower than your environment is changing.

This is where founders have an advantage. We've been operating in this mode since day one. The hypothesis we started with is wrong by month three. We know this. We've built systems to test, learn, and shift quickly. But most corporate decision-making isn't designed for this. It's designed for certainty, for vetting, for making sure we don't make a mistake. In a slow-moving environment, that's wisdom. In an environment moving at AI-speed, it's a death sentence.

The Four Things Leaders Do to Make Transformational Thinking Contagious

I've studied this from both angles, and the pattern is clear. The leaders who make transformational thinking actually contagious across their organisation are doing four specific things. Most organisations are doing none of them.

1. They Tolerate Intelligent Failure Visibly

Not in speeches. In how they actually respond when failure happens in front of the team.

I had a director report to me who proposed a market entry strategy that was bold. It required us to move faster than we'd ever moved before, burn capital we weren't sure we could recoup, and challenge an entrenched competitor. I could have said no. The risk assessment alone would have justified it. Instead, I asked her: "What's the downside if this doesn't work?" She had the answer. We moved forward.

We failed. The market wasn't ready. We lost the investment. And what I did next mattered more than the failure itself: I promoted her six months later. Not because we'd failed, but because she'd done rigorous thinking, moved fast, tested reality, and learned something valuable about the market that the organisation now understood for certain.

That signal moved through the organisation. People watched what happened to her. And suddenly, people who'd been afraid to propose bold things because one failure might end their career saw that the real career risk was staying in the safe lane where transformational thinking never happens.

Visible tolerance of intelligent failure is how you signal that this organisation rewards learning over risk avoidance.

2. They Model the Learning Posture

They're seen learning new things. Asking questions they don't know the answer to. Changing their minds based on evidence. In front of the team.

The most dangerous thing a leader can do in the AI era is pretend to understand something they don't. Your team knows. They can sense it. And when they see you nodding confidently about a technology or market dynamic you don't actually understand, they take the signal: pretend to understand things. Don't ask questions. Don't expose uncertainty.

I spend time learning things my team knows better than I do. I ask them to teach me. I read things I don't understand and ask for help interpreting them. I've changed major strategic positions because someone brought me new data and made a better argument than what I believed before. And I do this deliberately, in public, because I need my team to know that learning isn't a career liability in this organisation.

When the leader models "I don't know the answer, let's figure it out together," the team permission for uncertainty cascades down. People start testing ideas without requiring absolute confidence first. They share half-formed thoughts in meetings instead of only bringing fully-baked recommendations. The entire operating tempo accelerates.

3. They Connect Innovation to Commercial Stakes

Not abstract innovation. This specific market opportunity will be gone in eighteen months if we don't move. These specific competitors are moving into our territory. This specific customer segment is about to shift to a new approach, and we need to get ahead of it.

Abstract exhortation to "innovate more" doesn't move behaviour. Specific urgency does. Not artificial urgency—that gets spotted immediately and breeds cynicism. Real urgency rooted in actual market facts.

I once inherited a legacy product that was losing market share slowly. The incremental response would have been to optimise it, extend it, make it cheaper. Instead, I sat down with the product team and we looked at the actual market data. A new approach was emerging. Our customers weren't asking for iteration on the old thing. They needed something fundamentally different, and we had an eighteen-month window before a well-funded competitor would own that space.

Suddenly innovation wasn't a department mandate. It was survival. The team moved like a startup. Features that would have taken six months got tested in two weeks. Processes that normally required three layers of approval got collapsed. Not because I removed them, but because people understood the stakes, and they self-organised around speed. The organisation didn't need to change. The clarity about what we were fighting for changed how people naturally behaved.

4. They Remove the Permission Requirement

They design the operating model so that people below the leadership team can move without waiting for approval on every decision.

This is where most organisations fail. They talk about autonomy and empowerment. And then they build permission architectures that make it impossible. You need approval to hire someone. Approval to buy software. Approval to change a process. Approval to pursue a promising lead.

The effect is invisible at first. Individuals get slower. They learn to wait before moving. And then, by the time you've centralised enough approvals, you've created an organisation that can't move.

Permission-free doesn't mean anarchic. It means you set the criteria—this project can move forward if it meets these thresholds. This hire can happen if they meet these competencies. This budget can be spent if it's allocating toward these strategic priorities. And then you get out of the way. People move. They test. They learn. They adjust.

In the ventures and advisory engagements I've led, I've built teams making decisions about market positioning, product direction, and capital allocation that would take weeks to get approved in many Fortune 500s. They're not acting recklessly. They're operating with clear criteria and real accountability. But they're not waiting for approval on every move. And because of that, they can operate at the speed the market actually demands.

The Difference Between an Innovative Individual and an Innovative Organisation

Here's what's counterintuitive: organisations routinely hire innovative people and then systematically prevent them from innovating.

You bring in someone with a reputation for disruption. Founder energy. A track record of building something. And then you plug them into your processes. They need approval for hiring. They need to work through the legal team to adjust a contract. They need to align with the function you're trying to disrupt before they can propose disrupting it. And within eighteen months, you've hired an innovative person and turned them into an executor of incremental change.

The problem is never talent. I've worked with exceptional people in both worlds. The problem is always architecture. Innovation isn't a function. It's a property of how the whole system works.

Most organisations treat it as a function. You have marketing. You have operations. You have innovation. But you can't localise transformational thinking to one department when the rest of the organisation is running on slow-moving systems. It doesn't spread. It gets contained. The innovative people either leave or assimilate to the surrounding culture.

The organisations that actually manage to become innovative aren't the ones with a big innovation budget. They're the ones that redesigned how decisions get made everywhere. How projects get funded. How people can move. How failure gets treated. That's architectural change, and it's harder than hiring the right person. But it's the only thing that actually works at scale.

What Founders Bring That Corporations Tend to Suppress

Having built from zero and also operated at Fortune 500 scale, I see specific things the founder mindset offers that corporate culture systematically suppresses:

First: comfort with uncertainty. Founders assume they don't know. We build systems to test and learn. Corporations assume they should know. The policy documents get written. The procedures get locked in. And uncertainty gets treated as a problem to eliminate rather than a condition to operate within. In the AI era, comfort with uncertainty is the core adaptive capability.

Second: speed-to-test orientation. Founders ask: what's the smallest, fastest way to test this assumption? Can we do it in a week instead of a quarter? Can we validate this with ten customers instead of needing a full market study? Corporations ask: what's the most complete way to understand this? What data do we need before we can be confident? Both are reasonable questions, but they lead to different tempos. The founder tempo wins when the environment is moving fast.

Third: the willingness to kill something without a committee. A founder looks at a product, sees it's not working, and shuts it down or pivots it. No "let's run one more experiment." No "let's get buy-in from all the stakeholders." The decision happens fast, and people move. Corporations have learned to sunk-cost fallacy their way into irrelevance. We've invested so much. We're so close. Let's give it one more quarter. Meanwhile, the market has moved on.

The founder mindset isn't about being reckless. It's about moving fast enough to learn from reality before your assumptions become irrelevant.

What to Do on Monday

Here's the test, and here's what I want you to try this week if you're serious about whether your organisation actually has the conditions for transformational thinking:

Propose one thing that would be faster, simpler, or better if you removed an existing process.

Not added something. Removed something. Kill a meeting. Eliminate an approval. Simplify a workflow. Delete a policy that made sense three years ago but doesn't now.

Watch what happens in the room. That response is diagnostic.

If the response is "that's a good idea, let's study whether we can remove it," you have an organisation that can improve incrementally but probably can't transform. If the response is "why would we remove that without understanding all the implications," you have an organisation optimised for risk avoidance. If the response is "good catch, let's kill it next week," you have an organisation that might actually be able to move at speed.

Because transformational thinking at scale doesn't start with new ideas. It starts with removing the barriers that prevent the new ideas that already exist from actually reaching the market.

Your team has better ideas than you're hearing. They have faster ways to solve problems. They have seen market shifts your board hasn't seen yet. The constraint isn't the thinking. The constraint is the architecture. The permission requirements. The approval chains. The processes designed for certainty in an era that demands speed.

If you want to make transformational thinking contagious, start by making thinking itself possible. Remove one barrier. See what happens. Then remove another.

That's not a revolution. That's just letting your organisation operate at the speed the market actually demands.