Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to resolve a conflict when both sides are right

medium.dave-bailey.com

Post reply on HN
Print view View original

111–120 of 167 posts

Re: How to resolve a conflict when both sides are right

#111

Post by elmomle »

btilly wrote: post #107
quanticle wrote: post #28

Suppose product development has slowed down, reported bugs have increased 30% since last month, and sprint velocity is down by 40%. Your engineer is feeling desperately unhappy and is terrified of building new features because of the risk to the system as a whole. They want to stop building new features and refactor some of the system architecture. But what do you think their unmet universal need is here? If I were i…

In my experience situations where the bug-count goes up by 30% and sprint velocity goes down by 40% don't just happen out of nowhere. In every situation I've been in where that's happened, management has been warned repeatedly and well in advance that engineering was implementing short term hacks that would come back to bite us later on. To respond to something you were warned about with NVC baby-talk (as opposed to…

These are all good points, though I think a deeper point may be missing regarding employing empathic, curious, positive communication tools (If you prefer a term besides NVC, please use it--the politics of taxonomy could only distract us from the potential benefit of ideas).

Here's a theorem: For common personal or professional conversation types, I maximize the expected outcome of "difficult conversations" (both to me and to the group) by (in the conversation) assuming the best and focusing on open-mindedness and collaboration.

