Have Backbone, Disagree and Commit
And how to deal with stubborn, uninformed people
Have backbone, disagree and commit. Amazon’s leadership principles include a line that sounds wise until you’ve lived it.
Push hard for what you believe, then once the decision is made, commit fully even if you disagree. It sounds mature. In practice it quietly answers a much harder question while pretending not to.
Who pays when the decision turns out wrong?
Should we let people make mistakes?
There’s a real argument for letting people fail. Mistakes teach faster than warnings do. A person who pushes a bad architecture into production and watches it buckle under load learns something a code review comment never delivers. If you intervene every time you smell a bad decision, you raise people who can’t smell anything themselves.
But that argument only holds when the cost of the mistake lands on the person who made it. Most of the time it doesn’t.
The senior engineer who says “I told you so” six months later isn’t the one who stayed until midnight migrating off the system that got rushed to production. The product manager who insisted on the feature isn’t the one fielding support tickets two quarters later. The mistake teaches a lesson, just rarely to the person who needed to learn it.
So the question isn’t really “should people be allowed to fail.” It’s “who is the textbook in this story, and who is the lab subject.”
Having backbone
This is where backbone earns its name. Speaking up before the decision, clearly and on the record, is the only leverage you have to stop being the lab subject in someone else’s lesson. Not because you’re certain you’re right. Most disagreements aren’t about certainty, they’re about risk you can see and the other person can’t.
If you’re not 100% sure, say so anyway. Certainty was never the bar. The bar is, did you say enough that, when it goes wrong, the failure mode was visible in advance.
What happens after
Decisions get made. Some of them are bad. Then someone has to clean up.
Cleanup is never evenly distributed. It falls on whoever is closest to the system, which is usually the person who raised the concern in the first place, now doing unpaid penance for someone else’s confidence.
This is the part the leadership principle conveniently skips. “Disagree and commit” describes the meeting. It says nothing about the three months after, spent paying down debt that someone else borrowed against your time.
Dealing with stubborn, uninformed people
The hardest version of this isn’t disagreeing with a sharp person who happens to be wrong. That’s normal work. It’s disagreeing with someone who is both confident and uninformed, and who outranks the argument by sheer force of will.
It is psychologically draining in a specific way. You’re not just losing an argument. You’re pre-living the cleanup before it happens, doing the math on hours you haven’t lost yet.
You can let them make the mistake. That part is easy, you just stop pushing. The actual question is narrower and uglier: will you be the one who works the extra hours to fix it? Will you be the one who carries the technical debt nobody else remembers borrowing?
If the answer is yes, “letting them learn” isn’t a development strategy. It’s you volunteering to be collateral.
What I see at work
Here’s the part that should bother people more than it does. Stubborn people get ahead. Not the people who are right, the people who refuse to budge regardless of whether they’re right.
Confidence reads as competence to anyone who isn’t close enough to check the work. A person who never says “I’m not sure” looks more promotable than a person who flags risk honestly, even when the second person’s track record is better. Organizations reward the appearance of conviction because it’s legible. They rarely audit whether the conviction was earned.
So the stubborn survive and the careful absorb the cost of their mistakes quietly, which teaches the organization exactly the wrong lesson: stubbornness works.
What to do instead
Don’t confuse “disagree and commit” with “go silent and absorb.” The principle works when disagreement is genuinely heard and the commitment is a real choice, not a forced one.
A few things that actually help:
Put your disagreement in writing before the decision, not after. Memory is a terrible witness, and an email is not.
Ask for the specific failure condition. “What would have to be true for this to go wrong?” forces the stubborn person to engage with the mechanism, not just the outcome.
Refuse to be the default owner of someone else’s bad call. If you didn’t make the decision, say clearly who is accountable for the outcome before you start fixing it.
Pick your battles by blast radius, not by how annoying it is to be ignored. Save backbone for decisions that are expensive to reverse.
If the pattern repeats, that’s not a decision problem anymore. That’s a person or a structure problem, and no amount of better disagreeing fixes it.
Disagree and commit is a fine principle for a single decision made in good faith by people who will actually update when they’re wrong. It is a terrible substitute for a culture that lets the same people make the same expensive mistakes, on someone else’s time, again and again.