Team Health Checks: Beyond the Retro

Retrospectives answer the question "what happened in the last two weeks?" Health checks answer a different question: "what is it like to work here, and which way is that trending?" Teams that only run retros have sharp vision up close and nothing at distance — they'll catch a flaky test pipeline within a sprint, but they'll miss slow-moving problems like eroding code quality, growing dependency on one person, or a team that has quietly stopped believing in the roadmap. Those problems don't spike in any given sprint. They drift, a few percent a quarter, until one day they're the reason your best engineer resigns.

A team health check is a structured, recurring self-assessment: the team rates itself on a fixed set of dimensions — usually with a simple green/yellow/red scale — discusses the ratings, and tracks how they move over quarters. It takes about an hour four times a year. Done well, it's the cheapest early-warning system a team can install. This guide covers the model made famous by Spotify's engineering culture, how to adapt it without cargo-culting it, exactly how to run a session, and the part most teams botch: what happens after the colored dots are on the board.

The Spotify model, and what to actually take from it

The best-known health check framework is the "Squad Health Check" that Spotify's coaches published in the mid-2010s. The mechanics are simple: the team is presented with a set of dimensions — things like teamwork, mission, code quality, speed, learning, support, fun — and for each one, a pair of contrasting statements:

Easy to release: "Releasing is simple, safe, painless and mostly automated." versus: "Releasing is risky, painful, lots of manual work, and takes forever."

Each person votes green (closer to the good statement), yellow (somewhere in between), or red (closer to the bad statement), and separately votes on the trend: improving, stable, or getting worse. The votes go on a grid — dimensions as rows, one column for the color spread, one for the trend — and the team discusses the gaps.

Three design choices in this model carry most of its value, and they're the parts to keep even if you change everything else:

Contrasting statements instead of abstract scores. "Rate code quality 1–10" produces noise, because everyone's 6 means something different. A concrete pair of statements — "we're proud of our code" versus "our code is a pile of hacks and workarounds" — anchors every voter to the same scale. Writing good statement pairs is most of the work of adapting the model.

Trend as a separate vote. A yellow that's improving and a yellow that's degrading are opposite situations wearing the same color. The trend vote is frequently more informative than the level vote: a team can be honestly red on "speed" during a migration and calm about it, because everyone can see it's temporary and improving. Conversely, a green with a worsening trend is a warning nobody would have voiced without being asked.

Self-assessment, not measurement from above. The output is the team's own perception, gathered for the team's own use. The moment health checks become a management scorecard, the data corrupts — more on that failure mode below, because it's the most common way the whole practice dies.

What not to copy blindly: Spotify's specific dimensions were designed for their squads at a particular time. A support team, a marketing team, or a five-person startup will need different rows. The model is the mechanism; the dimensions are content, and content should be yours.

Choosing your dimensions

Aim for eight to eleven dimensions. Fewer than eight misses whole territories; more than twelve makes the session drag and the data mushy. A solid starter set that works for most product and engineering teams:

Dimension	Green statement	Red statement
Mission	"I know why our work matters and it energizes me."	"I have no idea why we're doing this."
Value delivered	"We ship things our users demonstrably care about."	"We ship, but I doubt anyone notices."
Speed	"We get things done quickly; little waiting."	"Everything takes forever; we're always stuck."
Process	"Our way of working helps us."	"Our process is bureaucratic theater."
Quality	"I'm proud of what we build; debt is under control."	"We're drowning in hacks and known breakage."
Releasing	"Shipping is routine and boring."	"Shipping is a risky event we dread."
Learning	"I'm learning things here that make me better."	"I've learned nothing in months."
Support	"We get help when we ask — from inside and outside the team."	"We're on our own; asking for help goes nowhere."
Teamwork	"We're a team; we win and lose together."	"We're individuals who share a standup."
Sustainability	"This pace is one I could keep for years."	"We're sprinting every sprint; people are fraying."
Fun	"I enjoy working with these people."	"Work is joyless."

Adaptation guidelines: keep mission, sustainability, teamwork, and learning in nearly any version — they're the slow-drift dimensions retros never catch. Swap the delivery-mechanics rows for whatever your team's work actually is: a support team might use "queue health" and "escalation paths"; a design team might use "craft time" versus "production-line work." Rewrite every statement pair in your team's own vocabulary — the statements should sound like something a teammate would actually say at lunch. And once you've picked dimensions, freeze them. Trend data is the entire long-term payoff, and every dimension you rewrite resets its history to zero. Add or reword at most one row per year.

Running the session: a 60-minute script

Quarterly cadence, 60 minutes, whole team, one facilitator. It works in a room with a printed grid and sticky dots, and it works remotely on a shared board — Openbook teams typically run it in a Retrospective room, which has health-check cards and voting built in, with the grid on a whiteboard frame next to it. The script:

