What Google's Project Aristotle Taught Us About Better Retros

Google's Project Aristotle looked at why some teams worked well together while others struggled. The public write-up is still worth reading because it moved the focus away from individual talent and towards team behaviour.

The best-known finding is psychological safety. People need to feel safe speaking up with ideas, questions, concerns, and mistakes.

But Project Aristotle named five team dynamics, and all five show up in a good retrospective:

• Psychological safety
• Dependability
• Structure and clarity
• Meaning
• Impact

A retro will not fix a team by itself. It can, however, give the team a regular place to practise those five behaviours.

1. Psychological safety: can we say the real thing?

A retrospective asks people to talk about what went wrong. That is a risky request if the team punishes bad news.

Start with the Prime Directive. Remind the room that the goal is learning, not blame. Then prove it through facilitation.

If someone raises an uncomfortable point, do not rush past it. Thank them, ask what happened, and move the conversation towards the process rather than the person.

Useful prompts:

• What made this hard to spot earlier?
• What did we assume that turned out to be wrong?
• What support would have changed the outcome?
• What can we try next sprint?

That kind of response teaches the team that plain speech is welcome.

2. Dependability: do we keep our promises?

Dependability is built through small commitments kept over time.

Retro action items are a clean way to practise it. The team agrees on a change, one person owns it, and the next retro checks what happened.

This only works if the action is specific. "Improve QA" is too loose. "Add test data setup steps to the QA handover checklist by Thursday" is better.

Reviewing the action matters as much as creating it. If the team completes it, say so. If it stalls, ask why. A missed action is not a moral failure. It is data about scope, priority, workload, or ownership.

3. Structure and clarity: does everyone know how this works?

A retro does not need to be elaborate. It does need to be clear.

People should know:

• Why the meeting exists
• What format you are using
• How decisions will be made
• What happens to action items after the meeting

A simple agenda helps:

1. Review last sprint's actions.
2. Write feedback silently.
3. Group similar notes.
4. Discuss the highest-value themes.
5. Create one or two actions with owners and dates.
6. Share the summary.

With a predictable structure, the team can focus on the sprint rather than the ceremony.

4. Meaning: why did the work matter?

Retros often spend too long on problems and too little on work worth repeating.

The positive side is not fluff. It reminds the team what good looks like. It gives people a chance to notice craft, care, and teamwork that can vanish under delivery pressure.

Ask for concrete wins:

• What helped a customer?
• What made the codebase easier to work with?
• Who made the sprint easier for someone else?
• What decision are we glad we made?

Meaning is easier to feel when the team connects daily work to people, quality, and progress.

5. Impact: can we see that change happened?

A retro loses energy when the team cannot see any effect from previous discussions.

Close the loop visibly. If an action changes something, show it:

• The deployment checklist reduced confusion on release day.
• The new pull request rule stopped reviews piling up on Friday.
• The planning change caught a risky dependency earlier.

You do not need grand metrics for every action. A short note is often enough: we tried this, it helped, we will keep it.

SprintPulse supports this loop with action item history, analytics and trends, AI summaries, and Slack summary sharing. That makes it easier to show how retro themes move from feedback to follow-up.

Put the five dynamics into your next retro

Here is a practical way to apply Project Aristotle without turning the retro into a lecture.

The lesson for retros is simple: the meeting is only valuable if it changes how the team behaves.

Run the retro in a way that helps people speak plainly, keep promises, understand the process, notice meaningful work, and see progress. That is how a routine meeting becomes a useful team habit.