The Spotify Model: Squads, Tribes and Guilds Explained

In 2012, two agile coaches at Spotify published a short whitepaper describing how the company organized its engineering teams. It was not a manifesto. It was not a methodology. It was a snapshot, a description of how one company happened to work at one particular moment in time. The authors said so explicitly.

Within a few years, thousands of organizations had adopted it as a prescriptive framework. They renamed their teams “squads,” grouped them into “tribes,” created “chapters” and “guilds,” and expected the results to follow. Many discovered that copying an organizational structure without understanding the culture behind it produces little more than new vocabulary for old problems.

The deeper irony: Spotify itself moved on. The company’s own engineers have publicly acknowledged that the model described in the whitepaper no longer reflects how Spotify works. Yet the “Spotify model” remains one of the most widely discussed approaches to scaling agile organizations, precisely because the ideas at its core address real problems that every growing company faces.

This guide explains what the Spotify model actually described, how its four building blocks work, why it spread so far, where it breaks down, and how to adapt its principles without falling into the most common traps.

What Is the Spotify Model?

The Spotify model originated in a 2012 whitepaper titled “Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds,” written by Henrik Kniberg and Anders Ivarsson. Kniberg was an agile coach working with Spotify; Ivarsson was the company’s organizational coach. The paper, accompanied by a two-part video series, described how Spotify organized its roughly 30 engineering teams at the time, approximately 250 people working across three cities.

The key thing to understand about this whitepaper is what it was not. It was not a framework to be adopted. It was not a set of practices to follow. The authors were careful to describe what Spotify was doing at that specific point in time, not what other companies should do. Kniberg himself has repeatedly emphasized this distinction: what they described was Spotify’s way of working, not a one-size-fits-all model.

The whitepaper described a set of organizational structures (squads, tribes, chapters, and guilds) designed to solve a specific problem: how to maintain the speed and autonomy of small teams while scaling to hundreds of engineers working on a shared product. It was the tension between autonomy and alignment made structural.

What happened next was predictable. The whitepaper was clear, well-illustrated, and addressed a problem that hundreds of growing tech companies were facing. It spread rapidly through the agile community. Conference talks referenced it. Blog posts explained it. Consulting firms packaged it. Within a few years, “the Spotify model” had become a recognized organizational pattern, adopted, adapted, and sometimes imposed wholesale on organizations with vastly different cultures, sizes, and challenges.

The gap between what Kniberg and Ivarsson described and how the industry received it is the defining tension of the Spotify model’s story: a descriptive snapshot treated as a prescriptive blueprint.

The Four Building Blocks

The Spotify model organizes people into four overlapping structures, each designed to solve a different coordination problem. Understanding how these four pieces relate to each other is essential; they are not independent departments but intersecting layers of a matrix.

Squads

The squad is the fundamental unit. A squad is a small, cross-functional team of 6 to 12 people with end-to-end responsibility for a specific feature area, product component, or user journey. Each squad operates like a mini-startup: it has its own mission, decides its own way of working, and controls its own backlog.

A squad typically includes all the skills needed to design, develop, test, and release its work: developers, a designer, a product owner, and a QA specialist. The squad does not need to hand off work to another team to get something done. This is by design: the cross-functional composition eliminates handoffs, reduces dependencies, and gives the squad autonomy over its delivery.

The Product Owner defines what the squad builds and in what order. The squad itself decides how to build it. There is no formal Scrum Master role prescribed by the Spotify model, though many squads adopt one. The squad chooses its own agile methodology: Scrum, Kanban, a hybrid, or something else entirely.

Autonomy is the defining characteristic. Squads are trusted to make their own technical decisions, manage their own work, and ship independently. This trust is not unconditional (it depends on alignment with the broader product direction) but the default is autonomy, with coordination emerging from culture and shared goals rather than top-down control.

Tribes

