Building Psychological Safety in Teams

Core Concepts

1. The asymmetry of safety: why it breaks faster than it builds

Psychological safety is not a property of individuals — it is a shared belief about whether speaking up is safe, and it forms through accumulated experience. What the research makes clear is that this belief is structurally fragile: it takes repeated positive signals to establish and only a single negative signal to disrupt.

Research on surgical teams found that one dismissive response from a leader to a safety concern can silence team members for months. The lesson translates directly to engineering. A senior engineer who responds to a production alert with visible irritation, or a manager who publicly minimizes a concern raised in a post-incident review, does not just affect the person who spoke up. The observation ripples through the team, recalibrating everyone's estimate of what is safe to say next time.

2. How hierarchy suppresses voice

Hierarchy creates interpersonal risk gradients. People with less organizational rank face steeper consequences for speaking up than those with more. Evidence from clinical settings — where hierarchies are steep and consequential — consistently shows that team members hesitate to voice concerns when they fear criticism or retaliation from those above them in the structure.

The mechanism operates through social capital: rank and seniority affect not just whether you can say something without consequence, but whether your contribution will be taken seriously. This applies with particular force in engineering contexts that combine steep reporting structures with strong individual expertise hierarchies (principal engineer, staff engineer, senior engineer), where different axes of status compound rather than cancel out.

A second mechanism involves emotional expression. Leaders who show frustration or negative emotion when team members raise concerns send an implicit signal that speaking up was a mistake — regardless of the explicit content of their words. Emotional responses carry more weight than policy statements. A team that has a "no blame culture" codified in documentation but routinely experiences leaders expressing irritation when things go wrong will calibrate to the emotional reality, not the written norm.

3. Identity threat and belonging uncertainty

Underrepresented groups in engineering face additional barriers to psychological safety that go beyond hierarchy and status. These barriers operate through two related mechanisms: identity threat and belonging uncertainty.

Belonging uncertainty is the concern about the quality of one's social connections in a team context: "Do I actually belong here?" Research shows that belonging uncertainty predicts disengagement and performance gaps, particularly for members of groups that carry negative stereotypes about competence. In engineering, this manifests when a developer doubts whether their ideas will be taken seriously, whether their failures will be interpreted through a lens of deficit rather than as normal learning, or whether their presence in the team is genuinely wanted.

Stereotype threat operates at a related but distinct level: the concern about confirming a negative stereotype about one's group. This threat reduces sense of belonging and interpersonal trust, and affects behavioral choices including social engagement with peers. The person experiencing it may appear withdrawn, overcautious, or disengaged — behaviors that are rational responses to a real perceived risk, but which team members without that experience may misread as a lack of interest or capability.

These effects are amplified by underrepresentation itself. Female engineers in male-dominated teams are more sensitive to signals of peer exclusion, and the team composition makes every ambiguous interaction more loaded with potential meaning. Microaggressions — subtle, often unintentional slights directed at members of marginalized groups — accumulate to reinforce identity threat and undermine belonging even when no single incident is severe enough to be named as a problem.

Diversity improves team performance only when psychological safety is high enough to enable members to integrate their different perspectives. In teams with low psychological safety, diversity shows neutral or slightly negative effects on performance.

The implication is significant for engineering organizations pursuing both diversity and performance: psychological safety unlocks the performance potential of diverse teams. Without it, adding diverse team members does not improve outcomes and may worsen team dynamics as diverse perspectives go unvoiced or meet resistance.

4. Remote and hybrid work adds friction without removing the fundamentals

Recent research confirms that psychological safety continues to function as a mechanism through which leadership behavior influences employee voice in remote and hybrid settings. The underlying dynamics do not change: people still calculate whether speaking up is safe, still respond to dismissive signals, still need to feel they belong. But remote and hybrid work introduces additional friction at almost every point.

Informal relationship-building — the corridor conversation, the spontaneous lunch, the shared observation of body language — happens less or not at all. Without these accumulated small signals, team members have less information on which to calibrate their estimates of safety. Leaders have fewer natural opportunities to model the behaviors that create safety. And positive social relationships and workplace friendships — which research shows directly contribute to psychological safety and creativity — are harder to form at a distance.

For distributed teams, the implication is that deliberate design replaces organic emergence. Practices that happen spontaneously in co-located environments need to be explicitly created and protected in distributed ones.

5. First impressions set durable patterns

Early impressions of team safety are difficult to reverse once established. The first few interactions in a team — or the first time a concerning situation arises — calibrate subsequent behavior in ways that persist even when conditions change. A new engineer's first experience raising a concern in a code review, the first post-incident review in a newly formed squad, the first time someone challenges an architectural decision in front of a senior leader: these moments carry disproportionate weight.

