The research a lead should be able to cite

What it is

A small set of studies and named effects that do real work in a leadership conversation, because they convert an opinion into a finding. "I think we should pair the target metric with a counter-metric" is a preference. "Goodhart's law says the metric will stop measuring what it measured the moment it becomes a target, so I want a counter-metric" is an argument, and the second one survives contact with a director who disagrees.

The other reason to know them precisely is that most of them are misquoted in a specific, consistent way, and knowing the actual finding is a fast and non-obnoxious way to demonstrate that you have read the source rather than the summary. Each entry below states what the study found and, where it differs, what people claim it found.

Don't be confused: citing research is not the same as deferring to it. The failure mode is using a study as an authority that ends discussion ("Aristotle says psychological safety, so we are doing psychological safety"), which is both bad reasoning and unpersuasive. Use the finding to name a mechanism, then argue about your specific situation. The study tells you what generally predicts what; it does not tell you what is true of your team, and the person across the table knows that.

The problem it solves

Leadership arguments are usually decided by seniority, volume or persistence, because nobody has anything better. Having a small stock of well-understood evidence changes what the argument is about: instead of two opinions about whether individual productivity dashboards work, you have a named, decades-old result about what happens to any metric under target pressure, and the burden shifts to the person who wants to build the dashboard anyway.

In an interview it does a narrower job. It signals that your views came from somewhere, which is the difference between a candidate with opinions and a candidate with a model.

Mechanics

Goodhart's law, and its sharper cousin

What it says. Charles Goodhart, writing about UK monetary policy in 1975: any observed statistical regularity will collapse once pressure is placed on it for control purposes. Marilyn Strathern's 1997 restatement is the one everyone quotes: "When a measure becomes a target, it ceases to be a good measure."

Why it is true rather than merely cynical is the part worth being able to explain. A metric is a proxy: it correlates with the thing you care about across the range of behaviours people were exhibiting when you measured the correlation. Making it a target expands the behaviour space to include actions taken because of the target, and those actions were not in the sample the correlation came from. The correlation is not being broken by dishonesty; it is being broken by optimisation. That is why it happens even with people acting in complete good faith, which is the misconception to head off: Goodhart is not a claim about gaming, it is a claim about correlations under selection pressure.

Campbell's law (Donald Campbell, 1979) is the social-science version and is sharper for organisational use: the more a quantitative indicator is used for social decision-making, the more it will be subject to corruption pressures, and the more it will distort the processes it was meant to monitor. Note the second clause, which Goodhart's formulation lacks: the measurement damages the activity, not just the measurement. Measuring code review turnaround does not merely produce a useless number; it produces worse reviews.

The practical consequence, and what to say in an interview: never gate on a single metric. Pair the target with a counter-metric chosen specifically to catch the cheapest way to cheat. Deployment frequency pairs with change failure rate. Click-through rate pairs with unsubscribe rate. Review turnaround pairs with defects found in review. If you cannot name the cheapest way to cheat your metric, you are not ready to make it a target.

Google's Project Oxygen: managers matter, and the ranking is the finding

What it was. Google began Project Oxygen in 2008 partly expecting to show that managers did not matter much, which is worth knowing because it is the opposite of a study designed to find its conclusion. The data said otherwise: teams under highly rated managers performed better on turnover, satisfaction and performance. The project then worked backwards to identify what those managers actually did, producing eight behaviours, expanded to ten in 2018.

The finding people miss is the ordering. In the original list, "has key technical skills that help advise the team" ranked last. Being a good coach ranked first. That is not a claim that technical skill is unimportant, and misreading it that way is the standard error: Google was ranking within a population of managers who all had substantial technical skill, so the result says technical depth is a threshold rather than a differentiator. Above the threshold, coaching, empowering without micromanaging and clear communication distinguish people; below it, nothing else helps. That distinction between a threshold variable and a differentiating variable is the useful transferable idea, and it applies well beyond management.