A tribe is a collection of squads working in a related product area. If squads are the mini-startups, the tribe is the incubator. Tribes typically contain between 40 and 150 people. The upper bound is deliberate, drawing on Robin Dunbar’s research suggesting that humans can maintain stable social relationships with approximately 150 individuals. Beyond that number, trust-based coordination starts to break down and formalized processes become necessary.

Each tribe has a Tribe Lead who is responsible for creating a productive environment for the squads. The Tribe Lead does not manage individual squads or make their decisions. Their job is to remove obstacles, facilitate coordination between squads, and ensure alignment with the broader organizational direction.

Tribes create physical and social proximity. In the original Spotify model, squads within the same tribe sat together, shared common spaces, and had regular tribe-wide gatherings. This proximity is not an accident; it is an intentional mechanism for informal coordination. When people work in the same area, they overhear conversations, bump into each other at coffee machines, and share context without needing formal meetings.

The tribe boundary defines a coordination space. Squads within the same tribe coordinate frequently and informally. Squads in different tribes coordinate less often and more deliberately. This creates a natural tension: tribe boundaries that are drawn well reduce internal friction; boundaries drawn poorly create silos.

Chapters

Chapters solve the competence problem that squads create. When you organize people into cross-functional squads, specialists get distributed. Your iOS developers are scattered across ten different squads, each working on a different feature. Who ensures they follow consistent technical standards? Who coaches them professionally? Who handles career development and salary discussions?

A chapter is a group of people with the same skill set working within the same tribe but in different squads. All the backend developers in a tribe form a chapter. All the designers form another. All the testers form another. Each chapter has a Chapter Lead, and this is where the model introduces its most significant structural tension.

The Chapter Lead is the formal line manager for chapter members. They handle performance reviews, career development, and salary conversations. But the Chapter Lead is also a working member of a squad, doing hands-on work alongside their people-management responsibilities. This dual role is deliberate: it keeps the Chapter Lead connected to the daily reality of the work. It also means they carry two jobs.

Chapters meet regularly to share knowledge, align on technical practices, discuss tooling choices, and address cross-squad concerns. They are the mechanism through which technical consistency and professional growth happen across squad boundaries.

Guilds

Guilds extend the community-of-practice concept beyond tribe boundaries. A guild is a voluntary, cross-tribe group of people who share an interest, skill, or knowledge area. Unlike chapters, guilds are open to anyone. You do not need to be a backend developer to join the backend guild. You just need to be interested.

Each guild has a Guild Coordinator who facilitates activities (meetups, workshops, shared channels, documentation efforts) but holds no formal authority. Guild membership is voluntary, participation is self-directed, and the guild exists only as long as it generates value for its members.

Guilds serve as the antidote to tribal silos. When tribes are large and self-contained, knowledge can become trapped within tribe boundaries. Guilds create cross-pollination channels: a testing guild shares automation practices across all tribes; a web development guild aligns on frontend standards company-wide; a leadership guild shares management practices across the organization.

How the Four Structures Intersect

The four structures form a matrix, but a matrix with a clear primary axis. The squad is the primary organizational unit. It is where work happens, where people spend most of their time, and where day-to-day decisions are made.

Tribes group squads for coordination. Chapters group specialists for competence. Guilds group enthusiasts for knowledge sharing.

Every engineer belongs to exactly one squad and one chapter. They may belong to one or more guilds. This means every person has two reporting lines: their squad (for product delivery) and their chapter (for people management and technical standards). This is the Spotify model’s version of a matrix organization, designed to capture the benefits of functional expertise and cross-functional delivery simultaneously.

Tribe A
├── Squad 1: [Designer, iOS Dev, Backend Dev, Tester, Product Owner]
├── Squad 2: [Designer, iOS Dev, Backend Dev, Android Dev, Product Owner]
├── Squad 3: [Designer, Backend Dev, Backend Dev, Tester, Product Owner]
│
├── Chapter: iOS Developers (spans Squad 1 + Squad 2)
├── Chapter: Backend Developers (spans all squads)
├── Chapter: Designers (spans all squads)
└── Chapter: Testers (spans Squad 1 + Squad 3)