This puts particular pressure on intentional onboarding and on how teams handle high-stakes events early in their formation. An incident that is handled with blame and frustration in the team's first month creates a safety impression that becomes the reference point for everything that follows. Reversing it requires sustained, visible counter-evidence — which is much harder than getting the first impression right.

Key Principles

1. Your response to voice matters more than your policy about voice

The gap between formal psychological safety policies and the emotional dynamics that govern actual team communication is well-documented. Emotional displays of frustration undermine psychological safety even when safety protocols explicitly encourage reporting. Teams read leader behavior, not documentation.

The practical implication: work on how you receive bad news, not on how many channels exist to report it. A leader who responds to a production incident with visible frustration is communicating something louder than any blameless postmortem process can counteract.

2. Address voice suppression at the structural level, not just the individual level

Individual confidence, trust in leadership, and professional commitment do predict speaking up. But relying on individual courage to overcome systemic suppression puts the burden in the wrong place. Hierarchy, role identity conflicts, and identity threat are structural conditions. Addressing them requires changing structures: how decisions get made, who is expected to speak, how meetings are facilitated, how roles are defined.

This also means that interventions aimed at helping underrepresented individuals "speak up more" without addressing the structural conditions that suppress their voice treat the symptom while leaving the cause in place.

3. Identity safety requires active signals, not the absence of active harm

Identity safety cues — environmental and interpersonal signals that group membership is not a barrier to belonging or success — do not emerge automatically from the absence of discrimination. They require deliberate, affirmative action: actively welcoming different perspectives, calling out microaggressions when they occur, structuring participation so that dominant voices do not automatically crowd out others.

For engineering teams, this means practices like round-robin contributions in design reviews, explicit invitation of dissenting views, and naming the pattern when a quiet team member's observation gets talked over and then repeated by someone else a moment later.

4. Conflict on the work is healthy when safety is high enough to hold it

Psychological safety moderates whether task conflict helps or hurts team performance. When safety is low, disagreement about technical approaches threatens relationships. When safety is high, the same disagreement becomes the mechanism through which better decisions get made. Engineering teams that confuse the absence of disagreement with psychological safety may actually be observing a silence born of fear, not consensus born of trust.

The diagnostic implication: if your team rarely disagrees about technical decisions in group settings, that is a signal worth investigating, not celebrating.

5. Measurement should match the complexity of what you are measuring

Psychological safety is a team-level, interpersonal phenomenon. Survey instruments alone may not capture important interpersonal dynamics and behavioral patterns. A team whose survey scores look healthy but whose meeting behavior shows consistent voice suppression has a problem that the survey is not detecting.

Use surveys as a starting point, and complement them with behavioral observation: who speaks, who is interrupted, who receives credit, whose concerns get logged and acted on after post-incident reviews. Composite measurement approaches — combining observational and survey data — give a more complete picture of whether psychological safety is actually present in day-to-day team behavior.

Worked Example

The code review that changed the team's patterns

A senior engineer on a four-person team had been the technical lead for three years. The team used asynchronous code review as its primary quality gate. Two more junior engineers — one of whom had joined six months earlier — rarely commented on each other's code, and when they did, they framed observations as questions ("Is it possible this might...?") rather than statements.

The lead's review comments were detailed and technically thorough. They were also often phrased as corrections ("This is wrong," "This won't work"), delivered without contextual framing, and sometimes accompanied by follow-up Slack messages that pushed for changes before the author had responded to the original review thread.

The newer engineer had noticed a pattern in the codebase: a data access layer that the lead had designed was creating N+1 queries in several recent features. They had raised it once in a design discussion and received a brief response that the lead was "aware of it" and "there were reasons for the current design." The newer engineer dropped it.

Six months later, a production incident traced back to database saturation. The postmortem identified the N+1 query pattern as a contributing cause. The newer engineer had known about the pattern for six months and had not raised it after the first dismissal.

What the mechanisms tell us:

• The lead's review style created a hierarchy signal: corrections without context implied the lead held the correct view by default. This raised the interpersonal cost of dissent.
• The single dismissal of the data access concern was sufficient to silence future voice on that topic. One dismissive response can silence team members for months.
• The pattern of follow-up messages before the author had responded modeled impatience, signaling that the lead's judgment was the endpoint of the review, not one input into it.

What a recovery looks like:

