Don't Get Your Coworker to Agree with You

I've read a bunch of negotiation books as well as conversation books. What the latter heavily emphasized is:

Do not ask leading questions

What you describe is textbook behavior. People usually will know when you are doing it, and will get defensive. Especially the smarter ones. I look back in all my years and understand a lot of people's reaction to me: Some people have literally shouted at me when adopted the Socratic approach. The rest don't shout, but they do get defensive. The better among them will ask why I'm probing. But the majority will either answer (but internally think negative of me and damage the relationship), or will get nasty.

That's not to say you can't ask questions. The key is to ask genuinely curious questions (the opposite of leading questions). If you have a concern, learn how to state the concern in a non-threatening manner. Don't try to lead people to it.

The other thing they all say, which the submission has: "If your goal is to change someone (be it internally or externally), the chances of having a poor conversation are high."

Hello there! Author of the article here. I love the point you've made. Often there are long term costs in e.g. technical debt.

I assumed in this article that the stakes are low (and they are more often than we think) but I have a future article in mind about how to make team decisions when the stakes are high, and it'll be something along the lines of: Have a strong process, and make it the responsibility of one person to follow the process, which should involve gathering information and driving the consensus of the team on that issue. Give that responsibility to someone already established to have good people skills e.g. a lead. What would be your approach?

There's a lot in here that might boil down to how you asked the questions/gave the feedback, but there are also certainly cases where you just aren't getting through to someone.

Something I often do there is sanity check my approach with my manager and some trusted coworkers. Did you talk to anyone else about where the two of your coworkers communication was breaking down? Sometimes others have additional perspective on why you aren't getting through to someone since they have a different vantage point.

I've also had cases where my manager basically tells me "no, I don't think you're doing anything wrong, let me do some investigation myself" - and if other people have had the same experience as me, that's occasionally led to positive organizational changes such as shifting people around onto different projects where their skills fit better.

I see posts like these once in a while on HN.

I suggest folks read some good books on conversations and negotiations.

Conversations:

Nonviolent Communications:

https://www.amazon.com/Nonviolent-Communication-Language-Lif...

Crucial Conversations:

https://www.amazon.com/Crucial-Conversations-Talking-Stakes-...

Difficult Conversations:

https://www.amazon.com/Difficult-Conversations-Discuss-What-...

Negotiation books:

Bargaining For Advantage:

https://www.amazon.com/Bargaining-Advantage-Negotiation-Stra...

Getting To Yes:

https://www.amazon.com/Getting-Yes-Negotiating-Agreement-Wit...

Getting Past No (billed as a negotiations book, but really more of a conversations book):

https://www.amazon.com/Getting-Past-Negotiating-Difficult-Si...

I strongly recommend reading Influence before you read these - much of what is in the books above will make more sense once you've read Influence.

https://www.amazon.com/Influence-Psychology-Persuasion-Rober...

When you read these, keep in mind: Change is hard. Don't expect to read these and become good communicators quickly. It may take a few years of stumbling and practice.

I see a mixture of comments agreeing and disagreeing with the original submission. For those who disagree: Most of what the author is saying is in agreement with what the books say:

If your goal is to change someone, you will either fail, or will succeed at the cost of the relationship (and relationships at work do matter).

Another important related point: If you cannot summarize why the other person is acting this way without using phrases like "stubborn", "irrational" or similar negatives, then it means you have no idea about the other person's concerns and motives, and are being lazy. It is easier to label, and much harder to probe effectively. Additionally, people often act stubborn because they realize you are not really interested in their perspective. Internally their thought process (which is very rational) is "This person does not really want to hear me out, so I'm not going to invoke too many neurons engaging with him and will just dig in my heels." - which is why a lot of books focus a lot on listening skills (which includes skills to signal that you are listening - you may in reality be listening just fine but the other person does not know it - so you signal it by summarizing their stance).

A lot of the comments here are invoking false dichotomies. Since HN has a comment limit, I'll address some here:

>I don't believe you can have a successful software team with individuals who can't take a code review well.

This is tangential. You can give feedback in a code review poorly, or efficiently. Both ways allow for you to point out problems with the other's code. One way will not be taken well. The other way has a higher chance of being taken well. A big step forward is to realize you can have your cake and eat it too.

>I started to try and reason with people with carefully crafted questions to guide them towards my goal.

Leading questions is a bad idea (all the communications books say it). Learn how to state your concerns. It is OK to ask questions if genuinely curious. But if you want to point something out, learn how to state it in a non-defensive manner.

(3 separate comments below):

>If Kara's emotions and defensiveness can't handle a clearly articulated, rational, objective argument against design decisions, then for the sake of the product and the company, she probably needs to find another job. Avoiding discussions doesn't work for me.

>Learned to let go and he has his parts of the code base and I have mine.

>And this is how you end up with a terrible, in-cohesive product.

Again, false dichotomies. The solution is not to be quiet and let it go. The solution is to learn how to talk about the issues effectively. One of the books calls this "The Fool's Choice" - thinking that either you have to be quiet and not air your concerns (to save relationships), or that you have to air them and damage the relationship.

>It's either you convince them, or perhaps they convince you. Logic wins.

Logic alone rarely wins. One key point in one of the books: Don't pretend that emotions should not be part of the decision making process. The reality is that emotions are already part of the decision making process. If you get angry that someone cannot take your feedback well, emotions are present.

>It's safe to assume Kara wrote this article.

It is safe to assume that the author of this comment is unwilling to question his views on the topic.

That's what assumptions get you.

>I have seen more technical damage done by nice and competent people deferring to bullies in the workplace than by legitimate disagreements expressed passionately.

Another false dichotomy. What the submission describes is normal among non-bullies.

>The flaw here is that you assume that "Kara" will learn from her mistakes. Not always the case.

It is a similar flaw to assume that merely telling her what mistakes she made will make her learn from them. Definitely often not the case.

It's a two way street. Improving one's listening skills and not reacting emotionally is just as important. The general tone of the article sounds to me as if it does not give much priority to the latter. This strikes me as an expression of an over protective approach to people's emotions that limits rational discussion. I see this often and in my experience I find that it has negative effects on organizations and relationships and, in cases like the one in the article, quality and business success.