Strategy into Action: Organising Teams to Execute at Pace

---

Want to level up your strategic thinking and learn how to align your organisation? Don't miss my upcoming workshops in London, Manchester, Melbourne, and Sydney!

Tickets are on sale now!

---

"If I was in control, I could have this out in a day, but we depend on 10 other product teams."

Every leader has heard some version of this complaint. Your engineers are frustrated. Your designers feel like small cogs in a giant wheel. Your product managers spend more time managing dependencies than delivering value.

You've hired brilliant people. You've crafted a compelling strategy. So why does execution feel like wading through treacle?

The answer isn't in your strategy. It's not even in your processes. It's in how you've organised your people.

Strategy without execution is wishful thinking. But execution without the right organisation is chaos.

Org Design vs Team Topology: The Critical Distinction Nobody Makes

But here's what most organisations miss: the way you organise your work is fundamentally different from your org structure. Confuse the two, and you'll kill your strategy before it has a chance. The best organisations understand that organisational structure and team topology are completely different things. 

As Marty Cagan and Christian Idiodi explained this brilliantly in their podcast on the topic:

Organisational design is about reporting lines. If you're an engineer, you report to an engineering manager. If you're a designer, you report to a design manager. This is about career development, skill growth, and administrative efficiency.

Team topology is about something else entirely: Who works together? What are they responsible for? What are they working on to deliver value? Those same engineers might be spread across five different product teams, moving between them as priorities shift.

I like to think of this as separating line management (who we report to) from task management (what we work on).

Matthew Skelton and Manuel Pais crystallised this in their excellent book Team Topologies. Though they approach it from a DevOps angle - optimising for flow and engineering throughput - we’re using the same tools to optimise for the bigger picture too: outcomes and strategic impact.

Get this distinction wrong, and you end up with the worst of both worlds: the overhead of matrix management without the benefits of true empowerment.

The Dependency Trap That Kills Strategy

Dependencies are where good strategies go to die. They're the reason your competitor with worse technology and mediocre talent somehow ships faster than you. They're why enterprises move like molasses while startups run circles around them.

The trap starts innocently enough. You want specialised expertise, so you create specialised teams. A payments team to handle the complexity of global transactions. A platform team to manage shared infrastructure. A data team to ensure governance and quality. Each team excellent at what they do. Each team a bottleneck for everyone else.

Now multiply that across your organisation. Your seemingly simple feature touches three backend services (owned by three teams), needs a database migration (platform team), requires payment processing changes (payments team), and must track new events (data team). What should take one team a week now takes six teams three months of meetings, tickets, and "alignment sessions."

The real killer? These dependencies compound exponentially. If Team A depends on Team B, and Team B depends on Team C, you don't have two dependencies - you have a chain that moves at the speed of whoever is slowest, most overloaded, or happens to be reorganising this quarter.

There's a deeper force at work here: Conway's Law. Melvin Conway observed that organisations are constrained to produce designs that mirror their communication structures. If you have separate frontend, backend, and database teams, you'll inevitably build a three-tier architecture. If you organise by geographic regions, you'll end up with regional silos.

But here's the opportunity: use this force deliberately. The Inverse Conway Manoeuvre (first coined by Jonny Leroy and Matt Simons from ThoughtWorks) means organising your teams to create the architecture - and the strategic capabilities - you want. Need rapid experimentation? Create small teams that own complete services. Need seamless customer experiences? Organise around customer journeys, not technical layers.

The Hidden Strategy Killer: Cognitive Overload

When teams can't hold their entire domain in their heads - the business rules, the customer context, the technical landscape, how it connects to strategy - they lose something fundamental: strategic alignment.

If your team is spread across fifteen services, touching fifty customer journeys, working with six stakeholder groups, they're not just overwhelmed technically. They've lost the plot. They can't see how their work connects to the strategy because they're too busy trying to remember which API does what.

This is where unclear topology becomes a strategy killer. Teams default to tactical execution. They fix bugs. They ship features. But they stop thinking strategically about the problems they're solving. The cognitive overhead of just coordinating displaces the mental space needed for innovation.

The best teams have cognitive clarity. They know their domain deeply, understand their customers intimately, and can trace a clear line from their daily work to the company's strategic objectives. This requires clarity through the Decision Stack - a clear thread of decisions from company strategy down to individual team execution, where each level informs but doesn't dictate the next.

Teams Set Up to Execute at Pace

When Richard Banfield, Nate Walkingshaw, and I wrote Product Leadership, we interviewed hundreds of product leaders worldwide, looking for what separated great product organisations from the rest. The common theme that emerged was autonomous teams. 

The best example I've seen is how Wise structures their teams. They don't just have cross-functional teams - they have cross-capability teams.

Their currencies team doesn't just have engineers, designers, and a product manager. It has bankers. It has lawyers. It has everyone the team needs to make decisions and execute without waiting for another team's roadmap to align with theirs. When they need to launch support for a new currency, they don't file tickets with legal or set up meetings with compliance. Those people are already in the room, part of the team, invested in the same outcome.

This isn't just efficient - it's transformative. It changes the entire dynamic from "us requesting something from them" to "we're solving this together." The team has true empowerment because they have all the capabilities they need. They have alignment because everyone is working toward the same strategic outcome.

