Disagreeing and committing, honestly

Disagree and commit is a decision protocol with two halves. While a decision is still open, you argue your position as completely as you can; once the decision is made, you execute it fully, even when it went against you. Andy Grove ran Intel on it and described it in High Output Management, and Jeff Bezos gave it its most quoted modern form in his 2016 shareholder letter. I run my own teams on it because I have sat through the alternatives: a team that needs consensus on every contested call decides at the speed of its most reluctant member, and a team where lost arguments continue in hallways never really finishes deciding anything. Grove also attached an execution standard that deserves precise quoting, because it demands more than the version that usually circulates: if you disagree with a decision, work especially hard to implement it well, so that if it fails, everyone knows it failed because the idea was bad, and not because you dragged your feet.

All of this prepares you for the meeting where you lose. Most of the practice, though, happens outside that meeting: there is work before it in how you disagree, work after it in what you tell your own team on Monday, and a full half of it that belongs to the person who won. A written decision record sits under every part of the practice: it holds the dissent and the decision in the same place, so neither side has to rely on memory or on trust.

Disagree in writing, before the decision

The disagree half has a deadline. If you believe a forming decision is wrong and it touches work you are answerable for, make the complete case once, in writing, addressed to the person who will decide, before the decision is made. Fragments do not accumulate into a case: a concern raised in one standup and a worried message to a peer register as mood, and a decider cannot weigh a mood.

On one team this looks like a senior engineer who believes a platform migration is premature writing a one-page objection two days before the decision review, instead of spreading the same worry across three standups. The page gets read, the risk gets named out loud in the review, and whatever happens next, nobody can claim the objection was invented after the fact.

The deadline matters because an objection that first surfaces after the failure changes no decision; it only shifts blame, whatever its author intended. And making a full case is still participation in the decision: if what you need is to decline the work outright, you are refusing the work rather than losing an argument, and refusal carries its own costs.

Put the loss on record, then stop

When the decision goes against you, ask for two lines in the decision record, who raised which risk and why the decision proceeds anyway, and then stop writing. Two lines preserve the position; a page attached to the decision reads as a dissenting opinion, and a dissenting opinion invites the team to keep the argument alive under the surface of the commit.

For the migration above, the record might say: "Objection raised: p99 latency risk on the new stack. Proceeding because platform consolidation matters more this year." The whole objection is two sentences, with no appendix arguing the case a second time.

The record also frees you to commit without swallowing anything. Once the objection exists in writing you can stop performing it; your position survives on paper while your energy goes into the decision. It also depersonalizes whatever comes later: if the named risk materializes, the question reopens on what the record says, and nobody has to make it a confrontation to reopen it.

Commit at Grove's standard

Grove's standard covers all of it: staff the work properly and speak for the decision in public with nothing in your tone that separates you from it. Execute at that standard and a failure teaches something, because if the idea was bad, full-conviction execution proves it was bad, and the team changes course on evidence.

Malicious compliance can look like this from a distance: the work gets done to the letter while the judgment and initiative that would make it succeed stay parked, and the eventual failure gets treated as vindication. A half-committed failure vindicates nobody, because the team cannot tell whether the idea or the execution died first, and finding that out costs you the quarter.

Bezos's own example in the 2016 letter deserves a close look at who commits in it. He disagreed with his team about greenlighting an Amazon Studios production, told them so, and then wrote that he hoped it would become the most watched thing they had ever made. The most famous disagree-and-commit story on record is a boss committing to the team's idea, and the demand runs up the hierarchy as naturally as it runs down.

Carry it down without the wink

Losing the argument often comes with a delivery job attached, because the people who report to you were not in the room, and to them you are the "they" who decides things. Say once, plainly, that you argued for another path and lost to a reasonable case, and that you now back the call. After that sentence the decision is yours to represent, in roadmap reviews and one-on-ones, wherever your team probes to find out whether you mean it.

Picture two managers delivering the same roadmap cut. One says "leadership decided this, there was nothing I could do," which costs nothing that afternoon and quietly reclassifies every future decision from above as an imposition. The other says "I argued to keep the project, I lost to a reasonable case about focus, and here is what we are doing now." Six months later, the second manager can still ask the team to commit to a call they dislike, because the team has watched their manager do exactly that.

The wink is the raised eyebrow that says "I fought this," and it is cheap; I have wanted to reach for it more than once. It buys a moment of solidarity at the price of teaching the team that decisions made above them are illegitimate, and the team will eventually apply that lesson to your own calls.

Name what reopens the question

Committing to a decision you doubt gets easier when the commitment has a condition attached: at commit time, agree on what evidence would reopen the question, and write it next to the decision. Until that evidence arrives nobody relitigates, including you; when it arrives, reopening the question is administration rather than rebellion.

The migration record can carry one more clause: "Revisit if p99 latency exceeds 300ms two months after cutover." If the clause fires, the question reopens on numbers. The engineer who objected does not need to rebuild the case, the decider does not need to absorb an I-told-you-so, and the rest of the team watches a decision get revisited without anyone spending credibility to force it.

The clause protects against drift in both directions: without it, a doubter can relitigate every sprint under the banner of new data, and a loyal committer can ride a dead decision long past the point where the evidence has spoken, out of respect for a commitment that was never meant to be permanent.

The decider's half of the contract

The commit demand is only legitimate when the disagree half was real, and that puts three debts on whoever makes the call. The person who lost is owed:

• evidence that their dissent was heard, which the two lines in the record provide
• a clean decision with the reason attached
• zero penalty for having disagreed, so the next contested question comes to them as readily as this one did

A team that watches someone object in writing and lose, and then stay trusted, learns more about whether dissent is safe than any value statement can teach them.

You can hear the difference in how the phrase gets used. A decider who says "disagree and commit" in the same meeting where the option first surfaced is closing a discussion that never happened, and the team learns that the phrase means stop talking. A decider who says "write down your objections tonight, we decide tomorrow, and then we all commit" is running the same protocol with the first half intact.

That half of the contract is easier to describe than to run, and I will not claim I get it right every time a decision is mine.

When commit is not available

Disagree and commit covers bets, the architecture choices and roadmap tradeoffs that can turn out wrong without anyone being wronged. It does not cover being asked to mislead a customer, misrepresent data, ship something you believe harms users, or cross a line you named in advance as non-negotiable. Those get escalation or refusal, said in those words, and commit language can launder a great deal if you let it: a commitment that requires crossing one of those lines should never have been made. I write my own short list of non-negotiables before the quarter starts, because a line drawn in the moment, under pressure, tends to move.