The Leader’s Dilemma: When both engineers are right, who is “more” right?

You are leading a team. After you raised a problem that needs solving for a customer, two of your engineers propose solutions that use very different tools and methodologies. Instead of focusing on which solution is best for this customer, or building on each other’s ideas, they start arguing about the qualities of the tools within each solution and the methodology of solving the problem.

What do you do? How do you stop the argument? How do you decide which one to go with and why this is the best one (especially when you don’t necessarily understand their solutions to the level of technical detail they do)?

Let’s call the engineers Martin and John. Martin proposes solving the problem in X way. John proposes solving it in Y way. Martin says John’s Y methodology won’t work, as he believes the tools John proposes are too new to know they will work and therefore not good enough for the task. John says Martin’s methodology won’t work because his whole process is out of date and after the first test he will discover it will be riddled with bugs that his tools would automatically identify before they are even created. Martin cares about using tried and tested, traditional tools and likes process. John cares about using the latest tech tools and trying out new ways of doing things.

However they both miss the point of the meeting: what the customer needs is a solution that goes 3x faster and uses 1.5x less power and yet:

• Martin’s solution would make it go 5x faster but uses 1.5x more power
• John’s solution would go at the current speed but use 2x less power.

So, who is right?

No one is “right”, unless they justify their proposition with how this fits the solution the customer is after. Ideally they also show that their solution is taking into account strengths/knowledge/tools from the team as well.

The core problem emerges because there’s a misunderstanding between what the engineers arguing (Martin and John) think is “right” and what is actually “needed” in this situation:

It could be that the engineers are unconsciously operating on the belief/criteria that they will be valuable if their idea is “the best” (and “the best” is based on their own criteria of how one should approach the problem and the tools they would use).

The Leader would be operating on different criteria: does this solve the problem for the customer in a way that this team can deliver the solution?

There’s 3 key reasons why the engineers start arguing about the methodology and the tools in this situation:

1. The focus of the conversation is not constantly kept (by you, the team lead or the person running the meeting) on the problem the customer is trying to solve, the outcome they want and how this team can make this outcome happen given their experience/tools/knowledge.

2. Individual engineers have become very attached to their own approach, tools, ideas, methodologies, ways of doing things. They have lost sight of that others have very different tools they prefer using and those people are right in their own way.

3. They are not operating as a team who build on each other’s ideas, they are instead focused on: who is going to win this argument? Who is the Alpha engineer on this occasion? This may be because Martin and John might think that to be a good engineer it means to show your way is always the best way; instead of realising that great engineers focus on the customer and build on colleagues’ ideas, not fight them. Here, Martin and John don’t realise that great engineers always keep the customer in mind when designing their solutions: what problem are customers trying to solve and what solution they need.

What can you do about it in the meeting?

1. At the beginning of the meeting explain very clearly the problem you are looking to solve for the customer and the outcome they are after (what it does and what they want it to do instead). E.g. “customer is unable to perform XYZ tasks because the processor can’t cope with the data load and the battery runs out mid task at minute 7. Customer ABC data indicates it needs to process data 3x faster and use 1.5x less power”.Before you open the floor to suggestions, remind the team that by the end of the meetingyou want to agree on a solution that works best for the customer and that this team can deliver.

2. If despite your statement above at the start of the meeting, the conversation still veers off track and Martin and John start arguing about the methodology and tools, simply say: “Let’s go back to the purpose of this meeting: how is using this methodology/tool going to make it to go 3x faster and use 1.5x less power. At present, Martin, your solution would make it go 5x faster but uses 1.5x more power. John, your solution would use 2x less power but it will go at the current speed. How can we build something that uses Martin’s speed and John’s low power use?”

3. Remind them that what you value is coming up with a solution that works for the customer and the only way you can get there is by building on each other’s ideas rather than fighting for one person’s solution.

4. If they both come up with a solution that fits perfectly the customer requirementsbut you are not sure which methodology to go with, ask them: “how will your methodology use the skills/tools and knowledge of the other people in the team?”

5. In both situations (when Martin and John’s solutions are not quite perfect or are indeed perfect for the customer) you should always go back to the quiet members of the team and ask what they think? How could they see getting Martin’s speed and John’s low energy consumption in the same solution? Which methodology/tools would they feel most able to work with/familiar with?

When in doubt of what to do next or who is “right”, remember what you are trying to achieve (solve X problem and achieve Y outcome for the customer), remind people of this and remind them that there’s a misunderstanding between what they think is “right” and what is actually “right” in this situation.

They will not be most valuable if their idea is “the best*”, but if they solve the problem for the customer in a way that this team can deliver the solution (* “the best” is based on their own criteria of how one should approach the problem and the tools they would use).

And if you are stuck and don’t know what to say in the meeting, just ask this one question: “How does this help us solve X problem and achieve Y outcome”? From this point, it’s their job to prove this to you, not your job to figure out who is “right”.