Guild: Web Development (spans Tribe A + Tribe B + Tribe C)
Guild: Testing Practices (spans all tribes)

Core Principles Behind the Model

The structural components (squads, tribes, chapters, guilds) are the visible part of the Spotify model. But they are not what made it work at Spotify. What made it work was a set of cultural principles that the structure was designed to support. Copy the structure without these principles and you get a Spotify-shaped hierarchy.

Autonomy with alignment

This is the central tension the entire model is built around. Squads are autonomous: they choose their own methods, manage their own work, and make their own technical decisions. But they are not independent. They are aligned around a shared product vision and a common set of strategic priorities.

Kniberg described this as a spectrum. At one end, high alignment and high autonomy: leaders communicate the problem to solve and why it matters; squads figure out how to solve it. At the other end, low alignment and high autonomy: squads do whatever they want, and the result is a collection of disconnected efforts. The goal is to stay in the high-alignment, high-autonomy quadrant, where squads are free to decide how to work but clear on what the organization is trying to achieve.

This requires leaders who can articulate direction without dictating solutions. It requires squads who seek context about the bigger picture rather than optimizing locally. And it requires organizational transparency so that squads can align themselves rather than needing to be aligned by managers.

Culture over process

The Spotify model explicitly favored cultural norms over formalized processes. Rules were kept minimal. Trust was the default. The assumption was that hiring good people, giving them context, and trusting them to make reasonable decisions would produce better outcomes than detailed process documentation.

This worked at Spotify because the company had invested heavily in its engineering culture. Psychological safety, open communication, and a tolerance for experimentation were not slogans; they were practiced behaviors. The model was shaped by this culture, not the other way around.

Trust as default

Squads were trusted by default. They did not need to earn autonomy through a track record or justify their decisions to management. The organizational assumption was that squads would make good decisions, and that occasional mistakes were an acceptable cost of the speed that autonomy provided.

This is harder to implement than it sounds. Most organizations operate on the opposite default: trust must be earned, and autonomy is granted incrementally. Shifting to trust-as-default requires leaders to accept that some squads will make decisions they disagree with, and to intervene only when the consequences are significant, not merely when they would have chosen differently.

Cross-pollination over silos

Chapters and guilds existed specifically to prevent the silo effect that autonomous teams can create. When squads are fully autonomous, they may solve the same problem in three different ways, adopt incompatible technologies, or develop knowledge that never spreads beyond the squad.

The model addressed this through structural cross-cutting: chapters for technical alignment within tribes, guilds for knowledge sharing across tribes. The emphasis was on organic exchange (shared practices, voluntary participation, peer learning) rather than mandated standards imposed from above.

Continuous improvement over following a playbook

The Spotify model was never static. The whitepaper described a specific moment in the company’s evolution. Spotify continued to evolve its organizational structure after the whitepaper was published. The model itself was meant to be treated as a starting point for continuous experimentation, not a destination.

This principle is both the model’s greatest strength and the source of its most common misadoption. If the model is an invitation to experiment, copying it exactly is already a violation of its core philosophy.

The Spotify Model vs Other Organizational Frameworks

The Spotify model sits within a broader landscape of approaches to organizational design. Each addresses different problems, operates at different levels of formality, and suits different contexts. The following comparison helps clarify what the Spotify model does and does not offer relative to alternatives.

