Ask HN: When both colleagues think the other is wrong, how to proceed?
12 comments
I've been on critical troubleshooting calls with dozens of people. Everyone always has their idea. What works best is to find the person that knows the most about the system and have them lead. Hopefully they have decent communication skills.
Next thing is to have someone watching and taking notes of everything that was performed. As detailed as possible. There's going to come a time where you have to double back.
Then, form a "backlog" of ideas. If people on the call have a suggestion, it gets put on the queue until the current "thread" is seen to the end. This way, people still get to contribute but you're kind of doing a depth first search.
Lastly, deputized person always gets final say, and people should acquiesce, even if they disagree. It's just the only way to really get anything done in those situations. Yeah, it might be inefficient if they're going down the wrong path, but it's entirely more inefficient to have a dozen people suggestion alternatives and trying them all in a half-assed way.
Next thing is to have someone watching and taking notes of everything that was performed. As detailed as possible. There's going to come a time where you have to double back.
Then, form a "backlog" of ideas. If people on the call have a suggestion, it gets put on the queue until the current "thread" is seen to the end. This way, people still get to contribute but you're kind of doing a depth first search.
Lastly, deputized person always gets final say, and people should acquiesce, even if they disagree. It's just the only way to really get anything done in those situations. Yeah, it might be inefficient if they're going down the wrong path, but it's entirely more inefficient to have a dozen people suggestion alternatives and trying them all in a half-assed way.
Aside from other good techniques mentioned here (have a mediator who is empowered to force a "disagree and commit" resolution, use collective or impersonal language), one useful technique is to focus not on where you disagree, but on where you agree.
For instance: in debugging, even if you disagree on what to try, you probably still agree on what's happening, and that you want to fix it. This changes your task from proving who's right to solving the problem together. It also focuses attention on what you know / can observe to be true.
For instance: in debugging, even if you disagree on what to try, you probably still agree on what's happening, and that you want to fix it. This changes your task from proving who's right to solving the problem together. It also focuses attention on what you know / can observe to be true.
"He knew that the way to make people do what you wanted was to make them think it was their idea. If there was one thing that got right up a nome's nose, it was someone saying, 'Here is a really sensible idea. Why are you too stupid to understand?' It wasn't that people were stupid. It was just that people were people."
Ask anyone throwing in solutions (A, B, perhaps even other people) to add pros and cons for each solution. Make a short meeting and then discuss within the whole team and make a vote. At my last job this worked really well.
From the start:
1. Decide who's going to take point on fixing this (one single person). This person has the final say on how it will be done.
2. Get input from all parties to extract as much information as possible, with the understanding that a lot of it will involve conjecture and opinion, and that the pointman will decide what to do in the end. This changes the relationship from rival to lobbyist (an important psychological distinction).
3. The pointman thanks the other person for their input, and then implements their best judgment based on the information at hand.
4. If the solution fails, reconvene, assess whatever new information came out of the attempted solution (without judgment, blame, or I-told-you-so), and then decide on the next plan of attack (Is there already another avenue to try? Do you need to do more research and reconvene again? Do you want to switch who takes point?)
5. Collaborate to write a blog post about what you learned. If two professionals have such divergent opinions on the solution, it's likely a difficult problem with many gotchas that others will appreciate reading about.
Difference of professional opinion is an empowering thing, offering learning and even potentially the discovery of new knowledge; the trick is to channel it skillfully to a constructive end.
1. Decide who's going to take point on fixing this (one single person). This person has the final say on how it will be done.
2. Get input from all parties to extract as much information as possible, with the understanding that a lot of it will involve conjecture and opinion, and that the pointman will decide what to do in the end. This changes the relationship from rival to lobbyist (an important psychological distinction).
3. The pointman thanks the other person for their input, and then implements their best judgment based on the information at hand.
4. If the solution fails, reconvene, assess whatever new information came out of the attempted solution (without judgment, blame, or I-told-you-so), and then decide on the next plan of attack (Is there already another avenue to try? Do you need to do more research and reconvene again? Do you want to switch who takes point?)
5. Collaborate to write a blog post about what you learned. If two professionals have such divergent opinions on the solution, it's likely a difficult problem with many gotchas that others will appreciate reading about.
Difference of professional opinion is an empowering thing, offering learning and even potentially the discovery of new knowledge; the trick is to channel it skillfully to a constructive end.
twister
This article made a huge impact on me: https://capwatkins.com/blog/the-sliding-scale-of-giving-a-fu...
When I sense a situation like that incoming, I’ll rate how much I care on a scale of 1–10 and encourage the other party to do the same. The person with the higher number gets their way.
There are basically three possible outcomes:
1. The decision succeeds. Hooray!
2. The decision fails. Learn what you can from the outcome and try another approach. Don’t blame the person who called the decision.
3. The decision doesn’t matter. Maybe the two solutions were both fine, or maybe one was technically worse but inconsequential in practice. You’ve avoided a heated argument over nothing.
When I sense a situation like that incoming, I’ll rate how much I care on a scale of 1–10 and encourage the other party to do the same. The person with the higher number gets their way.
There are basically three possible outcomes:
1. The decision succeeds. Hooray!
2. The decision fails. Learn what you can from the outcome and try another approach. Don’t blame the person who called the decision.
3. The decision doesn’t matter. Maybe the two solutions were both fine, or maybe one was technically worse but inconsequential in practice. You’ve avoided a heated argument over nothing.
It seems like the heated argument part could have been avoided if both parties assumed each other's competence.
If A says they've already tried something, B could have believed that they did and that they did so with competence. A then even tried it _again_ to show B, but B still didn't trust that their coworker was doing it right.
I think it should be encouraged to double check each other's work. Often we _are_ missing something. But "Maybe you're missing something" is not a constructive contribution. At that point, B could try the thing themselves to see first hand what indeed, if anything, was "missing" instead of offering an unhelpful comment. Or suggest that maybe "we're" missing something, and then offer a concrete suggestion for how to modify the approach for another attempt.
If A says they've already tried something, B could have believed that they did and that they did so with competence. A then even tried it _again_ to show B, but B still didn't trust that their coworker was doing it right.
I think it should be encouraged to double check each other's work. Often we _are_ missing something. But "Maybe you're missing something" is not a constructive contribution. At that point, B could try the thing themselves to see first hand what indeed, if anything, was "missing" instead of offering an unhelpful comment. Or suggest that maybe "we're" missing something, and then offer a concrete suggestion for how to modify the approach for another attempt.
A: "I'm pretty sure this won't work, I've tried it already. Here let me try it. See, it does't work"
B: "Well, I was reading this article here and it said to try it this way. Maybe you're missing something"
-- Heated argument --
-- Apologies exchanged --
What are some methods/strategies you've used to prevent the -- Heated argument -- phase before it happens?