Other organisations solve this differently. Spotify evolved their famous squad model toward what they call "aligned autonomy" - squads maintain independence but align on strategic bets. Amazon uses "single-threaded leadership" where one senior leader owns one initiative completely, with no split focus. The specific model matters less than the principle: minimise dependencies, maximise ownership, maintain strategic alignment through clear accountability.

Empowered, not Autonomous

But Nilan Peiris, Chief Product Officer at Wise, learned something important after a decade of building autonomous teams: the word itself can be a problem.

"I don't use the word autonomy in public anymore," Nilan explained at Mind the Product London in 2023. "It's incredibly confusing because what does it mean - does it mean I can do whatever I want?"

Instead, Wise talks about empowered teams. The distinction matters. Autonomy suggests independence without boundaries, teams doing whatever they think best. Empowerment means something different: teams have everything they need to deliver on their mission - the capabilities, the decision rights, the resources - but within a clear strategic context.

Peiris shared a perfect example. When Wise got its Singapore license, regulators demanded that they physically meet every customer before allowing money transfers. No product roadmap could have predicted this. No top-down strategy could have planned for it. But their regional expansion team didn't need permission to solve it. They sent someone to Singapore to start meeting customers while simultaneously lobbying regulators. After a year, they achieved the world's first selfie-based KYC approval for Singapore.

"If I, as Chief Product Officer, was going to say we're going to launch Singapore in two years, it's going to have this cost and it's going to be entirely digital, I'd be making it up," Peiris noted. "The only person who could make that happen is the product team."

This is empowerment: the team had the authority to make decisions, the resources to execute them, and the strategic clarity to know why it mattered. They weren't autonomous - they couldn't decide to abandon Singapore or change Wise's core mission. They were empowered to find the best path to achieve a clear strategic goal.

The same pattern played out with Wise's multi-currency account and their payment acceptance features. These weren't top-down initiatives. They came from teams closest to customers who had both the insights and the ability to execute. As Peiris put it: "Our strategy isn't set top down, it's set by the teams closest to the customers who are uniquely able to execute against them."

This bottom-up meets top-down strategy is where the magic happens, and is only possible with the clarity of a well-communicated Decision Stack - and clear accountability. Every month, teams at Wise answer two questions: What did you ship for customers? What was its impact? The empowerment comes with radical transparency about results.

The Platform Team Paradox

Platform teams are supposed to solve the dependency problem by creating shared services everyone can use. Too often, they become the bottleneck they were meant to eliminate.

Here's what actually works: platform teams should be architects and enablers, not implementers. When a product team needs a new capability, the platform team helps design it and ensures it fits the overall architecture. But the actual work gets pulled into the product team that needs it. The product team builds it, owns it, delivers it - with the platform team's guidance, ensuring it becomes a reusable capability.

This "pull" model beats the traditional "push" model, where work gets pushed onto the platform team's backlog, where it inevitably ends up in dependency prioritisation purgatory. The platform team becomes a centre of expertise, not a bottleneck. They empower other teams rather than creating dependencies.

Making Aligned Empowerment Real

Creating an organisation that can actually execute on strategy at pace requires four fundamental shifts:

1. Separate topology from structure deliberately. Your reporting lines don't have to match your team composition. Use reporting structures for career development and skill growth. Use team topology for strategic execution. The Decision Stack becomes your alignment mechanism - each team understands how their decisions connect to broader strategic choices without waiting for approval.

2. Design team topologies for true empowerment. Get the right people in the room - not just product, design, and engineering, but everyone needed to make decisions and deliver value. This means architects who can approve technical decisions, lawyers who can clear legal hurdles, and data scientists who can measure impact. If a team constantly waits for another team, they’re not empowered.

3. Architect systems to match your topology. Use the Inverse Conway Manoeuvre deliberately. If you want empowered teams, build services with clear boundaries. Well-designed APIs and micro services aren't just good engineering - they're what let teams innovate without permission. Your architecture should unleash your topology, not constrain it.

4. Move mountains to minimise dependencies. Dependencies are where strategies go to die. They are why we have decades of horribly bureaucratic project management processes that slow everything down to the slowest common denominator. You’ll never get rid of them completely in any complex system, but leaders should always work to minimise them as much as possible - and empower teams to pull work into their execution rather than push it onto other teams where you can’t control the priority.

The Strategic Choice You Can't Avoid

Here's what it comes down to: your organisational design and team topology are strategic choices, whether you make them intentionally or not.

This doesn't mean pure autonomy - it means aligned empowerment. Teams with strategic clarity about why their work matters, everything they need to deliver on that mission, and clear accountability for results. It means "disagree and commit" cultures, where decisions get made even when consensus is impossible. It means being clear about what you're optimising for and accepting the tradeoffs that come with that choice.

As Peiris noted in closing his talk, "Our customers don't care about autonomous teams. They don't care how we run. They only care about the speed with which we achieve our mission." Highly empowered teams help you achieve that speed. But empowerment without alignment is chaos, and alignment without empowerment is bureaucracy.

The companies that win aren't just the ones with the best strategies. They're the ones who organise their people in a way that lets those strategies flourish and be executed at pace. They understand that empowered teams aren't created by declaration - they're created by design. Design that minimises dependencies. Design that enables true ownership. Design that connects daily work to strategic intent through clear decision rights and accountability at every level.

Your strategy might eat your competition's lunch. But only if you design your organisation to execute on it first.

What's your experience with organisational design and strategy execution? How does your company balance functional expertise with team empowerment? I'd love to hear your thoughts and examples in the comments.