The Spotify Model: An Organizational Framework for Scaling Agile
The Spotify Model is an organizational framework that structures engineering teams into small, autonomous squads, each owning a piece of the product. Squads are grouped into tribes for coordination. Chapters connect people who share the same discipline across squads, while guilds create voluntary communities of interest across the entire company. The model prioritizes team autonomy and loose coupling over standardized processes, aiming to preserve startup speed as an organization scales.
Overview
The Spotify Model emerged from a 2012 whitepaper by Henrik Kniberg and Anders Ivarsson, two agile coaches working inside Spotify's engineering organization. The paper, titled "Scaling Agile @ Spotify," was not a prescription. It was a snapshot. Kniberg and Ivarsson described how Spotify had organized its roughly 30 engineering teams at the time, explaining the logic behind four structural elements: squads, tribes, chapters, and guilds. The paper spread rapidly through the agile community, and within a few years the "Spotify Model" became one of the most referenced frameworks for scaling product development. Ironically, Spotify's own leaders have repeatedly said the snapshot was already outdated by the time it went viral, and that the company itself kept evolving away from the structures the paper described.
The core idea is that traditional organizational hierarchies slow teams down as companies grow. Functional departments create handoffs. Matrix structures create confusion about who decides what. The Spotify Model proposes an alternative: organize primarily around small, cross-functional teams (squads) that each own a specific mission or piece of the product end-to-end. These squads are the basic unit. They have the autonomy to choose their own tools, processes, and ways of working. They are expected to be loosely coupled (minimal dependencies on other squads) but tightly aligned (working toward shared company goals). The model then layers on three additional structures to handle the coordination and craft-development needs that autonomous squads alone cannot solve.
Tribes group related squads together, typically around a product area or business domain, capped at roughly 100 people following Dunbar's number logic. The tribe lead ensures squads within the tribe are aligned and not duplicating effort. Chapters are the discipline homes. All backend engineers across a tribe, for instance, belong to a backend chapter. The chapter lead (who is also an engineering manager) handles people management, career growth, and craft standards. This lets squads stay cross-functional for delivery while ensuring engineers still get mentorship from someone who understands their craft deeply. Guilds are the loosest structure: voluntary communities of interest that span the entire organization. A web technology guild, a testing guild, a leadership guild. They have no formal authority but serve as knowledge-sharing networks.
What makes the Spotify Model distinctive in the landscape of scaling frameworks is what it is not. It is not SAFe (Scaled Agile Framework), which prescribes ceremony-heavy coordination across teams with release trains and portfolio Kanbans. It is not LeSS (Large-Scale Scrum), which insists all teams run Scrum with shared backlogs. The Spotify Model is intentionally loose. It provides structural vocabulary but no mandated process. Squads can run Scrum, Kanban, or something entirely custom. There is no prescribed sprint cadence, no mandatory ceremonies, no formal release train. This flexibility is its greatest strength and its greatest risk. It works well in high-trust engineering cultures where teams are mature enough to self-organize. It can collapse into chaos in organizations that adopt the structure without the culture.
Since 2012, the model has been adopted (and adapted) by companies including ING Bank, Zalando, Bosch, and many mid-stage startups. ING's implementation, in particular, became a well-known case study of applying the framework outside pure tech companies. The model has also accumulated meaningful criticism. Jeremiah Lee, a former Spotify employee, published a widely cited critique in 2020 arguing that the model had not actually worked well inside Spotify itself, that matrix management through chapters created confusion, and that the framework's popularity outstripped its proven results. The honest take is that the Spotify Model provides a useful set of organizational primitives for thinking about team structure at scale. The mistake is treating it as a blueprint to copy rather than a set of ideas to adapt.
Teams using Hamster can model their squads, tribes, and guild structures within their workspace, leveraging AI agents to help coordinate across teams while preserving the autonomy that makes the model work. But the real value of studying the Spotify Model is not in copying its org chart. It is in understanding the tensions it tries to resolve: autonomy versus alignment, craft depth versus delivery speed, team independence versus organizational coherence. Those tensions exist in every growing company, regardless of which labels you put on the boxes.
How It Works
Step 1: Map Your Product into Potential Squad Missions
Before creating any squads, decompose your product into distinct areas of ownership. Each potential squad mission should correspond to a user-facing capability, a platform concern, or a business domain that can be developed somewhat independently. " The test for a good mission is whether the squad could set goals, plan work, and ship improvements without needing another squad's permission for most of their work. If two proposed missions cannot be changed independently because they share the same data models, deployment pipelines, or user flows, they may need to be combined or the underlying architecture needs to be decoupled first. A common mistake is defining squads around technical layers ("the API team," "the database team") rather than product domains. This recreates functional silos with new names.
Step 2: Form Cross-Functional Squads Around Those Missions
Staff each squad with the mix of disciplines needed to deliver on its mission end-to-end. A typical squad includes 6-8 people: a product owner, a few engineers, a designer, and potentially a data analyst or QA specialist depending on the mission. The product owner sets priority and represents stakeholder needs. There is no designated squad "lead" in the original model. The squad self-organizes around delivery. You know you have formed a good squad when it can take a user problem from understanding to shipped solution without filing tickets for other teams to do parts of the work. Watch out for squads that are too small (a 3-person squad cannot realistically be cross-functional) or too large (beyond 8-9 people, communication overhead increases and the team starts to fragment into sub-groups).
Step 3: Group Related Squads into Tribes
Cluster squads that work on related parts of the product into a tribe. The tribe should correspond to a meaningful product area or business domain. Aim for 3-10 squads per tribe, staying under roughly 100 people total. Assign a tribe lead whose job is not to manage squads but to ensure alignment between them, remove cross-squad blockers, and represent the tribe's needs to the rest of the organization. The tribe lead often works closely with a product director or area lead to set the strategic direction that squads align to. You will know the tribe boundaries are wrong if squads within the same tribe rarely need to coordinate, or if squads in different tribes are constantly blocked by each other. Redraw the boundaries based on actual dependency patterns, not theoretical org chart symmetry.
Step 4: Establish Chapters Within Each Tribe
For each discipline that appears across multiple squads within a tribe, create a chapter. All iOS engineers in a tribe form the iOS chapter. All designers form the design chapter. Appoint a chapter lead who serves as both the people manager for chapter members and the steward of craft standards for that discipline within the tribe. The chapter lead conducts one-on-ones, handles career development, participates in hiring, and facilitates regular chapter meetings where members share techniques, review each other's work, and agree on baseline standards. The dual allegiance (squad for delivery, chapter for growth) is the most complex aspect of the model. Be explicit about how conflicts are resolved. In most implementations, day-to-day priority comes from the squad and product owner, while the chapter lead focuses on long-term growth, quality standards, and ensuring people are not burning out.
Step 5: Seed Guilds Based on Organic Interest
Identify topics that span multiple tribes and where practitioners want to share knowledge. Common starting guilds include web technology, testing practices, agile coaching, and leadership development. Guilds should be voluntary. Appoint a guild coordinator (not a guild manager) whose role is to organize regular sessions, maintain shared documentation, and keep the guild active. A good guild cadence might be a monthly meetup plus an active chat channel. Resist the urge to create guilds for everything. Start with 2-3 where clear energy exists, and let others emerge organically. Guilds that are mandated from above tend to die quickly because nobody has genuine motivation to participate. Guilds that solve real pain points (like inconsistent testing practices across tribes) sustain themselves.
Step 6: Define Alignment Mechanisms Without Centralizing Control
Autonomy without alignment produces chaos. Establish lightweight mechanisms that keep squads pointed in the same direction without micromanaging their work. Common approaches include: quarterly company bets or OKRs that squads align their missions to, tribe-level showcases where squads demo recent work to each other, and cross-tribe architecture reviews for decisions that affect shared infrastructure. The original Spotify approach emphasized internal open source, where any squad could contribute to any codebase, reducing the need for formal coordination. The key test is whether a squad can explain how its current work connects to a company-level goal. If it cannot, alignment has broken down. But if aligning requires attending five coordination meetings a week, the mechanism has become heavier than the problem it solves.
Step 7: Iterate on the Structure Based on What You Learn
The Spotify Model is not a target state. It is a starting point. Run retrospectives on the organizational structure itself, not just on squad-level delivery. Every quarter, assess: Are squads actually autonomous, or are dependencies forcing constant coordination? Are chapters providing genuine craft mentorship, or are they just another meeting? Are tribes sized correctly? Are guilds alive or zombie structures that exist on paper? Be willing to merge squads, split tribes, reassign missions, and shut down guilds that are not providing value. The organizations that succeed with this model treat it as a living system that evolves with their product, their people, and their market. The ones that fail treat the initial design as sacred and refuse to adjust when reality contradicts the plan.
When to Use
- When your engineering organization has grown past 40-50 people and traditional team structures are creating bottlenecks, handoffs between functional groups are slowing delivery, and nobody has a clear picture of who owns what part of the product.
- When you have a single large product (or tightly related product suite) that can be decomposed into relatively independent areas of ownership, where each area has enough scope to keep a squad busy and enough independence that squads can ship without coordinating every release.
- When your codebase architecture supports independent deployment, either through microservices, modular monoliths, or well-defined API boundaries, so that the organizational autonomy you are granting to squads is backed by technical autonomy rather than contradicted by a tangled shared codebase.
- When your leadership culture already leans toward trust and delegation rather than command and control, and you have engineering managers who are comfortable coaching rather than directing, because the Spotify Model amplifies whatever culture already exists rather than creating a new one.
- When you are scaling from a startup culture that already values autonomous teams and you want to preserve that energy while adding enough structure to coordinate across 5, 10, or 20 teams, rather than imposing a heavy top-down framework like SAFe that would feel alien to your existing culture.
- When knowledge silos are forming between teams because people in the same discipline (design, backend, data) are isolated in different squads and have stopped learning from each other, and you need a mechanism like chapters and guilds to reconnect craft communities without sacrificing cross-functional squad delivery.
When Not to Use
- When your organization has fewer than 3-4 teams. The Spotify Model solves coordination problems that emerge at scale. With a small number of teams, the overhead of defining tribes, chapters, and guilds outweighs the benefit. Simple cross-functional teams with direct communication channels are faster and lighter. You do not need a coordination framework when everyone fits in one room.
- When your codebase is a tightly coupled monolith where every change requires coordination across multiple teams. The model assumes squads can work independently, and if your architecture contradicts that assumption, squads will have autonomy on paper but constant dependencies in practice. Fix the architecture first, then reorganize. Putting Spotify labels on teams that cannot actually ship independently creates frustration, not speed.
- When your leadership culture is fundamentally command-and-control. If managers expect to approve every decision, if there is no tolerance for squads choosing their own tools or processes, if failure is punished rather than analyzed, then the Spotify Model becomes theater. You will create squads that are autonomous in name but micromanaged in practice. The model requires genuine delegation, which is a cultural shift that takes years, not a reorg that takes weeks.
- When your company operates across many unrelated products or business units with little shared technology or customer overlap. The tribe structure assumes squads within a tribe are working on related parts of a shared product. If your teams are building entirely independent products, traditional business unit structures with their own dedicated teams may be simpler and more honest than forcing unrelated work into a tribe container.
- When regulatory or compliance requirements demand strict process standardization across all teams. Industries like healthcare, aviation, or financial services sometimes require documented, auditable processes that every team must follow identically. The Spotify Model's principle of letting squads choose their own ways of working can conflict with these requirements. You may be able to adapt the model by defining non-negotiable compliance guardrails, but the core philosophy of maximum squad autonomy may not fit.
Examples
Example: ING Bank's Agile Transformation Using Spotify Structures
In 2015, ING Netherlands undertook one of the most publicized adoptions of the Spotify Model outside of tech. The bank's IT and business teams, roughly 3,500 people, were reorganized from traditional functional departments into squads, tribes, and chapters. Each squad of about 9 people focused on a customer journey (like mortgage applications or mobile banking). Tribes were organized around customer domains rather than banking products. ING reported a 30% improvement in time-to-market for new features within two years. However, the transformation required laying off hundreds of middle managers whose roles were eliminated, which created significant organizational pain. They also found that strict regulatory requirements in banking meant squads could not have full autonomy over processes, so they added compliance guardrails that the original Spotify paper never addressed. The lesson: the structural vocabulary transferred well, but the cultural and regulatory context required heavy adaptation.
Example: Mid-Stage SaaS Startup Scaling from 4 to 12 Teams
A B2B SaaS company with about 80 engineers had grown from 4 teams to 12 over 18 months. Teams were originally organized by technology layer: frontend, backend, infrastructure, and data. As they added teams, handoffs between layers slowed every feature. They reorganized into product-domain squads: onboarding, core workflow, integrations, billing, and analytics. Related squads were grouped into two tribes. Backend engineers across all squads formed a backend chapter to maintain shared API standards. They launched a single guild for developer experience tools. Within two quarters, feature cycle time dropped from 6 weeks to about 3 weeks because squads could ship end-to-end without cross-team tickets. The chapter prevented API inconsistency by establishing shared conventions. One mistake they would correct: they initially made the guild mandatory, which killed engagement. After making it opt-in and focusing it on a specific pain point (CI pipeline speed), participation tripled.
Example: Enterprise Hardware Company Attempting the Model Without Cultural Readiness
A 2,000-person hardware company with a growing software division tried adopting the Spotify Model for its 200-person engineering group. They renamed all teams to squads, grouped them into tribes by product line, and created chapters for each engineering discipline. On paper the structure looked textbook. In practice, it failed. The company's culture was deeply hierarchical. Managers who became chapter leads continued to assign daily tasks to their reports, overriding squad priorities. The tribe leads treated their role like traditional VP positions and ran top-down planning cycles. Squads had no real autonomy because the monolithic codebase required release coordination across all teams. After a year, developers reported being more confused than before about who to listen to (squad product owner or chapter lead), and delivery velocity had not improved. The company reverted to a simpler team-of-teams structure and invested 18 months in decoupling their architecture before attempting any further organizational change. The takeaway: structure follows culture and architecture, not the other way around.
Example: E-Commerce Platform Adapting the Model for a Distributed Workforce
A European e-commerce company with 120 engineers across 4 countries adopted Spotify-inspired structures while being fully remote. They formed 14 squads organized into 3 tribes (buyer experience, seller tools, platform infrastructure). The twist was that chapters became the primary social fabric for remote employees. Chapter leads ran weekly video sessions focused half on craft discussion and half on team bonding, which countered the isolation that remote squad members felt. Guilds operated entirely through async Slack channels and monthly recorded presentations. They discovered that the tribe concept was harder to make real in a remote context because the informal hallway conversations that tribes rely on for coordination did not happen naturally. They compensated by adding a short weekly tribe standup (15 minutes, tribe lead plus one representative per squad) to surface cross-squad dependencies. After a year, employee engagement scores for engineering improved by 22%, and inter-team dependency blockers decreased by 40%. What they would change: they wish they had invested earlier in shared tooling for cross-squad visibility rather than relying on tribe standups, which became a bottleneck as the third tribe grew past 8 squads.
Skills in This Method
Organizing Squads into Tribes for Strategic Alignment
How to group related squads into tribes, set tribe size limits, appoint tribe leads, and maintain alignment across squads without sacrificing autonomy.
Scaling Agile Practices Using Spotify Structures
How to use the Spotify organizational model as a scaling framework, including when to split tribes, spawn new squads, and evolve governance as the company grows.
Evaluating Spotify Model Tradeoffs and Common Pitfalls
How to assess the pros, cons, and known failure modes of the Spotify Model so you can make an informed adoption decision and avoid cargo-culting.
Building Guilds for Cross-Tribe Knowledge Sharing
How to create and sustain voluntary, company-wide guilds that share knowledge, tooling, and best practices across tribe boundaries.
Balancing Squad Autonomy with Organizational Alignment
Techniques for setting guardrails, defining loose coupling and tight alignment, and using OKRs or mission briefs so squads stay autonomous yet strategically coherent.
Forming Autonomous Squads with Clear Missions
How to define, staff, and launch cross-functional squads with well-scoped missions, product ownership, and end-to-end delivery responsibility.
Adapting the Spotify Model to Your Organization
A step-by-step approach for implementing and customizing the squad/tribe/chapter/guild structure to fit your company's size, culture, and existing processes.
Running Chapters to Build Discipline-Specific Excellence
How to establish and facilitate chapters—groups of specialists across squads within a tribe—to standardize practices, mentor members, and manage career growth.