Forming Autonomous Squads with Clear Missions

Squad formation for the Spotify model: write a squad mission statement, staff cross-functional squads, and launch autonomous squads that ship on their own.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

Forming autonomous squads is the first practical step in the Spotify model, because every other structure (tribes, chapters, guilds) is built around squads. Squad formation means deciding what each team owns, who is on it, who sets its priorities and where its autonomy ends. Get these right and a squad can take a user problem to a shipped change without filing work for other teams. Get them wrong and you have renamed your old teams.

The reference description is the 2012 paper by Henrik Kniberg and Anders Ivarsson, Scaling Agile @ Spotify. It describes a squad as similar to a Scrum team and designed to feel like a mini-startup. Squad members sit together and have all the skills and tools needed to design, develop, test and release to production. Each squad decides its own way of working and has a long-term mission, such as building the Android client or providing payment solutions. The squad has a product owner who prioritizes the work but is not involved in how the team does it, and it has no formally appointed squad leader.

Cross-functional squads are close to what Team Topologies calls a stream-aligned team: a team aligned to a flow of work from a segment of the business that owns that slice end to end (Team Topologies). Either name works. What matters in practice is the long-term mission, the full set of skills, and the absence of hand-offs.

This skill produces a squad charter for each new squad: a one-sentence squad mission statement, the people and skills on the team, the product owner, what the squad owns and what it depends on, the limits of its autonomy, and how it will know it is healthy. The charter is short. Its job is to make the decisions explicit so that the squad, its tribe and its stakeholders all read the same thing.

How It Works

A squad is a bet that a small, stable, cross-functional team with a clear purpose will outperform a set of functional teams passing work to each other. Four things make the bet pay off.

The first is the mission. A good squad mission names a part of the product or a user outcome the squad will own for a long time. In the 2012 paper, missions are things like the radio experience or scaling the backend systems, and squads stick with them long enough to become experts (Kniberg and Ivarsson). A mission drawn around a technical layer, such as "the API team", fails this test because almost every user-facing change needs other teams too.

The second is architecture. Conway's law says a system's design tends to copy the communication structure of the organization that builds it, and the reverse pressure also applies: a squad cannot be autonomous inside a system it cannot change or release on its own. Spotify's paper describes over 100 separately deployable systems and an operations team whose job is to help squads release code themselves (Kniberg and Ivarsson). Before forming a squad, check that its mission lines up with code and deployment boundaries it can actually own.

The third is staffing. The squad needs every skill its mission requires, from design to engineering to whatever testing and data work the mission involves. Published descriptions of squad size vary: Atlassian's summary says squads are typically 6-12 people (Atlassian), and ING's version of the model used about 350 nine-person squads (McKinsey Quarterly). Size follows the mission; a squad too small to cover its skills will depend on others, and one too large splits into sub-groups.

The fourth is written autonomy. Autonomy is never unlimited. A study of Spotify found squads are expected to coordinate and align with others and to comply with a few enabling constraints (Smite et al.). The squad charter says which decisions the squad makes alone, which it makes with others, and which are fixed.

Launch is where the charter becomes real. ING had each new squad start by writing down the purpose of its work and agreeing on how to measure its impact on clients (McKinsey Quarterly). The same step works anywhere: the squad rewrites the mission in its own words, agrees on its first measures, and picks its working process.

Step-by-Step Guide

Step 1: Map the product into ownable areas

List the parts of your product that a team could own for a long time: user-facing capabilities, platform services and business domains. For each area, note which code, data and deployment pipelines it touches. Mark areas that share so much with a neighbor that neither can change alone. Those either merge into one mission or need decoupling work before a squad can own them. The output is a candidate list of missions, each with the systems it needs.

Step 2: Write a squad mission statement for each candidate

Write one sentence per squad that names who it serves and what outcome it owns, and leave feature lists to the backlog. "Help new users get to their first saved playlist quickly" is a mission; "build onboarding screens" is a backlog item. Test each mission by asking whether the squad could set goals and ship changes without another squad's permission most of the time. Check that no two missions own the same outcome. A clear mission is also one of the indicators in Spotify's squad health check, so write it to be understood by the squad itself.

Step 3: List the skills each mission needs

For each mission, write down the disciplines needed to go from idea to production: product, design, the engineering specialties involved, testing, data and anything else. Mark which skills are needed full time and which only occasionally. Occasional needs can come from an enabling or platform team rather than a permanent squad member. Keep the list honest; missing a skill here creates a dependency later.

