§ 100
Braintrust (Notes Without Authority)
Feedback from people who can overrule the owner gets defended against rather than used; peers with no power to impose a fix can be candid, and the owner can afford to hear them.
Keep in mind
Give candid notes, and leave the fix to the owner
What to do
In a design or RFC review, let reviewers name problems and their suspected causes but not dictate the fix, and leave the decision with the author, who answers each point in writing. Fill the room with peers who have built something similar, not the manager who rates the author. Where a mistake would land on others (security, data loss, an irreversible migration), keep a blocking approval, but run it as a separate step from the advisory review.
Why it happens
Someone deep in a piece of work loses perspective and needs outside eyes. But if those eyes can impose a fix, the owner comes in to defend the work instead of to hear about it, and reviewers drift from naming the problem to dictating their own solution. Taking away the veto changes both sides: reviewers can be blunt because nothing they say is binding, and the owner can listen because nothing they hear is an order. The owner, who still answers for the result and knows constraints the room does not, then chooses the remedy.
When it stops applying
Review as a Gate: where a blind spot's cost lands on someone other than the owner (a security hole, lost data, another team's pager), advice that can be ignored is not enough, and a reviewer has to be able to block.
Source
Ed Catmull, quoted in "Spark Creativity with These Tips from Pixar's President" (First Round Review, 2015) — "the Braintrust should have no authority", so that the person responsible "would never have to come into the room in a defensive posture"; the practice is set out at length in Ed Catmull with Amy Wallace, Creativity, Inc. (Random House, 2014). The counter-force is the approver model of code review, where "the reviewer can certainly deny approval" (Google, The Standard of Code Review).
Read the sourceCite this
Hammurabi, § 100, “Braintrust (Notes Without Authority).” https://kanywst.github.io/hammurabi/laws/braintrust/
BibTeX
@misc{hammurabi-braintrust,
title = {Braintrust (Notes Without Authority)},
author = {{Hammurabi contributors}},
note = {Hammurabi, § 100},
url = {https://kanywst.github.io/hammurabi/laws/braintrust/}
}Related laws
- 86Approve What Improves Code HealthHolding every change to a standard of perfection makes review slow, and slow review leaves the codebase worse, not better.
- 74Blameless PostmortemPunishing the person nearest a failure teaches people to hide what they did.
- 32Curse of KnowledgeOnce you know something, you can't easily imagine what it's like not to know it.
- 116Psychological SafetyA team learns when its members admit mistakes, ask for help and disagree, and they do that far more readily when they believe it is safe to.