Hire Only A-Players; Then Organize Them Like Spotify

How small, autonomous teams beat big org charts

Most transformation projects start in the wrong place.
They begin with a framework, a blueprint, or a re-org slide deck.

They should start with this brutal rule:

If you hire A-players, you can trust them and give them autonomy.
If you hire B-players, they’ll quietly fill your company with C- and D-players – because they’re afraid of anyone better than them.

Spotify understood this very early. When you’re fighting Apple, Google and Amazon for the future of music, you can’t afford “defensive hires”. You need people who are good enough – and secure enough – to work in small, autonomous teams with very little process and a lot of responsibility.

This post is about what happens after you raise the talent bar: how you design the organization around those A-players so they can move fast without creating chaos.

And yes, it leads us straight into Spotify’s squad–tribe–chapter–guild model, Amazon’s two-pizza rule, and the shift from I-shaped to M-shaped people.

From I-Shaped Experts to M-Shaped Innovators

For most of the 20th century, companies were built on I-shaped people:

• Deep expertise in one narrow domain
• Little interest (or incentive) to look left or right

They fit nicely into silos and functional departments: marketing over here, IT over there, business somewhere in the middle sending tickets to both.

Then things got faster and messier. We needed T-shaped people:

• Deep expertise in one field
• A “horizontal bar” of basic understanding across other disciplines

This made cross-functional teamwork possible. Designers could at least talk to developers. Product people could understand enough tech to not promise the impossible every week.

Today, in a world of AI, platforms and continuous change, we’re drifting toward M-shaped people:

• Deep in more than one domain (for example: coding and UX; data and product; business and facilitation)
• Comfortable moving between roles as the team needs

Spotify’s culture is full of these M-shaped profiles. Engineers who also care about UX. Designers who understand experiments and metrics. Product people who can facilitiate retrospectives or hack together a prototype.

Why does this matter?

Because small autonomous teams can only work if each person is more than their job description. The squad needs enough overlapping skills to ship real value without constantly begging other departments for favors.

Two-Pizza Teams and the Mathematics of Focus

Jeff Bezos once said that a team should be small enough to be fed by two pizzas.

Spotify’s squads live in that spirit:

• Usually fewer than eight people
• Sitting together (physically or virtually)
• Owning a clear mission, end-to-end

That size is very close to what I recommend in Continuous Innovation Culture (CIC): teams of around 6 people (a little more or less), with all the skills they need to deliver value from idea to impact.

Why so small?

• Communication is cheap. You don’t need status meetings to know what’s going on.
• Responsibility is visible. You can’t hide in the corner of a 6-person team.
• Decisions are fast. You don’t need three committees to ship a small experiment.

Big organizations try to copy this with “squads” of 15–20 people and wonder why it feels like a mini-department. The math just doesn’t work. If your team needs more than two pizzas, you don’t have a team – you have a conference.

Squads: Small Teams with Big Responsibility

Spotify calls these two-pizza teams squads.

A squad is:

• Cross-functional – developers, design, product, QA, data… whatever is needed
• Self-organizing – they decide how they work, which tools they use, how they plan
• End-to-end – responsible for design, build, deploy, operate, maintain

Each squad has a long-term mission, not just a backlog:

• “Make Spotify the best place to discover new music”
• “Make A/B testing infrastructure fast and easy”

This is important. Missions are more stable than features. Features come and go; missions persist. That gives squads room to learn, refactor, and improve without waiting for permission from a project steering committee.

Autonomy here is real. Squads decide:

• What to build
• How to build it
• How to organize their own work

But autonomy has a dangerous twin: fragmentation.

If every squad runs in a different direction, you don’t get innovation – you get a Frankenstein product.

So the real genius in Spotify’s model isn’t autonomy. It’s how they combine autonomy with alignment.

Aligned Autonomy: Jazz, Not Marching Band

Spotify likes the metaphor of a jazz band:

• Each musician is autonomous; they play their own instrument.
• But they listen to each other and focus on the whole song.

In organizational terms, they draw it as two axes:

• Alignment (low → high)
• Autonomy (low → high)

The sweet spot is high alignment + high autonomy:

• Leaders are crystal clear about what problem needs to be solved and why.
• Squads are free to figure out how to solve it.

Strong alignment actually enables more autonomy.

If everybody understands the strategy, the bets, the metrics that matter, you don’t need heavy process to coordinate them. Squads can make local decisions that still move the company in a shared direction.

And this isn’t just a cool idea from tech companies. Flat, cross-functional teams have proved so effective that they’ve been tested even inside one of the most hierarchical systems on the planet: the military. In Team of Teams, General Stanley McChrystal describes how U.S. special operations units had to abandon a rigid pyramid and reorganize into small, empowered teams connected by constant information-sharing.

He contrasts the old view – people are lazy and must be tightly controlled – with McGregor’, which sees people as capable of self-motivation when they’re trusted and treated with respect.

McChrystal calls the result “a team of teams” – a network where shared understanding allows highly autonomous units to act fast without waiting for orders. That is very close to what Spotify is aiming for: squads, tribes, chapters, and guilds that understand the whole system well enough to act independently without breaking it.

Beyond Scrum: Agile Principles Over Rigid Process

When Spotify launched its first music player in 2008, they were basically a Scrum company. One product. A few teams. Daily standups. Sprints.

