You’re Not Agile. You’re Just Fast at the Wrong Things.

How to Rewire Your Organisation for the AI Era – Before Someone Does It For You

Last month we named the problem. AI isn’t failing your organisation. Your organisation is failing AI.

This month we’re going one level deeper. Because knowing the problem isn’t enough. You need to understand what’s causing it… and what to do about it.

The cause, in almost every organisation we work with, is the same: the way you’re organised was designed for a world that no longer exists. Vertical functions. Sequential handoffs. Governance that sits at the end of a process rather than inside it. This structure made sense when change was slow and predictable. It doesn’t make sense now.

And AI doesn’t just expose this. It accelerates it. Every hour AI saves inside one function gets lost in the queue between functions. The technology moves faster than the organisation around it, and so the organisation becomes the constraint.

“AI isn’t going to manage around your org chart. You either redesign the org chart to harness AI – or you’ll get minimal benefit from it.”

That’s not our line. That’s a CEO we worked with, about six months into a transformation programme. He’d seen the pilots succeed. He’d watched the gains disappear. And he’d finally understood why.

This blog is about what he did next.

The Efficiency Trap

Here’s the pattern we see constantly, and we’ve started calling it the efficiency trap.

A team adopts an AI coding assistant. Suddenly they’re shipping features in days instead of weeks. Leadership celebrates. The ROI deck looks great.

Then the feature hits the deployment queue. Compliance review. Security sign-off. Change management board. Three weeks later, the customer finally sees it.

Local efficiency. Global inefficiency. AI made one slice of work faster. The end-to-end flow didn’t improve. The customer experience didn’t improve. The business result didn’t improve.

This is happening everywhere right now. Retailers using AI to predict trends, while stock sits in the wrong warehouse because procurement and logistics aren’t aligned. Financial services firms deploying AI in customer onboarding, while the back-office processes that actually determine approval time haven’t changed at all.

The technology is real. The transformation isn’t.

The reason, almost always, is structure.

The Two-Pizza Rule – and Why It Still Matters

Jeff Bezos had a principle: if a team can’t be fed by two pizzas, it’s too big.

Not because he likes pizza. Because he understood that communication overhead kills speed. When a team grows beyond the point where everyone knows what everyone else is doing, coordination becomes the work. Meetings multiply. Decisions slow. Accountability blurs.

Amazon grew into a global giant, but structurally it stayed a network of small, autonomous teams with real decision power. Each team owned an outcome. Each team had everything it needed to deliver that outcome. Each team could move without waiting on anyone else.

Most enterprises do the opposite. They scale control. Silicon Valley scales autonomy.

The question worth sitting with is a simple one: how many of your teams have everything they need to deliver their outcome, without waiting on another team?

If the honest answer is “not many,” that’s not a performance problem. It’s a design problem.

“The cross-functional team is the unit of speed. When a team has everything it needs to deliver –  business, tech, compliance, all of it – without waiting on others, the queue disappears.”

The Spotify Model Problem

By now, most leaders have heard of the Spotify model. Squads. Tribes. Chapters. Guilds. It’s been presented at more leadership offsites than we can count.

And it keeps failing. Not because the model is wrong. Because it’s being implemented in the wrong context.

The Spotify model was created for Spotify. It was designed contextually, for a specific organisation, at a specific moment in its growth. When Spotify’s people shared it at conferences, they were describing what worked for them. What happened next was entirely predictable: every other organisation tried to copy it.

The question we’ve started asking organisations who tell us they’re “moving to the Spotify model” is a deliberately blunt one: are you a music streaming company based in Sweden?

If the answer is no, the model won’t work for you either. Not because the principles are wrong, cross-functional teams, aligned guardrails, shared objectives, but because the implementation has to be built for your context, your structure, your people, your market. You can’t retrofit someone else’s operating model. You have to design your own.

The same is true for every agile framework that’s been rolled out as a solution rather than a starting point. SAFe. OKRs. Scrum at scale. All of them work – in the right context, implemented with the right intent. None of them work when they’re layered on top of a command-and-control culture and expected to produce different results.