Dimension	Traditional Hierarchy	Spotify Model	Holacracy	Sociocracy	RenDanHeYi	Beta Codex / Peach	DSO (Bayer)	SAFe	Buurtzorg
Authority structure	Top-down chain of command	Squad autonomy within tribe alignment	Constitution-governed roles and circles	Consent-based circles with double-linking	Distributed to microenterprises	Decentralized center-periphery	Distributed to autonomous teams	Hierarchical with agile layers	Self-managing neighborhood teams
Basic unit	Department / division	Squad (6-12, cross-functional)	Circle with defined roles	Circle with double-linking	Microenterprise (10-15 people)	Autonomous cell at periphery	Customer/product team (6-10)	Agile Release Train	Self-managing team (10-12 nurses)
Decision-making	Manager approval	Squad-level autonomy	Integrative decision-making process	Consent (no reasoned objections)	Market-driven, ME autonomy	Mastery-based, at the periphery	95% at team level	PI Planning + team decisions	Team-level consensus
Scaling mechanism	Adding management layers	Tribes (max ~150), chapters, guilds	Nested circles	Nested circles with double-linking	Ecosystems of micro-communities	Federalized cells	90-day cycles, VACC coaching	ARTs, Solution Trains, Portfolio	Regional coaching + back-office
Leadership model	Hierarchical managers	Tribe leads, chapter leads	Lead Links and Rep Links	Facilitators and delegates	”Everyone is their own CEO”	Distributed, mastery-based	VACC (Visionaries, Architects, Catalysts, Coaches)	RTE, System Architect, Product Management	Coach (not manager)
Formality	High (policies, procedures)	Low to moderate (culture-driven)	Very high (written constitution)	Moderate (principles-based)	Moderate (market discipline)	Low (network principles)	Moderate (VACC + 90-day structure)	Very high (SAFe framework)	Low (principles-based)
Best suited for	Stable environments, compliance-heavy	Product-oriented tech companies, 50-500 engineers	Organizations wanting explicit governance	Organizations prioritizing inclusive decisions	Large enterprises seeking entrepreneurial speed	Market-facing organizations seeking decentralization	Large enterprises reducing bureaucracy	Large enterprises scaling agile delivery	Care/service organizations
Scale tested	Any scale	Hundreds to low thousands	Hundreds to low thousands	Hundreds to low thousands	80,000+ employees	Varies	100,000+ (in progress)	Tens of thousands	15,000+ professionals

Key distinctions

Spotify Model vs SAFe: SAFe (Scaled Agile Framework) is prescriptive where the Spotify model is descriptive. SAFe provides detailed ceremonies, roles, and planning events at every level of the organization. The Spotify model provides structural concepts and trusts teams to fill in the details. SAFe works well for organizations that need process rigor and compliance traceability. The Spotify model works better for organizations with strong engineering cultures that resist heavy process. Many organizations use elements of both.

Spotify Model vs Holacracy: Holacracy provides a formal governance constitution with explicit rules for how roles are created, how decisions are made, and how meetings run. The Spotify model has no constitution. Its governance is cultural, not procedural. Organizations that want clear, documented governance processes will find holacracy more structured. Organizations that prefer cultural norms over formal rules will find the Spotify model more natural.

Spotify Model vs Sociocracy: Sociocracy centers on consent-based decision-making and double-linking between governance layers. The Spotify model does not prescribe a decision-making process; squads decide how they decide. Sociocracy is better suited for organizations that want structured governance across all levels. The Spotify model is better suited for product engineering contexts where delivery speed matters more than governance formality.

Spotify Model vs RenDanHeYi: RenDanHeYi at Haier pushes autonomy further than the Spotify model. Each microenterprise operates with full profit-and-loss responsibility and hires its own team. Spotify’s squads are autonomous in how they work but not in how they are staffed or funded. RenDanHeYi is designed for market-driven enterprises where each unit connects directly to customers. The Spotify model is designed for product engineering organizations where squads contribute to a shared product.

Spotify Model vs Beta Codex: Beta Codex operates at a higher level of abstraction. It defines 12 laws about how organizations should be structured, perform, and adapt, without prescribing specific team shapes. The Spotify model is more concrete: it defines specific structural units (squads, tribes, chapters, guilds) with specific sizes and relationships. Beta Codex can encompass a Spotify-style structure within its peripheral cells, but it addresses the entire organizational model rather than just the product engineering function.