As they grew, something interesting happened:

• The Scrum rules started getting in the way.
• The Agile principles were still exactly right.

So they did something most organizations are afraid to do:

• They made Scrum practices optional.
• They kept the agile values and mindset.

Scrum Masters became Agile Coaches – servant leaders, not process police.

Teams were free to use Scrum, Kanban, something hybrid, or something home-grown – as long as they:

• Delivered value frequently
• Learned from real users
• Improved continuously

This is another lesson for CIC:

Don’t worship the framework.
Use whatever helps small teams learn faster and create impact.

Tribes, Chapters, Guilds: Community Instead of Hierarchy

When you have dozens of squads, you need some structure. Spotify’s answer was a lightweight matrix:

• Squads – where the real work happens (product delivery)
• Tribes – a group of squads working on a related product area
• Chapters – people with the same specialty across squads (e.g. backend devs, testers, agile coaches)
• Guilds – informal communities of practice anyone can join (e.g. “Continuous Delivery”, “Leadership”)

Your squad is your home team.
Your chapter lead is your line manager and coach.
Your guilds are your learning network.

This keeps silos soft:

• Developers from different squads share practices in their chapter.
• Designers exchange patterns in their guild.
• Tribes coordinate work around a shared product or customer journey.

It’s less like a pyramid, more like a nervous system.

Architecture That Lets Teams Move Fast

All the culture in the world won’t help you if your architecture is a giant monolith.

Spotify invested heavily in decoupling:

• Over a hundred independent services, each focused on a specific need
• Clear interfaces and protocols
• An internal open-source model: any squad can change any code, as long as it’s reviewed

They also invested in continuous delivery infrastructure:

• Lots of automated tests
• Frequent, small releases
• Release trains on a fixed schedule (e.g. every week)
• Feature toggles to hide unfinished work and gradually roll out features

This creates what they call a limited blast radius:

• If a squad makes a mistake, it only affects a small part of the system
• Typically for a small group of users
• For a short period of time

When failure is small and recoverable, teams are willing to experiment.
And when teams experiment, learning speeds up.

This is a core principle of Continuous Innovation Culture:

Make it cheap and safe to run experiments. Make it even cheaper to roll back and try again.

Failure, Hack Weeks, and the Minimum Viable Bureaucracy

Spotify’s founder once said they aim to “make mistakes faster than anyone else.”

That only works if:

• Failure is non-lethal
• Learning is mandatory

So they do things like:

• Post-mortems that focus on what we learned, not who to blame
• “Fail walls” where teams share their experiments and missteps
• Regular retrospectives in every squad
• Big Hack Weeks twice a year, where hundreds of people can build whatever they want and demo it on Friday

Is it chaotic? Sometimes.
Is it worth it? Absolutely.

To avoid drowning in their own creativity, they keep asking one question:

What is the minimum viable bureaucracy we need to avoid chaos – and nothing more?

Too little structure → chaos.
Too much structure → paralysis.

The art is in staying in the middle, guided by a culture that is strongly waste-repellent. Anything that doesn’t add value (status reports, useless meetings, extra handoffs) tends to die quickly.

So… Should You Copy the Spotify Model?

Short answer: No.

Even Spotify doesn’t “do the Spotify model” in one uniform way. The videos and PDFs you’ve seen are snapshots in time. Inside the company, different tribes and squads work in different ways, and the model keeps evolving.

But you can copy the principles:

1. Hire A-players and M-shaped people.
   People who are good enough, and secure enough, to work in small, autonomous teams without hiding behind job descriptions.
2. Keep teams small and cross-functional.
   Think two-pizza teams. In CIC, that usually means around six people with all the skills needed to deliver value.
3. Aim for high alignment + high autonomy.
   Make strategy, bets, and metrics radically transparent. Then let teams figure out how to win.
4. Invest in architecture and tools that remove friction.
   Continuous delivery, decoupled systems, self-service platforms. Make it easier to ship than to delay.
5. Make experimentation part of the job, not a side hobby.
   MVPs, A/B tests, hack days, safe-to-fail probes. Measure impact, not output.
6. Treat managers as servant leaders and coaches.
   Less command-and-control, more Team of Teams: shared consciousness and empowered execution.

Some banks, telecoms and retailers are already moving this way – introducing tribes and squads to escape silo thinking and become more like networks of teams. The labels matter less than the mindset.

Where This Fits into Continuous Innovation Culture

Spotify is not a perfect model. They have problems, growing pains, and trade-offs like everyone else.

But they are a powerful case study in Continuous Innovation Culture:

• Small teams over big departments
• Experimentation over prediction
• Trust over control
• Learning speed over comfort

If your organization wants to survive in a world of AI, automation and accelerating change, this is no longer “nice to have”. It’s a survival strategy.

In my upcoming book Disrupt or Be Disrupted: Continuous Innovation Culture Shift, I go deeper into how to design such cultures: structures, leadership, rituals, and the messy human side of change.

And if you’re curious how these organizational choices connect to the broader levers of wealth and progress – time, energy, capital, innovation and speed – you’ll find more practical examples in Leverages of Wealth & Progress.

For now, maybe start with one simple question:

If we hired only A-players and trusted them… how would we have to reorganize the company so they could actually do their best work?

Answer that honestly – and you’re already on your way from silos to squads.

Stay curious.