What the Rewire Actually Looks Like

So, what does it mean to genuinely rewire, not just rearrange?

It starts with a question most organisations don’t ask. Not “how do we structure our teams?” but “what outcomes do we need to deliver, and what does the team that can own one of those outcomes end to end actually look like?”

That shift in thinking produces a completely different organisational design. Instead of building around functions, finance, technology, marketing, operations, you build around outcomes. The team that owns customer onboarding has a commercial lead, a technologist, a risk specialist, and a designer in it from day one. Not because it’s tidier, but because those are the capabilities the outcome requires. When they’re all in the same team, the queue between them disappears.

This is what we mean by RewireX. Not a restructuring programme. Not an agile rollout. A fundamental redesign of how work flows through your organisation, built around what you’re trying to achieve, not the functions you’ve inherited.

The three things a genuinely rewired organisation does differently:

1. It designs around outcomes, not functions. 2. It puts governance inside the team, not at the end of the process. 3. It gives teams the authority to match the accountability it asks of them.

Embedded Governance: The Thing Most Organisations Get Wrong

One of the most common objections we hear when we talk about cross-functional, autonomous teams is a governance concern: if teams have real decision-making power, how do you maintain control? How do you manage risk?

The honest answer is that most traditional governance doesn’t manage risk. It delays decisions and creates the illusion of oversight while the real risks, market relevance, speed to customer, competitive positioning, accumulate quietly in the queue.

Embedded governance is different. Instead of a compliance review at the end of a process, you put a compliance expert inside the team at the start. Instead of a security gate before deployment, you build the security checks into the deployment pipeline itself. Instead of a change board that meets fortnightly, you give teams a clear set of principles that tell them what decisions they can make independently and what requires escalation.

The result is that teams move faster and stay within the right boundaries, because the guardrails are part of the engine, not speed bumps on the road.

This is what agility without anarchy actually looks like. It’s not freedom from governance. It’s governance that’s been redesigned to enable speed rather than slow it down.

Where to Start: The 90-Day Proof Point

If you’ve read this far and you’re thinking “this all makes sense, but where do we actually begin,” here’s our answer.

Don’t start everywhere. Start somewhere visible.

Pick one high-impact area of your business, a process that’s genuinely important, genuinely broken, and genuinely worth fixing. Something that matters to your customers and costs you time, money, or competitive ground. Customer onboarding. Product development. Service delivery. Supply chain planning. It doesn’t matter which, as long as it’s real.

Then form a dedicated cross-functional strike team to own that area for 90 days. Pull the right capabilities together, business, technology, whatever the outcome requires. Give the team a clear mandate. Give them an executive sponsor who will clear the path when the organisation pushes back (and it will push back). And get out of their way.

The goal isn’t to transform the whole organisation in 90 days. The goal is to produce a proof point so compelling that the rest of the organisation looks at what that team achieved and asks: how do I get to work like that?

“Start small and fast – with the group of people who will become evangelists for everyone else. Let the result do the persuading.”

We’ve seen this work. We’ve seen a single lighthouse team change the conversation in a business more effectively than any transformation programme announcement ever could. Because it’s not a slide. It’s evidence.

The Rewire Isn’t the Hardest Part

Here’s something worth saying plainly: the structural redesign, the cross-functional teams, the embedded governance, the outcome-based operating model, is not actually the hardest part of this.

The hardest part is the culture that sits underneath it. The leadership habits that have to change. The permission structures that have to be rebuilt. The willingness to give people real authority and trust them to use it.

We’re going to talk about that in June.

For now: if your organisation is running AI on top of a structure that was designed for a different era, the technology will not save you. But the right structure, built around the right outcomes, with the right people inside it, that’s a different story entirely.

That’s the Rewire. And it’s the most valuable thing you can do right now.

Ready to start the conversation? Talk to PerfectRebel about Rewire – how we redesign the way organisations deliver.

perfectrebel.com | Hear Tomorrow’s Call