Chapter 02 Flashcards — How to Work Well on Teams
flashcards seg teamwork hrt humility respect trust blameless-culture
What is the “Genius Myth” and why is it harmful in software engineering?
?
The Genius Myth is the culturally prevalent belief that transformative software is created by solitary individuals of exceptional intellect who work alone and need neither feedback nor collaboration. It is harmful because it (1) is historically false — major engineering achievements are team efforts; (2) encourages engineers to hide work, avoid asking for help, and interpret feedback as personal attack; and (3) creates organizations with low bus factors, fragile knowledge distribution, and culture where silos are treated as power rather than risk.
What is the Bus Factor (also called Truck Factor)?
?
The Bus Factor is the minimum number of team members who could be made unavailable (hit by a bus) before a project can no longer make progress. A bus factor of 1 means the entire project’s knowledge — architecture, context, history, critical implementation details — lives in one person. Their absence (voluntary or involuntary) is fatal to the project. Raising bus factor through early code sharing, knowledge documentation, and collaborative review is an explicit risk management goal.
What are the three pillars of effective social interaction in engineering teams, according to the book?
?
HRT: Humility, Respect, and Trust. The authors present these not as personality traits but as behavioral practices that can be deliberately adopted and reinforced through team culture. Teams that exhibit strong HRT are demonstrably more productive, produce better code, and sustain higher velocity over time than those that do not. Each pillar has specific, observable behavioral manifestations.
Define Humility as an engineering behavior (not a personality trait).
?
Humility in engineering practice means: (1) treating code review feedback as information about the code, not as personal attack; (2) acknowledging uncertainty and knowledge gaps honestly rather than bluffing; (3) remaining open to the possibility that your design has flaws and your understanding is incomplete; and (4) crediting collaborators and recognizing collective achievement rather than claiming individual credit for team work. The opposite is false confidence and defensiveness.
Define Respect as an engineering behavior in the context of HRT.
?
Respect means treating colleagues as capable, well-intentioned professionals whose time and contributions have value. In practice: providing feedback that is specific, actionable, and constructive — not dismissive or condescending; engaging seriously with ideas even when disagreeing; not wasting teammates’ time with poorly-prepared proposals; and explicitly acknowledging others’ contributions. Respect for the person is always required; agreement with their ideas is not.
Define Trust as an engineering behavior in the context of HRT.
?
Trust means believing in the good faith and competence of colleagues, and acting on that belief. In practice: delegating work and letting colleagues do it their own way; giving the benefit of the doubt on ambiguous decisions; extending trust generously before it is fully earned; and building personal track record through consistent, reliable behavior. Engineers who never trust others deprive themselves (and their teams) of the collaboration benefits that raise bus factors and accelerate development.
Why is hiding code until it is “finished” an anti-pattern?
?
Because it defers problem detection to the most expensive possible point — exactly the opposite of Shifting Left. Three specific harms: (1) Design flaws and misunderstood requirements are cheapest to fix in early stages, not after significant implementation; (2) Bus factor stays at 1 — every week of solo development is a week during which only one person understands the code; (3) Progress slows — engineers working alone over-engineer, stay blocked longer (reluctant to ask for help), and miss the social accountability that keeps work focused.
What is the “Big Reveal” anti-pattern?
?
The Big Reveal is working solo for an extended period and then sharing a large, complex change all at once. Problems with this pattern: (1) Large changes are expensive to review — reviewers must understand the entire scope at once; (2) Problems discovered late are expensive to fix and may require redesigning significant portions; (3) Criticism of large finished work feels more personal and more demoralizing than early-stage feedback on a work-in-progress. Google’s culture strongly prefers small, frequent changes shared early over large, infrequent Big Reveals.
What is a blameless post-mortem?
?
A blameless post-mortem is a structured retrospective on an incident (outage, data loss, deployment failure) that: (1) establishes a clear timeline; (2) identifies systemic and procedural causes rather than attributing fault to individuals; (3) produces specific, assigned, tracked action items to address root causes; and (4) is shared broadly so others can learn. Blamelessness is not about absolving negligence — it is about recognizing that most failures are caused by process and system failures, not individual inadequacy.
Why does blameless culture produce better engineering outcomes than blame culture?
?
Two reasons: (1) Systemic causation — most incidents arise from process gaps, incomplete runbooks, inadequate monitoring, and tooling that makes the wrong action too easy; blaming an individual for following a broken process changes nothing about the process. (2) Reporting incentives — when engineers fear blame, they conceal problems and delay reporting; blameless culture makes early transparent reporting the rational choice. Early reporting almost always reduces total incident cost. The goal is to fix the system, not punish the person.
What are the five key sections of an effective post-mortem document?
?
- Impact: Who was affected, for how long, and what was the business/user cost?
- Timeline: Chronological account of when the problem started, was detected, mitigated, and resolved.
- Root Cause Analysis: The underlying systemic causes — often using “5 Whys” to go beneath surface-level triggers.
- Contributing Factors: Process gaps, monitoring deficiencies, tooling failures, runbook gaps.
- Action Items: Specific, assigned, tracked improvements — each with an owner and target date. “Be more careful” is not an action item.
What is the post-mortem anti-pattern “naming individuals as root cause”?
?
This anti-pattern stops the root cause analysis at the symptom level (a person made an error) rather than identifying the systemic reason the error was possible, undetected, or unmitigated. The correct question is always: “What process, tool, or system allowed this error to reach production?” Naming individuals as root cause also creates the blame culture that incentivizes concealment and delayed reporting, degrading the organization’s ability to learn from failures.
What does “Being Googley” mean in the context of engineering behavior?
?
“Being Googley” describes a set of behaviors that Google has observed to be associated with high-performing, effective engineers in collaborative environments: (1) Thrives in ambiguity — makes progress without complete specs; (2) Values feedback — seeks it actively; (3) Challenges status quo — constructively, not obstructively; (4) Puts users first; (5) Does the right thing — even when politically difficult; (6) Cares about the team — shares knowledge, mentors, unblocks others. Notably, it is not about agreeableness — vigorous technical disagreement conducted with HRT is valued.
What are the two main reasons the authors reject the Genius Myth historically?
?
- Survivorship bias: We remember rare solo breakthroughs and forget the far more numerous solo efforts that failed for lack of feedback, diverse perspective, and collaboration. The successes we attribute to lone geniuses typically involved teams, co-founders, and early collaborators whose contributions are retrospectively erased.
- Attribution error: Even genuine individual contributors (Linus Torvalds, etc.) built on prior work, received substantial feedback, and led or participated in collaborative communities. The “lone genius” narrative is a simplification that serves the Genius Myth’s appeal rather than historical accuracy.
How does HRT apply specifically during code review?
?
High HRT behavior: Ask clarifying questions (“I’m curious about this approach — what were the trade-offs you were considering?”); surface specific concerns (“I think this will fail when X happens — have you considered Y?”); engage with the author’s responses; seek consensus. Low HRT behavior: Dismissive judgment (“This is wrong”); rhetorical questions implying the author should have known better (“Why would you do it this way?”); leaving comments without engaging; approving to avoid conflict rather than raising real concerns.
What is the “Drive-by Criticism” anti-pattern in code review?
?
Drive-by Criticism is leaving dismissive, superficial, or condescending comments in code reviews or design documents without engaging seriously with the work. It poisons psychological safety — engineers become reluctant to share early-stage work because they fear superficial dismissal that feels worse than useless feedback. It is a failure of Respect: the reviewer has not taken the author’s time or effort seriously. High-HRT reviewers engage substantively, ask genuine questions, and give feedback they would want to receive.
Why do the authors say soft skills are engineering skills?
?
Because the outputs of software engineering — functional, maintainable, scalable systems that serve users over time — require sustained collaboration across large, evolving teams. The ability to give and receive useful feedback, share knowledge effectively, work through technical disagreement, conduct blameless retrospectives, and build trust with colleagues directly determines how effectively a team can execute the technical work. At Google’s scale, interpersonal effectiveness is a force multiplier on technical skill — or, when absent, a force multiplier on dysfunction.
What does raising the Bus Factor require in practice?
?
- Early code sharing — sharing in-progress work through WIP pull requests, early design reviews, and regular check-ins distributes knowledge incrementally.
- Documentation — architecture decisions, non-obvious implementation choices, and system context documented in code comments, design docs, and ADR-style records.
- Pair and collaborative work — working alongside colleagues on critical systems rather than always working independently.
- Code review culture — requiring reviewers to genuinely understand (not just approve) changes creates distributed understanding as a side effect of normal process.
Each practice incrementally raises bus factor as a byproduct of standard engineering activity.
What is psychological safety and why is it a prerequisite for high-performance engineering?
?
Psychological safety is the belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes. It is a prerequisite for: (1) early code sharing (engineers won’t share unfinished work if early sharing invites ridicule); (2) honest code review (reviewers won’t surface concerns if doing so creates conflict); (3) transparent incident reporting (engineers won’t report early if blame is the response); and (4) genuine learning from mistakes (post-mortems are only valuable if participants report honestly). Without psychological safety, all of these practices degrade.
How does the “False Confidence” anti-pattern undermine team effectiveness?
?
False Confidence is presenting estimates, designs, or solutions with more certainty than the evidence warrants — to appear competent or avoid admitting uncertainty. Its harms: (1) discourages challenge, so problems with the approach are not surfaced; (2) blocks honest discussion of risk and alternatives; (3) when the confident assertion turns out to be wrong, the discovery comes later and costs more; and (4) creates culture where admitting uncertainty is seen as weakness, which is the opposite of Humility and suppresses organizational learning.
What is the core argument for why most incidents have systemic rather than individual causes?
?
Because production systems are complex, and individual engineers operate within processes, tooling, and environments designed by the organization. An engineer who deploys a bad change typically: followed a deploy process that allowed unreviewed changes to proceed; used monitoring that did not detect the problem; followed a runbook that did not include the relevant scenario; worked in an environment where the wrong action was too easy to take. These are systemic failures. The engineer was a symptom; the system was the root cause. Fixing the system prevents recurrence; blaming the engineer does not.
What does “doing the right thing” mean in the context of Being Googley?
?
It means acting with integrity even when it is uncomfortable, politically costly, or career-risky. In engineering practice: surfacing a security flaw even if fixing it will delay a launch; escalating a data integrity concern even if the team is under deadline pressure; declining to approve a code change that violates important principles even if the author is a senior engineer; admitting a mistake clearly rather than minimizing or deflecting it. The authors present this as a component of trustworthiness — engineers who do the right thing when it is hard are the ones whose judgment others can rely on.
Why is challenging the status quo listed as a component of Being Googley?
?
Because at Google’s scale, existing processes and systems are often no longer optimal — they were designed for a different scale, a different team structure, or a different set of requirements. Engineers who identify and constructively challenge sub-optimal practices are creating value even when they are not writing code. The key qualifier is constructively: the behavior valued is not contrarianism or obstruction but the combination of critical thinking, evidence-based argument, and willingness to propose alternatives and follow through — conducted with Respect and Humility.
Total Cards: 23
Review Time: ~18 minutes
Priority: HIGH
Last Updated: 2026-06-02