The 2018 additions are also revealing about what changed as Google grew: "collaborates across Google" and "is a strong decision maker". Both are about the boundary of the team rather than its interior, which is the shift that happens to every organisation past a certain size.

Project Aristotle: how the team works beats who is on it

What it was. Google studied around 180 teams from 2012, looking for the composition that predicted effectiveness: seniority mix, personality types, tenure, colocation, whether people socialised outside work. None of it predicted much. What predicted effectiveness was how the team behaved, and five dynamics emerged, with the first far more important than the rest: psychological safety, dependability, structure and clarity, meaning, and impact.

The uncomfortable implication for a lead is that assembling talent is not the job. You can staff a team with excellent engineers and get mediocre output, and the mechanism is observable: in a team without safety, people do not report problems early, do not admit confusion, do not disagree with the loudest person, and do not try things that might fail. Each of those is individually rational and collectively fatal.

Psychological safety is Amy Edmondson's construct, from her 1999 study of hospital teams, and its origin story is the best thing about it. She expected better teams to make fewer errors. The data showed better teams reported more errors. The measurement was of reported errors, and what varied was not the error rate but whether people were willing to say so. That is the single most useful thing to know about the concept, because it tells you what to look for: not the absence of problems but the presence of people mentioning them. A team with no reported incidents is not a safe team, it is an opaque one.

Normalization of deviance: how safe teams drift

What it is. Diane Vaughan's term, from The Challenger Launch Decision (1996). The O-rings on the shuttle boosters had shown erosion on previous flights. Erosion was outside the original design specification, but it had never caused a failure, so over successive flights it was progressively reclassified as an acceptable, expected condition. The launch decision was not made by people knowingly accepting a catastrophic risk. It was made by people whose definition of "acceptable" had migrated, one uneventful flight at a time.

Vaughan's finding is that this is a normal organisational process, not a moral failure, which is what makes it dangerous: every occurrence of the deviation without consequence is evidence, and the evidence genuinely does accumulate in the direction of "this is fine". The engineering translations are everywhere: manual production changes that have never gone wrong, an alert that has been firing for months, a test that everyone knows to re-run, a permission that was temporary in March. The diagnostic question, and it is a good one to ask in an interview: "what are we currently doing that we would not approve if we were proposing it today?"

The counter-mechanism is to make deviation visible and effortful rather than to exhort people to care: a break-glass procedure that pages someone, an exception with an expiry date, an alert that fails loudly rather than degrading. Anything that requires ongoing vigilance will lose to this process, because this process is what vigilance decays into.

Conway's law, and the deliberate inverse

What it says. Melvin Conway, 1968: organisations design systems that mirror their own communication structures. It is an observation about information flow, not a metaphor: two modules can only have a clean interface if the people building them can negotiate one, and the interface will be as good as that conversation.

The lead-relevant version is the inverse manoeuvre, sometimes called the inverse Conway manoeuvre: since architecture will follow team structure anyway, change the team structure to get the architecture you want. This is the intellectual foundation of Team Topologies, and it is the reason "should we split this team" and "should we split this service" are the same question asked twice. When someone proposes a service decomposition that does not match how the teams communicate, Conway's law predicts it will be reabsorbed, and it usually is.

Brooks's law and the second-system effect

What it says. Fred Brooks, The Mythical Man-Month, 1975: adding people to a late software project makes it later. The mechanism matters more than the slogan, because the slogan is false as stated and Brooks knew it. Two costs: new people consume the time of existing people to ramp up, and communication paths grow as $n(n-1)/2$, so the coordination overhead grows quadratically while capacity grows linearly. Adding people helps when work is genuinely partitionable and the ramp-up is short; it hurts when the work is sequential and the context is deep. So the useful form is: adding people to a late project makes it later unless the remaining work partitions cleanly and the new people need little context, which is rarely true late in a project and is exactly why it is late.