Before the session (async, 10 minutes per person): Send the dimensions and statement pairs two days ahead, and collect votes privately — a form, a poll, or the retro tool's private-vote mode. Private pre-voting matters more than any other facilitation choice. Voting live in front of the group produces anchoring (the first dot placed drags the rest) and diplomatic yellows (red feels like an accusation when the person who owns that area is watching). Anonymous pre-votes give you the honest distribution; the session is for discussing it, not producing it.

Minutes 0–5 — frame it. The facilitator restates the contract: this is the team's data, for the team; nothing leaves the room except what the team agrees to share; the goal is two or three focus areas, not a fix for everything. If it's the first session, add: "Red is not failure. Red is information. A team with no reds either has no problems or no honesty, and I know which is more likely."

Minutes 5–20 — reveal the grid. Show all dimensions with the vote spread and trend arrows. Give people two quiet minutes to just read it. Then ask the two highest-value questions, in order:

1. "Where are we most split?" A dimension where half the team voted green and half voted red is the most interesting row on the board — it usually means two sub-groups are having different experiences (new hires versus veterans, one project versus another, on-call versus not). Splits beat averages: a 5-green/5-red row averaged to "yellow" would hide exactly the thing worth discussing.
2. "Which trends are pointing down?" — including down-trending greens.

Minutes 20–45 — discuss two or three rows. Not all eleven. The facilitator picks (split rows and worsening trends first) and timeboxes each to about eight minutes. The discussion pattern that works: ask a red or yellow voter to describe a specific recent moment that informed their vote — "give us an example from the last month" — rather than debating the abstraction. Concrete stories convert a colored dot into something the team can act on. Facilitation here is standard retro craft; if your facilitation muscles are rusty, our complete guide to retrospective formats covers the fundamentals.

Minutes 45–58 — pick focus areas and actions. Choose at most two dimensions to actively work on this quarter. For each, define one concrete action with an owner and a date, plus — this is the part that makes next quarter's session meaningful — a "what would make this yellow?" statement: the observable change that would move votes. Example: "Releasing is red. Action: Dana automates the changelog and staging smoke test by Dec 1. Yellow looks like: a release takes one person under an hour."

Minutes 58–60 — close the loop forward. Confirm what gets shared outside the team and who will bring the action-item status to the next health check.

Reading the results: patterns that matter

Single-session data is a snapshot; the value compounds when you can lay four quarters side by side. Keep the history in a place the team can see — a wiki page with the quarterly grids, or a dashboard with one tile per dimension. Patterns worth knowing:

The slow bleed. A dimension that goes green → yellow-improving → yellow-stable → yellow-worsening over four quarters. No single reading was alarming; the sequence is. This is precisely the pattern retros can't see and health checks exist to catch. Sustainability and learning are the classic slow-bleed rows.

The permanent yellow. A dimension that's been yellow-stable for a year. Either it genuinely doesn't matter to the team (fine — say so and stop agonizing), or it's a chronic condition everyone has learned to live with. Ask directly: "This has been yellow for four quarters. Do we care? If yes, why haven't we acted? If no, can we say that out loud?" Both answers are progress over silent drift.

The post-action bounce — or its absence. If last quarter's focus area doesn't improve after the team actually did the action, the diagnosis was wrong: you fixed a symptom. Releasing stayed red after the automation work? Then the pain wasn't the manual steps — maybe it's fear from an outage six months ago, or an approval chain outside the team. The miss is valuable; it redirects the next attempt.

All green, everywhere, always. On a team of eight-plus humans doing real work, a uniformly green board across multiple quarters is not health — it's a safety problem or a boredom problem. Either people don't believe honesty is safe, or the check has become a rote ritual nobody thinks about. Change something: rotate the facilitator, re-anchor the statements, or have a skip-level conversation about what's actually going on.

Mood data is the natural companion here: quarterly health checks give you depth on eleven dimensions, while a lightweight weekly mood pulse gives you frequency between sessions. The two catch different problems — Mood Tracking and Team Health: Signals Before Burnout covers the weekly layer and how the two feed each other.

Acting on results: the part that decides everything

Here is the uncomfortable truth about health checks: an unactioned health check is worse than none at all. Asking a team to honestly report problems, then visibly doing nothing, teaches a sharper lesson than never asking — it proves that speaking up is pointless here. Teams that run three consecutive check-ins with no follow-through will start voting all-green in the fourth, not because things improved but because they've stopped spending honesty on you. Survey researchers call the antidote "closing the loop," and it's just as essential here as in any pulse survey program.

The action discipline, concretely:

Two focus areas, maximum. A team that tries to move five dimensions moves none. Two real actions per quarter, resourced like real work — on the sprint board, not in the margins.

Sort problems by who can fix them. Health check findings come in three kinds, and mixing them up wastes the quarter: (1) team-fixable — process, quality, teamwork issues the team can act on directly; (2) manager-fixable — staffing, priorities, shielding from thrash; (3) organization-level — comp, strategy, cross-org dysfunction. The team acts on the first kind, the manager explicitly owns the second, and for the third, the honest move is transparency: "This one's above our pay grade. I'll raise it with my manager, and I'll report back what I hear — including if the answer is no." A truthful "no, and here's why" maintains trust; a vague "we'll look into it" spends it.