The team introduced three changes after the incident. First, the lead revised their review style to include reasoning ("I'd suggest X because Y — what do you think?") and to wait a full working day before following up. Second, they established a norm in design discussions that every concern raised would receive a written response, even if the decision was to proceed unchanged, with the reasoning documented. Third, they introduced a ten-minute slot in their weekly team meeting for "things I noticed that I'm not sure I should raise" — framed explicitly as a space for concerns that felt too small or too uncertain for a formal channel.

Within two months, the code review thread volume had increased, and three separate concerns that had previously gone unvoiced were raised and resolved before reaching production.

Active Exercise

Diagnose the voice patterns in your team

This exercise is designed to surface behavioral signals of voice suppression that surveys may miss. It works best as a private self-audit before any group discussion, to avoid anchoring on the leader's perception first.

Step 1: Map the last five high-stakes conversations. Select five recent discussions where the stakes were meaningful: a design review, a post-incident discussion, a planning session, a technical decision with architectural implications. For each, write down: Who spoke? Who didn't? Were there moments of visible hesitation? Did any concern get raised and then not addressed?

Step 2: Identify recurring patterns. Look across the five conversations. Are there team members who are consistently absent from the discussion? Are there topics that reliably don't get raised until after a decision is made? Are there people whose concerns get acknowledged but rarely get logged as action items?

Step 3: Apply the hierarchy lens. For each of the five conversations, note who held the most organizational seniority present. Was seniority correlated with who spoke most? Was it correlated with whose view prevailed when there was disagreement?

Step 4: Apply the identity safety lens. Are there team members from underrepresented groups? Do their participation patterns differ from the rest of the team? Have there been moments — however small — that could have registered as exclusion or dismissal? What signals of identity safety has the team actively provided?

Step 5: Identify one structural change. Based on your audit, identify one structural change — not an individual intervention, not a conversation about norms, but a change to how work is organized — that would address the most significant pattern you found. Examples: switching from verbal design review to written asynchronous review to reduce voice hierarchy; assigning formal roles in post-incident discussions so that all perspectives are structurally included; rotating who leads technical decision discussions.

Facilitation Guide

Session: Identifying and redesigning voice-suppressing practices

Purpose: Surface team norms and structural practices that suppress voice, and co-design concrete changes.

Format: Team session, 75–90 minutes. Works in person or distributed. Requires a facilitator who is not the team's direct manager (or a skilled manager who can hold the power differential carefully).

Preparation:

• Distribute Edmondson's psychological safety scale survey anonymously 48 hours before the session. Share aggregated results, not individual scores, at the start of the session.
• Ask team members to privately note one time in the last three months when they held back a concern they now wish they had raised. This is not shared publicly in the session — it primes honest reflection.

Opening (10 minutes): Share the survey results without interpretation. Ask: "What surprises you? What doesn't?" Normalize that most engineering teams score lower than leaders expect.

Round 1 — Mapping suppressors (20 minutes): In pairs or trios (deliberately mixing seniority levels), discuss: "What makes it hard to raise concerns in our team?" Capture answers on a shared board. Facilitator clusters into themes without judgment. Common themes include: fear of looking incompetent, uncertainty about whose job it is, past experiences of dismissal, async communication reducing ability to gauge reaction before committing to a statement.

Round 2 — Structural inventory (20 minutes): As a full group, review the team's current practices: code review, incident review, design discussion, standups, planning. For each, discuss: "Does this practice make it easier or harder to raise concerns? Who has voice in this practice by default?"

Key facilitation move: When someone raises an interpersonal concern ("X never responds to comments"), redirect to the structural ("What would need to change about how we run reviews for responses to be expected?").

Round 3 — Designing one change (20 minutes): Select the single practice the group agrees is the highest-leverage target. Redesign it together. The output is a written description of the new practice with: what changes, what stays the same, who is responsible for running it, and how the team will know in 30 days whether it is working.

Close (10 minutes): Acknowledge that structural changes are necessary but not sufficient — leader behavior matters. Invite the manager (if present) to name one specific behavioral commitment: something they will do differently in response to what they heard in the session. This is not a performance of humility; it models that the session produced accountability at every level.

Facilitator notes:

• If the group moves quickly to blaming individuals, bring it back to structure: "What would need to be true about how we work together for that not to happen?"
• If the manager dominates the diagnosis phase, the data will reflect their perception more than the team's. Structure the session so team members speak before the manager on key questions.
• Remote sessions: use breakout rooms for Round 1, a shared whiteboard tool for clustering, and explicit turn-taking with a timer for Round 3. The shared online identity that comes from co-creating visible artifacts in a distributed session can substitute partially for the informal belonging cues of in-person work.