Centralized vs. Decentralized Org Choice
Pick your org model from your product strategy: speed (Amazon) or unified experience (Apple), and accept its cost.
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 4
- Confidence
- 90%
Organizational structure is a spectrum with two working extremes. The decentralized model (Amazon-style two-pizza teams, minimal dependencies, internal competition) buys speed and novelty but ships your org chart to users and resists platform leverage. The centralized model (Apple-style functional org, single bottleneck) buys a simple unified experience at the cost of speed. Choose based on what your strategy most needs.
Origin
Söderström's contrast of Amazon and Apple, including Bezos's 'hard API' mandate, applied to Spotify's single-app multi-content strategy.
Core principles
- 01Both extremes work — Amazon and Apple are each trillion-dollar companies
- 02Decentralization maximizes speed and time-to-user but ships org-chart complexity to users
- 03Competing teams have no incentive to share code, so hard APIs must be centrally forced to regain leverage
- 04Centralization yields a single coherent experience but bottlenecks throughput
- 05The right model follows from your strategy, not from fashion
How to run it
- 1
Name what your strategy most needs
Decide whether your edge depends on raw speed and independent bets, or on a single simple experience across many offerings. This choice, not preference, selects the org model.
Pro tip Being at an extreme of the org spectrum may itself be an advantage — like a 'smiling curve,' the value is at the ends, not the muddled middle.
- 2
If you choose decentralization, force hard APIs
Independent, competing teams won't cooperate by default. Mandate hard, well-defined APIs between teams so you still get platform leverage — the discipline that let Amazon later externalize AWS.
Pro tip The very structure that penalizes cooperation, once forced into hard APIs, becomes the easiest to turn inside-out and sell externally.
Watch out Without forced APIs, competing teams hide code and results and you get zero platform leverage.
- 3
If you choose centralization, install a coherence bottleneck
Route decisions through a single organizing function (e.g. a shared recommendation org, a unified experience team) that decides how each piece fits the whole. Accept that this slows shipping.
Pro tip Centralization is right when keeping one simple user experience across many different backend business models is the core of your strategy.
Watch out Expect long queues — features can wait years in the pipeline before they fit the whole.
- 4
Accept the model's inherent drawback
Decentralization will occasionally ship visible org-chart artifacts (duplicate search boxes, multiple toasters on one screen); centralization will be slower. Own the tradeoff you chose rather than trying to have both.
Watch out Trying to sit in the middle can forfeit the advantages of either extreme.
In the wild
Amazon's competing, dependency-minimizing teams had every incentive to hide code, which would kill platform leverage. Bezos mandated hard APIs — expose your technology or you're out. Because those interfaces were so rigidly defined, Amazon could later turn its infrastructure inside-out as AWS.
→ A structurally uncooperative org became the one best positioned to externalize its platform, producing AWS.
Spotify runs many content businesses (music, podcasts, audiobooks) with very different backend economics inside one app. Because a simple unified experience is its strategy, it routes them through a single recommendation org and unified experience team rather than letting each build its own UI.
→ A coherent single-app experience, trading away some speed, consistent with the chosen strategy.
Common mistakes
Copying an org model without matching it to strategy
Amazon's and Apple's opposite models both work because each fits its strategy; importing one that contradicts what your product needs imports its drawbacks without its benefits.
Decentralizing without enforcing hard APIs
Competing teams left to their own incentives hide work and share nothing, so you lose all platform leverage and ship a fragmented org chart to users.
Is it for you?
Best for
Executives designing or restructuring a company's operating model who need to tie structure to product strategy.
Not ideal for
Single-product startups too small for the tradeoff to bite, where structure is not yet the constraint.
From the transcript
“you're faster there, but it's going to be hard to cooperate.”
“he's well known for pushing extremely hard on hard APIs. Like if you don't create hard APIs to your technology, you're out.”
“you get the drawback of kind of shipping your org chart and shipping complexity to the end user.”
“these different sort of vertical businesses, if you think about it, the music business, podcast, audiobooks business, they have to go through a single recommendation…”
From the episode
Lessons from scaling Spotify: The science of product, taking risky bets, and how AI is already impacting the future of music
Gustav Söderström (Co-President, CPO, and CTO at Spotify)