The second-system effect, from the same book, is the tendency of an architect's second system to be over-engineered, because they finally get to build everything they had to leave out of the first one. It is the most accurate published description of what a rewrite looks like from the inside, and it is worth naming when a team proposes one.

DORA, Westrum, and what culture predicts

What DORA found, across a decade of surveys and the Accelerate book: four measures (deployment frequency, lead time for changes, change failure rate, time to restore) separate high from low performers, and crucially throughput and stability move together rather than trading off. That result is the empirical refutation of "we ship slowly because we care about quality", and it is worth citing precisely because that sentence is otherwise unanswerable.

Westrum's typology (Ron Westrum, 2004, from safety research in healthcare and aviation) classifies organisations by how information flows: pathological (power-oriented, information is hoarded, messengers are shot), bureaucratic (rule-oriented, information moves through channels, responsibility is narrow), and generative (performance-oriented, information is actively sought, messengers are trained, failure leads to inquiry). DORA found that Westrum-generative culture predicts software delivery performance, which gives you a measured link from culture to output, and the measurement is behavioural rather than attitudinal. The single best diagnostic question from this framework: what happens to the person who brings bad news?

A few named effects worth having ready

Chesterton's fence. Do not remove a fence until you know why it was put there. The reason it is a good principle rather than a conservative one: the argument "I do not see why this exists" is evidence about you, not about the fence. The lead application is to require an explanation before a deletion, and the counter-application is that it is frequently used to defend things nobody can explain, in which case the correct response is a time-boxed investigation, not indefinite preservation.

Hyrum's law. With a sufficient number of users, every observable behaviour of your system will be depended on by somebody, regardless of what the contract says. Named for Hyrum Wright at Google. It is why "that was never part of the API" is a true statement that does not help you, and it is the argument for expand-and-contract migrations over clean breaks.

Gall's law. A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched into working; you have to start over with a working simple system. This is the most compact available argument against big-bang rewrites and for walking skeletons.

Survivorship bias, in its best-documented form: Abraham Wald, working for the Statistical Research Group in the Second World War, was asked where to add armour to bombers based on the distribution of bullet holes in returning aircraft. His answer was to armour the places with no holes, because the sample consisted only of planes that came back, so damage in those areas was evidently survivable. The engineering translations are constant: your latency percentiles exclude the requests that timed out, your user research excludes the users who left, and your postmortems cover the incidents you detected.

The planning fallacy (Kahneman and Tversky, 1979): people underestimate task duration even when they know that similar tasks have historically taken longer, and the effect survives being told about it. The operational counter is reference class forecasting, popularised by Bent Flyvbjerg: instead of estimating this project from its parts, find the distribution of outcomes for similar past projects and place this one in it. In engineering terms, "how long did our last three migrations take" beats any bottom-up estimate, and it is the honest answer to a date question. See the estimation page for what to do with that distribution once you have it.

Parkinson's law of triviality (1957), the origin of "bikeshedding": a committee spends a few minutes approving a nuclear reactor and hours on the design of the bike shed, because everyone can form an opinion about a bike shed. The lead value is diagnostic: the amount of discussion a decision attracts is inversely related to its importance, so a long argument is a signal to check whether the topic deserves it.

Worked example

A concrete case where citing the right result changes an outcome, drawn from the most common version of this conversation.

The situation. A director wants a dashboard of per-engineer PR counts and review turnaround, visible to management, "so we can see who needs support".

The weak objection: "I don't think individual metrics are a good idea." True, and it loses, because it is one opinion against another and the director has more authority.