Step 4: Staff the squads

Assign people so that each squad covers its skill list, and prefer stable membership over perfect balance. Keep the squad small enough that everyone takes part in planning and knows what the others are doing. Where a skill is scarce, decide explicitly whether to share a person across squads or to narrow a mission; sharing is a dependency, so keep it rare. Let people state preferences, because squads made of volunteers start with more energy than squads made by assignment.

Step 5: Appoint a dedicated product owner

Give each squad one product owner who prioritizes its work and represents stakeholders. In the 2012 paper the product owner decides what to work on and leaves how to the team, and product owners across squads maintain a shared high-level roadmap. Avoid splitting one product owner across many squads, because the squad then waits for decisions. If you cannot staff a product owner for a squad, question whether it should be a separate squad yet.

Step 6: Define ownership boundaries and dependencies

Write down what the squad owns: systems, services, user flows and metrics. Then list the other squads it depends on and whether each dependency blocks it or only slows it down. The 2012 paper describes Spotify regularly asking squads exactly this and using the answers to drive reprioritization, reorganization or architectural change (Kniberg and Ivarsson). A squad with several blocking dependencies on day one is not yet autonomous, and the charter should say what will be done about it.

Step 7: Document autonomy guardrails

List the decisions the squad makes alone, such as its process, tools and sprint length. List the decisions it makes with others, such as changes to shared interfaces. List the constraints it must follow, such as security, privacy and architecture standards. Keep the fixed list short and explain each item, because unexplained constraints read as distrust. Review it after the first few months.

Step 8: Launch with a kickoff

Hold a kickoff where the squad rewrites its mission in its own words, agrees on how it will measure its impact, and chooses its way of working, whether Scrum, Kanban or something else. Introduce the squad to its stakeholders and to the squads it depends on. Schedule its first health check for about three months later. Publish the charter where the tribe can read it.

Best Practices

• Draw missions around user outcomes or business domains rather than technical layers. Layer-based squads need each other for almost every change, which is the dependency problem squads exist to remove.
• Keep squads stable. Expertise in a mission builds up over months, and the 2012 paper treats long-term missions as the reason squads become experts in their area.
• Check the architecture before announcing squads. If a squad cannot deploy its part independently, fix the pipeline or merge missions first, or the squad will be autonomous only on paper.
• Let the product owner own priorities and the team own the method. Mixing the two, with the product owner assigning tasks, turns the squad back into a delivery team for someone else's plan.
• Write the charter in plain language and keep it to a page. People read and use a short charter; a long one becomes a document nobody opens.
• Use a regular health check to see whether squads are working as intended. Spotify's version asks the squad itself to rate areas such as mission, speed and ease of release, and presents it as a support tool rather than a way to judge teams (Spotify Engineering).

Common Mistakes

• Renaming existing teams as squads: A functional team with a new label keeps its hand-offs. Rebuild teams around missions and required skills, even if that means moving people.
• Missions that are really projects: A mission that ends when a feature ships leaves the squad without purpose a few months later. Write missions around outcomes that last for years.
• Skipping the dependency map: Squads launched without one discover their blockers in their first sprint. Map dependencies before launch and decide which ones to remove.
• No product owner, or one shared too widely: Without someone who can decide priorities quickly, the squad stalls or makes its own guesses. Give each squad a product owner with time for it.
• Unlimited autonomy: Telling squads they can do anything creates conflicts over shared systems and standards. Write the few constraints down so autonomy has clear edges.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: The Spotify Model

Related Skills

• Organizing Squads into Tribes for Alignment
• Balancing Squad Autonomy with Organizational Alignment
• Running Chapters for Craft Excellence
• Building Guilds for Cross-Tribe Knowledge Sharing
• Adapting the Spotify Model to Your Organization
• Scaling Agile with Spotify Squads and Tribes
• Evaluating Spotify Model Tradeoffs and Failure Modes

Sources

• Henrik Kniberg and Anders Ivarsson: Scaling Agile @ Spotify (2012)
• Team Topologies: Key concepts
• Mel Conway: Conway's Law
• Atlassian: Discover the Spotify model
• McKinsey Quarterly: ING's agile transformation
• Smite et al.: Decentralized decision-making and scaled autonomy at Spotify
• Spotify Engineering: Squad Health Check model

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.