Proof: Enumerate expected outcomes from using that mindset versus not doing so over all possible values of {am I in the wrong?, is other person in the wrong?, other person's disposition}. (For full rigor multiple through by your priors on each of these but I hope the idea is clear enough).

In the example you gave, if I'm management and I'm in the wrong, being curious when trying to debug the problem will make it way easier for me to be open to my mistakes, since I've introduced no specter of guilt, shame, or blame for the fact that there is a mistake.

Re: How to resolve a conflict when both sides are right

#112

Post by cheshire_cat »

cousin_it wrote: post #4

I've seen this pattern a few times now: someone encounters NVC - claims that his interpersonal skills have massively increased - starts trying to recruit others into it - others don't follow because he's mostly talking in canned robotic phrases - when others point it out to him, he uses NVC tools to ignore/deflect - all efforts to reach him fail. In contrast, I've never seen anyone who could be described as an NVC su…

This is actually a known and discussed issue in NVC circles. I highly recommend Miki Kashtans workshop "Naturalizing NVC" [0] to everyone. A shorter watch about the topic is a video from "Cup of Empathy"[1].

[0] https://www.youtube.com/watch?v=oHtDZ98CTDc

[1] https://www.youtube.com/watch?v=WiCtf5sZWHA&t=266s

Re: How to resolve a conflict when both sides are right

#113

Post by wintermutestwin »

pmichaud wrote: post #109
wintermutestwin wrote: post #77

Earlier quoted context omitted.

I think you are pointing out that reframing can be misused. Do you think that this cut from my conflict resolution doc is a "concise alternative?" "The art of reframing is to maintain the conflict in all its richness but to help people look at it in a more open-minded and hopeful way." -- Bernard Mayer How to reframe a statement: Acknowledge the emotion Restate the problem or issue removing the inflammatory language…

I really like that quote! I think your steps are a decent approximation, but I don't think they are fully general. For example, sometimes clarifying the details and reality of a conflict causes the conflict to be more directly inflammatory. And if you're following a procedure that has "be less inflammatory" as a metric, then you'll fuck that up. (For the record, I don't think it's a bad heuristic to follow. Most of t…

Yes, you are spot on with that example and I have had similar experiences when mediating with parties that have higher EQ, but lack a rich set of soft skills. My process doc addresses the basics of facilitating conflict resolution as could be taught in a one day class. Your example is something I would consider to be more advanced and requiring an experienced mediator. I'll also say that most conflicts requiring "honorable combat" lend themselves better to an interests-based negotiation approach. I really appreciated your comments here and would love to get your feedback on my doc. Email me if you are interested.

Re: How to resolve a conflict when both sides are right

#114

Post by llamataboot »

uk_programmer wrote: post #45
llamataboot wrote: post #8

Earlier quoted context omitted.

IMHO this stage of NVC lasts about 6 months, and it is rarely "doing NVC" - ie; if you get really angry/scared/etc you prob haven't built up the muscle memory yet to even reach for those canned phrases (probably applies more in more intimate relationships than the workplace - partner(s), parents, kids, etc) but maybe you do, and surprisingly even a clumsy canned phrase about your own feelings or needs rather than jum…

The very acronym itself redefines violence to something it isn't which is always a red flag. This all sounds like the worst parts of working in a lot of modern offices where people don't speak frankly and instead everything is done through this sort of political office speak which is lets be honest here all about politics and not about solving problems. When I read things like this. I find it very insidious.

It sounds like you are worried that using communication frameworks like this will inhibit being able to communicate freely and honestly and that instead of solving problems and working together (and even having some sharp disagreements), those disagreements will just be avoided through some sort of unclear speech in the name of not offending someone or hurting someone's feelings, and that as a result honesty and quality of collaboration will suffer...Does that sound right?

Re: How to resolve a conflict when both sides are right

#115

Post by geofft »

BeetleB wrote: post #83
geofft wrote: post #54

Earlier quoted context omitted.

> Just yesterday there was a nasty discussion at work about whether to split a monorepo into smaller individual repos. One side's work is bogged down by it being a monorepo, and the other side would have trouble if it were split into monorepos. Both sides discussed the their problems, yet neither side acknowledged the other's pain. Validating the other's emotions is a core principle of all communications books I've r…

> This is a technical tooling problem, not a problem about the feelings of the two teams. By all means, dig technically into why one team's work is being bogged down and why one team prefers the current setup. Maybe you need a different design for integration testing or deployment pipelines. Maybe you need another branching strategy. Maybe you need some ground rules about monorepo-wide changes. All of those can be di…

> In the past my thought process almost exactly mirrored yours. It's only due to a bunch of years of observing these dynamics in multiple teams did I realize that these expectations I had were off. SW folks, as much as they try to deny it, are as emotional as anyone else. Everyone is emotional - they just manifest it in different ways.

That does not describe my thought process at all. Of course software people are as emotional as anyone else. No part of my argument is about software people being unemotional - and no part of my argument is about software people in particular. It applies to everyone who's trying to get a job done. If your altos and sopranos aren't blending because they're using different vowels, that isn't about how they feeling, that's about the vowels they're using. If your choir director isn't able to notice that, that isn't about an emotional desire for a particular choir director, that's because it's the choir director's job to notice it.

Yes, you can be upset or sad or exasperated at the choir director. You can be jealous that he has the job and you don't. You can even be indifferent. That's all worth addressing if you want a happy choir, sure, but none of that changes that the choir director's job is to notice when the altos and sopranos aren't pronouncing their vowels the same. The purpose of a choir (even a community choir that never performs) isn't to make a happy choir, it's to make good music. People are in the choir because they think making good music will make them happy - and everyone knows that, that's not an interesting observation.

> I've worked on plenty of technical problems that arose because people did not get along.

I have, too. I've also worked on plenty of technical problems that would have been equally present had everyone got along. I think whoever told you that there are "no technical problems" had a pretty limited view of the world. Sure, many problems are from behind-the-scenes social problems. I'd maybe even say that most problems that actually get solved are those. But it hardly means that if you had a company full of people who were perfect empaths operating in perfect good faith, you'd have no technical problems left.

(And, again, same for other fields - I've been in plenty of choirs with interpersonal problems, and the altos not liking the sopranos and the soprano who's unwilling to admit she's really an alto certainly aren't make things easier, but solving those won't magically make you blend!)

> You are not going to succeed unless you deal with the social problem? No matter how bullet proof your technical solution is.

Firmly agree. But you're also not going to succeed without a technical solution, either. Yes, if you've built out the pre-push CI, figuring out why people don't want to switch to it is a social problem, and you must solve that. But you also have to build it, and take any technical concerns they raise into account.

Re: How to resolve a conflict when both sides are right

#116

Post by neeleshs »

btilly wrote: post #107
quanticle wrote: post #28

Suppose product development has slowed down, reported bugs have increased 30% since last month, and sprint velocity is down by 40%. Your engineer is feeling desperately unhappy and is terrified of building new features because of the risk to the system as a whole. They want to stop building new features and refactor some of the system architecture. But what do you think their unmet universal need is here? If I were i…

In my experience situations where the bug-count goes up by 30% and sprint velocity goes down by 40% don't just happen out of nowhere. In every situation I've been in where that's happened, management has been warned repeatedly and well in advance that engineering was implementing short term hacks that would come back to bite us later on. To respond to something you were warned about with NVC baby-talk (as opposed to…

But, technical debt is a real thing. Making sure that refactoring/clearing debt is part of every sprint (one or two tasks per sprint, probably) is important.

However, if benefits of refactoring are abstract, and not attached to immediate or short-term/medium term features/perf, there is a very high probability that it is not a tech debt. "Code looks better this way" - is an overrated rationale to refactor.

Re: How to resolve a conflict when both sides are right

#117

Post by harumph »

quanticle wrote: post #28

Suppose product development has slowed down, reported bugs have increased 30% since last month, and sprint velocity is down by 40%. Your engineer is feeling desperately unhappy and is terrified of building new features because of the risk to the system as a whole. They want to stop building new features and refactor some of the system architecture. But what do you think their unmet universal need is here? If I were i…

Your comment about "NVC baby-talk" resonates. It reminds me of this, recently posted to HN:

https://gp.blaisemcrowly.com/dont-kill-them-with-your-positi...

In my opinion, be honest with people. Consider their feelings too. But people need honesty to make rational decisions.

We're in a moment in time in which speaking the truth is in short supply.

Re: How to resolve a conflict when both sides are right

#118

Post by wolfgke »

BeetleB wrote: post #35
quanticle wrote: post #28

Suppose product development has slowed down, reported bugs have increased 30% since last month, and sprint velocity is down by 40%. Your engineer is feeling desperately unhappy and is terrified of building new features because of the risk to the system as a whole. They want to stop building new features and refactor some of the system architecture. But what do you think their unmet universal need is here? If I were i…

> If I were in a situation like that, my "unmet universal need" would be "a manager that understands the concept of technical debt and taking time for unit testing as opposed to spouting mindless psycho-babble at me". If you cannot state your need without judgmental comments (blaming others, etc), you are not going to get far in solving the problem. Your problems are valid, but you have to be able to communicate them…

> If you cannot state your need without judgmental comments (blaming others, etc), you are not going to get far in solving the problem. Your problems are valid, but you have to be able to communicate them in ways that don't trigger defensiveness.

Bullshit stays bullshit, even if you sugar-coat it.

> Imagine you're saying these things to someone who has never dealt with this problem (e.g. someone not in SW).

In this case, the respective person should better trust the judgement of the software developers who have gone through this lots of time.

> I wonder if you're merely blaming NVC for something that is independent of NVC.

Applying psychobable instead of attempting to solve the problem will make people angry.

Re: How to resolve a conflict when both sides are right

#119

Post by pmichaud »

wintermutestwin wrote: post #113
pmichaud wrote: post #109

Earlier quoted context omitted.

I really like that quote! I think your steps are a decent approximation, but I don't think they are fully general. For example, sometimes clarifying the details and reality of a conflict causes the conflict to be more directly inflammatory. And if you're following a procedure that has "be less inflammatory" as a metric, then you'll fuck that up. (For the record, I don't think it's a bad heuristic to follow. Most of t…

Yes, you are spot on with that example and I have had similar experiences when mediating with parties that have higher EQ, but lack a rich set of soft skills. My process doc addresses the basics of facilitating conflict resolution as could be taught in a one day class. Your example is something I would consider to be more advanced and requiring an experienced mediator. I'll also say that most conflicts requiring "hon…

Sure, I'm happy to take a look. Not sure what your email is, mine is in my profile.

Re: How to resolve a conflict when both sides are right

#120

Post by sanderjd »

nailer wrote: post #66
quanticle wrote: post #28

Suppose product development has slowed down, reported bugs have increased 30% since last month, and sprint velocity is down by 40%. Your engineer is feeling desperately unhappy and is terrified of building new features because of the risk to the system as a whole. They want to stop building new features and refactor some of the system architecture. But what do you think their unmet universal need is here? If I were i…

> By framing itself as the "non-violent" option, it makes any other form of communication "violent" by default I like and use NVC, but the naming is terrible. Violence is violence. Communication is not. Not only does the silly name throw aspersions onto other forms of communication, it trivialises actual violence and mars the actual NVC methodology, what I personally have found to be an effective way of resolving dis…

> "When we push updates without facing technical debt, it slows down our velocity for future updates as we're having to deal with things like flaky tests and infrastructure outside our configuration. I'm worried we're actually losing long term speed with our current focus"

Coming into this article and thread without knowing anything about this NVC thing, that just seems like a normal thing for a person to say when describing a problem, having very little nothing to do with the technique I just read about... Does your "NVC done well" just boil down to communicating concerns clearly and honestly? If so, I don't see why it needs a name at all.

Post reply on HN