Culture, Psychological Safety and Retrospectives

Posters on a wall do not make a culture. What does: how the lead reacts when someone breaks production, whether a junior feels safe to say "I don't understand", whether a retro changes anything. This lesson is about those daily habits. It explains psychological safety in plain words, gives a retrospective you can run tomorrow, shows how a well-known company guide runs incident debriefs, and covers remote habits, recognition and the "brilliant jerk" problem.

It builds on 1:1s, feedback, delegation and conflict, Lesson 8 (trust), Incidents, team health and growing as a lead, Lesson 4 (blameless postmortems and delivery measures) and Scaling teams, ownership and on-call, Lesson 16. For writing things down, see Design docs, Lesson 5.

Everything here is common practice and opinion. Teams and countries differ. Use the ideas, not the exact words, and always use your own true examples.

Words used in this lesson

• Culture means the habits and unwritten rules of a team: what is praised, what is ignored, what is punished.
• Psychological safety (in simple words) means people believe they can ask a question, admit a mistake or disagree without being punished, mocked or ignored.
• Retrospective (retro) is a regular meeting where the team looks at how the last period went and chooses a few things to change.
• Debrief (or incident review) is a meeting to learn from an incident by reconstructing what happened.
• Facilitator is the person who runs a meeting's process without taking sides.
• Blameless means the review looks at how the system and process allowed the event, and assumes people did their best with what they knew.
• Action item is a concrete follow-up with an owner and a date.
• Brilliant jerk is a very skilled person who treats colleagues badly.
• Async (asynchronous) work means people do not need to be online at the same time: they use writing and replies over hours or days.

What culture is, in daily behaviour

Ask: what happens when…

People copy what they see rewarded. If the person who stays up all night to fix a crisis gets praise and the person who prevented the crisis gets none, you teach heroics (Lesson 16).

The reading list I used has a small culture section. Titles in it (all title only, so I do not describe their content): Lessons from 7 highly successful software engineering cultures, Engineering a culture of psychological safety, Culture Eats Strategy For Breakfast, Habits of High-Functioning Teams, Principles trump processes and Brilliant Jerks in Engineering. One more has a description: The maze is in the mouse "lays out how Google's culture impeded its results and execution". These are good next reads. Their titles show the topics that keep coming back: safety, habits, principles over rules, and the cost of talented jerks.

Psychological safety, and how a lead builds it

The list does not define it, so here is my plain version again: people can speak up without fear. It does not mean being nice all the time or having no standards. A team can have very high standards and high safety. Safety is what lets people say "I think this is wrong" or "I broke it" early, when it is cheap to fix.

Habits that build it (my own, from common practice):

1. Go first. Admit your own mistakes, doubts and "I don't know". When the lead says "I got that wrong", everyone else gets permission.
2. Thank the bad news. If someone reports a problem, even late, your first words are "thanks for telling me". You can ask harder questions afterwards.
3. Ask more than you tell. "What do you think?" and "What am I missing?" make space. Then actually change something when you hear a good point.
4. React to mistakes with curiosity. "How did this get through? What would have caught it?" is a very different sentence from "Who did this?".
5. Protect the quiet people. In meetings, ask for written input first, or go round the room. Do not let the fastest talker decide.
6. Keep promises, even small ones. Trust comes from small commitments kept (Lesson 8).
7. Say what is not negotiable (security, safety, respect for each other) so that freedom elsewhere is clear.

The trust section of the list quotes an idea (from a Simon Sinek talk, as the list describes it) that a medium-performing, high-trust person can be better for a team than a high-performing, low-trust one. That is an opinion from a talk, not a measured fact, but it fits the next section.

The brilliant jerk

A person with strong output who is rude, dismissive or undermining. Why leads avoid dealing with them: the output is real, and the damage is quiet. The damage: others stop asking questions, stop sharing ideas, leave, and the person's knowledge becomes a single point of failure. The reading list names the problem in an article title (Brilliant Jerks in Engineering, title only).

