Organizing Squads into Spotify Tribes for Strategic Alignment
This skill teaches you how to group related squads into tribes with clear boundaries, the right size constraints, and effective tribe leadership so that autonomous squads stay aligned on shared strategic outcomes.
Group squads that share a related mission area into a tribe of no more than roughly 100 people. Appoint a tribe lead who owns strategic context, facilitates cross-squad coordination, and removes systemic blockers. The tribe lead does not manage individual squads but ensures they row in the same direction through regular rituals like tribe gatherings, shared OKRs, and lightweight dependency tracking.
Outcome: You produce a documented tribe structure that groups related squads under tribe leads, with explicit size limits, coordination rituals, and alignment mechanisms that reduce cross-squad friction while preserving each squad's autonomy.
Prerequisites
- An existing set of squads with defined missions (see forming-autonomous-squads)
- A clear product or organizational strategy to align tribes toward
- Basic understanding of the Spotify Squad Model structure (squads, chapters, guilds)
- Authority or sponsorship to make structural organizational changes
Overview
Spotify tribes are the primary mechanism for creating strategic alignment among autonomous squads. When you have more than a handful of squads, coordination costs start creeping up. Squads working on related parts of the product duplicate effort, make conflicting architectural decisions, or drift apart on priorities. Tribes solve this by grouping squads that share a mission area, a customer segment, or a product domain into a cohesive unit with shared context and lightweight governance. The concept comes directly from the Spotify Squad Model, where tribes were designed as the smallest organizational unit large enough to pursue a meaningful strategic objective, yet small enough to maintain trust and informal communication.
The concrete artifact this skill produces is a tribe design document. This document maps each squad to a tribe, names the tribe lead, defines the tribe's mission boundary, lists the coordination rituals the tribe will use, and sets explicit size constraints. It also specifies how tribes relate to each other, identifying the narrow interfaces where cross-tribe coordination is genuinely necessary versus where tribes can operate independently. Think of it as an organizational blueprint that makes implicit groupings explicit and accountable.
The success criteria are observable. After implementing a well-designed tribe structure, you should see fewer unplanned dependencies surfacing mid-sprint, faster resolution of cross-squad blockers, and squads that can articulate how their work connects to the broader tribe mission. If squads still feel isolated or, conversely, feel micromanaged, those are signals the tribe boundaries or the tribe lead's operating model need adjustment. This skill sits between forming autonomous squads, which gives you the building blocks, and balancing autonomy and alignment, which gives you the ongoing calibration practices to keep the whole system healthy.
One important distinction: tribes are not traditional departments. A department is usually organized by function (all engineers, all designers). A tribe is organized by mission (all squads working on the payments experience, regardless of function). This cross-functional grouping is what makes tribes powerful for alignment. It is also what makes them tricky to get right, because you are drawing boundaries through your product architecture and your people structure simultaneously.
How It Works
The mental model behind Spotify tribes draws from Dunbar's number research and the military concept of a "company" sized unit. Robin Dunbar's work suggests that humans can maintain roughly 150 stable social relationships, and functional working groups tend to top out around 100 before communication overhead becomes unsustainable. Spotify adopted this as a practical constraint: a tribe should contain no more than about 100 people. Below that threshold, people can still know each other by name, bump into each other in hallways or Slack channels, and maintain the informal trust networks that make real coordination possible without heavy process.
The reason tribes work for alignment is that they create a bounded context for strategic decision-making. Without tribes, alignment is either centralized (a leadership team that makes all the calls, creating a bottleneck) or absent (squads make their own calls, creating drift). Tribes provide a middle layer. The tribe lead holds strategic context for the tribe's mission area and translates company-level strategy into tribe-level priorities. Individual squads then figure out how to execute within that frame. This is the "aligned autonomy" principle from the Spotify Squad Model: the tribe lead aligns on the "what" and "why," while squads own the "how."
The sizing constraint is not arbitrary. When a tribe grows past 100 people, several failure modes emerge. The tribe lead can no longer maintain meaningful relationships with all squad members. Tribe gatherings become unwieldy presentations instead of interactive sessions. Cross-squad coordination requires more formal process, and informal trust degrades. At that point, you need to split the tribe, which means finding a natural seam in the mission area where two distinct strategic objectives can be separated with minimal ongoing coordination.
Tribe leads occupy a unique role that is easy to misunderstand. They are not managers of the squads within the tribe. Squad product owners and tech leads still own their squad's execution. The tribe lead is more like a gardener: they create the conditions for squads to thrive by providing strategic context, removing systemic blockers, facilitating cross-squad conversations, and ensuring the tribe's collective output adds up to something coherent. A tribe lead who starts approving squad backlogs or attending squad standups is overstepping. A tribe lead who never convenes cross-squad discussions is understepping.
The tribe boundary itself is the most consequential design decision. You are drawing a circle around a set of squads and saying, "coordination inside this circle is easy, coordination across circles is harder by design." This means you want high cohesion inside the tribe (squads that genuinely need to coordinate frequently) and loose coupling between tribes (tribes that can operate largely independently). If you draw the boundary wrong, you end up with constant cross-tribe escalations, which is worse than having no tribes at all because you have added a layer of overhead without reducing coordination cost.
Step-by-Step
Step 1: Map your current squads and their dependencies
Before grouping anything, you need a clear picture of what exists. List every squad, its mission, its primary product area, and its key dependencies on other squads. Dependencies include shared codebases, shared data pipelines, shared customers or user journeys, and squads whose work frequently blocks or is blocked by another squad. The best source for this data is not an org chart.
It is the squads themselves. ). Plot this as a simple dependency graph where squads are nodes and coordination needs are edges. This graph is the raw material for tribe design.
Tip: If you have more than 15-20 squads, do this exercise in a shared spreadsheet or a lightweight tool like Miro rather than in a meeting. Asking squad leads to fill it in asynchronously yields more honest answers because people are not anchoring on each other's responses.
Step 2: Identify natural clusters of high-dependency squads
Look at the dependency graph from Step 1 and identify clusters, groups of squads with many connections to each other and few connections to squads outside the cluster. These clusters are your candidate tribes. Common clustering patterns include: product area clusters (all squads working on search and discovery), customer journey clusters (all squads touching the onboarding experience), platform clusters (all squads maintaining shared infrastructure), and business unit clusters (all squads serving enterprise customers). You are looking for the grouping that minimizes cross-group dependencies.
There is no perfect answer. Every grouping creates some cross-tribe seams. Your goal is to make the seams as narrow as possible and to place them where coordination is infrequent and well-defined.
Tip: If two clustering options seem equally valid, choose the one that aligns with your product architecture rather than your business org chart. Product architecture changes less frequently, so tribes aligned to it are more stable over time.
Step 3: Apply the size constraint and split or merge as needed
Take each candidate tribe from Step 2 and count the total headcount (not just engineers, but all members of all squads, including designers, PMs, data analysts, and anyone else embedded in those squads). If a tribe exceeds roughly 100 people, look for a natural seam to split it into two tribes. The seam should be a point where dependencies across the split are minimal and well-defined. If a candidate tribe has fewer than about 30-40 people (roughly three to four squads), consider whether it should be merged with an adjacent tribe or whether it genuinely represents a distinct strategic area that will grow.
Very small tribes risk becoming isolated and under-resourced. Very large tribes lose the informal communication benefits that make tribes valuable. Document the final grouping with a simple table: tribe name, member squads, total headcount, and the one-sentence mission for the tribe.
Tip: The 100-person limit is a guideline, not a law. Some organizations find their threshold is closer to 80 or 120 depending on geographic distribution, communication culture, and how much shared context squads actually need. If your tribe feels unwieldy at 70 people, it is too big for your context.
Step 4: Define each tribe's mission boundary
Each tribe needs a mission statement that makes its boundary explicit. A good tribe mission answers three questions: What outcome does this tribe own? What is inside this tribe's scope? What is explicitly outside this tribe's scope?
The "outside" part is just as important as the "inside" part because it prevents scope creep and territory disputes. Write the mission in terms of customer outcomes or business capabilities, not in terms of technology. " The technology framing is too narrow and will break as architecture evolves. Test the mission by asking: if a new product initiative came up related to payments, would it be obvious that this tribe should own it?
If the answer is ambiguous for too many realistic scenarios, the mission boundary needs sharpening.
Tip: Run a quick stress test by listing three or four recent product initiatives and asking, 'Which tribe would own this?' If people disagree or the answer requires a meeting to resolve, your boundaries have gaps or overlaps that need addressing now, not later.
Step 5: Appoint tribe leads and define their operating model
Select a tribe lead for each tribe. The ideal tribe lead has strong product and strategic thinking skills, the respect of the squads, and the interpersonal skills to influence without authority. They should be someone who can translate company strategy into tribe-level priorities and who can facilitate hard conversations about trade-offs between squads. Critically, write down what the tribe lead does and does not do.
The tribe lead facilitates cross-squad alignment, owns the tribe's strategic roadmap, removes systemic blockers, and represents the tribe in company-level planning. The tribe lead does not manage squad backlogs, attend squad standups, approve squad-level decisions, or serve as a single point of escalation for every problem. Document this operating model and share it with all squad leads and the tribe lead's manager so expectations are explicit.
Tip: The most common failure with tribe leads is appointing a senior manager who treats the role as a traditional management position. Look for someone who is comfortable with influence-based leadership and who will resist the urge to micromanage squads.
Step 6: Establish tribe coordination rituals
Define the recurring rituals that will keep the tribe aligned. At minimum, most tribes need three: a tribe gathering (all-hands for the tribe, typically monthly or every six weeks, used to share progress, surface dependencies, and celebrate wins), a tribe lead sync (the tribe lead meets weekly or biweekly with all squad product owners to review priorities and surface blockers), and a dependency review (a lightweight session, often biweekly, where squads flag upcoming work that might affect other squads). Keep these rituals short and purposeful. A tribe gathering that becomes a two-hour status report will be avoided.
A 45-minute session with two squad demos and 15 minutes of open discussion will be attended. Document each ritual's cadence, format, participants, and the specific decisions or outputs it should produce. This documentation prevents rituals from drifting into unfocused meetings over time.
Tip: Start with fewer rituals than you think you need. You can always add a ceremony when a real coordination problem surfaces. Removing a ritual that people find useless is much harder politically than never starting it.
Step 7: Define cross-tribe interfaces
Even well-drawn tribe boundaries will have seams where tribes need to coordinate. Identify these seams explicitly and define how coordination works across them. ), who the point of contact is on each side, and how changes to the interface are communicated. The goal is to make cross-tribe coordination as narrow and well-defined as possible, so that it does not require tribe leads to broker every interaction.
Squads on either side of a seam should be able to coordinate directly using the agreed-upon interface, escalating to tribe leads only when the interface itself needs to change.
Tip: Cross-tribe interfaces work best when they mirror your technical architecture. If two tribes share a database, you have a tight coupling that will generate constant coordination overhead. Invest in decoupling the architecture, and the organizational coordination problem gets easier.
Step 8: Communicate the tribe structure and rationale
Roll out the tribe structure to the entire organization with clear communication about the rationale behind each decision. People need to understand not just which tribe they belong to, but why the boundaries were drawn this way, what problem the tribe structure is solving, and what will change about their day-to-day work. The communication should cover: the mapping of squads to tribes, the tribe missions, the tribe leads and their role, the new rituals and their cadences, and what is explicitly not changing (squad autonomy, chapter structures, guild participation). Hold a Q&A session, ideally one per tribe, where people can ask questions and surface concerns.
Early concerns are gold. They reveal boundary ambiguities or role confusions that are much cheaper to fix now than after three months of friction.
Tip: Create a simple one-page visual that shows all tribes, their squads, and the key cross-tribe interfaces. This artifact becomes the most referenced document in the organization. Update it whenever squads move between tribes or new squads form.
Step 9: Review and iterate the tribe structure quarterly
Tribe structures are not permanent. Product strategy shifts, squads are created or disbanded, and the dependency landscape evolves. Set a quarterly review cadence where tribe leads and senior leadership assess whether the current structure is still serving the organization. In the review, examine: Are cross-tribe dependencies increasing?
) Is any tribe consistently exceeding the size constraint? ) Are squads frequently requesting to move between tribes? ) Are tribe rituals well-attended and productive? ) Make small, incremental adjustments rather than wholesale reorganizations.
Moving one squad between tribes is manageable. Redrawing every boundary simultaneously is disruptive and destroys the institutional knowledge that tribes build over time.
Tip: Track a simple metric: the number of cross-tribe escalations per month. A rising trend is the earliest warning sign that your tribe boundaries are no longer aligned with your actual work.
Examples
Example: B2B SaaS company with 12 squads and 95 engineers
A project management SaaS company has 12 squads covering features like task management, time tracking, resource planning, reporting, integrations, billing, and internal platform. The company has 95 engineers plus 25 product and design staff across all squads. Coordination problems are surfacing weekly, especially between squads working on reporting and the squads whose features generate the data being reported on.
The team maps dependencies and finds three natural clusters. Cluster one: task management, resource planning, and time tracking squads, which share a core data model and frequently need to coordinate on schema changes. Cluster two: reporting, dashboards, and analytics squads, which consume data from cluster one but coordinate heavily with each other on shared visualization components. Cluster three: integrations, billing, platform, and authentication squads, which share infrastructure concerns and rarely interact with the product-facing clusters.
They form three tribes: 'Work Management' (4 squads, ~45 people), 'Insights' (3 squads, ~35 people), and 'Platform & Growth' (5 squads, ~40 people). Each tribe gets a tribe lead appointed from the most senior product-oriented leader in each cluster. The critical cross-tribe interface, data flowing from Work Management squads to Insights squads, is documented with a clear data contract and a named point of contact on each side. Tribe gatherings are set to monthly, tribe lead syncs to biweekly.
After two months, the weekly cross-squad escalations drop from roughly 8 per week to 2, because most coordination now happens within-tribe through informal channels and tribe rituals.
Example: E-commerce company splitting an oversized tribe
An e-commerce company's 'Buyer Experience' tribe has grown to 140 people across 14 squads as the company expanded its product line. Tribe gatherings have become 90-minute status readouts. The tribe lead cannot track dependencies across all 14 squads and has started missing conflicts that surface during sprint reviews. Cross-squad frustration is rising.
The tribe lead and VP of Engineering run the dependency mapping exercise and find a natural seam: squads working on search, browsing, and product discovery have tight internal dependencies but limited interaction with squads working on cart, checkout, and post-purchase experience. They split into two tribes: 'Discovery' (7 squads, ~70 people) covering search, browse, recommendations, and product pages, and 'Purchase' (7 squads, ~70 people) covering cart, checkout, payment, shipping, and returns. The primary cross-tribe interface is the 'add to cart' action, which sits at the boundary between discovering a product and purchasing it. They define a clear API contract and designate one squad in each tribe as the owner of their side of the interface.
Two new tribe leads are appointed, one promoted from within each cluster. The original tribe lead takes the Purchase tribe and mentors the new Discovery tribe lead for the first quarter. Within six weeks, tribe gathering attendance improves from 40% to 85% because the sessions are smaller, more relevant, and more interactive.
Example: Startup forming its first tribes at 8 squads
A 60-person fintech startup has been running with 8 autonomous squads and no formal grouping structure. As the company grows, the CEO notices that the lending squads and the savings squads are making conflicting decisions about the shared customer identity system. The two groups also interpret the company's risk appetite differently, leading to inconsistent customer experiences.
The startup is small enough that a single tribe would technically work (60 people is well under 100), but the two product areas have genuinely different strategic priorities and customer segments. They form two tribes: 'Lending' (3 squads, ~25 people) and 'Savings & Investing' (3 squads, ~20 people). The remaining 2 squads, identity and platform, are kept in a lightweight 'Foundation' tribe (~15 people) with clear SLAs to the product tribes rather than a full tribe mission. Each product tribe gets a tribe lead who owns the strategic roadmap for their area.
The Foundation tribe lead focuses on internal service quality rather than external outcomes. The key cross-tribe interface, customer identity, is governed by a shared technical standard that all three tribes ratify, with changes requiring sign-off from at least two tribe leads. This is intentionally high-friction because identity changes affect every product. The startup also decides that tribe gatherings are overkill at this size and instead runs a single all-hands demo every two weeks, with tribe-level planning happening in lightweight biweekly syncs.
The approach scales naturally: as each product tribe grows, it can adopt fuller tribe rituals without changing the overall structure.
Example: Distributed company designing tribes across time zones
A 200-person developer tools company has squads distributed across San Francisco, Berlin, and Singapore. They are forming tribes for the first time and wrestling with whether to organize by product area (which would create tribes spanning three time zones) or by geography (which would keep tribes co-located but break product area cohesion).
They map dependencies and find that most squads interact primarily with other squads working on the same product area, regardless of location. A Berlin-based squad working on the CLI tool coordinates daily with a San Francisco-based squad working on the CLI's plugin system, but rarely with the Berlin-based squad working on the web dashboard. They decide to organize tribes by product area, accepting the time zone challenge, because the alternative (geographic tribes) would force constant cross-tribe coordination on every product decision. To mitigate the time zone friction, each tribe establishes a 4-hour overlap window (8 AM-12 PM Pacific / 5 PM-9 PM Berlin) for synchronous tribe rituals.
Tribe gatherings rotate between two time slots each month, so no single time zone always takes the inconvenient slot. Async communication becomes a first-class ritual: each squad posts a weekly written update in a shared tribe channel, and the tribe lead publishes a biweekly written summary of priorities and decisions. The tribe lead role is assigned to someone in the time zone with the most squads in that tribe, but with an explicit deputy in another time zone who can handle escalations during off-hours. After one quarter, they survey squad members and find that 78% prefer the product-aligned structure over the geographic alternative, despite the time zone cost.
Best Practices
Keep tribes between 40 and 100 people. Below 40, a tribe lacks the critical mass to pursue a meaningful strategic objective and the tribe lead role becomes part-time overhead. Above 100, informal communication breaks down, tribe gatherings become broadcast-only events, and the tribe lead cannot maintain relationships with all members. When you approach the upper limit, start identifying seams for a future split before you are forced into an emergency reorganization.
Name tribes after their mission, not their technology stack. A tribe called "Payments Experience" communicates scope and purpose clearly to everyone in the organization. A tribe called "Backend Services Team 2" communicates nothing. The name frames how the tribe thinks about its work and how others understand what the tribe owns. Poor naming creates ambiguity that compounds over months.
Define tribe lead authority explicitly in writing and share it with all squad leads. The most damaging failure mode in tribe design is ambiguity about the tribe lead's role. If squad leads think the tribe lead is their manager, they will defer decisions upward. If they think the tribe lead is irrelevant, they will ignore alignment signals.
Write down the specific decisions the tribe lead makes, the decisions they facilitate, and the decisions that remain with squads. Review this document with both the tribe lead and their squad leads in the same room.
Align tribe boundaries with your product architecture, not your business org chart. Business org charts reflect reporting relationships and budget ownership, which change with every reorg. Product architecture reflects how your systems actually interact, which changes more slowly and maps directly to the coordination needs that tribes are designed to manage. When tribe boundaries contradict the architecture, every sprint brings unexpected cross-tribe dependencies.
Invest in tribe-level onboarding for new squad members. When someone joins a squad, they also join a tribe. Make sure they understand the tribe's mission, the other squads in the tribe, the key cross-squad interfaces, and the tribe rituals they are expected to participate in. A 30-minute tribe onboarding session with the tribe lead prevents weeks of confusion and helps new members contribute to cross-squad coordination from day one.
Use tribe gatherings for alignment, not status reporting. If your tribe gathering consists of each squad lead reciting their sprint metrics while everyone else checks email, you are wasting everyone's time. Effective tribe gatherings feature squad demos of work-in-progress, open discussion of upcoming dependencies, celebration of cross-squad collaboration wins, and strategic context from the tribe lead. Keep it under 60 minutes and make attendance genuinely valuable.
Track and visualize cross-tribe dependencies separately from within-tribe dependencies. Cross-tribe coordination is inherently more expensive, so you want a clear signal when it is increasing. Maintain a simple log or board where squads flag work items that depend on a squad in another tribe. Review this log monthly.
A consistent upward trend means your tribe boundaries are drifting out of alignment with your actual work patterns.
Resist the urge to create a tribe for every organizational need. Platform teams, internal tooling teams, and shared service teams sometimes get organized as tribes, but they often lack the customer-facing mission that makes a tribe cohesive. Consider whether a guild or a dedicated service team with clear SLAs to consuming tribes is a better fit for these cross-cutting concerns.
Common Mistakes
Drawing tribe boundaries around existing reporting lines instead of around mission areas
Correction
This happens because reorganizing reporting relationships is politically hard, so leaders default to wrapping a tribe label around an existing department. The result is tribes that look like old departments with new names, where squads within the same tribe have unrelated missions and little need to coordinate, while squads that desperately need to coordinate are in different tribes. Watch for this signal: if your tribe's squads share a manager but rarely discuss each other's work, you have a department masquerading as a tribe. Redraw boundaries around the actual product areas where coordination is genuinely needed, even if it means changing reporting lines.
Letting tribes grow past 100 people without splitting
Correction
This creep usually happens gradually. A new squad is added here, a team is absorbed there, and suddenly the tribe is at 130 people. The tribe lead rationalizes that splitting would be disruptive, so they add more process to compensate. But the process (more meetings, more documentation, more formal requests) is itself the problem that smaller tribes were designed to avoid.
Set an alert at 80 people. When you hit it, start designing the split. Identify the natural seam, socialize it with squad leads, and execute the split before you hit the point where communication has already degraded. Splitting a healthy tribe proactively is far less painful than emergency-splitting a dysfunctional one.
Appointing a tribe lead who acts as a layer of management over squads
Correction
This is the single most common failure in tribe implementation. It typically happens when organizations appoint a senior engineering manager or director as tribe lead because they have positional authority. The tribe lead then starts attending squad ceremonies, reviewing squad-level decisions, and routing all cross-squad communication through themselves. Squads lose autonomy, decisions slow down, and the tribe lead becomes a bottleneck.
' If more than one squad says overhead, coach the tribe lead on facilitative leadership, or find someone better suited to the role.
Creating tribes with no regular coordination rituals, assuming alignment will happen organically
Correction
Some organizations create tribes on paper but never establish the rituals that make tribes functional. They expect that simply being in the same tribe will make squads coordinate. It will not. Without a regular tribe gathering, squads have no forum to surface dependencies.
Without a tribe lead sync, priorities drift apart. Without a dependency review, conflicts are discovered at integration time rather than planning time. Start with three rituals (monthly gathering, biweekly lead sync, biweekly dependency review) and adjust from there. Having too few rituals is more dangerous than having too many, because the failure mode is invisible until a major coordination breakdown occurs.
Treating tribe structure as permanent and avoiding reorganization
Correction
Organizations invest significant political and emotional capital in their initial tribe design and then treat it as sacred. But product strategy evolves, market conditions shift, and the dependency landscape changes. A tribe structure that was optimal six months ago may be generating unnecessary cross-tribe friction today. The signal to watch for is increasing cross-tribe escalations or squads that spend more time coordinating with squads in other tribes than within their own.
Review tribe boundaries quarterly, and normalize small adjustments (moving one squad between tribes, splitting a growing tribe) as routine organizational hygiene rather than dramatic reorgs.
Defining tribe missions that are too broad or overlapping
Correction
Vague tribe missions like 'own the customer experience' or 'drive growth' create territory disputes because multiple tribes can claim the same work. This leads to either duplicated effort or political standoffs where no tribe takes ownership. The fix is specificity. A mission should be concrete enough that a hypothetical new product initiative would clearly belong to one tribe or another at least 80% of the time.
Test your missions with real examples. List five recent product decisions and ask three different people which tribe should have owned each one. If they disagree on more than one, your mission boundaries need narrowing.
Other Skills in This Method
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.
Frequently Asked Questions
How many squads should a single tribe contain?
Most effective tribes contain between 4 and 12 squads, which typically translates to 40 to 100 people. Below 4 squads, the overhead of a dedicated tribe lead and tribe rituals is hard to justify. The squads would coordinate fine on their own. Above 12, the tribe lead cannot maintain meaningful relationships with all squad leads, and tribe gatherings become unwieldy. The exact number depends on how tightly coupled the squads' work is: highly coupled squads justify a smaller tribe because coordination intensity is high.
Should I organize tribes before or after forming squads?
Form squads first, then organize them into tribes. Squads are the atomic unit of the [Spotify Squad Model](/methods/spotify-squad-model), and their missions should be defined based on product needs, not predetermined tribal groupings. Once you have squads with clear missions, the dependency patterns between them reveal the natural tribe boundaries. If you design tribes first, you risk forcing squads into groupings that look clean on paper but do not match actual coordination needs. See [forming autonomous squads](/skills/forming-autonomous-squads) for the prerequisite skill.
What does a tribe lead actually do day-to-day?
A tribe lead spends roughly 30% of their time on strategic planning (translating company objectives into tribe-level priorities, maintaining the tribe roadmap), 30% on facilitation (running tribe rituals, mediating cross-squad trade-offs, removing systemic blockers), 20% on stakeholder management (representing the tribe in company planning, communicating tribe progress and needs upward), and 20% on coaching and culture (mentoring squad leads, reinforcing tribe values, onboarding new members). They do not write code, attend squad standups, or approve individual squad decisions. The role is closer to a chief of staff than a traditional manager.
How do chapters and guilds interact with tribes?
, all backend engineers in the Payments tribe). The chapter lead is the line manager for those individuals, handling career development and craft standards. , all frontend engineers across all tribes). Tribes handle strategic alignment, chapters handle people management and craft excellence within a tribe, and guilds handle knowledge sharing across tribes. See [running chapters](/skills/running-chapters-for-craft-excellence) and [building guilds](/skills/building-cross-cutting-guilds) for detailed guidance on each.
When should I split a tribe into two?
Split when you observe two or more of these signals: the tribe exceeds 100 people, tribe gatherings have become passive status updates with low engagement, the tribe lead cannot articulate how more than two or three squads' work connects, squads within the tribe have clearly divergent strategic priorities, or cross-squad coordination within the tribe has decreased because subgroups have naturally formed. The best time to split is proactively, when you see these signals emerging, not reactively after a coordination failure. Start planning the split at around 80 people so you have time to identify the right seam and prepare the organization.
How do I handle squads that could logically belong to two different tribes?
This is common, especially for squads that own shared capabilities like search, notifications, or identity. You have three options. First, assign the squad to the tribe where it has the most dependencies, and define clear interfaces with the other tribe. Second, split the squad's responsibilities into two squads, one per tribe, if the workload justifies it. Third, keep the squad in a 'platform' or 'foundation' tribe with explicit SLAs to the product tribes. The worst option is letting the squad float between tribes or report to two tribe leads, which creates confusion and accountability gaps. Pick one home and make the cross-tribe interface explicit.
Why does my tribe structure keep generating cross-tribe escalations?
Persistent cross-tribe escalations usually mean one of three things. First, your tribe boundaries cut through a high-dependency area, so squads that need to coordinate daily are in separate tribes. The fix is to redraw the boundary to bring those squads together. Second, your cross-tribe interfaces are poorly defined, so squads do not know how to coordinate directly and escalate to tribe leads by default. The fix is to document interfaces with clear owners and communication protocols. Third, your tribe leads are not empowered or not meeting regularly enough to resolve boundary issues between themselves. A weekly or biweekly tribe lead sync where leads proactively surface upcoming cross-tribe work can prevent most escalations from reaching senior leadership.