Team Health & Dynamics

Key Dimensions

Dimension	Healthy Team	Unhealthy Team
Trust	People share mistakes without fear	People hide problems and blame others
Conflict	Productive disagreement on ideas	Either fake harmony or personal attacks
Commitment	Clear decisions, team buys in even when they disagree	Ambiguous decisions, silent vetoes
Accountability	Peers hold each other to standards	Only the manager holds people accountable
Results	Team goals matter more than individual status	Individual ego trumps team outcome

Psychological Safety — The Foundation

What it is (and isn’t):

Amy Edmondson (Harvard) defined psychological safety as “a shared belief that the team is safe for interpersonal risk-taking.” It’s the #1 predictor of team performance in Google’s Project Aristotle research (2015), ahead of dependability, structure, meaning, and impact.

What psychological safety IS:

• People feel safe to ask questions, admit mistakes, propose half-formed ideas
• Disagreement is expected and welcomed
• Failure is treated as learning, not punishment
• People speak up when they see problems

What psychological safety IS NOT:

• Being nice all the time (that’s actually a sign of low safety — people are avoiding conflict)
• Absence of accountability (high safety + high standards = the sweet spot)
• Permission to be mediocre (“we’re safe, so it’s okay to not try hard”)
• Unconditional psychological comfort (challenge and discomfort are part of growth)

The Edmondson 2x2:

                High Standards
                     |
    Anxiety Zone     |    Learning Zone
    (high bar,       |    (high bar,
     unsafe to fail) |     safe to fail)
    -----------------+------------------
    Apathy Zone      |    Comfort Zone
    (low bar,        |    (low bar,
     unsafe to fail) |     safe to fail)
                     |
                Low Standards

You want the Learning Zone: high psychological safety AND high accountability. Most dysfunction happens because teams are either in the Anxiety Zone (high bar, fear of failure — common in high-pressure orgs) or the Comfort Zone (safe but no push — common in “nice” cultures).

How to build psychological safety:

As a manager, you model it first:

1. Admit your own mistakes publicly — “I made the wrong call on the Q2 architecture. Here’s what I learned.” This gives permission.
2. Ask for feedback on yourself — “What’s one thing I could do better?” and then visibly act on it.
3. React well to bad news — the first time someone brings you a problem, your reaction sets the norm forever. Thank them, don’t shoot the messenger.
4. Normalize “I don’t know” — say it yourself in meetings. Senior people saying “I don’t know” liberates everyone.

Structural supports:

• Blameless postmortems — Etsy, Google, and Netflix all practice these. The focus is “what happened and how do we prevent it” not “who screwed up”
• Pre-mortems — before launching, ask “imagine this failed — what went wrong?” This catches problems without someone having to be the pessimist
• Rotating meeting facilitation — gives quieter team members practice speaking up
• Anonymous retro tools — Slido, RetroTool — let people surface issues they wouldn’t say in person

Measuring psychological safety:

Edmondson’s 7-question survey (used by Google internally):

1. If you make a mistake on this team, it is often held against you (reverse scored)
2. Members of this team are able to bring up problems and tough issues
3. People on this team sometimes reject others for being different (reverse)
4. It is safe to take a risk on this team
5. It is difficult to ask other members of this team for help (reverse)
6. No one on this team would deliberately act to undermine my efforts
7. Working with members of this team, my unique skills and talents are valued

Score on 1-5 Likert scale. Average below 3.5 = significant safety gap.

Tuckman’s Stages of Group Development

Bruce Tuckman (1965) identified four stages every team goes through. It’s old theory but still the most useful mental model for understanding team evolution.

The stages:

Stage	What’s Happening	Manager’s Role	Duration
Forming	Polite, cautious, testing boundaries	Provide structure, set norms, clarify roles	2-6 weeks
Storming	Conflict emerges, power struggles, frustration	Don’t suppress conflict — channel it productively	2-8 weeks
Norming	Roles clarified, trust building, processes established	Step back, reinforce positive patterns	4-12 weeks
Performing	High trust, autonomous, self-correcting	Shield the team, provide strategic direction	Ongoing
Adjourning	Team dissolves (reorg, project end)	Acknowledge the loss, celebrate, help transitions	1-2 weeks

Why managers fail at the Storming stage:

Most managers panic when conflict emerges and try to suppress it — forcing agreement, mediating every disagreement, or shuffling team composition. But Storming is necessary. A team that never storms never builds the trust that comes from navigating conflict. The manager’s job during Storming is to:

1. Normalize it — “This friction is a sign we’re working through real differences”
2. Keep it about ideas, not people — redirect personal attacks to substantive disagreements
3. Facilitate resolution — help the team develop their own conflict resolution patterns
4. Protect vulnerable team members — make sure louder voices don’t drown out quieter ones

