Balancing Squad Autonomy with Organizational Alignment

Keep autonomous squads pointed the same way: make priorities visible, write a few enabling constraints, and review alignment on a regular cadence.

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

Autonomy and alignment is the central tension of the Spotify model. Autonomous squads move fast because they decide for themselves. Without alignment, they move fast in different directions. This skill is about getting both: squads that choose how to work, pointed at priorities they understand and bounded by a few constraints they accept.

Henrik Kniberg drew this as a matrix with autonomy on one axis and alignment on the other, to explain how teams and management related at Spotify. The key reading is that the two are separate dimensions rather than opposite ends of one scale, so more alignment does not have to mean less autonomy (Org Topologies). Kniberg illustrates alignment with a shared goal, crossing a river, and the article's reading is that management's part is to convey the why while teams act within that purpose.

Spotify's own people have been direct about the risk of getting this wrong. Marcin Floryan, a chapter lead, said "Autonomy is futile without alignment" in a 2016 talk (InfoQ). Jeremiah Lee, writing in 2020 about his time at Spotify, reported that the original write-up covered autonomy while the planned parts on alignment and accountability were never completed, and that squads each having a unique way of working made collaboration between them harder (Lee).

The output of this skill is a working alignment system: a visible set of company and tribe priorities, a short list of enabling constraints, a way for each squad to connect its work to those priorities, and a cadence for checking that the system still works.

How It Works

Alignment has three parts: direction, constraints and feedback.

Direction is the set of priorities leaders make visible. Spotify changed how it did this more than once. Kniberg's 2016 talk on Spotify Rhythm describes trying OKRs and a model called Priorities & Achievements before arriving at company "bets" defined with the Data-Insight-Belief-Bet framework, stack-ranked, shown on a company board with Now, Next and Later columns, and linked to bet boards in each part of the company (Kniberg, Spotify Rhythm). The lesson is less about the specific format than about its properties: priorities are few, ranked, visible to everyone, and connected from the company level down to the squads.

Constraints are the few rules every squad follows. A study of scaled autonomy at Spotify found that it "does not mean anarchy, or unlimited permissiveness": squads are expected to take responsibility for their work, to coordinate and align with others, and to comply with a few enabling constraints (Smite et al.). The same study describes managerial authority being spread through workgroups with collective authority, and compromises to team autonomy made deliberately to keep alignment. Other Spotify speakers put it as autonomy always being within boundaries, made as explicit as possible and often set with the teams themselves (InfoQ).

Feedback tells you whether the system works. At the squad level, Spotify's squad health check asks squads to rate areas that include their mission and whether they feel like "pawns or players", along with speed, value and support (Spotify Engineering). At the tribe level, ING runs a quarterly business review in which each tribe records what it achieved, what it learned, what it aims for next quarter and which other tribes or squads it needs, and shares the result openly (McKinsey Quarterly). ING's CIO names squads going in different directions as a main risk if they are not aligned regularly.

The balance point differs by organization and changes over time. Early on, clear direction and a few constraints are usually enough. As more squads depend on each other, more collaboration rules are needed, which is the gap Lee's critique describes.

Step-by-Step Guide

Step 1: Write down company direction

State the company's few current priorities in plain language, ranked, with the reasoning behind each. Include what the company believes about its market and customers, not only goals, so squads can make their own judgement calls. Keep the list short enough that every squad can remember it. Publish it where everyone can see it.

Step 2: Translate direction into tribe priorities

Have each tribe write its own ranked priorities that connect to the company list. Show the link explicitly, so a squad can trace its work from its own mission to the company's priorities. Where a tribe priority does not connect to any company priority, question it. Keep tribe priorities visible to other tribes to expose overlaps.

Step 3: Let squads connect their missions and goals

Ask each squad to show how its current goals support tribe priorities, using whatever goal format it prefers. The squad decides how to contribute; leaders check that the connection is real. A simple test is whether any squad member can explain how their current work serves a company priority. If they cannot, the problem is usually direction that was never communicated clearly.

Step 4: Define a short list of enabling constraints

Write down the few rules every squad must follow, such as security and privacy standards, shared interfaces, and architecture principles. For each, explain the reason and who can change it. Invite squads to challenge constraints that block them without clear benefit. A long list signals distrust and reduces autonomy without improving alignment.

Step 5: Agree how squads collaborate

Define a small set of shared practices for work that crosses squads: how to request something from another squad, how to raise a dependency, and how joint projects are coordinated. Lee's critique is that leaving every squad to invent its own way of engaging made collaboration harder, and a former Spotify coach he quotes suggests a "minimum viable agility" that squads can opt out of (Lee). Keep squads free to run their internal process as they like.

Step 6: Map the dependencies that threaten alignment

Survey squads regularly about which other squads they depend on and how much each dependency slows them down. Blocking dependencies are where misalignment turns into delay. Use the results to reprioritize, move people or plan architectural work. Share the map so squads can see which neighbors to coordinate with.

Step 7: Set a review cadence at each level

Choose how often priorities are reviewed at company, tribe and squad levels, and keep the cadences related so changes flow down. A quarterly tribe review, like ING's quarterly business review, works for many organizations. Add squad health checks so squads can report when they feel like pawns rather than players. Treat what you learn as input to the next cycle.

Step 8: Adjust the balance

After each cycle, ask whether squads were blocked by too many constraints or pulled apart by too few. Remove constraints nobody needed, add collaboration rules where squads kept colliding, and sharpen direction where squads guessed differently. Expect the balance to shift as the organization grows.

Best Practices

• Make priorities few, ranked and public. A ranked list lets a squad decide between two good options without asking for permission.
• Explain the reasoning behind every constraint. Squads follow constraints they understand and challenge the ones that no longer make sense, which keeps the list short.
• Separate what from how. Leaders own the problem and its priority; squads own the solution, which is the top-right corner of Kniberg's matrix: high alignment and high autonomy.
• Agree a minimum of shared collaboration practice. Complete freedom in how squads engage each other makes every cross-squad project a negotiation.
• Use squad feedback as an alignment signal. Health check results on mission clarity and on being pawns or players show quickly when alignment has turned into control or has faded.
• Change the alignment process when it stops working. Spotify replaced its own more than once, according to Kniberg's Spotify Rhythm talk.

Common Mistakes

• Equating autonomy with no rules: Squads told they can do anything collide over shared systems and customers. Write down the few constraints that apply to everyone.
• Aligning through approval: Requiring sign-off for squad decisions removes autonomy without adding understanding. Make priorities clear enough that sign-off is unnecessary.
• Too many goals: A long list of equal priorities gives squads no way to choose. Rank them and keep the list short.
• Alignment by meeting: A growing set of coordination meetings is a sign that direction or boundaries are unclear. Fix the direction or the boundaries rather than adding meetings.
• Ignoring cross-squad collaboration: Aligning each squad to strategy while leaving them no shared way to work together produces squads that agree on goals and still block each other.

References

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

Related Skills

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

Sources

• Org Topologies: Aligned Autonomy at Scale
• InfoQ: Don't Copy the Spotify Model
• Jeremiah Lee: Spotify's Failed #SquadGoals
• Henrik Kniberg: Spotify Rhythm
• Smite et al.: Decentralized decision-making and scaled autonomy at Spotify
• Spotify Engineering: Squad Health Check model
• McKinsey Quarterly: ING's agile transformation

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