Spotify Model vs DSO: Dynamic Shared Ownership at Bayer shares the Spotify model’s emphasis on autonomous teams but adds structured planning cadence (90-day cycles) and an explicit leadership framework (VACC). DSO was designed for enterprise scale from the start; the Spotify model emerged from a mid-sized engineering organization and faces challenges at larger scales.

Why Spotify Moved On

Understanding why Spotify evolved beyond its own model is essential context for anyone considering adoption. The model was a snapshot, and the organization it described continued to change.

The Jeremiah Lee critique

In 2020, Jeremiah Lee, a former Spotify employee, published a widely circulated critique titled “Spotify’s Failed Squad Goals.” Lee argued that the model described in the whitepaper had not worked as intended even at Spotify. His key observations:

• Autonomous squads created coordination problems. When squads independently chose their own tools, architectures, and approaches, the result was fragmentation: inconsistent codebases, duplicated effort, and integration headaches.
• The chapter structure did not deliver on its promise. Chapter Leads were stretched between their squad responsibilities and their people-management role, and chapter meetings often felt like an afterthought.
• Tribal boundaries became silos. Tribes, designed to create focused coordination, also created walls. Cross-tribe collaboration was harder than the model anticipated.
• The culture that made it work was not transferable. Spotify had a specific engineering culture (high trust, strong autonomy norms, tolerance for messiness) that the model was shaped by. Other companies adopted the structure without this culture and got different results.

Lee’s critique resonated because it articulated what many companies had experienced: the Spotify model sounded right but did not feel right when implemented in a different context.

The matrix trap

The Chapter Lead role is the model’s most structurally fragile element. A Chapter Lead is simultaneously a working member of a squad (contributing to product delivery) and a people manager for chapter members across multiple squads (responsible for career development, performance feedback, and salary decisions).

This is a half-time role split in both directions, and it creates predictable tension. During sprint crunch periods, squad work dominates and chapter duties get deferred. During performance review cycles, management responsibilities consume time that was committed to the squad. Chapter Leads who lean toward management become disconnected from the code. Those who lean toward engineering become poor people managers.

The result is often a Chapter Lead who does neither job well, not because they lack capability, but because the structural design demands two conflicting uses of the same person’s time.

Tribal silos

Tribes were sized at approximately 150 people for a reason rooted in social psychology. But the social cohesion that Dunbar’s number encourages within a tribe can also create an us-and-them dynamic between tribes. When a tribe is self-sufficient, with its own squads, its own priorities, and its own Tribe Lead, the incentive to collaborate with other tribes diminishes.

Guilds were supposed to bridge this gap, but guild participation is voluntary. When deadlines tighten, guild activities are the first thing dropped. Without strong investment in cross-tribe coordination, the tribe boundary becomes an information wall.

What Spotify does now

Spotify has not published a successor model with the same clarity as the 2012 whitepaper. What is known is that the company has moved toward a more flexible, less labeled structure. The language of squads and tribes persists in some areas but is no longer the defining organizational framework. The company continues to experiment with how it organizes work, which, ironically, is exactly what the original whitepaper recommended.

Where the Spotify Model Works (and Where It Doesn’t)

Where it works

Product-oriented technology companies with 50-500 engineers. This is the sweet spot. The model was designed for a product engineering organization at roughly this scale, and its mechanisms (squad autonomy, tribe-level coordination, chapter-led technical alignment) map well to this context. Companies building software products with multiple feature areas and cross-functional teams will find the model intuitive.

Organizations with a strong engineering culture. The model depends on cultural norms that cannot be mandated: trust, autonomy, psychological safety, and a willingness to let teams make mistakes. Organizations where engineers are accustomed to self-direction and where leadership practices servant-leadership will find adoption smoother.