A practical approach (opinion):

1. Separate behaviour from skill. "Your reviews are accurate and also, last week, you called a teammate's work 'trash'. The second part has to stop."
2. Give specific, early, private feedback, with examples (Lesson 8).
3. State the expectation and the consequence clearly, and write it down.
4. Check in on the team, not only on the person. Ask others, in 1:1s, how things are going.
5. Follow through. If nothing changes after clear feedback and support, escalate with your manager and HR. Rules on performance and dismissal differ by country, so ask HR.
6. Do not excuse behaviour with output. A team will remember what you tolerated.

Motivation, briefly

The Motivation section of the list points to a summary of Daniel Pink's book Drive (described as a summary of the book) and to the Two-factor theory (a Wikipedia article, described as saying that workplace factors fall into two separate sets: one that causes satisfaction and one that causes dissatisfaction). Other titles are Bored People Quit and The Development Abstraction Layer (both title only). I did not read these, so I only use the part I know from the descriptions: removing annoyances (pay disputes, broken tools, unclear roles) does not by itself create motivation, and people need a reason to care. In daily terms, a lead can:

• Explain why the work matters (see Lesson 10: why before what).
• Give people choice in how they work and room to master something.
• Remove blockers quickly.
• Give specific thanks.

Remote and async habits

• Write it down. The list links an article about Amazon's "document culture", described as saying that written documents reduce bias and avoid audio and screen-sharing problems. A written update or a short design doc (Lesson 5) lets people in other time zones take part.
• Say your working hours and response times. "I answer messages twice a day" removes guessing.
• Default to public channels for work questions, so the answer helps the next person.
• Use video for the human things: 1:1s, hard feedback, welcome, celebration.
• Cancel meetings you can live without. The list has an article with exactly that title.
• Check on isolation. Remote people can disappear quietly. Ask about it in 1:1s.

Recognition

• Be specific and fast. "Your rollback plan in the migration doc saved us an hour this morning" beats "good job".
• Praise in public what you want repeated, and give hard feedback in private.
• Praise prevention and teaching, not only rescue (Lesson 16).
• Make credit visible: name the people in the update, not just "the team".
• Match it to the person. Some like public thanks, some prefer a note. Ask.

Retrospectives that change something

A retrospective is a short, regular meeting to improve how the team works. Many teams hold one at the end of a sprint or project, with the same simple shape.

A 45-minute retro you can run tomorrow

1. Set the tone (3 min). State the goal: "learn and choose one or two changes; not to blame". Remind people of the rule: we talk about the process, not about people.
2. Check last time's actions (5 min). Read the last retro's actions. Were they done? If not, why? This one habit decides whether retros are respected.
3. Collect (10 min). Silent writing first, so loud voices do not set the tone. Three columns: went well, hurt or slowed us, ideas. One idea per note.
4. Group and vote (10 min). Cluster similar notes, then each person gets three dots to vote for the most important.
5. Discuss the top two or three (12 min). Ask "how did this happen?" and "what could we try?" (the same questions the debrief guide recommends, below).
6. Choose actions (5 min). One to three actions, each with an owner and a date, and a way to see whether it worked. Write them where the team will see them.

# Retro <date>   Facilitator: <name>   Note-taker: <name>## Last time's actions- [x] Add runbook for the failing nightly job (Ana)- [ ] Reduce PR size (Sam) -> not done; PRs were still 600+ lines. Why? <note>## Went well- ...## Hurt / slowed us- ...## Top issues (votes)1. Flaky tests (7)2. Unclear ownership of the email worker (5)## Actions| Action | Owner | Date | How we will know ||---|---|---|---|| Quarantine and fix the 5 flakiest tests | Priya | Fri 24th | CI failure rate under x% |

Retro anti-patterns