The stronger version, using three of the results above: "I want the visibility too, and I think this specific design will destroy the thing it measures. Three reasons. Goodhart: the moment PR count is visible to management it stops correlating with output, because people will split PRs, and the split is individually rational so we cannot fix it by telling people not to. Campbell's stronger version says the measurement will also degrade the underlying activity, and here that means review quality, because the fastest way to improve turnaround is to approve without reading. And Aristotle's finding is that psychological safety is the strongest predictor of team effectiveness, so a management-visible individual ranking is a direct tax on the thing that predicts our output. What I think you actually want is to know where work is getting stuck, which is a team-level flow question, so let me give you cycle time broken down by stage, plus review queue depth, which shows exactly the same problem without creating a leaderboard. If a specific person is struggling, that shows up in a one-to-one and I will tell you."

Same position, different outcome, and the difference is that the second version names mechanisms, offers the thing the director actually wanted, and does not require anyone to lose an argument.

Production evidence

The findings above are themselves the production evidence, which is unusual for this book, so the useful thing to add is where they have been adopted rather than merely published. Google turned Project Oxygen into its manager feedback survey and its manager training, and published the behaviour list along with the fact that they revised it in 2018, which is the more credible detail: a framework that gets updated is one somebody is still using. DORA's four metrics have been adopted widely enough to appear as built-in dashboards in GitHub, GitLab and Azure DevOps, which is the strongest available signal that the measures survived contact with practice. Team Topologies' cognitive-load-first team design has been adopted publicly by several large engineering organisations as the basis for platform team charters.

The honest caveat to state if pressed: most of this literature is correlational and survey-based. DORA's data comes from self-selected respondents answering self-reported questions, and its causal claims rest on structural equation modelling rather than experiment. That is a real limitation and naming it before your interviewer does is worth more than the citation itself.

The debate

Is Goodhart's law an argument against measurement? No, and the version of it that gets deployed as one is worth pushing back on. It is an argument against unpaired metrics under target pressure. Metrics used for observation rather than for targets are far less affected, which is why "we measure this but do not target it" is a coherent and useful position. The correct conclusion is to measure more things and target fewer of them, and to be explicit about which is which. The failure I would name in an interview: teams that read Goodhart, concluded that measurement is futile, and now run on anecdote, which is strictly worse.

Does psychological safety mean avoiding conflict? It means the opposite, and this is the most consequential misreading of Aristotle in circulation. Edmondson's construct is the shared belief that the team is safe for interpersonal risk-taking: disagreeing, admitting error, asking an obvious question, challenging a senior person. A conflict-averse team scores low on the thing, not high. The observable proxy is not harmony, it is whether junior people publicly disagree with senior people, and a lead who reads safety as niceness produces a team where nobody says anything, which is the pathology the research was describing.

Should you cite this material in an interview at all? There is a real risk of sounding like someone who reads management books instead of leading teams, and I have seen candidates overrun by it. My position: cite the mechanism, attribute briefly, and spend most of your words on your own situation. "That is Goodhart's law, and concretely what happened on my team was..." works. Three paragraphs on Project Aristotle without a single example from your own experience does not, because it answers a question about reading rather than about doing. One attribution per answer is plenty.

Follow-up Q&A

If throughput and stability move together, why do so many organisations believe they trade off? Because the trade-off is real at a fixed level of capability and disappears only when capability changes. If your deployment is manual and your test suite is unreliable, shipping more often genuinely does break more, and everyone in that organisation has direct evidence for the trade-off. DORA's finding is that the practices removing the trade-off (automated deployment, trunk-based development, small batches, comprehensive automated testing) are available and are what high performers have. So the honest statement is not "there is no trade-off", it is "the trade-off is a symptom of a fixable condition", and saying it that way is much more persuasive to someone whose lived experience is the trade-off.

How would you actually measure psychological safety on your team? Edmondson has a validated seven-item survey instrument and you can use it, but for a team of eight the survey is often worse than observation because anonymity is not credible at that size. Behavioural proxies I would use: the ratio of questions to statements in design reviews, whether anyone below staff level has publicly disagreed with anyone above it in the last month, whether incident timelines contain the phrase "I did not understand", and how long it takes for bad news to reach you compared with how long the person had known. Ask for the anecdote rather than the score: "tell me about the last time you told someone here that they were wrong" is one question and it produces more information than an instrument.