Companies willing to adapt rather than copy. The organizations that succeed with the Spotify model are the ones that treat it as a starting vocabulary, not a rigid blueprint. They adopt the structural concepts, tune the details to their context, and evolve the model as they learn. ING, the Dutch banking group, famously adopted a Spotify-inspired model but adapted it significantly to fit a regulated financial services environment.

Where it struggles

Non-technology contexts. The model was designed for software engineering. Its assumptions (cross-functional delivery teams, iterative development, frequent releases, technical autonomy) do not map cleanly to manufacturing, logistics, healthcare, or other domains where work is sequential, physical, or heavily regulated. Renaming a nursing unit a “squad” does not make it autonomous in any meaningful sense.

Organizations without an autonomy culture. Adopting the Spotify model in an organization where decisions are currently made by managers and execution is directed from above requires a cultural transformation that the model itself does not provide. The structure assumes the culture exists. If it does not, the structure becomes a facade: squads in name, command-and-control in practice.

Heavily regulated industries. Compliance requirements in pharmaceuticals, finance, and aerospace often demand documented approval chains, audit trails, and standardized processes. Squad-level autonomy in choosing tools, approaches, and architectures can conflict with regulatory requirements that mandate consistency and traceability.

Very large organizations (1,000+ engineers). The model scales through tribes, but beyond 5-10 tribes, coordination across tribes becomes a significant challenge. The model does not prescribe a structure above the tribe level. Organizations at this scale often need additional coordination layers, which pushes them toward frameworks like SAFe, LeSS, or custom hybrid approaches.

The adaptation principle

The most important takeaway is also the simplest: take what works, leave what does not. The Spotify model is not a package deal. You can adopt squads without tribes. You can use chapters without guilds. You can draw on the autonomy-with-alignment principle without labeling anything. The value lies in the ideas, not in the labels.

Common Adoption Mistakes

Having observed the Spotify model’s adoption across many organizations, several failure patterns recur with striking regularity.

Mistake 1: Treating a description as a prescription

The whitepaper described how Spotify worked. It did not recommend that other companies work the same way. Treating a descriptive document as a prescriptive framework (“We will now have squads, tribes, chapters, and guilds”) misses the point. The specific structural choices Spotify made were tailored to Spotify’s context, size, product, and culture.

The fix: use the model as inspiration and vocabulary. Ask which problems in your organization the model’s components address. Adopt the parts that solve your problems. Leave the rest.

Mistake 2: Copying structure without culture

This is the most common and most damaging mistake. Organizations rename teams to squads, group them into tribes, appoint Chapter Leads and Tribe Leads, and nothing changes. People still wait for manager approval. Squads still escalate decisions upward. Chapter meetings happen but produce no value.

The structure is a container. The culture is what goes inside it. Autonomy, trust, psychological safety, transparency, and a bias toward action are not structural properties; they are behavioral ones. You cannot install them by reorganizing the org chart.

Mistake 3: Ignoring the Chapter Lead tension

The dual role of Chapter Lead (part squad member, part people manager) is a known weakness of the model. Organizations that adopt the model without explicitly addressing this tension produce Chapter Leads who burn out, underperform in one or both roles, or quietly abandon the squad work to focus on management.

Some organizations resolve this by making Chapter Lead a full-time management role (sacrificing the connection to daily work). Others split the responsibilities between a technical lead and a people manager. Others reduce the management load by moving career conversations to HR partners. Each approach has trade-offs, but ignoring the tension is not an option.

Mistake 4: Forcing it on non-product teams

Support functions (HR, finance, legal, infrastructure) do not naturally fit the squad model. Their work is often reactive, cross-cutting, and process-oriented rather than feature-oriented. Forcing these teams into squads creates artificial boundaries and unnecessary overhead.