The reorg reset:

Every significant team change (new member, departing member, new manager, scope change) drops the team back to Forming. This is why frequent reorgs are so destructive — the team never reaches Performing because they keep getting reset. An insight from Will Larson (An Elegant Puzzle): the most common cause of underperforming teams is not bad people but too-frequent organizational change.

Lencioni’s Five Dysfunctions of a Team

Patrick Lencioni’s model is a pyramid — each dysfunction must be addressed before the one above can be resolved.

        +-----------------------+
        | Inattention to        |  5. Team members prioritize individual
        | RESULTS               |     goals over team goals
        +-----------------------+
        | Avoidance of          |  4. Team members don't hold each other
        | ACCOUNTABILITY        |     accountable — only the manager does
        +-----------------------+
        | Lack of               |  3. Without real debate, people don't
        | COMMITMENT            |     buy in to decisions — silent vetoes
        +-----------------------+
        | Fear of               |  2. People avoid disagreement —
        | CONFLICT              |     "artificial harmony"
        +-----------------------+
        | Absence of            |  1. People don't show vulnerability —
        | TRUST                 |     they perform instead of being real
        +-----------------------+

How to diagnose which dysfunction you have:

Signal	Dysfunction	Intervention
People don’t admit mistakes or ask for help	Absence of Trust	Vulnerability exercises, personal histories, manager models first
Meetings are boring, everyone agrees	Fear of Conflict	“Devil’s advocate” role, explicitly ask for dissent, reward disagreement
Decisions keep getting revisited	Lack of Commitment	“Disagree and commit” norm, clear decision owner, written decisions
Poor work goes unchallenged by peers	Avoidance of Accountability	Peer code reviews with real standards, shared team commitments
People optimize for personal goals (promotions, visibility)	Inattention to Results	Team-level OKRs, celebrate team wins not individual heroics

The “artificial harmony” trap:

This is the most common dysfunction in teams that pride themselves on being “collaborative” or “no-drama.” Meetings are pleasant, everyone nods, and then nothing changes because no one actually committed to anything. Artificial harmony is not health — it’s avoidance. A healthy team argues about the technical direction, then commits to the decision. An artificially harmonious team agrees in the room and undermines in the hallway.

How to break artificial harmony:

• Ask explicitly: “What are the arguments against this approach?”
• Assign someone to argue the opposing position
• Use decision logs: “Decision: X. Disagreed: Y. Rationale: Z.”
• Celebrate the person who says “I don’t think this will work, and here’s why”

Conflict Resolution

The Thomas-Kilmann model:

Five conflict-handling modes based on assertiveness (concern for your goals) and cooperativeness (concern for the other’s goals):

Mode	When to Use	When to Avoid
Competing (high assert, low cooperate)	Time-critical decisions, safety issues, you know you’re right	Relationship matters, you might be wrong
Collaborating (high assert, high cooperate)	Both parties’ needs are important, time available	Trivial decisions, time pressure
Compromising (medium both)	Need a quick resolution, equal power	Underlying issues need real resolution
Avoiding (low both)	Issue is trivial, emotions too hot, you need information	Issue will escalate if unaddressed
Accommodating (low assert, high cooperate)	You’re wrong, relationship matters more than the issue	Sets a pattern of giving in

Handling interpersonal conflict on your team:

Step 1: Don’t triangulate. When person A complains about person B to you, don’t become the messenger. Ask: “Have you talked to them about this directly?” If they haven’t, coach them on how to.

Step 2: If direct conversation fails, mediate. Sit both people down. Set ground rules: (1) speak from your own experience (“I feel” not “you always”), (2) listen without interrupting, (3) focus on the behavior, not the person.

Step 3: Find the interest behind the position. Most conflicts are positional (“I want X” vs. “I want Y”). The underlying interests are often compatible. Classic example: two engineers fighting over the architecture are both trying to build a reliable system — they disagree on the path, not the destination.

Step 4: Make it structural. If two people consistently clash because of overlapping ownership, the problem is the system, not the people. Clarify roles, create explicit ownership boundaries, and reduce forced collaboration on contentious areas.

The brilliant jerk problem:

A high-performing engineer who is toxic to the team — condescending in code reviews, dismissive in meetings, creates fear. The standard advice is “fire them” (Netflix’s position), but the reality is more nuanced:

1. Give them direct, specific feedback — many brilliant jerks don’t know how they land. “In yesterday’s code review, you wrote ‘this is obviously wrong.’ That comment made [person] reluctant to submit PRs for the rest of the week.”
2. Set a clear expectation — “Continued collaboration issues will affect your performance rating and potentially your role on this team”
3. Give them time to change — 30-60 days with specific behavior targets
4. If they don’t change, exit them — the math is clear. One toxic person causes 2-3 good people to leave. The net productivity loss is severe.

