Disagree and Commit
Disagree once, in writing, before the decision; then build it as if it were yours, and agree in advance what would show which of you was right.
The ask, the obvious response, and how it goes wrong
Every lesson starts where the work starts: someone asked for something, and the first response that comes to mind has a problem.
Once a decision you argued against is made, what do you owe it?
The PM decides to make account creation mandatory before checkout, so the store can send order updates and build a customer list. You think it will lose guest customers. The PM says: "I hear you, but we are doing it. Can you own the build?"
Either keep arguing until the decision changes, or say "fine" and build it — perhaps a little reluctantly — and note in the retro that you did warn everyone.
Arguing after the decision turns every standup into a rerun. The team slows down, and the PM stops bringing you in early because early means arguing.
- Arguing after the decision turns every standup into a rerun. The team slows down, and the PM stops bringing you in early because early means arguing.
- "Fine" with no record means nobody remembers what the concern was. If it turns out right, the lesson is lost in "I told you so"; if it turns out wrong, nobody learns that either.
- Building reluctantly means building badly: the minimum, no measurement, no thought about the edge cases. The feature then fails for reasons unrelated to the decision, and the team learns nothing about accounts at all.
- Without an agreed signal, when orders dip everyone has a story — seasonality, a campaign ending, the new account step — and the argument restarts with opinions instead of numbers.
What is really going on
- Disagree and commit separates two things: the decision, which has an owner, and the quality of execution, which is yours. A wrong decision built well produces a clear answer quickly. A wrong decision built badly produces noise that protects it.
- Disagreement is most useful once, before the decision, in writing. Written, the owner can read it properly, weigh it without an audience, and a future team can find it (Decision Records).
- Naming what would prove you right turns an opinion into a test. "If new-customer conversion drops by more than two points in the first two weeks, we switch to optional accounts" — agreed before launch — takes the ego out of the review.
- Commit means building it as if it were your idea: instrumented so the test can be read, behind a flag so reversal is cheap, with the failure paths thought through (Feature Flags as Product Tools).
- It has limits. Disagreements about legality, safety, security or ethics are not preferences, and they escalate rather than commit.
Two things that get conflated
The decision and the execution are different things with different owners. The PM owns whether accounts are mandatory. You own whether mandatory accounts are built well enough that, in two weeks, the number means something.
Most bad versions of this come from merging the two: arguing about the decision through the execution ("I will do the minimum and we will see"), or letting the execution silence the disagreement ("I am building it, so I should not say anything").
Disagreeing in writing
A written disagreement is shorter and fairer than a spoken one. It can be read without an audience, it does not depend on who talks faster, and it survives into the decision record. Keep it to a few lines: the concern, the evidence, the alternative, and what would change your mind.
The PM is leaning towards mandatory accounts. You think it will cost first-time customers. The decision is tomorrow.
"I really do not think forcing accounts is a good idea, customers hate creating accounts. Everyone knows guest checkout converts better. Can we talk about it?"
"Before tomorrow — my concern with mandatory accounts: most first-time customers currently check out as guests, and the account step adds a password in the middle of paying. Alternative: offer the account on the confirmation page, one click, pre-filled. You would still get the customer list, a bit slower. If you go with mandatory, I will build it properly and would like us to agree now what we watch — I suggest new-customer conversion, reviewed after two weeks."
1### Dissent — mandatory accounts at checkout2 3**Concern:** first-time customers who check out as guests will drop off at the password step.4**Evidence:** share of new-customer orders placed as guest last quarter; support tickets about forgotten passwords.5**Alternative:** offer an account on the confirmation page, pre-filled.6**What would change my mind:** new-customer conversion within two points of baseline after two weeks.7**Status:** decided mandatory (PM, 2 March). I am committed and own the build.The last line matters as much as the first. It records that the disagreement was heard and the commitment was made, so nobody reads it later as sabotage or as a grudge.
Naming what would prove you right
The single most useful sentence in a disagreement is the one that says what evidence would settle it. Agreed before launch, it turns the post-launch review from "who was right" into "what does the number say", and it protects both of you: the PM from endless relitigating, you from being ignored.
Pick one signal that the disagreement is actually about, a threshold, and a date. If the traffic is too low to read the threshold honestly, say that too, and agree what you will do with an inconclusive result.
The PM has decided on mandatory accounts. You are in the one-to-one straight after.
"OK, we will do it your way. Let us see how it goes."
"OK — mandatory it is, and I will build it properly. Can we agree what we look at? I suggest new-customer conversion, compared with the four weeks before. If it drops by more than two points by the 14th, we switch to accounts on the confirmation page; I will have that behind a flag so it is a config change. If it holds, I will say so in the channel."
When not to commit
Disagree and commit is for decisions reasonable people can differ on. Some disagreements are not of that kind, and committing to them is not professionalism — it is passing the risk to the customer.
You disagreed, the owner decided the other way. What now?
when It is a product or technical judgement call, the owner heard your concern, and a signal can tell you both later.
cost You build something you believe is wrong, well, and wait for the number.
when Something the owner did not know has since appeared — a support spike, a legal note, a test result.
cost Uses up goodwill if the evidence is thin; do it once, in writing, with the new fact first.
when The concern is legal, security, safety or ethics — for example, the account step would store data the privacy notice does not cover.
cost Strains the relationship with the owner, which is why it is reserved for concerns that are not preferences.
How to do it
Most important first.
- Disagree once, in writing, to the decision owner, before the decision: the concern, the evidence, the alternative, and what would change your mind.
- When the decision lands, say it explicitly: "I disagree, and I am committed. Here is what I would like us to watch."
- Agree the signal, the threshold and the date you will look — before launch, with the owner (Guardrail Metrics).
- Build it properly: instrument the signal first, ship behind a flag, and make switching back a configuration change rather than a sprint (Instrumentation First).
- On the agreed date, report the number neutrally, whichever way it went, and recommend what the threshold said you would.
- If the concern is legal, safety, security or ethics, escalate to whoever owns that risk instead of committing.
How to explain the decision
The sentences, the order, and what to lead with — for someone who did not make the call.
- To the owner, before the decision: "I think mandatory accounts will cost us first-time customers — most of our new customers check out as guests, and the account step adds a password. I would rather offer an account after the purchase. If you still want mandatory, I will build it, and I would like us to agree what we watch."
- To the team, once decided: "We are making accounts mandatory. I argued for optional; the PM's call is mandatory and I am building it properly. We will look at new-customer conversion on the 14th, and the flag lets us switch back in minutes if we need to."
- On the agreed date, if you were right: "New-customer conversion dropped from 3.1% to 2.4%, past the two-point line we agreed. I suggest we switch to post-purchase accounts; the flag is ready."
- On the agreed date, if you were wrong: "Conversion held within the range we agreed. My concern did not show up; mandatory accounts stays, and we have a customer list growing faster than before."
- "Why do you want a threshold — do you not trust the decision?" I trust it enough to build it well. The threshold is so none of us has to argue about it in three weeks.
- "You said you were committed, so stop bringing it up." I will. I will bring it up once more, on the 14th, with the number we agreed on.
- "We do not have time to instrument it." Then we will not know whether it worked, and the next argument about accounts will be opinions again. The event is an afternoon.
What can go wrong
- Fake commitment: "I am committed" in the meeting, then doing the minimum and letting the feature fail by neglect.
- Committing without disagreeing: saying nothing, building it, and resenting it. The owner never got the information you had.
- Moving the goalposts: after launch, picking a different metric that happens to prove you right.
- Committing to something you should have escalated, because "disagree and commit" felt like the professional move.
- Gloating when you were right, which guarantees you will not be listened to next time.
- "Commit means stop thinking about it." Commit means execution quality. You still watch the number and bring it back on the agreed date.
- "Disagree and commit means the most senior person wins." It means the owner decides. Sometimes the owner is you, and then you are the one who has to hear the disagreement properly.
- "If I am proven right, I won." The owner made a reasonable call with the information available; together you now know something you did not. Treat it that way or you will not be asked again.
Knowing whether it worked
- Disagreements appear in the decision doc before the meeting, not in the corridor after it.
- Post-launch reviews start from the threshold agreed beforehand, not from fresh opinions.
- You are brought into decisions earlier — the sign that your disagreement is treated as useful rather than as friction.
- Standups stop relitigating decisions that were made last week.
- On a small team it is one conversation. In a larger organisation the owner is often not in the room where you work, so the disagreement has to be written to reach them at all.
- With enough traffic, "what would prove me right" becomes a proper experiment with a control group (Reading an Experiment Honestly). With little traffic, it is a before-and-after with an honest caveat.
- At senior levels the roles swap more often: you are the owner, and the disagreement is someone else's. The same rules apply in the other direction — ask for it in writing, and agree the signal with them.
- You will sometimes spend weeks building something you believe is wrong. That is the price of a team that can decide and move.
- Writing the disagreement down puts you on record, including when you turn out to be wrong.
- The threshold may be unreadable with the traffic you have. Then the test is inconclusive and you have to live with the decision without proof either way.
Where this applies
Product advice is context-sensitive. These labels say what each claim is specific to, and where a different stage, team or product would differ.
- GENERALApplies to product and technical decisions with a clear owner. It does not apply to legal, safety, security or ethical concerns, where the right move is escalation to whoever owns that risk, not commitment.
- ROLE-SPECIFICA junior engineer disagrees mostly to their lead or PM and commits to their call. A senior or staff engineer is often the owner, and the harder half becomes inviting disagreement and agreeing the signal with someone who thinks they are wrong.
Where the depth lives
This domain teaches the product-side judgement and hands the mechanism off.