Disagree and commit: what engineers owe after the call

The phrase is best known as half of one of Amazon's leadership principles, "Have Backbone; Disagree and Commit." Read as two halves, it is two obligations, owed at two different times. Before the call, you owe the decision your real objection, in a form it can weigh. After the call, you owe it your work.

Each common failure drops one half. Shut up and do it drops the first: the objection never reaches the person deciding, so the decision is made without it. Silent sabotage drops the second: the objection is never raised, so it gets settled in the code instead. The engineer in the composite managed to drop both while looking like he had done neither. He nodded in the review, and his disagreement went into commits.

Before the Room explains why this is so common without needing anyone to be dishonest: "A person can mean their yes in the review and find, at the keyboard, that they do not want to pay for it." Alignment does not show up in the meeting. It shows up in the review comments, the exception requests and the implementation choices where the cost lands.

Commit also does not mean three things people often read into it. It does not mean you now agree. It does not mean pretending you changed your mind. And it does not mean the decision is permanent. You keep the right to be right. What you give up is the option to win by attrition.

The disagree half has its own discipline, and most of it happens before the decision closes.

Choose the hill. Before the Room is blunt that credibility is spent each time you use it: "Credibility buys the right to be heard on a decision. It does not buy the decision, and each use changes what the next one buys." It adds a line from the debrief room I would underline: "In the debriefs I have sat in, the engineer who describes picking one hill a quarter has tended to read as more senior than the one who describes flagging everything he disagrees with." A naming convention is not the hill. A data boundary that costs a year if it is wrong might be.

Label it. The book's operating rule for technical objections is that each one names the failure mode, cites the evidence, and labels itself a blocker or a preference. "This will not survive production" does not qualify. Its example of one that does: "This retry path has no idempotency guard, so a duplicate delivery double-charges the customer, and that is a blocker." The label matters later, too: a preference you lost is easy to commit to, and a blocker you lost needs one of the routes in the section on when not to commit.

Say what would change your mind. The book's test for a technical objection, as opposed to an incentive in disguise, is that the objector can name the evidence that would make them comfortable: a test, a benchmark, a rollback drill. Say yours out loud before the decision. If the call goes the other way, that same sentence becomes your reopen criterion.

Say it to the owner, in time. An objection raised for the first time in the meeting lands as an ambush; raised a week earlier, the same objection is a design input. Find out first who actually decides, because the room often does not. If you are not sure whose call it is, the article on saying no to a project as a tech lead walks through the five decision roles.

It also helps to know what kind of disagreement you are in, because they are settled by different things. Controlled Change, my book on mobile architecture, sorts them into six kinds:

Two of those rows end in someone else's decision. If your disagreement is about priorities or resources, the most you can do is put it clearly in front of the owner. After that, commit is the only honest option left.

The hardest version is the disagreement with someone who is better than you in a narrow domain: the staff engineer on platform whose rollback opinions you are not senior enough to overrule, or the strongest engineer on the team who has caught bugs nobody else saw. Before the Room opens its conflict chapter with the second case. When he says, in the flat voice he uses for settled things, that an approach will not survive production, the room goes quiet and the decision goes his way, even though the tech lead thinks the alternative might be better.

The book names two ways to get this wrong. Defer, so his opinion closes conversations it should only inform. Or decide he is difficult, discount his judgment and route around him. The move between them is to keep his influence and remove the private veto: his objection gets the same rule as everyone's, failure mode, evidence, blocker or preference. Then use reversibility. If the choice can be undone cheaply, make it, watch the measure you agreed on, and reverse it if the measure turns. Where the path touches money or customer data, do not experiment on customers: replay recorded production traffic through both designs in staging, or run the alternative in shadow.

The line the book gives for that conversation is worth having ready:

"You have flagged this as a blocker. Walk me through the failure mode and the evidence. If it is a real correctness bug we fix it now. If it is a preference, we replay last week's production traffic through both designs in staging, compare duplicate deliveries and latency, and go with what the replay shows."

Whatever the replay leaves unsettled goes on the record with the evidence that would prove him right. The book's summary of the rule is the best short definition of disagree and commit I know: "The rule takes away his ability to end a decision by status, and leaves him every chance to be right."

Sometimes the evidence goes the other way, and the disagreement ends with you committing to their view. In the book's event-bus case, an engineer reads the consuming team's ordering objection as turf protection, runs the replay the lead asked for, and finds out-of-order events for a small but steady share of accounts. He tells the reviewers he misread the objection, withdraws the proposal as written, and records per-account ordering as a constraint with the lead as the person who signs off on it. That is also disagree and commit, done well.