• Same complaints every time, no change. If actions are never done, people stop caring. Fewer, smaller, finished actions beat a long list.
• Blame in disguise. "The backend team keeps…" turns a process review into an accusation. Rephrase as a pattern in the process.
• The lead talks most. Let others speak first.
• No follow-up. Always start the next retro with the last actions.
• Only complaints. Include what went well. It shows what to keep.
• Too long a gap. Retros after six months are archaeology. Hold them often enough that people remember what happened.
• Skipping when busy. The busy weeks are when the process most needs fixing.

Learning from incidents: Etsy's debrief guide

Etsy's Debriefing Facilitation Guide is a public guide on running an incident review. Its README says it is a practical companion to a 2012 post about learning from accidents and mistakes, built on the "New View" of human error from systems safety and human factors. I read two chapters directly. In short:

Structure and preparation

• The goal is learning, not preventing every future event. The guide says emailing a form is too static; real learning comes from gathering data, building a timeline and holding a group discussion led by a skilled, neutral facilitator.
• Before the meeting: the people closest to the event draft the timeline. The facilitator reviews it, marks decision points and gathers objective data (chat transcripts, dashboards, logs, timestamped actions). They talk to key people in advance, especially those who may fear blame, and remind them that hindsight makes decisions look worse than they seemed at the time.
• Who: a facilitator who was not directly involved, a co-facilitator who shadows and gives feedback, a dedicated note-taker, and everyone named in the timeline (each team mentioned should be represented).
• A 60-minute example: introduction (a learning mindset, a semi-structured group interview, blameless, about how things happened rather than why); timeline reconstruction, about 35 to 40 minutes, which is the main task; park ideas for fixes until the timeline is complete; confirm accuracy; brainstorm learning points freely without turning them into tickets yet; then a small group follows up about two working days later to decide which remedies are viable (the guide calls this "soak time").
• Remediation items are not required for a good debrief, and the guide warns about fixes that add complexity and so create new risks. The key output is the annotated timeline agreed by the room.

The art of asking questions

• Prefer "how" to "why". The guide says "why" invites people to build their own cause-and-effect story and tends to bring out only evidence that supports it, while "how" collects accounts and produces descriptions. Explanations tend to be reductive or defensive and can shut down learning.
• Watch for hindsight. Reconstruct what was happening around the incident, from inside the situation where people did not know the outcome. Ask what other options were considered and what pressures were present.
• Ask about cues and decisions. For "it seemed a little off", ask what specifically made it seem off and what was seen. For a decision, ask what led to it and what options were considered. For "I knew...", ask how they knew.
• Ask what normal work looks like, and what usually happens next.
• Ask "dumb questions" freely about jargon. It is low risk for the facilitator, lets experts show what they know and reveals different assumptions.
• Dig when someone says "obvious" and zoom out to hand-off points, where misunderstandings are most likely.
• The guide's line on calibration: there is no single right question; "Curiosity should be your geiger counter."

You can use the same approach for a retro about a missed deadline or a failed release, even when there was no outage.

Interview questions

Key takeaways

• Culture is what people do when nobody is watching. A lead shapes it with small daily behaviours: go first, thank bad news, react with curiosity, keep promises.
• Psychological safety means people can speak up without fear. It is compatible with high standards and makes problems visible early.
• Don't excuse a brilliant jerk because of their output. Give specific feedback, state consequences, check on the team and follow through.
• A retro is short and structured: check last time's actions, collect in silence, vote, choose one to three actions with owners and dates.
• For incident reviews, use a neutral facilitator, build a timeline, ask "how" not "why", park fixes until the timeline is complete, and leave a short soak time.
• Write things down, state working hours and cancel meetings you can live without, especially in remote teams.
• Recognition should be specific, fast, public for what you want repeated, and include prevention.
• This is common practice and opinion. Adapt it to your team.

What's next

You have finished the extra lessons of this series. The sources and what could and could not be read are listed in Sources and reading list, Lesson 11. Practise: run a 45-minute retro this week using the template. Start with last time's actions, and end with at most three actions that have an owner and a date.