Centralised vs. Decentralised Product Teams
The org chart debate that consumes more leadership energy than actual product decisions. And why the answer you're hoping for doesn't exist.
I once watched a VP of Product spend four months redesigning the entire team structure, moving from centralised to decentralised squads. Workshops. RACI matrices. New reporting lines. Slack channels renamed. The works.
Eighteen months later, her successor spent another four months moving everything back.
Same company. Same product. Different conviction about which structure was “right.”
Here’s what nobody told either of them: the structure wasn’t the problem. The structure is never really the problem. The structure is the thing we fiddle with when we can’t articulate what’s actually broken.
The Seductive Promise of Decentralisation
Autonomous teams sound brilliant on paper. Each squad owns their slice. They make decisions fast. They build deep expertise. They don’t wait for permission.
If you’ve ever sat in a prioritisation meeting with fourteen people arguing about whether Feature A or Feature B deserves the next sprint, you understand the appeal. Just give each team their own backlog. Let them run. Problem solved.
And sometimes it works. I’ve seen decentralised teams at a mid-sized fintech move with startling speed. One squad shipped a complete P2P payment flow in six weeks. No cross-team dependencies. No architecture review boards. No waiting for the “platform team” to build something first.
But here’s what I’ve also seen: three different squads building nearly identical onboarding components because nobody was tracking what already existed. Two teams accidentally degrading each other’s performance because their features competed for the same database resources. And a customer experience that felt like it was designed by five different companies who’d never met.
Decentralisation gives you speed at the cost of coherence. The question is whether you can afford the coherence debt.
The autonomy that makes teams fast also makes them blind to what’s happening two desks over.
The Gravitational Pull Toward Centralisation
Centralised product functions exist because someone, at some point, got burned by fragmentation.
Usually it happens like this: a customer complains that Feature X in one part of the product contradicts Feature Y in another. Or sales loses a deal because the product “feels disjointed.” Or engineering discovers they’ve built the same authentication module four times in four different ways.
So leadership centralises. One product vision. One roadmap. One person (or small group) making the calls about what gets built and when.
And for a while, it’s better. Consistency improves. Redundancy drops. The product starts to feel like a product again, not a collection of loosely affiliated features.
Then the complaints shift. “Everything takes forever.” “We can’t make decisions without escalating.” “I have to schedule a meeting to schedule a meeting.” “The central team doesn’t understand our domain.”
I watched this exact pattern at an enterprise SaaS company. Their centralised model worked beautifully when they had 40 people and one product. At 300 people and five product lines, it became a bottleneck that made decisions at roughly the speed of continental drift.
The Hidden Variables Nobody Talks About
Here’s what most org structure debates miss: centralised vs. decentralised isn’t a binary choice. It’s a spectrum, and where you should sit on that spectrum depends on things that have nothing to do with theory.
Company stage matters. A 50-person startup needs different coordination mechanisms than a 2,000-person enterprise. Obvious, right? Yet I’ve seen early-stage companies implement heavy governance structures borrowed from Fortune 500 playbooks. And I’ve seen enterprises try to “move fast and break things” across 47 product teams, creating breakage nobody could trace back to a source.
Technical architecture matters. If your systems are tightly coupled, decentralised teams will spend half their time negotiating dependencies. If your architecture is genuinely modular, autonomous teams can actually be autonomous. Most companies are somewhere in between, which means their org structure needs to acknowledge that reality.
Customer journey matters. If your product is a single flow that users experience end-to-end, fragmenting ownership creates handoff problems. If your product is genuinely a suite of distinct tools, unified ownership might be overkill.
Your people matter. Some teams thrive with autonomy. Others flounder without clear direction. Pretending everyone operates the same way is wishful thinking.
The structure that works depends on context you can only see if you’re actually inside the organisation. Which is why copying Spotify’s model or Netflix’s model or whatever company just published a blog post about their brilliant approach rarely translates.
What’s Actually Happening Beneath the Surface
When I dig into teams struggling with this question, the structure debate is usually a proxy for something else entirely.
Sometimes it’s a trust problem. Leadership doesn’t trust teams to make good decisions independently, so they centralise. Or teams don’t trust leadership to understand their domain, so they push for autonomy.
Sometimes it’s a communication problem. Information isn’t flowing, so nobody knows what anyone else is building. Centralisation feels like a fix because it forces coordination through hierarchy. But hierarchy is a terrible information conduit.
Sometimes it’s a strategy problem. The company doesn’t actually know what it’s trying to build, so teams either duplicate effort or wait for direction that never comes. Neither structure solves that.
Before you reorganise, ask: what specific dysfunction are we trying to fix, and are we sure the structure is causing it?
I’ve seen teams reorganise to solve problems that had nothing to do with the org chart. A centralised team that “moved too slowly” was actually waiting on legal approvals, not product decisions. A decentralised team that “lacked coherence” actually just needed a shared design system and some cross-team communication rituals.
The Trade-Off Frame That Actually Helps
Instead of asking “centralised or decentralised,” try asking: “Where do we need consistency, and where do we need speed?”
This reframes the question from structure to outcome.
Some things genuinely benefit from consistency:
Core user experience patterns
Platform capabilities that multiple teams depend on
Brand and design language
Data architecture and definitions
Security and compliance standards
Some things genuinely benefit from speed:
Feature discovery and experimentation
Domain-specific problem solving
Customer-facing improvements in discrete areas
Tactical response to feedback
The answer usually isn’t one structure for everything. It’s different coordination mechanisms for different types of decisions.
Consistency needs: centralise the standards, not necessarily the people. A shared design system with clear governance. Architecture principles that everyone follows. A small central team that owns cross-cutting concerns but doesn’t own every decision.
Speed needs: decentralise execution within guardrails. Autonomous teams that can ship without permission, as long as they’re working within agreed constraints.
Practical Signals That Your Structure Is Breaking
How do you know when your current setup isn’t working? Watch for these:
Signs your decentralised model needs more coordination:
Customers experience jarring inconsistencies between product areas
Teams are building similar things without knowing it
Technical debt is accumulating because nobody owns cross-cutting concerns
Strategic priorities aren’t reflected in what teams actually ship
Knowledge silos are forming, and people genuinely don’t know what other teams do
Signs your centralised model needs more autonomy:
Simple decisions require multiple levels of approval
Teams are waiting, constantly, for someone else to unblock them
Deep domain expertise is being overruled by generalist central teams
Innovation is slowing because everything must fit the master plan
Your best people are frustrated and starting to leave
Neither list is exhaustive. But if you’re nodding at three or more items on either list, you’ve found your problem.
What You Can Actually Try
If you’re a director or VP wrestling with this, here’s what I’ve seen work:
Start with the handoffs. Map where work currently gets stuck waiting for another team or approval. Those friction points tell you more about your real structure problems than any theory.
Experiment with coordination, not reorganisation. Before moving boxes on an org chart, try adding lightweight coordination mechanisms. Cross-team syncs. Shared OKRs for areas that touch multiple teams. Design reviews that create consistency without centralising decisions.
Be honest about what you’re optimising for. Speed and consistency trade off. You cannot maximise both. Pick which matters more for which parts of your product, and design accordingly.
Accept that you’ll need to adjust. The right structure at 100 people is wrong at 500 people. Build in the expectation that you’ll revisit this, rather than treating each reorg as the final answer.
The Uncomfortable Truth
I’ll be honest: there’s a part of me that wishes one answer was simply correct. It would make everything easier.
But after watching this play out across enterprise companies and scrappy scale-ups, across regulated fintech and experimental platforms, I’ve stopped believing in optimal structures. I believe in structures that fit the current context well enough, combined with the organisational awareness to notice when they stop working.
The best structure is the one that creates the fewest problems you can’t see.
Some companies thrive with radical decentralisation. Others need strong central coordination. Most need something in between, and that “something” will shift as the company grows and the product evolves.
The leaders who handle this well aren’t the ones who found the perfect model. They’re the ones who stay curious about what’s actually happening, who listen to the friction their teams experience, and who treat structure as a tool rather than an identity.
One Thing to Try This Week
Pick one recurring frustration your team experiences. Maybe it’s waiting for approvals. Maybe it’s duplicated work across teams. Maybe it’s inconsistent customer experience.
Ask yourself: is this a structure problem, or is it something else wearing a structure costume?
If it’s genuinely structural, what’s the smallest change that might help? Not a reorg. A process tweak. A new ritual. A shared artefact.
Try that first. See what happens.
Because the dirty secret of org design is that most of the real work happens in the spaces between the boxes on the chart. The structures that succeed aren’t the ones that look elegant in a presentation. They’re the ones that make it easier for smart people to do good work together.
And that, unfortunately, requires more attention than any single reorganisation can provide.