15 min read • Guide 90 of 877
Building Psychological Safety in Teams
Psychological safety enables team members to take interpersonal risks—asking questions, admitting mistakes, proposing ideas—without fear of punishment or humiliation. Teams with high psychological safety outperform peers in innovation, learning speed, and problem-solving. GitScrum's transparency features, structured feedback mechanisms, and async communication patterns help build safety by removing judgment triggers and creating equitable participation opportunities.
Understanding Psychological Safety
What It Is (And Isn't)
PSYCHOLOGICAL SAFETY DEFINED:
┌─────────────────────────────────────────────────────────────┐
│ CLARITY ON THE CONCEPT │
├─────────────────────────────────────────────────────────────┤
│ │
│ WHAT IT IS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ✅ Feeling safe to take interpersonal risks ││
│ │ ✅ Belief that team won't embarrass or punish you ││
│ │ ✅ Environment where mistakes are learning opportunities ││
│ │ ✅ Trust that ideas will be considered, not mocked ││
│ │ ✅ Confidence to disagree with senior people ││
│ │ ✅ Knowing help requests are welcomed ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ WHAT IT ISN'T: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ❌ Everyone agrees all the time ││
│ │ ❌ No accountability or standards ││
│ │ ❌ Being "nice" or avoiding hard conversations ││
│ │ ❌ Everyone gets what they want ││
│ │ ❌ No feedback or criticism ││
│ │ ❌ Job security (different concept) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ THE RELATIONSHIP: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ HIGH STANDARDS ││
│ │ ▲ ││
│ │ │ ││
│ │ ANXIETY │ │ LEARNING ││
│ │ ZONE │ │ ZONE ★ ││
│ │ │ │ (High safety + ││
│ │ (Pressure, │ │ High standards) ││
│ │ fear) │ │ ││
│ │ │ │ ││
│ │──────────────┼─────┼──────────────▶ HIGH SAFETY ││
│ │ │ │ ││
│ │ APATHY │ │ COMFORT ││
│ │ ZONE │ │ ZONE ││
│ │ │ │ ││
│ │ │ │ (Safe but ││
│ │ (Low both) │ │ no growth) ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Goal: Learning Zone = High Safety + High Standards │
│ │
└─────────────────────────────────────────────────────────────┘
Signs of Low Safety
RECOGNIZING THE SYMPTOMS:
┌─────────────────────────────────────────────────────────────┐
│ WARNING SIGNS │
├─────────────────────────────────────────────────────────────┤
│ │
│ IN MEETINGS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Same 2-3 people do all the talking ││
│ │ • Questions go unasked ("I'll figure it out later") ││
│ │ • No pushback on bad ideas from leadership ││
│ │ • "Any questions?" met with silence ││
│ │ • Junior people never speak ││
│ │ • Disagreements handled outside meetings ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ IN CODE REVIEW: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Comments avoid technical substance ││
│ │ • LGTM with no real review ││
│ │ • Defensive responses to feedback ││
│ │ • Feedback only from "safe" reviewers ││
│ │ • Reviewers soften valid criticism ││
│ │ • Senior code never gets critical review ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ IN RETROSPECTIVES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Surface-level issues only ("meetings ran long") ││
│ │ • No one mentions interpersonal problems ││
│ │ • Same issues every sprint, never resolved ││
│ │ • People blame external factors, never team ││
│ │ • Real feedback comes in 1:1s, not group ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ IN DAILY WORK: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Mistakes hidden until they become crises ││
│ │ • No one admits "I don't know" ││
│ │ • Questions routed through intermediaries ││
│ │ • Information hoarding as job protection ││
│ │ • Blame-finding after incidents ││
│ │ • People work around problems, don't report ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Building Safety Deliberately
Leader Behaviors
WHAT LEADERS MUST DO:
┌─────────────────────────────────────────────────────────────┐
│ MODELING PSYCHOLOGICAL SAFETY │
├─────────────────────────────────────────────────────────────┤
│ │
│ ADMIT YOUR OWN FALLIBILITY: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ❌ "I've been doing this 15 years, trust me" ││
│ │ ✅ "I might be wrong about this. Let's test it." ││
│ │ ││
│ │ ❌ [Never mention personal mistakes] ││
│ │ ✅ "I broke production once by doing exactly this" ││
│ │ ││
│ │ ❌ "I'll figure it out" ││
│ │ ✅ "I don't know. Who can help us understand?" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ASK GENUINE QUESTIONS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ❌ "Anyone have questions?" (rhetorical) ││
│ │ ✅ "Maya, what concerns do you have about this approach?"││
│ │ ││
│ │ ❌ "Let me explain why..." (defensive) ││
│ │ ✅ "What am I missing in my analysis?" ││
│ │ ││
│ │ ❌ Asking then ignoring answers ││
│ │ ✅ Visibly changing based on input ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ RESPOND TO BAD NEWS WELL: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ❌ "How did this happen?" (accusatory) ││
│ │ ✅ "Thanks for bringing this up. What do we know?" ││
│ │ ││
│ │ ❌ Visible frustration/anger ││
│ │ ✅ Genuine curiosity about the situation ││
│ │ ││
│ │ ❌ "Who's responsible for this?" ││
│ │ ✅ "What can we do to prevent this next time?" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ CREATE PERMISSION: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ❌ Hope people will speak up ││
│ │ ✅ "I specifically want to hear pushback on this" ││
│ │ ││
│ │ ❌ General invitation "any feedback?" ││
│ │ ✅ "Alex, you've seen this pattern before. What's wrong?"││
│ │ ││
│ │ ❌ Assume silence = agreement ││
│ │ ✅ "I'm getting consensus too easily. What aren't we ││
│ │ discussing?" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Structured Practices
Blameless Retrospectives
RETROSPECTIVE STRUCTURE:
┌─────────────────────────────────────────────────────────────┐
│ MAKING RETROS SAFE │
├─────────────────────────────────────────────────────────────┤
│ │
│ GROUND RULES (state at start of every retro): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ "We believe everyone did the best job they could ││
│ │ with the information and resources they had. ││
│ │ ││
│ │ We're here to improve systems, not assign blame. ││
│ │ ││
│ │ What's said here stays here." ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ANONYMOUS INPUT (before meeting): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Use GitScrum Discussions with anonymous option ││
│ │ ││
│ │ Questions: ││
│ │ 1. What helped you do your best work? ││
│ │ 2. What got in your way? ││
│ │ 3. What would make next sprint better? ││
│ │ ││
│ │ Facilitator reviews, groups themes ││
│ │ Names never attached to feedback in meeting ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DISCUSSION RULES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • No interrupting ││
│ │ • "I" statements, not "you" statements ││
│ │ • Focus on systems and processes, not individuals ││
│ │ • Every person speaks before anyone speaks twice ││
│ │ • Leader speaks last ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ LANGUAGE TRANSFORMS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ❌ "John didn't review the PR" ││
│ │ ✅ "PRs waited too long for review—what's in our way?" ││
│ │ ││
│ │ ❌ "The bug happened because Sarah didn't test" ││
│ │ ✅ "This bug wasn't caught—what tests would help?" ││
│ │ ││
│ │ ❌ "We need Bob to communicate better" ││
│ │ ✅ "Communication breakdown occurred—what tools/ ││
│ │ processes would help?" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Communication Patterns
Async Communication for Safety
WHY ASYNC INCREASES SAFETY:
┌─────────────────────────────────────────────────────────────┐
│ ASYNC ADVANTAGES │
├─────────────────────────────────────────────────────────────┤
│ │
│ REMOVES PERFORMANCE PRESSURE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ SYNC (Meeting): ││
│ │ "Quick, everyone's watching, say something smart NOW" ││
│ │ → Favors fast thinkers, extroverts, native speakers ││
│ │ ││
│ │ ASYNC (Discussion): ││
│ │ "I'll think about this, research it, write my thoughts" ││
│ │ → Equalizes all thinking styles and language abilities ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ REDUCES HIERARCHY EFFECTS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ SYNC (Meeting): ││
│ │ CTO shares opinion → Everyone nods → Discussion over ││
│ │ ││
│ │ ASYNC (Discussion): ││
│ │ Ideas posted simultaneously → Evaluated on merit ││
│ │ Junior dev's great idea gets same visibility ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ CREATES PAPER TRAIL: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ People are more thoughtful when writing ││
│ │ Less impulsive reactions ││
│ │ Can reference "here's what we agreed" later ││
│ │ Reduces "I never said that" disputes ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ IN GITSCRUM: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Use Discussions for: ││
│ │ • Technical proposals ││
│ │ • Process change suggestions ││
│ │ • Retrospective input ││
│ │ • Decision-making ││
│ │ ││
│ │ Everyone has time to think and contribute ││
│ │ Ideas stand on their own merit ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Safe Code Review
CODE REVIEW THAT BUILDS SAFETY:
┌─────────────────────────────────────────────────────────────┐
│ REVIEW PRACTICES │
├─────────────────────────────────────────────────────────────┤
│ │
│ LANGUAGE MATTERS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ATTACKING (Unsafe): ││
│ │ ❌ "Why did you do it this way?" ││
│ │ ❌ "This is wrong" ││
│ │ ❌ "You should know better" ││
│ │ ❌ "This is messy" ││
│ │ ││
│ │ CURIOUS (Safe): ││
│ │ ✅ "What led to this approach?" ││
│ │ ✅ "I'm wondering about X—can you explain?" ││
│ │ ✅ "Have you considered Y? Here's why..." ││
│ │ ✅ "This could be clearer—here's a suggestion" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ SEPARATE CATEGORIES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Label feedback clearly: ││
│ │ ││
│ │ 🚫 BLOCKING: "This will cause data loss, must change" ││
│ │ 💭 SUGGESTION: "Consider X, but your call" ││
│ │ ❓ QUESTION: "Why this approach? (Not critiquing)" ││
│ │ ✨ PRAISE: "This is elegant, nice pattern!" ││
│ │ 📚 LEARNING: "FYI, there's a library for this" ││
│ │ ││
│ │ Clear labels reduce anxiety about feedback ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ REVIEW THE CODE, NOT THE PERSON: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ❌ "You always forget error handling" ││
│ │ ✅ "This function needs error handling" ││
│ │ ││
│ │ ❌ "You need to learn about async" ││
│ │ ✅ "This could use async/await—want me to show pattern?" ││
│ │ ││
│ │ ❌ "Your naming is confusing" ││
│ │ ✅ "getUserData→fetchActiveUserProfile would be clearer" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ NORMALIZE ITERATION: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ "Multiple rounds of review are normal and expected" ││
│ │ "First drafts are supposed to have issues" ││
│ │ "PRs are conversations, not tests to pass" ││
│ │ ││
│ │ Track revisions without judgment ││
│ │ Celebrate good discussions, not "first-try approvals" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Responding to Failures
Blameless Post-Mortems
INCIDENT RESPONSE THAT BUILDS TRUST:
┌─────────────────────────────────────────────────────────────┐
│ BLAMELESS POST-MORTEM PROCESS │
├─────────────────────────────────────────────────────────────┤
│ │
│ THE PRINCIPLE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ "A person didn't cause the incident. ││
│ │ The system allowed the incident to happen." ││
│ │ ││
│ │ We fix systems, not people. ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ WHAT TO DOCUMENT (in NoteVault): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ## Incident: [YYYY-MM-DD] Service Outage ││
│ │ ││
│ │ ### Summary ││
│ │ What happened, impact, duration ││
│ │ ││
│ │ ### Timeline ││
│ │ Objective sequence of events (no "should have") ││
│ │ ││
│ │ ### Contributing Factors ││
│ │ NOT "Bob made a mistake" ││
│ │ BUT "Manual deployment process has no safeguards" ││
│ │ ││
│ │ ### What Went Well ││
│ │ Detection, response, communication ││
│ │ ││
│ │ ### Action Items ││
│ │ System improvements, not personnel actions ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ LANGUAGE IN POST-MORTEM: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ❌ "The engineer deployed bad code" ││
│ │ ✅ "The deployment occurred without staging validation" ││
│ │ ││
│ │ ❌ "Review was inadequate" ││
│ │ ✅ "The review process didn't catch this class of bug" ││
│ │ ││
│ │ ❌ "Should have known better" ││
│ │ ✅ "Training gap: This scenario wasn't covered" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ AFTER THE POST-MORTEM: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Create action items in GitScrum board ││
│ │ 2. Assign owners for system improvements ││
│ │ 3. Track completion in next sprints ││
│ │ 4. Share learnings broadly (without blame) ││
│ │ 5. Thank people who raised the issue ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Measuring Safety
Team Health Indicators
TRACKING PSYCHOLOGICAL SAFETY:
┌─────────────────────────────────────────────────────────────┐
│ MEASUREMENT APPROACHES │
├─────────────────────────────────────────────────────────────┤
│ │
│ SURVEY QUESTIONS (anonymous, quarterly): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. I feel safe to take risks on this team ││
│ │ [Strongly Disagree] 1 2 3 4 5 [Strongly Agree] ││
│ │ ││
│ │ 2. I can admit mistakes without negative consequences ││
│ │ [Strongly Disagree] 1 2 3 4 5 [Strongly Agree] ││
│ │ ││
│ │ 3. Team members can bring up problems and tough issues ││
│ │ [Strongly Disagree] 1 2 3 4 5 [Strongly Agree] ││
│ │ ││
│ │ 4. It's safe to ask for help on this team ││
│ │ [Strongly Disagree] 1 2 3 4 5 [Strongly Agree] ││
│ │ ││
│ │ 5. My unique skills are valued and utilized ││
│ │ [Strongly Disagree] 1 2 3 4 5 [Strongly Agree] ││
│ │ ││
│ │ Target: Team average of 4+ on each question ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ BEHAVIORAL SIGNALS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ POSITIVE SIGNS: ││
│ │ ✅ Mistakes reported early (before they escalate) ││
│ │ ✅ Questions asked in public channels (not just 1:1) ││
│ │ ✅ Junior people challenge senior people's ideas ││
│ │ ✅ "I don't know" said openly ││
│ │ ✅ Experimentation happens (new approaches tried) ││
│ │ ││
│ │ WARNING SIGNS: ││
│ │ ⚠️ Problems only surface in exit interviews ││
│ │ ⚠️ Same issues repeat sprint after sprint ││
│ │ ⚠️ Meetings dominated by same few people ││
│ │ ⚠️ Feedback only flows upward, never sideways ││
│ │ ⚠️ High performers protect information ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Daily Practices
Small Actions, Big Impact
DAILY SAFETY-BUILDING:
┌─────────────────────────────────────────────────────────────┐
│ PRACTICAL DAILY ACTIONS │
├─────────────────────────────────────────────────────────────┤
│ │
│ IN TEAM STANDUP: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Use GitScrum Team Standup for async updates ││
│ │ ││
│ │ Normalize blockers: ││
│ │ "What's blocking you?" → Regular question, not judgment ││
│ │ ││
│ │ Celebrate asks for help: ││
│ │ "Thanks for flagging that—who can help?" ││
│ │ ││
│ │ Rotate who goes first: ││
│ │ Don't always let senior speak first ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ IN DISCUSSIONS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Thank people for disagreeing: ││
│ │ "Good point, I hadn't considered that" ││
│ │ ││
│ │ Credit ideas publicly: ││
│ │ "As Maya suggested..." (visibility matters) ││
│ │ ││
│ │ Ask quiet people directly: ││
│ │ "Sam, you have experience here—what's your take?" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ IN CODE REVIEW: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Start with something positive: ││
│ │ "This tests coverage is great. One question about..." ││
│ │ ││
│ │ Offer pairing: ││
│ │ "This is tricky—want to work through it together?" ││
│ │ ││
│ │ Share your learning: ││
│ │ "I learned something new from this PR" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ IN GENERAL: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Say "I don't know" first: ││
│ │ Leaders modeling vulnerability ││
│ │ ││
│ │ Apologize quickly: ││
│ │ "I was wrong about that, sorry" ││
│ │ ││
│ │ Respond to mistakes with curiosity: ││
│ │ "Interesting—what can we learn from this?" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