What is the difference between normalization of deviance and reasonable risk acceptance? Documentation and expiry. Accepting a risk deliberately, with the reasoning written down, a named owner and a review date, is engineering judgement. The same risk accepted implicitly, because it has not bitten yet and nobody re-examined it, is normalization of deviance. The distinguishing test is whether anyone could tell you today why the deviation is acceptable, and if the answer is "we have always done it that way", the drift has already happened. This is why exceptions should expire by default; an expiry date converts a silent drift into a scheduled decision.

Conway's law says architecture follows org structure. What if I cannot change the org? Then predict rather than fight. If two teams in different reporting lines with no shared rituals own two halves of a system, the interface between them will be poor and will accrete workarounds, and you should design accordingly: put a hard, versioned, explicitly owned contract at that boundary and invest in it disproportionately, because that is where the organisational fracture will express itself. The realistic lead move when you cannot restructure is to add the missing communication path (a shared on-call, a joint design review, one person with a foot in both) rather than to pretend the boundary is not there.

A team of ten is proposing to split into two teams of five. What does the research say? Team Topologies' answer is to split on cognitive load rather than on component boundaries: each team should own a domain it can hold in its head end to end, which usually means splitting along the flow of change rather than along technical layers. Conway predicts the architecture will follow whichever split you pick, so pick the split whose implied architecture you want. Brooks warns that the transition itself has a cost and that the communication paths between the two teams are now a permanent tax, so the split should be justified by an ongoing gain and not by a one-time frustration. The question I would ask the team: after the split, what change would require both teams to coordinate? If the answer is "most of them", the boundary is wrong.

Which of these would you drop if you had to keep only three? Goodhart, because it applies to every metric conversation you will ever have. Psychological safety with Edmondson's reported-errors finding, because it tells you what to look at rather than merely what to want. And normalization of deviance, because it is the only one on the list that describes a failure mode you cannot see from inside without a deliberate mechanism, which makes it the one where knowing about it changes the most.

Common misconceptions

"Project Oxygen showed technical skills do not matter for managers." It showed they ranked last within a population of technically strong managers. It is a threshold, not an irrelevance, and the popular reading inverts the finding.

"Project Aristotle found that psychological safety is all that matters." It found five factors and ranked safety first. Dependability, structure and clarity, meaning and impact were also predictive, and a team with high safety and no clarity is pleasant and ineffective.

"Brooks's law means never add people." It means adding people to a late project with unpartitionable work and deep context requirements is counterproductive. Growing a team between projects, or adding to genuinely parallel work, is normal and fine.

"Goodhart's law is about people gaming metrics." It is about correlations breaking under optimisation pressure, which happens without any intent to game. This matters practically: a solution based on catching cheaters will not work, because there are no cheaters.

"Chesterton's fence means do not change things." It means find out why first. Chesterton's own formulation explicitly permits removing the fence once you can explain it, and the principle is regularly used to defend the indefensible by people who have not tried to find out.

Interview delivery note

The sentence pattern that works: name the effect, state the mechanism in one clause, then go immediately to your own experience. "That is normalization of deviance: each time the deviation does not cause a failure, it becomes evidence that it is safe. Concretely, on my team we had a manual step in the release that everyone knew about, and the way I found it was that a new engineer asked why we did it, which is the only reason anyone noticed." Fifteen seconds of theory, then the thing that actually demonstrates you.

The separator between a senior candidate and a lead candidate here is whether the research is used descriptively or prescriptively. A senior candidate quotes the finding. A lead candidate uses it to make a prediction about a specific situation and then says what they would do about the prediction: "Conway's law tells me that boundary will accrete workarounds, so before we commit to the split I want a shared design review between the two teams, because that is the communication path the architecture is going to need whether or not the org chart provides it." That is the difference between having read something and having a model.

The Staff & Team Lead Interview Reference