Some organizations exclude support functions from the Spotify model entirely, keeping them in a more traditional structure. Others create service-oriented squads within support functions, organized around the types of requests they handle. Both approaches are valid. The mistake is insisting that every team must be a squad.

Mistake 5: Not evolving the model

The original whitepaper was a snapshot. Spotify continued to change. Organizations that adopt the model and then freeze it, treating the initial implementation as permanent, violate the very principle of continuous improvement that the model embodies.

Build in regular retrospectives at the structural level. Ask: are tribe boundaries still right? Are chapters delivering value? Are guilds active or dormant? Are squads genuinely autonomous? The model should evolve as the organization evolves.

Making the Spotify Model Work for Your Organization

If you decide to draw from the Spotify model, here is a practical approach that avoids the most common pitfalls.

Start with squads

The squad is the model’s strongest idea: a small, cross-functional team with a clear mission and the autonomy to deliver on it. Start here. Identify a product area, form a squad with the necessary skills, give them a clear mission and decision-making authority, and see what happens. You do not need tribes, chapters, or guilds to test the core concept.

Define tribe boundaries by product area

If you grow beyond 3-4 squads, grouping them makes sense. Define tribe boundaries around product areas, customer segments, or platform layers, whatever creates natural coordination needs between the squads within the boundary. Resist the temptation to create tribes based on organizational politics. The boundary should reflect work dependencies, not reporting relationships.

Keep tribes below 150 people. If a tribe grows beyond that, split it. The social dynamics that make tribe-level coordination work depend on people knowing each other.

Solve the Chapter Lead dilemma explicitly

Do not accept the Chapter Lead role as described in the whitepaper without adapting it to your context. The half-squad-member, half-people-manager split works poorly in practice. Choose one of these alternatives:

• Full-time Chapter Lead: the Chapter Lead focuses entirely on people management and technical leadership. They attend squad standups and reviews but do not carry a squad workload.
• Split roles: separate technical leadership (a senior engineer in each squad) from people management (an engineering manager who covers multiple squads).
• Rotating Chapter Lead: the role rotates among senior members, distributing the burden and building leadership skills.

Whatever you choose, make the decision conscious and explicit.

Use guilds to prevent tribal silos

Invest in guilds from the start. Do not wait until silos form. Allocate time for guild activities. Give Guild Coordinators explicit support. Make guild outputs (technical guidelines, shared tools, documentation) visible and valued.

Guilds only work if participation is genuinely valued by the organization, not just permitted. If guild activities are the first thing canceled when a deadline approaches, the message is clear: cross-pollination is optional. It should not be.

Make the structure visible

Any organizational model only works if people can see it. When you organize into squads, tribes, chapters, and guilds, the resulting structure is more complex than a traditional hierarchy. People need to understand which squad they belong to, which tribe their squad is part of, who their Chapter Lead is, and which guilds are available.

This is where organizational mapping becomes essential. A living map (not a static diagram in a slide deck) that shows the current state of squads, tribes, chapters, and guilds gives everyone a shared reference point. It makes the structure navigable rather than abstract. Tools like Peerdom are designed for exactly this: making organizational structures visible, searchable, and up to date regardless of the model you use.

Evolve it

Set a cadence for structural retrospectives. Quarterly is a good starting point. Review whether tribe boundaries still reflect how work actually flows. Assess whether chapters are adding value or just adding meetings. Check whether guilds are active. Ask squads whether they feel genuinely autonomous.

The whole point of the Spotify model is that it was never meant to be permanent. The best version of it is the one you have adapted to your specific context and continue to refine.

Frequently Asked Questions

Does Spotify still use the Spotify model?

Not in its original form. Spotify has evolved its organizational structure significantly since the 2012 whitepaper. Some of the vocabulary persists (squads and tribes are still referenced) but the specific structures and practices described in the whitepaper no longer define how the company operates. Jeremiah Lee’s 2020 critique and statements from Spotify engineers confirm that the company moved on from the model as originally described. This is not a failure; it is consistent with the model’s own principle of continuous evolution.

