Photo by Icons8 Team on Unsplash

You’re working with another org in coming up with a joint architecture for web-based applications.

They want to use WebComponents, while you think React is the better way to go. They’re emotional about their choice, and don’t want to budge. How do you hold a rational discussion with these people?

Sound familiar?

The situation is a common cause of frustration and needless conflict. Now, I’m not saying that these types of issues are easily resolvable, and sometimes you’ll have to involve upper management and let them fight it out.

And yet, there are things you can do to make a positive outcome more likely.

TL;DR

Here’s a distilled version of the rest of this article. Use it as a framework for further discussion:

1. If you’re going to get into an argument, make sure it’s worth the cost to the relationship.
2. If you’re going to get into an argument, bring allies.
3. Involving stakeholders and directing conversation toward data will help you make your case.
4. Make sure you are arguing with the right person. Focus on the decision-makers instead of investing into convincing folks who ultimately won’t affect the decision.

Assumptions

For the purpose of this discussion, I’m going to make a few assumptions:

1. Overall your company is rational, and data matters.
2. Engineering is willing to listen to other stakeholders, like PM and Marketing.
3. Your Director is on your side.

… wait a moment. That #3 is actually problematic. Often enough the situation isn’t that another org is balking at your ideas, but that your coworkers are, or your Architect, or your Director.

Let’s take a brief detour and examine that scenario first, and then see how we expand it to encompass the higher-scope, higher-stakes scenario.

Point 1: Five years from now, nobody will care

It’s unfortunate to see colleagues become oppositional based on some relatively silly technical argument. They argue with each other, filling the hallways (when we still went to the office) with their escalating voices, and causing others to shrink away.

The discussion generates negativity that spreads through the team like a particularly virulent fart.

The thing is, unless the argument is really about something that’ll make or break the project, chances are the relationship between the people involved is far more important.

One of my favorite sayings is “Five years from now, nobody will remember the product you’re working on, but people do remember their coworkers and the interactions you had.”

Do you want to leave them with a memory of you as inflexible, didactic, hard to work with? Is the argument you’re having worth that risk?

No, you don’t need to become a dishrag, giving in at every disagreement. Some arguments really are worth having. So how do you approach those?

Point 2. Line up your ducks

In Microsoft, the approach I’m going to discuss is called “lining up your ducks.” In essence that simply means not going into an argument solo, but soliciting allies.

Let’s say you’re trying to convince your Architect, Jen, that React is the way to go. Other than data-driven approaches which we’ll discuss later, ask yourself the following questions:

1. Who does Jen respect on the team? Who does she listen to?
2. What is my relationship with those people? What do they think of my idea?

Run the idea past Jen’s influencers. See if you can enlist them into your army. Don’t just get their opinion, ask them for help. Making them feel like they have skin in the game is a much more effective way of getting them on your side than merely soliciting an opinion.

One of the influencers isn’t convinced? Well, who do they listen to? Rinse and repeat.

Look, it’s not a foolproof strategy, because you’re dealing with people, not machines. That requires “softskills”, and those, by definition, have a soft criteria for success. Assuming your argument has intrinsic merit, you’ll get some folks to agree with you.

If nobody agrees with you… well… are you sure you’re right? Even if you are, are you sure you want to swim against the current as strong as that one? You might get your way, somehow, but it’d be a pyrrhic victory, coming at the cost of the relationship with your team. Is your argument truly worth that?

Point 3. Stakeholders and data

Let’s now come back to our original scenario. You are convinced React is the way to go. The engineers from the other org are convinced WebComponents are better.

Well, what are the differences?

(Disclaimer: I don’t know either very well. This isn’t about the specific tech, it’s about the approach.)

React package is bigger. It’s (arguably) more complicated, further away from the “metal.” It’s also (arguably) easier to use.

Let’s translate that into PM-speak. A bigger package means slower initial load time. Ease of use means higher developer velocity.

So, this is about start-up-speed vs. time-to-market.

What’s more important?

Well, how about asking a PM? Naturally phrased like this, the question cannot be answered, so you need some data.

How much slower do you expect initial load to be? What development cost savings, and therefore, time-to-market speedup can we realistically expect? Talk with your allies. Gather the data. Then go to PM and ask. Go to Marketing and ask. Get the stakeholders’ input.

(There’s, of course, more detail needed here. What network bandwidth do you expect? What sort of hardware will your product be run on? What’s the skillset of the devs on your team? Etc, etc, etc. But I think you get the idea, right?)

Be prepared to be wrong. Let’s say you’ve arrived at the conclusion that with a React package your app will take 3s to start up on a target user’s machine. And let’s say PM says that’s unacceptable. Well, there’s your answer.

On the flip side, let’s say Marketing wants the product out yesterday, and they’re willing to live with the slowdown. Armed with that, you can now approach a higher-level discussion with the representatives of the other org.

Framework for argument

1. Figure out what the key stakeholders value most. (time-to-market? Perf? Something else?)
2. Collect data pivoting on that value
3. Talk to project stakeholders re data you collected. Get their input.
4. Articulate your choice based on that input.

Sounds simple, doesn’t it?

Point 4: convince the right people

What if you show up to that meeting with the other org, and they still persist in pushing their approach? Think that’s unlikely? Don’t forget that even engineers are humans, and humans are first and foremost emotional. We aren’t great at purely rational decisions.

There are other factors involved. What if the other guy’s promotion is tied to them coming up with and driving the approach? Are they going to cave to a rational argument? Maybe. And maybe not.

Tail wags dog, again.

In these situations, it’s going to come up to a fight between the VPs, and they have, hopefully, trained most of the emotion out of their interactions. That’s how they got to VP in the first place.

So, what really matters isn’t the opinion of your counterpart in the other org. What matters is how convinced your Director is that you’re right, and how good they’ll be at pushing that upstream

All those ducks you’ve enlisted in step 2, and all that data you collected in the step 3, are going to be critical to giving the Director the conviction to fight for your point of view.

Make their job easy. Arm them with data.

And, come annual review, they’ll reward you for it.