The team lead cheat sheet
The night-before page. Everything here is taught properly somewhere else in the book; this is the compressed form, for the train.
Three parts: the positions worth having ready, the research in one line each, and the vocabulary table.
Part 1: positions, with answers
Short answers to the questions that come up in nearly every lead loop. Each one is a committed position, not a survey, because "it depends" without the variables is the answer that loses.
"Why is your team slow?" Measure before answering. In most teams, most of cycle time is queueing, not work. Ask for cycle time split by stage, and expect review wait and deploy wait to dominate. Fixes in order of cost: WIP limit (free), review rotation with a same-day expectation (free), deploy on merge instead of a window (cheap), then capacity (expensive, and usually the wrong first answer because adding people to an unpartitionable late project adds coordination tax).
"How do you prevent this incident recurring?" With a mechanism, not an intention. Owner, trigger, forcing function, artifact someone reads. "We discussed it in retro" scores zero. Fix at three levels and say so: the instance, the class, and the default that let the class exist.
"How would you measure developer productivity?" Not per person. DORA's four at the team level (deployment frequency, lead time, change failure rate, time to restore), each paired with a counter-metric. Individual output metrics are Goodharted within one cycle, misattribute collaborative work, and tax glue work. Use them privately as a signal to go look, never publicly as a judgement. Saying "I'd build a per-engineer dashboard" is close to disqualifying at this level.
"When will it be done?" Two numbers and a commitment: "p50 is eight weeks, p90 is ten, I'll commit to ten." Then name where the spread comes from and what it would cost to reduce it. Never a padded single number: it works once, and after that every estimate you give is discounted.
"How do you handle disagreement with your team's consensus?" Ask whether it's a one-way door. Two-way: go with the team even if you disagree, because the cost of being wrong is small and their ownership is worth more. One-way: you may overrule, and if you do, say explicitly that you're overruling and why. Never win by persistence, because the thing it costs you is people telling you when you're wrong.
"How do you say no to product?" You don't say no. You give options with costs and a recommendation: "A by the date, or A and B three weeks later, or A and B by the date if we drop the migration, which moves compliance risk to Q3. I'd recommend the first. Which do you want?" Converts a capacity fight into their prioritisation decision.
"A senior engineer is disengaging. What do you do?" Find out which of three before acting: disagreement with direction (reopen it honestly or ask them to disagree and commit, once), loss of growth (the fix is scope, not conversation), or something outside work (the fix is flexibility). Diagnosing wrong costs you the person. Ask directly rather than inferring.
"You're in an incident on a system you don't understand." Say so, and route rather than lead. Appoint whoever does understand it as incident lead; take comms, timeline, channel discipline and escalation decisions. Candidates avoid this because it feels like admitting weakness, and it's the answer that demonstrates you know what the role is.
"How do you know your team is healthy?" Four observables, none requiring a survey. Do junior people publicly disagree with senior ones? Does bad news reach you early and unprompted? When someone's out, does their work continue? Does the team change things without asking you? Absence of visible disagreement is the strongest negative signal and is usually misread as harmony.
"Should a lead write code?" Yes, off the critical path. Prototypes, tooling, second reviewer on hard changes. Under ~5 engineers a non-coding lead loses credibility; above ~8 a lead on the critical path is a bottleneck, because their coding time is the first thing interrupts consume.
"First 30 days in a new lead role?" Listening on a deadline, not indefinitely. Everyone one-to-one in two weeks, three questions (keep, blocking you, change one thing), read the last quarter of incidents and retros, then fix one visibly broken thing fast. The early win matters less for the fix than as evidence that telling you about a problem causes the problem to change.
Part 2: the research, one line each
| Result | The one-line version | The bit people get wrong |
|---|---|---|
| Goodhart's law | When a measure becomes a target it stops being a good measure | It's about correlations breaking under optimisation, not about cheating. There are no cheaters to catch. |
| Campbell's law | The stronger form: measurement also corrupts the activity being measured | Not just a useless number, but worse reviews / worse teaching / worse care |
| Project Oxygen (Google) | Managers matter; the effective behaviours are learnable, and coaching ranks first | Technical skill ranked last among managers who all had it: a threshold, not an irrelevance |
| Project Aristotle (Google) | How a team works beats who's on it; psychological safety is the top factor | Safety is not niceness. A conflict-averse team scores low. |
| Edmondson, 1999 | Better teams reported more errors, because they felt safe reporting them | The metric was reported errors; what varied was willingness to speak |
| Normalization of deviance (Vaughan) | Repeated deviation without consequence redefines "acceptable" | Not a moral failure; a normal process. Vigilance loses to it; only mechanisms win. |
| DORA / Accelerate | Throughput and stability move together; they don't trade off | The trade-off is real at fixed capability. It's a symptom of a fixable condition, not a myth. |
| Westrum typology | Pathological / bureaucratic / generative, by how information flows | Diagnostic question: what happens to the person who brings bad news? |
| Conway's law | Systems mirror the communication structures that build them | The useful version is the inverse manoeuvre: change teams to get the architecture |
| Brooks's law | Adding people to a late project makes it later | Only when work is unpartitionable and context is deep. The mechanism is n(n-1)/2. |
| Second-system effect | An architect's second system is over-engineered | The most accurate description of a rewrite from the inside |
| Chesterton's fence | Don't remove it until you know why it's there | Permits removal once explained; often abused to defend the unexplainable |
| Hyrum's law | With enough users, every observable behaviour is depended on | "That was never in the contract" is true and does not help you |
| Gall's law | Complex systems that work evolved from simple systems that worked | The argument for walking skeletons over big-bang design |
| Survivorship bias (Wald) | Armour where the returning planes have no holes | Your percentiles exclude the requests that timed out |
| Planning fallacy | People underestimate duration even knowing the history | Counter with reference class forecasting: what did our last three migrations take? |
| Parkinson's law of triviality | Hours on the bike shed, minutes on the reactor | Diagnostic: discussion volume is inversely related to importance |
| Theory of constraints | Improving anything other than the constraint improves nothing | And fixing the constraint just moves it, so predict the disappointment |
| Little's Law | Cycle time = WIP / throughput | Therefore halving WIP halves cycle time with nobody working harder. It's a theorem. |
Part 3: numbers worth having
| Number | What it is |
|---|---|
| ~26 → p1 | Summing most-likely estimates for six tasks landed at the first percentile of the real distribution. This is why projects are late without anyone being optimistic. |
| Sum of p90s ≈ 25% too high | Percentiles don't add. Independent variation cancels; the total's p90 doesn't need every task at its own p90. |
| 50% | Google SRE's cap on toil. The cap having a consequence is what makes it real. |
| ~150 / 50 / 15 / 5 | Dunbar layers. Relevant to why org structures break at predictable sizes. |
| n(n-1)/2 | Communication paths. 5 people = 10, 10 people = 45, 15 people = 105. |
| 4 | DORA metrics: deployment frequency, lead time for changes, change failure rate, time to restore. |
| 5 | Aristotle factors, in order: psychological safety, dependability, structure and clarity, meaning, impact. |
Part 4: the vocabulary table
Terms that signal seniority when they name a distinction, and signal posturing when they don't. The test before using one: can you state the decision this term changes?
Taught in depth on decisions and risk, systems and failure, and organisations and delivery.
Decisions, risk and reversibility
| Term | Meaning in engineering | Example |
|---|---|---|
| Local maximum | A solution optimal within current constraints that blocks a better design | "We keep optimizing this service, but I think we're stuck at a local maximum." |
| One-way door | A decision that is expensive or difficult to reverse | "The database choice is close to a one-way door, so we should validate it carefully." |
| Two-way door | A reversible decision; don't over-analyze it | "This API naming choice is a two-way door. Ship it and adjust later." |
| Reversibility | How easily a decision can be undone | "Given the uncertainty, optimize for reversibility." |
| Option value | Value gained by preserving future choices | "Keeping the interface storage-neutral gives us option value." |
| Path dependence | Earlier choices constrain later possibilities | "Architecture is highly path-dependent; today's shortcut may become tomorrow's platform." |
| Point of no return | Stage after which reverting becomes prohibitively difficult | "The migration hasn't reached the point of no return yet." |
| No-regret move | Action worth doing under almost any plausible future | "Adding observability is a no-regret move regardless of which architecture we choose." |
| Reversible experiment | Small change designed to learn without committing heavily | "Treat the new ranking model as a reversible experiment." |
| Test the riskiest assumption first | Validate the uncertainty most capable of invalidating the design | "Don't build the UI yet; test the riskiest assumption, whether retrieval quality is sufficient." |
| De-risk | Reduce uncertainty before committing resources | "Prototype the OpenSearch workload to de-risk the architecture." |
| Risk retirement | Systematically eliminate major uncertainties early | "The first milestone should retire scaling and data-quality risk." |
| Pre-mortem | Imagine the project failed and identify likely reasons beforehand | "Let's run a pre-mortem before committing to the migration." |
| Postmortem | Structured analysis of an incident after it occurs | "The postmortem found retry amplification as the primary contributor." |
| Root cause vs contributing factor | Distinguish initiating cause from conditions that amplified it | "The expired cert was the trigger; missing alerting was a contributing factor." |
| Normalization of deviance | Unsafe behavior becomes accepted because it hasn't failed yet | "Manually patching production became normalization of deviance." |
| Known unknown | Something you know needs investigation | "Embedding latency at full scale is a known unknown." |
| Unknown unknown | Risk you do not yet know exists | "The prototype is mainly about exposing unknown unknowns." |
| Second-order effect | Consequence caused indirectly by an initial change | "The first-order effect is faster deploys; the second-order effect is teams deploying smaller changes." |
| Downstream consequence | Effect on components or teams later in the chain | "Changing this schema has downstream consequences for analytics." |
| Blast radius | Scope of damage if something fails | "Can we reduce the blast radius by rolling this out per tenant?" |
| Failure domain | Boundary within which one failure can affect components | "We shouldn't put both replicas in the same failure domain." |
| Single point of failure | Component or person whose failure stops the system | "She's become a human single point of failure for deployments." |
| Bus factor | How many people could disappear before critical knowledge is lost | "Our bus factor for the ranking pipeline is one." |
| Smoking gun | The single piece of evidence that settles a diagnosis | "The retry counters were the smoking gun." |
| Across the board | Uniformly, affecting everything in a category | "Latency is up across the board, not just on the search path." |
| Down the road | At a later point; names when a cost lands | "Denormalizing saves a join now and costs us a migration down the road." |
Design: does the system help or hurt its user
| Term | Meaning in engineering | Example |
|---|---|---|
| Escape hatch | Deliberate way to bypass the normal abstraction when necessary | "The framework needs an escape hatch for unusual query patterns." |
| Sharp edge | Design that is easy to misuse and causes serious problems | "The API works, but it has some sharp edges around retries." |
| Footgun | Something that makes it easy to accidentally harm yourself | "Allowing arbitrary timeouts here is a footgun." |
| Pit of success | Design where the easiest, default behavior is also the correct one | "Make idempotency automatic so developers fall into the pit of success." |
| Leaky abstraction | Abstraction whose implementation details still affect users | "Our repository layer is leaking database semantics." |
| Seam | Boundary where behavior can be changed or tested without editing around it | "We need a seam around the payment provider before we can test this safely." |
| Strangler pattern | Gradually replace a legacy system rather than rewrite it at once | "Put the new recommendation API in front and strangle the legacy path incrementally." |
| Walking skeleton | Minimal end-to-end implementation proving all major components connect | "Before building ranking logic, get a walking skeleton from ingestion to serving." |
| Tracer bullet | Thin implementation through the whole system used to discover unknowns | "Build a tracer bullet through Kinesis, embeddings, OpenSearch, and the API." |
| Thin vertical slice | Small feature implemented end to end rather than one full layer | "Do one thin vertical slice before building the entire data platform." |
| Accidental complexity | Complexity from implementation choices rather than the problem | "Half of this workflow is accidental complexity from the framework." |
| Essential complexity | Complexity inherent to the business or problem domain | "Exactly-once financial posting is essential complexity; we can't abstract it away." |
| Complexity budget | Informal limit on how much complexity a system or team can tolerate | "Kafka would work, but I'm not sure this use case justifies the complexity budget." |
| Change surface | Amount of system or code affected by a modification | "Can we reduce the change surface by putting compatibility logic at the boundary?" |
| Premature abstraction | Generalizing before enough concrete use cases exist | "I'd rather duplicate this twice than introduce a premature abstraction." |
| Gold-plating | Adding sophistication beyond requirements | "Multi-region active-active is gold-plating at our current scale." |
Failure behaviour under load
| Term | Meaning in engineering | Example |
|---|---|---|
| Backpressure | Mechanism preventing producers from overwhelming consumers | "The consumer needs to propagate backpressure instead of buffering indefinitely." |
| Load shedding | Intentionally reject lower-priority work to preserve critical service | "At 95% saturation, we start load shedding recommendation refresh requests." |
| Graceful degradation | Maintain reduced functionality rather than failing completely | "If personalization is unavailable, degrade gracefully to popular articles." |
| Brownout | Intentionally disable optional functionality during overload | "During peak traffic we brown out expensive recommendations." |
| Fail open / fail closed | Whether a dependency failure permits or rejects operations | "For authorization, we should fail closed." |
| Defense in depth | Multiple independent protection layers | "Rate limits, authentication, quotas, and isolation give us defense in depth." |
| Head-of-line blocking | One slow operation delays unrelated work behind it | "Large jobs are causing head-of-line blocking in the queue." |
| Thundering herd | Many clients simultaneously retry, wake or query | "Cache expiry causes a thundering herd against Postgres." |
| Retry storm | Retries amplify an outage instead of helping recovery | "Without exponential backoff, a dependency outage becomes a retry storm." |
| Death spiral | Degradation creates load, which creates further degradation | "Latency triggered retries, retries increased load, and we entered a death spiral." |
Platform and practice
| Term | Meaning in engineering | Example |
|---|---|---|
| Paved road / golden path | The recommended, supported way of doing something | "Kubernetes plus our deployment template is the paved road." |
| Guardrails, not gates | Prefer automated constraints over centralized approvals | "Security should provide guardrails, not gates." |
| Shift left | Move validation, testing or security earlier in development | "We shifted schema compatibility checks left into CI." |
| Shift right | Validate in production via observability, experiments, canaries | "Some reliability properties can only be validated by shifting right." |
| Force multiplier | Something or someone that makes others substantially more effective | "A good internal platform should be a force multiplier for product teams." |
| Toil | Repetitive manual ops work that scales linearly with little lasting value | "Certificate rotation is our biggest source of toil." |
| Undifferentiated heavy lifting | Necessary infra work that provides little competitive advantage | "Running our own message broker is undifferentiated heavy lifting." |
The taxes and the debts
| Term | Meaning in engineering | Example |
|---|---|---|
| Cognitive load | Mental effort required to understand or operate a system | "The architecture is technically elegant but imposes too much cognitive load." |
| Coupling tax | Ongoing cost caused by dependencies between systems or teams | "The shared database creates a significant coupling tax." |
| Coordination tax | Productivity lost because many people or teams must synchronize | "Splitting this across four teams adds more coordination tax than technical value." |
| Integration tax | Recurring cost of connecting independently developed systems | "Supporting five authentication systems creates a permanent integration tax." |
| Operational tax | Ongoing burden of running and maintaining something | "Self-hosting this gives us control, but also a substantial operational tax." |
| Carry cost | Ongoing cost of keeping an architecture or decision around | "Every additional datastore has a carry cost." |
| Debt service | Recurring cost of living with technical debt | "That old integration now consumes 20% of the team's capacity in debt service." |
| Pay down debt | Remove accumulated technical or operational shortcuts | "We'll spend the next sprint paying down reliability debt." |
| Tax the happy path | Make common operations worse to accommodate rare cases | "Don't tax the happy path just to accommodate a 0.1% edge case." |
| Paper over | Hide a deeper issue with a superficial fix | "Increasing the timeout just papers over the contention problem." |
| Kick the can down the road | Defer a problem rather than solve it | "Another exception just kicks the migration problem down the road." |
Flow, constraints and getting unstuck
| Term | Meaning in engineering | Example |
|---|---|---|
| Critical path | Sequence of dependencies determining earliest completion | "The frontend isn't on the critical path; data backfill is." |
| Long pole in the tent | Component determining the overall timeline | "Data migration is the long pole in the tent." |
| Constraint | Limiting factor governing system or team throughput | "If QA capacity is the constraint, adding developers won't increase throughput." |
| Move the bottleneck | Improvement removes one constraint and exposes another | "We sped up development and moved the bottleneck to code review." |
| Queue discipline | Rules governing how queued work is prioritized and processed | "Changing queue discipline may improve tail latency without adding capacity." |
| WIP limit | Limit on concurrent work to reduce queues and cycle time | "The team needs a WIP limit, not more parallel projects." |
| Bikeshedding | Disproportionate time arguing about trivial matters | "We're bikeshedding naming while the consistency model is unresolved." |
| Yak shaving | A chain of prerequisite tasks before reaching the original task | "I wanted to change one endpoint and ended up yak shaving the CI pipeline." |
| Boil the ocean | Attempt an unnecessarily huge scope | "Don't boil the ocean; solve recommendation freshness first." |
Ownership and decisions
| Term | Meaning in engineering | Example |
|---|---|---|
| Ownership boundary | Explicit division of responsibility between systems or teams | "The incident exposed an unclear ownership boundary." |
| Decision rights | Who has authority to make which decisions | "The problem isn't accountability; decision rights are unclear." |
| Escalation path | Defined route for resolving issues beyond local authority | "We need a clear escalation path for cross-team blockers." |
| DRI | Directly Responsible Individual; one accountable owner | "Who's the DRI for the migration?" |
| Two-in-a-box | Two leaders jointly responsible, often product plus engineering | "We're running product and engineering as a two-in-a-box model." |
| RACI | Responsible, Accountable, Consulted, Informed ownership model | "Use a lightweight RACI for the migration." |
| Hero culture | Organization depending on individuals repeatedly rescuing systems | "We should fix the process rather than reward hero culture." |
| Disagree and commit | Raise disagreement, then support the decision once made | "I still prefer Postgres, but I'll disagree and commit to DynamoDB." |
| Strong opinions, loosely held | Have a defensible view but update quickly with evidence | "Come in with strong opinions, loosely held." |
| Challenge the premise | Question the assumption behind a proposed solution | "Before discussing Kafka, I want to challenge the premise that this needs to be asynchronous." |
| Work backward | Start from the desired outcome, then derive implementation | "Work backward from the latency SLO rather than starting with technology." |
Mechanisms and measurement
| Term | Meaning in engineering | Example |
|---|---|---|
| Mechanism | Repeatable process that reliably produces an outcome | "Weekly review isn't enough; what mechanism prevents this from recurring?" |
| Operating mechanism | Recurring organizational process for ensuring execution | "The dashboard isn't the solution; the weekly review is the operating mechanism." |
| Closed loop | System where outcomes feed back into future decisions | "Recommendation evaluation needs a closed loop from impressions to model changes." |
| Leading indicator | Metric that predicts future results | "Review queue length is a leading indicator of cycle-time deterioration." |
| Lagging indicator | Metric showing the outcome after it happened | "Availability is mostly a lagging indicator." |
| Goodhart's law | Once a measure becomes a target, people optimize the measure | "Velocity became a target and immediately stopped being useful." |
| Proxy metric | Measurable approximation of the thing you actually care about | "PR count is a weak proxy metric for engineering productivity." |
| Vanity metric | Impressive-looking metric with little decision value | "Lines of code is mostly a vanity metric." |
| Counter-metric / guardrail metric | Metric ensuring one objective isn't optimized at another's expense | "CTR is the target metric; unsubscribe rate is a guardrail." |
Quantitative register
| Term | Meaning in engineering | Example |
|---|---|---|
| p50 / p90 / p99 | Percentiles: the value below which that share of outcomes falls | "p50 is eight weeks, p90 is ten. I'll commit to ten." |
| Monte Carlo | Simulate many trials to get a distribution when you can't derive one | "I ran a Monte Carlo over the three-point estimates; the sum of most-likely lands at p1." |
| Order of magnitude | A factor of ten; the precision most estimates deserve | "That's an order of magnitude more traffic than we're provisioned for." |
| Within noise | Smaller than the variation between two measurements of the same thing | "That's within noise; our A/A variation is 3% and this is 2%." |
| Directionally correct | Right about the sign, unreliable about the magnitude | "The model is directionally correct but I wouldn't plan against the absolute number." |
| Material | Large enough to change a decision | "It's statistically significant but not material." |