What is the difference between a chapter and a guild?

A chapter is a group of people with the same skill set within the same tribe (for example, all backend developers in Tribe A). It has a formal Chapter Lead who serves as the line manager. Membership is mandatory: if you are a backend developer in Tribe A, you are in the backend chapter. A guild is a cross-tribe community of interest (for example, everyone interested in testing practices across the entire company). Guild membership is voluntary, and the Guild Coordinator has no management authority. Chapters are for technical alignment and people management. Guilds are for knowledge sharing and cross-pollination.

How big should a squad be?

The whitepaper suggested 6-12 people. This range follows the general research on effective team sizes: large enough to contain the necessary skills for end-to-end delivery, small enough for everyone to know each other, communicate directly, and maintain shared context. Below 6, you may lack necessary skills. Above 12, coordination overhead starts to erode the benefits of being a small team.

Can non-tech companies use the Spotify model?

The structural concepts (autonomous cross-functional teams, groupings for coordination, communities of practice for knowledge sharing) apply broadly. But the specific implementation described in the whitepaper was designed for software engineering, where iterative delivery, technical autonomy, and frequent releases are the norm. Non-tech companies can draw on the principles, especially autonomy with alignment and cross-functional team structure, but should expect to adapt significantly. For organizations outside of tech, models like sociocracy, Beta Codex, or the Buurtzorg model may provide a better fit.

How does the Spotify model compare to SAFe?

SAFe (Scaled Agile Framework) is a comprehensive, prescriptive framework with defined roles, ceremonies, and planning events at team, program, and portfolio levels. The Spotify model is a set of structural concepts with minimal prescribed process. SAFe works well for large organizations that need process rigor, compliance traceability, and cross-team synchronization. The Spotify model works better for organizations with strong engineering cultures that want structural guidance without heavy process. The two are not mutually exclusive; some organizations use SAFe’s planning cadence with Spotify-style team structures.

What is a Tribe Lead’s role?

The Tribe Lead creates the environment in which squads can succeed. They do not manage individual squads or make product decisions for them. Their responsibilities include: removing obstacles that squads cannot resolve themselves, facilitating coordination between squads within the tribe, ensuring alignment with the broader organizational direction, and representing the tribe’s needs to other parts of the organization. The Tribe Lead is closer to a servant-leader than a traditional manager.

How do squads coordinate across tribes?

Cross-tribe coordination is one of the model’s weaker areas. The primary mechanisms are guilds (voluntary communities that share knowledge across tribe boundaries) and informal communication. Some organizations add explicit cross-tribe coordination roles, regular cross-tribe syncs, or architectural steering groups. Others rely on shared platform teams that provide services to multiple tribes. The right approach depends on how tightly coupled the work across tribes actually is.

How does the Spotify model handle role-based governance?

The Spotify model does not prescribe a formal governance process. Roles within squads (Product Owner, developer, designer) are defined by the model, but how those roles are created, modified, or retired is left to each squad and tribe. Organizations that want explicit role-based governance can layer it on top of the Spotify model, using holacratic or sociocratic governance processes within the squad and chapter structure.

Start mapping your organization

Whether you are adopting the Spotify model, adapting a few of its ideas, or exploring a different approach entirely, the first step is the same: make your current structure visible. Map your teams, roles, and relationships so that everyone shares the same understanding of how the organization actually works.

• Start mapping for free: Peerdom supports the Spotify model, holacracy, sociocracy, RenDanHeYi, Beta Codex, DSO, and any hybrid model. Map your squads, tribes, chapters, and guilds, or your circles, cells, and teams, in one platform.
• Browse templates: explore pre-built structures for various organizational models.
• Read the self-management software guide: compare tools for organizations using distributed authority models.
• Not sure where to start? Book a demo and we will walk through how your organization’s structure maps to the model you are exploring.