How To Win More Arguments At Work
Hint: avoid arguing! Instead, get better at guiding teams to the best answers... which may not be *your* answers.
TL;DR - Disagreement is common in all workplaces, including tech companies. But arguing is usually an inefficient and interpersonally risky way to resolve those disagreements. Instead, PMs can help teams learn to resolve disagreement efficiently, usually without fighting. This post explains a set of practical techniques to speed up decisionmaking while minimizing strife.
Paul Graham, in his popular essay How to Argue, defines a taxonomy of arguments: from Level 0 (“Name-calling”) to Level 6 which is an evidence-backed refutation of the opposing argument’s central point. Paul’s intended audience is probably engineers—especially young ones—who are smart and opinionated but who may not have strong interpersonal skills. For those folks, it’s reasonable advice.
But it’s not ideal advice. My experience leading PM for many tech startups has taught me that arguing isn’t the best way to resolve disagreements. Unlike low-EQ engineers, selfish salespeople, harried executives, and grumpy support reps, Product Managers are often the most socially adept members of the team. This post explains how you can use EQ and savvy to resolve most disagreements, usually without arguing.
Lessons from Open Source
A surprising source of resolving-disagreement skills has been my weird (for a PM) hobby: I contribute to open source projects. For example, in my spare time I’m a member of ECMA TC39: the standards committee for the JavaScript language, where I’ve got a PM-like role co-leading a team designing JavaScript’s new “Temporal” built-in date and time API.
Some open-source projects are contentious, like the Linux kernel where BDFL Linus Torvalds will call contributors stupid. But most open-source projects I’ve worked on aren’t like that, because (also unlike the Linux kernel) most open source projects really need help! Dissing contributors is a sure way to quickly end up with no contributors.
Instead, my open source work has been a stress test of influence without authority skills, because there’s no boss, no BDFL, no P&L, and no deadlines. The only way to make progress is to convince everyone else. Given these constraints, the only way to make fast progress without fracturing is to figure out how to resolve disagreements without demotivating contributors.
The best open-source teams develop a collaborative problem-solving style that allows teams—including senior engineers and others with strong opinions—to efficiently resolve hundreds of disagreements per year with very little zero-sum, adversarial argument.
In my “day job” leading PM for B2B startups, I’ve tried to apply the lessons I’ve learned from my open-source work. The rest of this post explains specific techniques for how to resolve disagreements quickly with minimal rancor.
A caveat: resolving disagreements without fighting is a difficult art to master. I’ve been practicing these techniques for many years and I still don’t always get them right. So don’t be discouraged; just keep at it and success will come.
Don’t argue; instead, resolve disagreements
My overall advice in this post is to shift your mental framing from “win arguments” to “help teams resolve disagreement”. Your goal should be to be a catalyst to help your colleagues make good decisions, which is not the same as winning arguments!
A focus on “winning” an argument is problematic because it requires that someone must lose. Humans hate losing! When people lose an argument, they can be unhappy, and sometimes bitter or resentful. This hurts team productivity and cohesion, and may make it harder to resolve future disagreements. Getting to a good result while minimizing squabbling isn’t just politeness; it’s a hard-nosed business strategy to avoid hurt feelings that will reduce your team’s long-term productivity.
Instead of resolving disagreements via zero-sum fights, I’ve had better outcomes by recognizing that arguing is just one way (often a sub-optimal way) to figure out solutions. A better way is to reframe your job-to-be-done—to yourself and others—as “resolving disagreement”, which is inherently a team sport. Instead of someone winning and someone losing, you’re all working together to figure out a good solution.
The rest of this post outlines techniques that I’ve used—and helped my colleagues learn and practice—to put this “efficiently resolve disagreements” goal into practice.
Listen before disagreeing
Asking questions before disagreeing is important, but even when you’re not asking questions it’s helpful to wait to communicate your opinions until you hear what other people think. Why?
If you listen to them, they’ll listen to you!
Their arguments may convince you, in which case they never need to know that you previously held a suboptimal opinion.
If you’re senior, hearing your opinion first may cause others to change their opinions simply to appease you, instead of presenting their best ideas.
Having more information about opposing points of view lets you build a more convincing case, and gives you more time to build it.
Before disagreeing, ask questions
Ask questions before expressing disagreement! Over the years I’ve tried to train myself to have a “question reflex”: whenever I disagree with someone at work, I try to make the first words out of my mouth be questions to learn more about their point of view.
Asking questions has practical benefits:
Many disagreements are actually misunderstandings. You might end up agreeing with others’ positions once you understand them better.
Even if you don’t fully agree, deeply understanding the other side may expose a synthesis or compromise solution that lets you both achieve your goals.
Asking questions makes it clear that you’re investing time to engage with and deeply understand others’ positions. This makes it more likely that they’ll give your opinions the same respect.
When you later present your own opinions, you can frame them in concepts and language that your colleagues used, so that you don’t require them to work as hard to understand—and hopefully agree—with your position.
If you agree with part of others’ position, you can narrow the scope of the disagreement. Smaller arguments are easier to resolve.
Yes, and…
Instead of saying no or stating disagreement, it’s often helpful to adopt the “Yes, and…” communication strategy that’s borrowed from improv comedy. If you can frame your opinion as an extension of someone else’s ideas instead of a refutation, then your own opinion is more likely to be accepted.
Most humans (especially people who haven’t read this post! 😀) view disagreement as a threat. After someone knows you disagree, they may solidify their positions or become defensive. But if it sounds to them like you’re on board with their idea, then you’ll have an easier time getting their support.
For example, imagine that your sales team is demanding that you provide them with a product roadmap that they can share with a potential customer. You know (perhaps because you read my post about handling customer feedback!) that you don’t want to do this. But instead of telling the salesperson “Sorry, we don’t share roadmaps”, instead you can say “I’m so glad you’re thinking about this. Who’s the customer and what are their interests? I can help you craft some talking points about what we’re considering to build next, but without committing to specific dates so that we can have flexibility to change things around later.” This isn’t exactly what your salesperson asked for, but you’re likely to get better results because you’re engaging with their suggestion and extending it, rather than rejecting it.
Emphasize agreement first
Many humans tend to focus on where they disagree more than where they agree. I especially see this behavior in engineers, accountants, and others whose jobs require them to pay more attention to fixing broken things than to celebrating things that work well.
This glass-half-empty, perfectionist habit can be demoralizing to people who do a lot of work on a project and then hear nothing but negative feedback. It can also be demoralizing to people giving that negative feedback, because it’s easy for them get unhappy about relatively small faults.
So what I often do when helping teams navigate disagreement is to first identify where there *is* agreement and to write down those points of agreement before moving on to the (often small) subset of disagreements. Doing this has a few advantages:
It stops people from rejecting a large body of work over a few fixable faults.
It can jolt people out of a negative frame of mind, making subsequent discussions about remaining disagreements more collaborative. And it can build confidence on the team that a solution is within reach, because the disagreement is only a small part of a much larger pool of agreement.
It suggests opportunities for compromise or synthesis by highlighting how relatively small the disagreement is. For example, imagine a mobile app with 10 screens, 9 of which are agreed-upon and one which evokes lots of disagreement. If you spend all your time arguing about #10, then it’s harder to get support for compromises like A/B testing two versions of that one screen.
Some people have trouble taking yes for an answer; they’ll keep nitpicking settled points long after everyone else has already agreed. Writing down points of agreement is a convenient signal that it’s time to move on to the next topic, and if the same topics come up again, you can point back to your list to remind everyone about what’s already settled. It helps calm the trolls!
Make disagreement-resolving meetings boring
I’ve had a lot of success by making resolving disagreement as boring and predictable as possible: more like checking off a shopping list than arguing about something important. The goal is to turn down the emotional temperature and encourage quick resolutions, and nothing does that better than being dull!
So when I call a meeting to resolve disagreements, I’ll typically share my screen and open a document with two sets of bullet points with headings “To Resolve” (usually prepared in advance) and “Decisions”. When I find an area of agreement:
I’ll say: “It sounds like we agree on ________. Does anyone disagree? [Pause, wait 2-3 seconds.] Great, let’s move onto the next topic.”
I’ll delete that bullet from To Resolve, type a short bullet to append to Decisions, and ask “Does this match what we just agreed on? [Pause, wait 2-3 seconds.] Great, let’s move on.”
If anyone mentions the same thing again, I’ll say “We previously agreed that we’d resolve _____ by doing _____. Do you have new info that would cause us to re-open that decision? [Pause, wait 2-3 seconds.] Great, let’s move on.”
This can get repetitive and boring, and that’s the goal: a monotonous walk through bullet points to put attendees in the right frame of mind to unemotionally solve problems and move on.
Vote early and often
Companies are not a democracy. But when the number of opinion-havers in a meeting exceeds 3-4, I’ve found that informal, non-binding voting can be a great way to speed up resolving disagreement.
Assume there’s 3 options that have been presented. You can ask for a quick show of hands for an in-person meeting. But I’ve found it’s actually easier and faster to do voting in writing, usually in shared meeting notes. Here’s one way to do it:
First, list the options and number them
Then everyone types a line in the (shared doc) meeting notes to rank the options in order of their preference, and distinguishing the options that they absolutely are not OK with vs. options that they don’t love but can live with. Optionally they can show notes about why they voted that way.
It could look like this:
Option 1: Show a modal dialog
Option 2: Make a new page
Option 3: Show AI recommendation, with “custom” buttonJG: 2 (clearest UX) > 1 >> 3 (too costly)
PC: 1 > 2, 3
SM: 1, 2 >> 3 (too much technical risk)
KN: 3, 1 > 2
Given the votes above, it’s clear that option 1 is OK with everyone, which might not have been clear if you hadn’t written it all down.
Often, as in this example above, there’s one option that rises to the top: where some people love, no one detests, and others are OK with. This can be a quick resolution.
Of course, sometimes the consensus answer isn’t the best one. As a PM you sometimes need to be sometimes willing to fight for the right answer even when the tide is against you. Sometimes a lowest-common-denominator solution is unacceptable. But in my experience those times are rare; most of the time a fast, good-enough resolution is better.
Lose gracefully
No one likes a sore loser. Also, being branded as a sore loser makes it even harder to prevail next time.
If a decision doesn’t go your way, the best thing you can do to improve your chance of winning the next argument is to disagree and commit: accept the decision as valid and to do your best to support it. Focus on the future. Don’t whine about the past.
On the other hand, if visibly have trouble accepting a decision, it will hurt your standing among your teammates and make it harder to gain support in future decisionmaking.
For example, years ago I joined a startup where a senior executive on the corporate finance team frequently complained about the company’s pricing model. Being new to the company, I assumed this was a recent change and he was still adjusting to it. It turned out that the change was over a year old! He just couldn’t let it go. The decision wasn’t going to be reversed, so by continuing to complain this executive achieved nothing other than making himself look less effective. Why remind your co-workers about an old fight that you lost?
Don’t be a sore winner either
Be chill if your favored opinion is selected. Never gloat! Everyone knows you got what you wanted, so reminding everyone will embitter folks who were on the other side.
Instead, if you downplay the outcome (and your role in it), then it’s a good way to repair the interpersonal rift that can happen when you get your way and others don’t.
A good way to do this is to de-personalize ideas. For example, say “If we’re going with this UX, is it something that Joe can start on next week?” instead of saying “Now that we’re going with my UX idea, could we assign Joe to work on it next week?” Everyone knows it’s your idea; there’s no need to rub it in.
Another good idea is to credit other people and elide yourself. For example: say “I’m glad we’re going with the Support team’s suggestion, because it matches what we heard from our SMB customers” instead of “I’m happy that this idea that Support and I came up with seems to align with SMB feedback”.
Never say “I told you so”
The advice above is especially true when a decision you opposed turned out to be a horrible failure.
Resist the urge to say “I told you so”! Everyone knows your original position, and they will appreciate your magnanimity in not rubbing their face in how wrong they were.
The only semi-exception to “don’t say I told you so” is when a past failure is helpful evidence when making a different decision. This works best if you don’t mention your role in that previous decision. For example, imagine if, over your objections, your CEO pushed your team to ship a big feature on Friday, and the launch was a disaster. The next time she’s asking you to do the same thing, consider saying something like: “Remember last quarter when we shipped a big feature on Friday, the entire team ended up working all weekend to fix it, and our Eng lead threatened to quit if we did it again? I think we risk of repeating that here.”
Don’t fight if you can’t win
Many years ago before remote work was commonplace, I was the only remote employee on my team. In meetings, I quickly noticed that it was nearly impossible to convince people when I was a disembodied voice on a speakerphone. Even if I had a powerful argument and strong evidence, the voice on the phone usually lost.
It’s tempting to let everyone know how unhappy you are with a group’s consensus or a leader’s decision, but in my experience this is ineffective, because the room will tune you out.
So I learned to sense whether the room was open to my idea or not. If “not” I usually quickly conceded or simply kept quiet. Then I’d wait for a more favorable opportunity to discuss it, for example during my trips to HQ or in 1:1s.
The point is this: if you know you’re going to lose an argument, then it’s usually better not to fight at all. I apply this lesson frequently, even when I’m not a voice on the phone.
Note that “don’t fight” doesn’t mean “don’t disagree”. You don’t have to be a pushover. There’s nothing wrong with presenting dissenting opinions in an even-handed way. Just avoid putting emotion and personal credibility into arguments where you’re unlikely to prevail. Save your political capital for times where it really matters.
Be fair; don’t be sneaky
It’s never OK to win arguments under-handedly. Examples of sneaky behaviors to avoid:
Waiting to make a decision until the main proponent of the opposing view is out of the office
Claiming that other people support your idea more strongly than they really do
Massaging data to amplify your position or hiding contradictory evidence
Convincing a senior manager to decide in your favor without giving the opposing side a chance to present their case
Back-channeling to colleagues to convince them to support your idea “as a personal favor” instead of on the merits
It’s OK to put a thumb on the scale in your own favor. It’s not OK to put your whole arm on the scale! The other side will find out and will disrespect you. It’s not worth it. Also, doing underhanded stuff feels icky. Finally, what you should want is for the best ideas to win out. If you have to cheat, then maybe, just maybe, your idea isn’t the best?
“Pre-meet” to ensure high-pressure meetings go your way
If an important decision is coming up in a high-pressure meeting (like an executive-team review), it’s usually smart to meet individually with the participants ahead of time to gauge their opinions. If they have objections to your plan, then you can better understand their concerns (which is much harder to do in a large meeting) and you’ll have time to make changes to your plan to reduce or eliminate those objections.
Your goal should be for the big meeting to be a rubber stamp on what you’ve already worked out 1:1.
Note that this is *not* a violation of the “don’t be sneaky” rule above. Your role is not (only!) to convince people of your position, but rather to have a low-pressure way to build support the honest way: by hearing others’ concerns and feedback and addressing them before the high-pressure meeting goes awry.
This advice doesn’t only apply to high-profile decisionmakers. It’s also good to give peers and juniors a heads-up about an upcoming big decision, because they might be too intimidated to share their feedback with influential managers in the room. Also, if you think they might be surprised or upset at the likely decision, it will really help their morale (and increase their trust in you!) if you give them a low-pressure venue to discuss it beforehand.
Concede small disagreements; only fight for really important things
Reciprocity is central to human group psychology. If one person is perceived to always get their way, everyone else will get resentful. The same psychology works in reverse: if you are generous to someone else, they are more likely to be generous to you later.
For these reasons, I try to intentionally concede as many low-priority disagreements as possible, especially if someone else is strongly in favor of another position. This helps me build a reputation as a team player who’s flexible, reasonable, and generous. So when something really important to me is on the table, and I decide to forcefully push for my position, then I’ll be able to draw on the social capital that I banked by graciously conceding all those other previous times.
I’ve found that this approach works best if you figure out ahead of time what your top priorities are, and you let others know what they are. For example: “I care a lot about A, B, and C, but I’m flexible about almost everything else.” If your teammates respect you and value your agreement, they’ll often work hard to accommodate your “red lines” because of your track record of respecting theirs.
Even when you are clear—to yourself and others—about your top priorities, it helps to scope those priorities to be as narrow as possible. An example from my open-source work for the JavaScript standards committee: after adding a new time-zone-aware API called ZonedDateTime, I worried that our existing unaware-of-time-zones DateTime API would be a source of Daylight Saving Time bugs. So I pushed to rename DateTime to a longer name that wouldn’t seem like the default choice for novices. I told the team that renaming DateTime was a “red line” for me, but I was OK with almost any other longer name. Being flexible made it more likely that my narrowly-scoped priority would be satisfied. Which it was! (The final name was PlainDateTime.)
Sometimes, delay decisions until circumstances are more favorable
If you don’t think you can convince people of your opinion then it may make sense to defer the decision until you have time to think through the options and consult with others. This might be because you don’t have enough evidence or arguments worked out, or because you don’t have enough allies in the room for your opinion to carry the day.
Imagine you’ve scheduled a meeting for Thursday afternoon to hash out a difficult decision. On Wednesday night, you get a text message from a senior colleague—who was a key supporter of your position—saying that they can’t make it. What do you do?
My advice: postpone the meeting if you can. The same advice holds more generally: if you haven’t convinced skeptical stakeholders, then postpone the decision for a while to see if you can win them over. This is especially effective if you’ve followed my advice above to wait to publicly state your opinion until you’ve heard from others.
An example of this strategy literally saving the world is in Thirteen Days, a movie about the Cuban Missile Crisis in the early 1960s which was the closest the world ever came to nuclear war. I think every Product Manager should see this movie!
The film’s pivotal scene is a meeting where military leaders try to push President Kennedy into launching nuclear weapons in response to Soviet aggression. JFK knew that telling the generals “no” might risk a military coup, so instead he thanks them for their input and ends the meeting, promising to come back with a decision soon. This buys JFK time to figure out a peaceful resolution.
Summary: better decisions > winning arguments
Sadly for your ego, but probably better for humanity, the fate of the world isn’t depending on your ability to resolve disagreements at work. But if you follow the advice above, you’ll have a better chance of leading your colleagues into better decisions with less drama and strife.
The more you can see yourself as a catalyst of good decisions rather than a crusader for your version of the truth, the better everything will work out for you and your company.
Happy decisionmaking!