A decision held only in memory belongs to whoever remembers it most forcefully. A disagreement held only in memory is worse: it leaks back into the code, because nothing says where it is allowed to go. The object that holds both is an architecture decision record with reopen criteria, appendix template 6 in Before the Room. Most of its ten fields, filled in for the composite's analytics SDK:

The template has no row for the dissent itself, so I add one: who argued for which option, what they predicted, and the evidence that would prove them right. Controlled Change says why in one line: "Record dissent. It may become valuable when conditions change." For the engineer in the composite, that row would read something like: argued for a hashed email; predicts attribution for logged-in users breaks across devices; would be proven right by an attribution gap with numbers, or by vendor processing terms that meet the criteria.

Two details make the record work. First, it says who rules on whether a challenge meets the bar: the decider it names, not the challenger and not whoever posts next. Second, it changes what disagreement can do. In the book's words, the record "separates "I have new evidence" from "I still do not like the outcome," and only the first gets a hearing."

Here is the part the meeting-focused advice leaves out. Before the Room defines divergence as named behaviors, written down before anyone is frustrated, and then says plainly what is not on the list: "Disagreeing is not on the list." The demand is narrower: "bring your evidence through the reopen path, and implement the active decision until that evidence changes it." Turned into a checklist for the person who lost the call:

The last row is the one people underrate. In the book's scope chapter, after the sponsor picks the option the tech lead argued against, engineering effort moves to that option's weak points: the load test pulled forward, the flag rehearsed in production. That is what commit looks like when you still think the other option was better. The full scene is in how to say no to a project as a tech lead.

On mobile, the cost of not committing is unusually hard to take back. A workaround merged on Tuesday ships in a binary, and a binary on people's phones cannot be recalled, only replaced through another review. Data already sent to a vendor does not come back with the next release either. A quiet disagreement on a server can be rolled back. On a phone, it ships to users.

Commit only works if the way back in is real. Reopen criteria are the specific evidence, written down before the disagreement, that would justify changing the decision. In the book's words, written down in advance they "give the dissenter a legitimate path to be right."

Two failure modes sit on either side. If the criteria are vague, any new opinion qualifies, and the template's own warning applies: "Name evidence, not discomfort." If they are so high that real evidence never clears them, the book's boundary is exact: the record "stops protecting the decision and starts freezing a mistake." A useful check when you write them: would the person who lost the argument agree that, if this evidence appeared, they should win?

When you are the one bringing evidence, the path is short. Put it on the record and take it to the owner the record names. If the numbers show attribution is broken badly enough to matter, the decision reopens on the merits. If what you have is the same argument stated more firmly, it does not.

The sign that a team has this right is not silence. The book says the signal you want is not the absence of dissent: "You want better dissent: earlier, more specific, and on the record." A decision system is working when the engineer who disagrees brings the vendor's new processing terms instead of a hashed email in a pull request, because the door was faster to walk through than the workaround was to hide.

Disagree and commit assumes the decision was within someone's right to make, and that the risk it carries can be accepted by the person accepting it. Before the Room names where that stops, in its note on method: "some decisions belong above you, including risks that no one at your level can rightly accept." Its stop list puts the most common case in one line: "No one you can reach can rightly accept the risk, as with regulatory, safety, security or privacy constraints. Hold the line."

Holding the line is not refusing quietly and not winning in the code. It is one of these, done in the open:

• The risk is not anyone's to accept at this level. A security finding, a privacy commitment, a safety or regulatory constraint. Say you cannot commit to that part, say why, and take it to the owner who can accept or refuse it. The article on escalating as a tech lead covers how to send that so it reads as a decision, not a fight.
• The decision is irreversible and the risk is being absorbed into a word. The book's boundary for the high-performer chapter applies: letting evidence settle it later works only for reversible decisions, and "a one-way door has to be resolved before the commitment." Commit to the reversible part, and ask for the rest in writing. The book's line: "If the business wants it anyway, that is your call and I will support it, but I need it written down as an accepted irreversible risk, not absorbed into the word launch."
• The harm is already live. In the composite, the app is sending identifiers the review rejected. The book's reset is explicit that "A live privacy problem cannot wait for a release": the decision owner stops the sending the same day, by a server-side or remote-config switch or by having the vendor drop the field. Committing to a decision never means keeping a live harm running until the next build.
• The objection turns out to be right. If the evidence shows the decision is wrong, the stop list says it in six words: "Change the plan, not the person." That is the reopen path working, not a failure to commit.
• Raising it gets punished. If honest evidence is met with retaliation, a better argument is not the tool. The book's advice is to protect yourself first: document, seek formal support, and weigh moving teams or leaving. It also states that it describes practices, not legal or employment advice.