The hardest part: the brilliant jerk often has a manager who’s protecting them because of their output. As a senior leader, you must override this — the team’s health is more important than any individual’s code output.

Team Topologies for People

Borrowing from the Team Topologies book (Skelton & Pais), think about how team structures affect people dynamics:

Stream-aligned teams:

People dynamics advantage: clear ownership, end-to-end responsibility, reduced coordination cost. People risk: isolation, “us vs. them” mentality, knowledge silos.

Platform teams:

People dynamics advantage: deep expertise, clear service boundaries. People risk: disconnection from customer impact, “ivory tower” perception, internal customers who don’t appreciate the work.

Enabling teams:

People dynamics advantage: mentorship, cross-pollination, growth opportunities. People risk: no permanent team, lack of belonging, always “helping” never “owning.”

The people implication:

When forming teams, consider not just the technical topology but the people topology. Who works well together? Who needs a new context to grow? Which team needs a senior leader and which can run autonomously? Who’s been on the same team so long they’ve stopped learning?

Team Rituals That Build Health

Ritual	Purpose	Frequency	Anti-Pattern
Retrospective	Surface process issues, celebrate wins, improve	Every 2 weeks	“Everything’s fine” — no real issues raised
Team lunch/social	Build personal connections	Weekly or biweekly	Forced fun, mandatory “team building”
Demo day	Showcase work, build pride, get feedback	Every 2-4 weeks	Only showing finished work — show WIP too
Blameless postmortem	Learn from incidents without blame	After every incident	Blame creeps in, or postmortems are filed and forgotten
Team health check	Structured assessment of team dimensions	Quarterly	Going through the motions without acting on results
Pairing/mobbing sessions	Knowledge sharing, relationship building	Weekly	Always the same pairs, never cross-level
Decision log	Track decisions and rationale	Continuous	No one reads it

The Spotify Health Check model:

Spotify developed a team health check with color-coded cards (green/yellow/red) across dimensions: Easy to Release, Suitable Process, Tech Quality, Value, Speed, Mission, Fun, Learning, Support, Pawns or Players. Teams rate each dimension and trends are tracked quarterly. The power is in the conversation, not the scores — it surfaces issues that wouldn’t come up in a regular retro.

Managing Team Size

The “two-pizza team” myth:

Bezos’s two-pizza rule (team should be small enough to be fed by two pizzas) is directionally correct but oversimplified. Research from J. Richard Hackman (Harvard) suggests 4-6 is optimal for collaborative work, while 7-10 is manageable for a team with clear roles and a strong manager. Above 10, communication overhead increases quadratically (Metcalfe’s law for people).

Your team of 16:

At 16 direct reports, you’re beyond the manageable range for a single manager. The standard approach is to split into 2-3 sub-teams with tech leads or senior engineers acting as team leads, while you remain the single people manager. Alternatively, grow one of your senior ICs into a management role. The risk of the first approach: you become a bottleneck for people decisions across all sub-teams. The risk of the second: you lose a strong IC and gain an untested manager.

The pragmatic approach: Identify 2-3 informal team leads who own technical decision-making and sprint coordination. Keep all 16 as your direct reports for career and people management, but reduce 1:1 frequency to biweekly for the more senior/autonomous members and keep weekly for those needing more support. This is not ideal long-term — it’s a bridge to eventually creating proper sub-teams with their own managers.

References

Books

• The Five Dysfunctions of a Team — Patrick Lencioni (the pyramid model)
• An Elegant Puzzle — Will Larson (team health, sizing, reorg dynamics)
• Team Topologies — Matthew Skelton & Manuel Pais (team structure patterns)
• The Fearless Organization — Amy Edmondson (psychological safety — the definitive reference)
• Turn the Ship Around! — L. David Marquet (leader-leader model vs leader-follower)
• Crucial Conversations — Patterson, Grenny, et al. (conflict resolution mechanics)
• The Culture Code — Daniel Coyle (belonging cues, vulnerability loops, purpose)

Research

• Google Project Aristotle (2015) — psychological safety as top predictor of team performance
• Tuckman, B. (1965) — “Developmental Sequence in Small Groups” — the Forming-Storming model
• Hackman, J.R. — “Leading Teams” — optimal team size, enabling conditions
• Edmondson, A. (1999) — “Psychological Safety and Learning Behavior in Work Teams”

Talks & Articles

• Amy Edmondson — “Building a Psychologically Safe Workplace” (TEDx)
• Google re:Work — “Guide to Team Effectiveness” (Project Aristotle findings, open-source)
• Spotify Engineering Culture videos (Parts 1 & 2) — team health check model
• Netflix Culture Memo — team-as-sports-team metaphor (controversial but worth understanding)