Squad health check: the full Spotify model, and how to run it
The full model, the workshop instructions, and what to attach so the check changes something.
The model
Published by Henrik Kniberg and colleagues at Spotify in 2014, materials and all. A squad reads a strong and a weak example per dimension, votes a traffic light simultaneously (green works well, yellow real problems but manageable, red serious), then agrees a consensus color and a trend arrow: improving, stable, or declining.
Run once or twice a year, the model stalls: the sprint takes over, nobody remembers what was decided, and two data points cannot show a trend. The check sensed accurately; nothing was attached to the sensor.
How Aurora Coach addresses it
Aurora Coach attaches a continuous improvement loop to that sensor: seven stages across six domains (Foundation, Product, Engineering, Operations, Workflow, Alignment). The health check lives mostly in Foundation: psychological safety, learning, purpose, autonomy. Codebase health maps to Engineering, easy to release to Operations, speed and process to Workflow.
- Sense and Analyze The AI asks structured questions; every team member answers in their own words. Integrations such as Aurora Coach for GitHub add quantitative signal; the workshop’s consensus colors slot straight in. The AI synthesizes it into a SWOT and maturity assessment grounded in the team’s actual situation plus industry best practices and academic research.
- Recommend, Refine, Commit Concrete next steps with rationale, implementation steps, and success criteria. Team members vote; the team lead refines to fit the team’s reality; the AI never decides. The team commits to improvements it owns, tracked through periods.
- Execute and Re-evaluate The team does the work alongside delivery, in its own context. Next period’s analysis sees what changed: progress against previous commitments is visible, context compounds. The trend arrow the model always asked for, drawn from data.
The model stays: the workshop becomes a Sense input, and free-text check-ins carry the signal between workshops.
The eleven dimensions
Works well · Real problems, manageable · Serious. Descriptions our own; the original deck is in Spotify's post above.
Delivering value
Green example: Stakeholders consistently get outcomes they value from us, and we stand behind what we ship.
Red example: We ship things we do not believe in, and stakeholders are not getting value.
Easy to release
Green example: A release is a routine event: automated, low-risk, over in minutes.
Red example: Every release is a slow, nervous, largely manual undertaking.
Fun
Green example: Working on this team gives us energy, and we genuinely enjoy each other.
Red example: The joy has drained out of the work.
Health of codebase
Green example: The code is clean and well-tested; we change any part of it with confidence.
Red example: Technical debt dominates the codebase, and every change is slow and scary.
Learning
Green example: We keep growing here; there is always something new being picked up.
Red example: Learning has stalled because the work leaves no room for it.
Mission
Green example: Our purpose is clear to everyone, and it motivates us.
Red example: Nobody could say what we are really here to achieve, and the stated mission moves no one.
Pawns or players
Green example: We shape our own direction: what we build and how we build it is largely our call.
Red example: Decisions about our work are made elsewhere; we just execute other people’s choices.
Speed
Green example: Work flows: we finish things quickly and rarely sit waiting.
Red example: Progress keeps stalling on interruptions, blockers, and dependencies.
Suitable process
Green example: Our way of working matches how this team actually operates.
Red example: Our process gets in the way more than it helps.
Support
Green example: When we ask for help, it arrives quickly and it is good.
Red example: Requests for help go nowhere, so we stay stuck.
Teamwork
Green example: We operate as one unit, pulling in the same direction.
Red example: We work side by side rather than together, with little idea of what the others are doing.
How to run the workshop
- Book one hour per squad Whole squad present, run by a facilitator the results do not reflect on.
- Walk one dimension at a time Read the green and red examples aloud. They are deliberately extreme; real teams land in between.
- Vote simultaneously Everyone shows green, yellow, or red at once, so nobody anchors on the loudest voice.
- Discuss, then agree Agree a consensus color plus a trend arrow (improving, stable, or declining) and capture a one-line note.
- Timebox 3–5 minutes per dimension Eleven dimensions fit in an hour only if deep dives get parked as improvement candidates.
- Discussion over averaging Do not average into a score; the conversation is the data. The output belongs to the squad, not a management scorecard, or voting turns political.
What is the Spotify squad health check?
A 2014 team self-assessment model from Henrik Kniberg and colleagues at Spotify. A squad votes traffic lights (green, yellow, red) on eleven dimensions, agreeing a consensus color and trend arrow per dimension in discussion rather than by averaging.
How often should we run a squad health check?
Quarterly workshops are common; once or twice a year kills the model, because two data points show no trend. Set a baseline in a workshop, then let free-text check-ins carry the signal between workshops.
What is the difference between a squad health check and a retrospective?
A retrospective asks what happened last period. A health check scans fixed dimensions that rarely surface in a retro: codebase health, mission, autonomy. The check finds the conversation worth having; the improvement loop acts on it.
Run the workshop this week with what is on this page. The free trial keeps the trend line drawing between workshops; MapROI (free, no signup, about 5 minutes) adds a tailored ROI analysis.