Managing disagreement in a team sucks

You know you're right but your colleagues are doing EVERYTHING to make your life worse...

It's common for Software Engineers to have opinions, sometimes bold opinions.

When your team needs to decide on something, happens that two or more people suggest using different tools/approaches.

Usually, the proposed solutions have both pros and cons. There are a few techniques to decide what to do and today we will see some of the techniques I prefer.

Understand if this is a one-way or two-way door

There are two types of decisions: one-way and two-way. A decision is a two-way door that can be reverted easily. Instead, a one-way door is way more risky. Once you pick that decision, doing a rollback is super difficult, if not impossible. Of course, these are two extremes but there are a lot of shades in the middle. Understanding this can really help in evaluating the risk associated with a decision and deciding how much time to invest in taking the decision itself.

The magic formula

In case two or more engineers cannot agree on a solution (if all of them have a bold opinion backed by data) there is a fascinating rule that can be used to decide. Just ask everyone "Is there someone who CAN'T live with decision x?". Maybe the developer who wants to use Technology X still believes that its option is better, but in order to make a decision and progress with the project can accept work with a different solution.

An external judge

You have multiple potential solutions to a problem and the team cannot decide what solution to pick. In case the decision is crucial for the project, you can write a Design Document explaining the problem and all the proposed solutions. Everyone can participate in this design document and write the pros and cons of each proposal. Then an external judge is nominated (usually the team lead or a Staff Engineer) and she/he becomes the owner of the decision. The judge will also write down the rationale behind the decision taken to make everyone aware not only of the decision but also of the reasons behind it.

Let me give you an example. A few months ago I was working on a noise-cancelling integration. We had two options in terms of APIs to use. One tool is backed by a huge company, with stable APIs, support, and a big suite of products and customizations.

The other tool, created by a single developer, had a minimal API but on the other hand, the noise canceling was much more efficient. I argued that we should go for the first, even because the second one was not performing noise cancelling, but was doing voice extraction (which was slightly different from the initial requirement).

My colleague argued that we should go with the second API which was working very nicely.

Let's evaluate the situation with the two mental models we just exposed: Was this a one-way or two-way situation? I'd say that this is a two-way situation! In the end, on our side, was just the implementation of a couple of API endpoints, and since the services were doing the same, also the code to use them wasn't changing that much. Also, we already had two proofs of concept in two separate branches, so in case the decision taken was wrong, we could easily swap them.

Also, since in that case, I cared only about the customer's feedback, I could live with both options. In the end, we decided to implement the second API and the customers loved the feature!

Understanding how to manage conflict (not Merge Conflicts, even if these can be really annoying) in your team will be essential to become a better engineer. In case you want to have a chat about Software Development, Italian food or what’s the best between Harry Potter and Lord of The Rings (we all know what’s the best one, right?!) you can schedule a 30-minute call on my Calendly :D careergrowth.dev