Beyond "Agree to Disagree"

A guide to making disagreement a competitive advantage

I'm on vacation this week, and to avoid the cardinal rule of not talking about vacations (it's bad writing because you're not here with me, though trust me, I'm enjoying some sun), I thought I would broach another topic.

People often ask me what made Amazon different from other tech companies. While there are many answers to this question, one thing stands out: the ability to productively disagree.

I don't mean the polite disagreements you might see in most workplaces. I'm talking about the kind of fundamental, passionate disagreements that make people uncomfortable but ultimately lead to better solutions.

Why is this important? Because in a world where there are big problems at work and no straightforward solutions, it's natural that a bunch of smart people will disagree and be opinionated.

In fact, it would be a bit odd if there weren't differences in opinion.

The critical piece, though, is that you don't want the loudest or most stubborn person to win. Or the person with the highest rank.

But the thing you definitely don't want is that because conflict is uncomfortable that people just choose not to engage. That's the least effective behavior.

Enter Amazon's leadership principal, Have Backbone; Disagree and Commit.

Here's what it looked like in practice:

Picture this: A team meeting where two senior engineers are in a heated debate about the architecture of a critical system. One is advocating for a complete rebuild, arguing that the current design won't scale. The other is pushing back hard, insisting that a tactical evolution would be less risky and achieve the same goals.

The discussion gets intense. Voices are raised. Diagrams are drawn and vigorously crossed out. To an outsider, it might look like a fight. But what's actually happening is that two people who deeply care about doing the right thing are pushing each other to think harder, to question assumptions, to find blind spots.

How is this going to end up? Who knows. What matters is that both engineers remain genuinely open to being convinced, even while passionately defending their positions.

If they reach an impasse, they might pull in a neutral third-party to pressure-test both approaches, or escalate to their senior leadership for a decision. Sometimes they'll even run a small proof-of-concept or to gather metrics to validate assumptions. But the specific resolution method isn't what's important–what matters is that once a direction is chosen, both people will throw their full weight behind making it successful.

The key is that both parties know this isn't personal. It's about finding the best solution. And when a decision is finally made, both will fully commit to making it successful, even if it wasn't their preferred approach.

Now, I often hear people say "Oh, that's just how Amazon operates–everyone argues all the time and the most-senior person, who is also likely the most stubborn, wins."

But this misses the point entirely. The key isn't the arguing. It's the foundation of mutual respect and shared mission that makes productive disagreement possible.

Let's look at how these anti-patterns show up when people miss this understanding:

The "Peace at All Costs" Failure - This is when someone says "I'm sure either approach would work fine" when they actually believe one approach would be a disaster. They're prioritizing short-term harmony over long-term success. I've seen entire projects fail because critical concerns went unvoiced. Peace isn't actually kept, it's just that the conflict happens later, when it's more expensive to fix.

Instead: Frame your concerns as risk mitigation. Say "I want to raise some specific concerns about scalability/reliability/maintenance that we should address now." This keeps the discussion focused on the work, not the conflict.

The "Hierarchy Wins" Failure - "Well, if that's what the principal engineer wants..." This is giving up your responsibility to advocate for what you believe is right. Yes, sometimes more senior people have better insight. But I've seen plenty of junior engineers spot critical flaws that senior folks missed. Your job isn't to agree–it's to help find the best solution.

Instead: Lead with curiosity. Ask specific questions about how the proposed solution handles your concerns. This shows respect while still advocating for your position: "I understand the approach you're suggesting. Could we talk through how it handles [specific scenario]?"

The "Endless Debate" Failure - Some teams never reach resolution because they don't know how to disagree and commit. They keep rehashing the same points, hoping for consensus that will never come. Meanwhile, nothing gets built. Perfect is the enemy of good, and momentum matters.

Instead: Set clear decision timelines upfront. Say "Let's debate this fully for the next week, then make a call by Friday." This creates urgency while still allowing space for thorough discussion.

The "Passive Aggressive Agreement" Failure - This might be the worst one. It looks like agreement in the room, but then you hear the real opinions in side conversations. Or worse, someone agrees but then subtly undermines the implementation. This erodes trust and makes future disagreements even harder to navigate.

Instead: Voice concerns directly in the moment, but be explicit about your commitment to the final decision: "I want to raise these specific concerns, but if we decide to move forward, you'll have my full support in making this successful."

So how do you foster productive disagreement in your own teams? Here are three practical tips that have served me well:

1. Choose your battles wisely - Ask yourself: "Is this the hill I want to die on?" If the wrong choice will be quickly apparent and easily reversible, maybe it's better to note your concerns and commit to the other approach. Not every disagreement needs to be a drawn-out battle. Sometimes the fastest way to prove a point is to let a sub-optimal decision play out.

2. Keep score thoughtfully - If you end up being right, store that receipt. When similar disagreements arise in the future, being able to say "Remember when we faced a similar situation with Project X?" carries immense weight. This isn't about gloating. It's about building a track record of good judgment. And when you're wrong? Own it openly. Send a quick note to the group: "Hey, I was wrong about X-the approach we chose is working better than I expected because [specific reason]. Good call on this one." This isn't just good sportsmanship–it builds trust, shows intellectual honesty, and makes your future disagreements more credible. Being right a lot isn't about having a perfect record; it's about consistently improving your judgment through both wins and losses.

3. Scale the debate appropriately - Start small. Two people disagreeing thoughtfully is often more productive than ten people arguing chaotically. If you're not making progress, gradually expand the circle: add more data, seek additional expert opinions, or pull in relevant stakeholders. But be strategic. Adding everyone with an opinion isn't collaboration–it's annoying. Think of it like a graduated response: start focused, and only expand the scope of the discussion when necessary.

The reality is that the best solutions often emerge from productive tension. If everyone on your team always agrees, you're probably missing opportunities to make your work better. Don't shy away from disagreement–just make sure it's the kind that makes everyone stronger.

Let me know in the comments about a truly difficult difference in opinion. I'd love to hear your stories.