Chapter 2: How to Work Well on Teams
seg teamwork collaboration humility respect trust blameless-culture
Status: Notes complete
Overview
Chapter 2 pivots from the abstract principles of Chapter 1 to the human dimension of software engineering: the social and organizational dynamics that determine whether engineering teams succeed or fail over time. The chapter’s central argument is that the “lone genius” model of software development is a myth — and a harmful one. Every major engineering achievement at scale is a team accomplishment, and the practices that make teams effective are learnable disciplines, not personality traits.
The authors introduce the concept of psychological safety through a framework of three pillars — Humility, Respect, and Trust (HRT) — and argue that these are not soft skills tangential to engineering but foundational prerequisites for the kind of rigorous, rapid, iterative development that Google’s scale demands. The chapter also introduces concrete practices: early code sharing over solo development, blameless post-mortems, and a set of behaviors the authors describe as “Being Googley.”
Core Concepts
The Genius Myth: The culturally prevalent belief that transformative software is created by solitary individuals of exceptional intellect — heroic programmers who work alone, produce extraordinary results, and need neither feedback nor collaboration. The authors argue this myth is (1) largely false historically, (2) actively harmful when internalized by engineers, and (3) particularly dangerous in large engineering organizations because it discourages the collaborative practices on which scalable engineering depends.
Bus Factor (also called Truck Factor): The minimum number of team members who could be struck by a bus (made unavailable) before the project becomes unable to make progress. A bus factor of 1 means the entire project’s knowledge lives in one person; their absence is fatal to the project. Raising the bus factor is an explicit goal of good knowledge-sharing and collaborative development practices.
HRT (Humility, Respect, Trust): The three pillars of effective social interaction in engineering teams. The authors argue these are not personality descriptors but behavioral practices that can be adopted deliberately, and that teams exhibiting strong HRT are demonstrably more productive and more innovative than those that do not.
Psychological safety: The belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes. The authors treat it as a prerequisite for the kind of open code review, early-sharing behavior, and honest post-mortem analysis that Google’s engineering culture depends on. (The term itself is more prominent in Google’s later Project Aristotle research, but the concept underpins the entire chapter.)
Blameless post-mortem: A structured retrospective on an incident or failure that focuses on identifying systemic causes and process improvements rather than attributing fault to individuals. The authors argue that blame inhibits honest reporting and that the causes of most failures are systemic rather than individual.
The Genius Myth and Why It Is Harmful
The Appeal of the Myth
The Genius Myth is seductive because it maps onto a few real historical examples (Linus Torvalds with early Linux, certain famous solo contributors) and because it aligns with how programmers often experience creativity — as a solo, flow-state activity. Engineers who internalize the myth believe that:
- The best code is written alone, without interference
- Showing work-in-progress invites premature criticism that stifles creativity
- Asking for help signals weakness
- Credit for good work is diluted by collaboration
Why the Myth Is False
The authors systematically dismantle each belief:
- Historical analysis: Linux, the internet, Google itself — all large-scale successful systems were team efforts. Even “solo” founders had co-founders, early collaborators, and teams. The myth retrospectively erases contributors.
- Survivorship bias: We remember the rare solo breakthrough; we do not remember the far more numerous solo efforts that failed because they lacked collaboration, feedback, and diverse perspectives.
- The collaboration advantage: Teams catch bugs that individuals miss, surface requirements that individuals overlook, and distribute knowledge in ways that make projects resilient. A “genius” who hides their work until it is perfect is denying the project all of these benefits during the period when they are most valuable.
Harm the Myth Causes
For individuals: Engineers who internalize the myth avoid asking for help, delay sharing their work, and interpret feedback as personal attack rather than collaborative improvement. This leads to wasted effort on misdirected work and slower growth.
For teams: Teams that celebrate lone genius behavior develop culture where code ownership is personal rather than collective, where knowledge silos are treated as power, and where collaboration is seen as a sign that someone isn’t smart enough to work alone.
For organizations: Projects with hero-dependent architectures have low bus factors, fragile knowledge distribution, and catastrophic failure modes when key individuals leave.
Hiding Code Considered Harmful
The chapter argues that the instinct to hide code until it is “ready” is one of the most counterproductive behaviors in software development. The authors identify three specific harms:
1. Early Detection Lost
The sooner a code change is visible to others, the sooner problems can be caught. Problems found in the first week of development cost a fraction of what they cost to fix in the fifth week:
- Design flaws are cheapest to fix before code is written or in early stages
- Misunderstood requirements surface quickly in early review
- Integration conflicts are visible as soon as code is shared with the team
By hiding code until it is “finished,” engineers do exactly the opposite of Shifting Left — they defer problem detection to the most expensive possible point.
2. Bus Factor Stays Low
Code that only one engineer has seen is code that only one engineer understands. Every week of solo development without sharing is a week during which the bus factor stays at 1. Beyond the risk of that engineer leaving, it also means:
- No one can review the code effectively
- No one can answer questions about it when the author is unavailable
- No one can continue the work if the author is blocked or reprioritized
Positive pattern: Regular sharing of in-progress work — through early code reviews, design documents, and WIP pull requests — continuously distributes knowledge and raises the bus factor incrementally rather than requiring a large knowledge-transfer event at project completion.
3. Pace of Progress Slows
Counterintuitively, hiding code slows individual progress as well as team progress. The authors argue that:
- Developers working alone for too long tend to over-engineer — building solutions to problems that do not exist
- Early feedback eliminates dead ends before significant time is invested
- The social accountability of shared work tends to keep engineers focused on what matters
- Blocked engineers stay blocked longer because they cannot easily ask for help without revealing their “unfinished” work
Anti-pattern — The Big Reveal: The tendency to work solo for an extended period and then share a large, complex change all at once. Big Reveals are expensive to review (reviewers must understand the entire change at once), risky (problems discovered late are expensive to fix), and demoralizing (criticism of a large finished work feels more personal than criticism of early-stage work). Google’s code review culture strongly prefers small, frequent changes over large, infrequent ones.
The Three Pillars: Humility, Respect, Trust (HRT)
The authors frame HRT not as personality traits but as behaviors that can be deliberately practiced. The framework is explicitly prescriptive — teams should actively cultivate these behaviors, not just hope that the right personalities are hired.
Humility
Humility means recognizing that you are not omniscient or infallible. In engineering practice:
- Being open to the possibility that your code has bugs, your design has flaws, and your understanding of requirements is incomplete
- Treating code review feedback as information, not as personal attack
- Acknowledging when you do not know something, rather than bluffing
- Crediting collaborators and recognizing collective achievement
Anti-pattern — False Confidence: Presenting estimates, designs, or solutions with more certainty than the evidence warrants, in order to appear competent. This discourages challenge and means problems are discovered later than they need to be.
Anti-pattern — Defensiveness in Code Review: Treating code review comments as attacks on personal competence rather than as collaborative improvement of the codebase. This pattern makes reviewers reluctant to comment honestly, degrading the quality of review over time.
Respect
Respect means treating colleagues as capable, well-intentioned professionals whose time and contributions have value. In engineering practice:
- Providing constructive feedback that is specific and actionable, not dismissive or condescending
- Engaging seriously with ideas even when you disagree with them
- Not wasting teammates’ time with avoidable questions or poorly-prepared proposals
- Recognizing and acknowledging others’ contributions explicitly
The authors distinguish between respecting the person (always required) and agreeing with their ideas (optional). Vigorous technical disagreement is healthy and expected; personal disrespect is not.
Anti-pattern — Drive-by Criticism: Leaving dismissive comments in code reviews or design documents without engaging seriously with the work. This behavior poisons psychological safety — engineers become reluctant to share early because they fear superficial dismissal.
Trust
Trust means believing in the good faith and competence of your colleagues. In engineering practice:
- Delegating work and then letting colleagues do it their way, without micromanagement
- Trusting that other teams are not building the wrong thing on purpose
- Giving the benefit of the doubt on ambiguous decisions
- Building a track record through consistent, reliable behavior
The authors note that trust is earned but also that it must be extended before it can be earned. Engineers who never trust others deprive themselves of the collaboration benefits that raise bus factors and accelerate development. Trust must be extended generously and adjusted based on experience — not withheld until perfect evidence exists.
HRT in Practice
The authors provide concrete behavioral examples for applying HRT:
During Code Review
| Low HRT | High HRT |
|---|---|
| ”This is wrong." | "I think this will fail when X happens — have you considered Y?" |
| "Why would you do it this way?" | "I’m curious about this approach — what were the trade-offs you were considering?” |
| Leaving comments and disappearing | Engaging with the author’s response and arriving at consensus |
| Approving to avoid conflict | Raising concerns clearly but professionally |
During Design Discussion
- Ask questions that assume good intent: “Help me understand the rationale for X” rather than “Why didn’t you do Y?”
- Separate the idea from the person: “I’m concerned this approach has a scalability problem” not “I don’t think you’ve thought this through”
- Look for partial agreement: “I like the goal here; my concern is specifically with the implementation of X”
When Receiving Feedback
- Separate emotional response from informational response: What is this feedback actually telling me about the code?
- Assume the reviewer wants the code to succeed, not to make the author look bad
- Ask clarifying questions rather than becoming defensive: “Can you say more about what specific scenario concerns you?”
Blameless Post-Mortem Culture
What It Is
A blameless post-mortem is a structured retrospective conducted after an incident (outage, data loss, deployment failure, security breach) that:
- Establishes a clear timeline of what happened and when
- Identifies the systemic and procedural causes of the failure
- Proposes actionable improvements to processes, tooling, monitoring, and runbooks
- Explicitly avoids attributing fault to individuals
The document produced is shared broadly — often publicly within the organization — so that others can learn from the incident.
Why Blamelessness Works
The authors make two arguments for blameless culture:
Argument 1 — Systemic causation: Most incidents are not caused by individual incompetence or negligence; they are caused by systemic failures — processes that allowed a bad change to reach production, monitoring that failed to detect a problem early, runbooks that were incomplete or outdated, tools that made the wrong action too easy. Blaming an individual for following a broken process changes nothing about the process; it just makes engineers feel bad and creates incentives to conceal future incidents.
Argument 2 — Reporting incentives: If engineers fear being blamed for incidents, they have an incentive to conceal problems, delay reporting, and minimize their involvement. Blameless culture creates the opposite incentive: report early, be transparent, contribute to the analysis, because there is no personal cost to doing so. Early reporting is almost always cheaper than late reporting; incentivizing it has significant engineering value.
Elements of an Effective Post-Mortem
Title and Date
--------------
Brief description of the incident and when it occurred.
Impact
------
Who was affected, for how long, and what was the business impact?
Timeline
--------
Chronological account of events: when the problem started, when it was
detected, when mitigations were applied, when the incident was resolved.
Root Cause Analysis
-------------------
The underlying systemic causes (not the immediate triggers).
Often structured as "5 Whys" to get beneath surface-level explanations.
Contributing Factors
-------------------
Process gaps, monitoring gaps, tooling failures, runbook deficiencies.
Action Items
------------
Specific, assigned, tracked improvements — each owned by a named person
with a target completion date. Not vague commitments like "improve monitoring"
but specific tasks like "Add latency alerting to checkout service by [date]."
Lessons Learned
---------------
What should other teams know to prevent similar incidents?
Anti-patterns in Post-Mortems
| Anti-pattern | Problem |
|---|---|
| Naming individuals as root cause | Stops analysis at the symptom; does not identify what process or tooling failed |
| ”We’ll be more careful next time” | Not an action item; cannot be tracked or verified |
| Closed post-mortems | Prevents organizational learning; others cannot benefit from the incident |
| Post-mortem without action items | Produces insight but no improvement |
| Delayed post-mortem | Memory of timeline details fades; participants reconstruct rather than recall |
Being Googley
The chapter closes by describing behaviors the authors call “Being Googley” — a collection of attributes that Google looks for in candidates and cultivates in engineers. The authors are transparent that this is an opinionated list, but they present it as empirically derived from observation of what makes engineers effective in Google’s collaborative environment:
- Thrives in ambiguity: Can function effectively and make progress without complete specifications or perfectly clear requirements
- Values feedback: Actively seeks feedback and treats it as information rather than criticism
- Challenges status quo: Willing to push back on assumptions and propose alternatives, but does so constructively
- Puts users first: Keeps the user impact of technical decisions in focus
- Does the right thing: Acts with integrity even when it is uncomfortable or politically difficult
- Cares about the team: Invests in colleagues’ success, not just personal achievement; shares knowledge, mentors, and helps unblock others
The authors note that “Being Googley” is explicitly not about being agreeable or deferential. Vigorous technical disagreement, honest critical feedback, and challenging established practices are all highly valued — as long as they are conducted with HRT.
TL;DRs
(Faithful reproduction from the book’s end-of-chapter TL;DR section)
- Be aware of the trade-offs of working in isolation.
- Acknowledge the importance of social skills, also known as “soft skills.”
- Understand that Humility, Respect, and Trust form the foundation of effective team culture (HRT).
- Learning how to be a good collaborator is just as important as being a good programmer.
- When considering all the skills you need to be a successful software engineer, keep the Team Player skills in your mind.
- Don’t underestimate the importance of being a good team player.
- Constructive feedback and blameless post-mortems are the tools of high-performing teams.
- Being Googley encompasses the behaviors of high-performing engineers.
Key Takeaways
- The Genius Myth is harmful at scale — it discourages early feedback, creates single points of knowledge failure (low bus factor), and produces culture where collaboration is misread as inadequacy.
- Hiding code until it is “ready” is a form of Shifting Right — every week of solo development defers problem detection to a more expensive point; early sharing is not a sign of unreadiness but a best practice.
- Bus factor is a concrete, measurable risk — a bus factor of 1 means one person’s absence kills the project; raising bus factor through knowledge-sharing and early code review is a risk management practice, not a nice-to-have.
- HRT (Humility, Respect, Trust) are behavioral practices, not personality traits — they can be deliberately cultivated, modeled by senior engineers, and reinforced through team culture and process design.
- Blameless post-mortems work because most incidents are systemic — blaming individuals changes nothing about the process; systemic root cause analysis and tracked action items change the probability of recurrence.
- Blameless culture creates better reporting incentives — when engineers fear blame, they conceal and delay; when blame is absent, early transparent reporting is the rational choice, and early reporting almost always reduces total incident cost.
- Code review is a collaborative practice, not a gatekeeping one — reviewers and authors are working toward the same goal (good code); HRT applied to code review produces honest, useful feedback and authors who genuinely improve.
- “Being Googley” includes constructive challenge — the behaviors valued are not agreeableness or deference but the combination of high technical rigor with collaborative practice; vigorous technical disagreement conducted with respect is exactly what the culture values.
- Psychological safety is an engineering prerequisite — teams where members fear judgment for honest mistakes, questions, or unfinished ideas cannot practice the rapid iteration, early sharing, and transparent post-mortems that high-performance engineering requires.
- Soft skills are engineering skills — the ability to give and receive feedback, collaborate under pressure, share knowledge, and work through disagreement is as critical to long-term engineering output as algorithmic ability or systems design knowledge.
Related Resources
- ch01-what-is-software-engineering — Establishes the time/scale/trade-offs framework that explains why team effectiveness is an engineering concern, not just a “people” concern
- ch03-knowledge-sharing — Extends the bus factor and knowledge-sharing principles to organizational level: how to build systems and culture for knowledge distribution at scale
- ch05-leading-teams — Applies HRT principles to engineering leadership: how managers can model and reinforce collaborative culture
- ch09-code-review — The formal practice of code review at Google, built on the HRT and early-sharing principles established in Chapter 2
Last Updated: 2026-06-02