Most decisions you disagree with are none of these. They are reversible, inside someone's authority, and wrong only in your judgment. For those, Controlled Change gives the posture I would copy into any disagreement with a decision above you: "The architect's position to leadership is not "I disagree." It is "I will deliver this, and here are the conditions under which it stays reversible."" And the rule for where to spend your resistance: "Spend effort in proportion to irreversibility, not in proportion to how much you dislike the decision."

These are mine, not the book's, built from its pieces. The weak versions are familiar: "Fine, it's your call," which commits to nothing and records nothing, and "Let's see how it goes," which quietly schedules an "I told you so."

When you lost the call and will commit, said at the moment it closes:

"I still think the hashed email is the better option, because attribution for logged-in users breaks across devices without it. It is the privacy lead's decision, and I will build the install-ID path. Please put my objection in the record with the evidence that would reopen it: an attribution gap with numbers, or vendor terms that meet the criteria."

When you cannot commit to one part:

"I can commit to everything except sending search text to the vendor. That is a privacy risk that is not ours to accept in this room. I am taking it to the privacy lead today, and I will build everything that does not depend on it in the meantime."

Both sentences do the same three things: they name the disagreement once, they name who decides, and they say what happens next. Neither one leaves the disagreement anywhere it can leak into a pull request.

If you are the tech lead and the drift has already happened, the book's reset moves the conversation from personality back to the decision. It starts with this:

"We have a closed decision here, and I want to keep new evidence separate from repeated disagreement. If you have evidence that meets the reopen criteria, let us put it on the record and take it to the owner. If you do not, the implementation needs to follow the decision."

Then it names the pattern without heat, makes the next behavior specific, and sends the data already shared with the vendor to the privacy owner on its own track. If the divergence continues, the escalation is clean, because it rests on a behavior and a record rather than frustration, and it asks for one of two decisions: reopen because the evidence meets the bar, or enforce because the divergence continues without it. Either is fine. What the book refuses is the third state, "neither reopened nor enforced," with data leaving the app while everyone stays polite.

The same section asks a question every lead should ask after a reset: why did six weeks of pull requests carrying a hashed email and a forwarding wrapper pass code review without anyone checking them against the record? Commit is not only the dissenter's job. Reviewers who approve the workaround are committing to it too.

Before the Room's level lines for these two chapters read as a self-check:

From the hiring side, the question "tell me about a time you disagreed with a decision" sorts along the same lines. The answers that read as more senior say what the disagreement was about, who decided, what went on the record, what they did in the weeks after, and what would have reopened it. The answers that read as less senior end at the meeting, either with "and they came round" or with "and I was proven right." For the wider behavioral round, see the article on influence without authority, which covers the moves that come before the call.

What does disagree and commit mean for engineers?

Two obligations, at two different times. Before the decision closes, you owe the decision owner your real objection, once, labelled as a blocker or a preference, with the evidence that would change your mind. After it closes, you owe the decision your work: your pull requests, your code reviews and your status reports follow the active decision until new evidence reopens it through an agreed path.

Is disagree and commit the same as shut up and do it?

No. Shut up and do it drops the first half: the objection is never weighed. Disagree and commit keeps it, on the record, next to the decision, with the evidence that would reopen the call. What commit removes is the option to keep fighting the decision through workarounds, side threads and slow compliance. You keep every chance to be right; you lose the chance to win by attrition.

How do you document a disagreement on a technical decision?

In the decision record, not in a private message. Write the decision as a choice, the one owner, the options rejected and why, the consequences accepted on purpose, and reopen criteria that name evidence, not discomfort. Then add the dissent: who argued for which option, what they predicted, and the evidence that would prove them right. That turns your objection into a test the team can run later.

When should you not disagree and commit?

When the risk is one nobody you can reach can rightly accept: safety, security, privacy or regulatory constraints. When the decision is irreversible and its risk is being absorbed into a word like launch instead of accepted in writing by a named owner. When the harm is already live, such as data leaving the app that the review rejected. In those cases you hold the line openly and take it to the owner who can decide, rather than committing or sabotaging.

Can you reopen a decision after you committed to it?

Yes, through the reopen criteria. If you bring evidence that meets them, the decision owner reopens it on the merits. If you bring the same argument again, it does not get a hearing. Committing never means the decision is permanent; it means the way back in is evidence, not persistence.