Open the next session with the receipts. Quarter N+1 begins: "Last time we picked releasing and learning. Here's what we did, here's what happened, here's what we said yellow would look like." Then vote. That two-minute ritual is what makes the whole system credible year over year.

A worked example: two quarters on one team

To make the mechanics concrete, here's a condensed history from a ten-person platform team, first two quarters of running checks.

Quarter 1 grid (abridged):

Dimension	Votes	Trend
Releasing	2 green / 3 yellow / 5 red	Worsening
Learning	3 green / 6 yellow / 1 red	Stable
Teamwork	5 green / 5 red	—
Sustainability	4 green / 6 yellow	Worsening

The facilitator went straight to the teamwork split — five green, five red, no yellows. The stories revealed the cause in ten minutes: the team was effectively two sub-teams after absorbing another squad's service, and the inherited half felt like permanent guests — they'd voted red; the original members, green. Nobody had said this in six months of retros, because no retro prompt ever asked. Focus areas chosen: releasing (action: automate the smoke-test and changelog steps, owner Dana, by Dec 1; yellow looks like "one person, under an hour") and teamwork (action: merge the two on-call rotations and pair across the old boundary for a quarter, owner Marcus).

Quarter 2, same rows: Releasing moved to 1 red / 6 yellow / 3 green, trend improving — the action worked, and the team said so with the receipts on screen. Teamwork moved to 7 green / 3 yellow with no reds; two of the inherited engineers said the shared rotation did more than any team-building event had. Sustainability, unaddressed, slid to 2 green / 7 yellow / 1 red, still worsening — so it became a Q2 focus area with a manager-owned action, since the cause (a commitment made over the team's head) wasn't team-fixable.

Two quarters, two real fixes, one slow bleed caught before it became a resignation. That's the instrument working as designed — and note that none of the three findings would have surfaced in a sprint retro.

The aggregation trap

If you run health checks across many teams, the temptation is to roll the grids up into an org-level heat map for leadership. Handle this carefully, because aggregation is where health checks go to die.

The failure sequence is predictable: grids get rolled up → a director notices Team C has three reds → the director "checks in" with Team C's lead → the lead feels scored → next quarter, Team C's lead nudges the team toward optimism → the data goes green and dead. Nobody lied outright at any step, and the instrument is ruined.

Rules that keep aggregate views useful without poisoning the source:

• Teams own their data. What leaves the room is the team's decision; the default share-out is focus areas and actions, not the raw grid.
• If grids are shared upward, they're anonymized or aggregated across teams — "4 of 9 teams report red on releasing" is genuinely useful for platform investment decisions and threatens no one.
• Leadership responds to aggregates with resources, never with team-level interrogation. The correct response to "4 of 9 teams red on releasing" is funding deploy tooling, not asking which four.
• Never, under any circumstances, tie health check results to performance reviews — of teams or of their managers. The first time that link is made, every future grid is fiction.

Common failure modes, quickly

• Running it monthly. Dimensions don't move that fast; monthly checks produce noise, fatigue, and all-yellow boredom. Quarterly is the cadence. (Weekly belongs to lightweight mood pulses, which are a different instrument.)
• Skipping the trend vote. You lose the most predictive half of the data to save ninety seconds.
• The manager facilitates and talks first. Votes anchor to power. Rotate facilitation, keep pre-voting private, and have the manager speak last in discussions — or step out for specific rows if the team is young in its safety.
• Litigating the colors. "I don't think quality is really red" is a facilitation failure — votes are perceptions, and perceptions are the data. The question is never "is the red correct?" but "what experience produced it?"
• New-team overreach. A team that formed last month will produce a wall of yellow that mostly means "we don't know yet." Wait one full quarter before the first check.

Your next steps

1. This week: Draft your dimensions — start from the table above, swap two or three rows for your team's reality, and rewrite every statement pair in words your team actually uses. Timebox it to an hour; the set improves with use, not with polish.
2. Next week: Announce the first session with the framing that matters: team-owned data, private voting, two focus areas max, and receipts next quarter. Send the pre-vote two days ahead.
3. Run the 60-minute script. Splits and down-trends first. Leave with at most two focus areas, each with an owner, a date, and a "what would make this yellow?" line.
4. Put the grid somewhere permanent and calendar the next session for one quarter out — the second session, where trends first appear, is where the method starts paying.

If you want the tooling in one place: an Openbook Retrospective room handles the voting and discussion (health-check cards, private votes, action export), a Check-in room covers the weekly mood pulse between sessions, and a Dashboard tile can hold the quarterly trend line. Everything lives in the same space, which is what keeps a quarterly ritual from getting lost. See what the rooms do at /features — and put the first health check on the calendar before this quarter gets away from you.