Skip to main content

Disagree-and-Commit, Managing Up

What This Concept Is​

Disagree and commit (Bezos's formulation, long predating Amazon) is a working norm: once a decision is made, people who disagreed with it execute as if they had agreed. The disagreement is recorded in writing; the execution is full-strength. No sabotage, no passive resistance, no "I told you so" if it fails.

The norm has two directions:

  • Downwards. A manager or lead makes a decision the team disagrees with. The team commits anyway.
  • Upwards. A senior IC disagrees with a decision coming from management. They state the disagreement clearly, in writing, and then commit to executing.

Managing up is the broader practice: keeping your manager and their manager informed, escalating before problems are fires, and making decisions at the right altitude rather than deferring all decisions upward.

Why It Matters Here​

Staff+ engineers frequently disagree with decisions they cannot veto. How they handle those disagreements determines whether they remain trusted.

Three common failure modes:

  • Silent dissent. You say nothing in the meeting, then slow-walk the implementation. Trust is lost when the dissent becomes visible via missed deadlines.
  • Loud dissent after the decision. You argue in the meeting, lose, then keep arguing in Slack for weeks. This signals that decisions are not final, which breaks the team's ability to move.
  • Sabotage disguised as thoroughness. "I'll do it, but first I need to document all the risks." Endless qualification becomes de facto obstruction.

The disagree-and-commit move is harder than any of the three but is the only one compatible with trust over time.

Concrete Example​

Decision: "We will rewrite the Orders service in Go rather than Rust, despite the team's preference for Rust."

Silent dissent. You said nothing in the meeting. Two months later, the rewrite is behind schedule; in retrospective you mention "the language choice was always a risk." Your manager flags you for passive resistance.

Post-hoc loud dissent. You write an angry memo, argue in Slack for three weeks, add caveats to every status update. The team cannot move. Your manager now owns both the original decision and the ongoing fight. Trust is burned.

Disagree and commit. In the meeting, you say: "I disagree. I think Rust is a better fit because of [specific reasons]. If Go is the decision, I'll execute, and here are the three risks we should track." You write a short memo: I disagreed with the Go decision for these reasons; I am executing in Go; if [observable trigger] happens by [date], I will reopen. Two quarters later, the rewrite ships. You were wrong; you say so. Or it failed at the trigger you named; the team reopens with credibility intact either way.

The Commit Memo: A Template​

A disagree-and-commit memo does not need to be long. A workable template:

Subject: Commit memo - Go rewrite of Orders service

Decision: We are proceeding with Go (not Rust) for the Orders service rewrite, as decided in the Apr 10 design review.

I disagreed because:

  1. Rust's compile-time safety fits our correctness-critical serialization layer.
  2. The team has stronger Rust ownership culture from previous projects.
  3. Our existing Go services have a recurring class of concurrency bugs I expected to repeat.

I understand the opposing argument: Hiring and operational familiarity outweigh the correctness advantage for a service this size; Go's ecosystem for our dependency graph is stronger; organization-wide observability tooling has first-class Go support.

I am executing at full strength. My tech lead and I reviewed the decision and I have no reservation about delivery.

Reopen condition: If we observe >3 production incidents attributable to serialization correctness between v1 ship and end of Q3, I will propose reconvening.

  • Signed, [name], [date]

The memo is 200 words. Writing it takes an hour. The value compounds for as long as the decision holds, and if the decision is wrong, the memo is how the learning survives the blame reflex.

Common Confusion / Misconception​

"Disagree and commit means suppressing disagreement." The opposite. The disagreement is stated clearly, in writing, while the decision is being made. What is being suppressed is post-decision sabotage, not the argument.

"Disagree and commit means I always have to commit." No. If the decision is unethical, illegal, or against your stated values, "commit" is not the right move. Leave or escalate instead. Disagree-and-commit is a working norm, not a surrender clause.

"Managing up means telling your manager what they want to hear." The opposite. Managing up means telling your manager what they need to hear, early, in a form they can act on. A manager surprised by a problem is a manager you are not managing up to.

"Escalating is a failure." Escalating late is a failure. Escalating with a clear proposed decision and a named tradeoff is one of the highest-leverage moves a Staff+ engineer makes.

"Writing down the disagreement is career-limiting." The opposite, if the writing is professional and specific. A clearly-stated disagreement with a named trigger signals judgment; silent compliance signals nothing and is often penalized later when the decision turns out wrong.

"If I was right, I should say so at the retrospective." Vindication is the one place most senior engineers damage trust they spent months building. A silent "the memo is on the wiki, dated, go read it" outperforms every variant of "I told you so." The memo is the record; your role in the retro is to help the team learn, not to re-litigate authorship.

"Disagree-and-commit is a way to avoid conflict." It is the opposite: it requires the conflict to happen on record, before the decision. Teams that skip the conflict and move directly to "we all agree" produce false consensus that shatters on first contact with reality.

How To Use It​

Disagree-and-commit move in practice:

  1. State the disagreement before the decision. Specific, written, with the strongest version of your side. Not vague concerns; named tradeoffs.
  2. Name what would make you change your mind. "I would accept this if [observable condition]."
  3. If the decision still goes against you, commit in writing. Short memo: "I disagreed for X, Y, Z; I am executing; I will flag if [trigger] occurs."
  4. Execute at full strength. Slower than full-strength reads as sabotage whether or not it is.
  5. Name the outcome later. If you were wrong, say so. If you were right, do not gloat - point to the memo and move on.

Check Yourself​

  1. What is the difference between disagreeing silently and disagreeing-and-committing?
  2. When is "commit" not the right move?
  3. Why is writing the disagreement down important even when you are losing the argument?

Managing Up: Three Habits That Compound​

Disagree-and-commit is a specific move; managing up is the broader practice of keeping your manager effective on your behalf. Three habits compound over a year:

  • Weekly written update. 5 bullet points every Friday: what shipped, what's blocked, what's coming, one risk, one ask. Your manager reads it in 90 seconds and shows up to your 1:1 already briefed. This is leverage for both of you.
  • Escalate with a proposed decision, not a problem. "The dual-write rollout has a latency regression; I propose we extend the window by two weeks and re-test. Alternative: cut now and accept the regression. Deciding by Thursday, reply 'veto' if you disagree." This gives your manager something to approve, which is faster than something to figure out.
  • Surface bad news early, in writing. A slip your manager hears about first from someone else is a trust injury; a slip your manager sees in a Monday-morning memo from you is a plan in motion. The delta is two days and you own the framing.

None of these are sycophantic. They are how a senior IC makes it easy for their manager to be a good sponsor, and they pay off most at promo time, when the manager has to recall specific examples on your behalf.

Mini Drill or Application​

Find a decision in the last 90 days that you disagreed with but executed anyway (most senior engineers can name at least two). Write the disagree-and-commit memo you should have written then:

  • the strongest version of your disagreement, in 150 words
  • the strongest version of the opposing argument, in 150 words (this is the hard part)
  • the observable trigger that would make you reopen the decision
  • a one-sentence commit statement

Then compare the outcome. Were you right? Were you wrong? Did the memo survive the quarter or get refuted? The retrospective is the learning.

Extension: pick a current open disagreement. Write the memo now, before the decision is made. Circulate it to the decision-maker. Note how the conversation changes when the disagreement is on paper rather than in your head. This is the single most uncomfortable drill in the module and the one that most reliably upgrades the engineer doing it.

Transfer / Where This Shows Up Later​

Disagree-and-commit and managing-up are operating norms under which every other leadership concept runs:

  • Strategy (Concepts 4-6). Strategies are made through a series of disagree-and-commit moments. A strategy doc without recorded disagreements read as false consensus; a roadmap's Now list is often where the commits live.
  • Written-first (Concept 7). The commit memo is itself a written-first artifact. Cultures that do not write down disagreements lose them.
  • Stakeholder mapping (Concept 8). The Accountable stakeholder is who the commit is addressed to; the other stakeholders see that you disagreed and still executed, which is how you earn their future trust.
  • Communication (Concepts 10-12). Delivering disagreement well is audience-aware: the exec version is a three-sentence BLUF; the peer version is a 1-page memo; the junior version is a teaching moment.
  • Feedback (Concept 14). The SBI model is how disagreement is delivered without becoming identity feedback. "When the decision meeting ended without a written trigger (S), the team proceeded without a shared view of what would make us revisit (B), and three weeks later we argued about whether the bad outcome counted as the trigger (I)."
  • Personal strategy (Concept 15). Your own annual strategy is an exercise in managing up to yourself - naming what you will disagree with in the year to come (e.g., taking on manager work, over-committing to projects).
  • Across Semester 8 and S10. M2-M4 all surface decisions the senior IC will disagree with; disagree-and-commit is the protocol for continuing to ship while those disagreements are alive. Semester 10 M5 returns to it as a career-scale habit.

Read This Only If Stuck​