In my experience, developers always warn management repeatedly and well in advance that engineering is implementing short term hacks. And if management believes them and gives them a free hand, then sprint velocity goes down by 80% and bug counts go up by 90% as stuff randomly breaks in the refactor. Which seldom works out in the end as well as development thinks it will.

(Hint: Refactoring is usually an inefficient way to write a second system, with all of the downsides of the second system effect.)

The moral of the story is that "...management has been warned repeatedly..." DOES NOT mean that the warnings are a correct diagnosis. Here are alternate diagnoses that may also cause the same symptom:

- Confusing product stories.

- Onboarding new developers without proper integration in the team.

- Poor communication patterns between developers.

- General company morale problems.

- Improved QA. (This one is actually an improvement. Reported bugs are up because they are being caught, and developer throughput is down because they have to fix the newly reported bugs. In dysfunctional organizations, though, developers can wind up upset at QA.)

And so on.

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.

Are you familiar with https://www.triballeadership.net/? Based on language patterns, people and organizations can be classified into 5 levels. The linguistic patterns are (1) Life Sucks, (2) My Life Sucks, (3) I'm Great (but you suck), (4) We're Great (but some other organization sucks), and (5) Life Is Great.

There are formal tools behind that classification, and formal ways to measure it, but in general the opinion of people you interact with will be fairly consistent. That notwithstanding, most people judge themselves as operating at a level or two better than they actually do.

Here is where that becomes a problem. Most successful executives operate at level 3, but think that they operate at level 4 or 5. They can adopt any linguistic pattern that they think will make them more successful, but the tools make them more effective at being level 3, with the attendant problems that result for others.

This is not a slight on the communication tools. Emotional people will tend to escalate until the emotion is noticed and acknowledged. Therefore doing that up front really does calm the other person down, and really does facilitate communication. Conversely, approaching challenges with openness, curiosity and openmindedness really does make problems easier to solve.

However if you give a person the tools without changing their underlying attitudes, what looks and sounds wonderful will, over time, create the exact same type of problems in the long run. It just creates them more effectively.

> if management believes them and gives them a free hand, then sprint velocity goes down by 80% and bug counts go up by 90% as stuff randomly breaks in the refactor.

5x less velocity and 10x bugs is not the result of any sane refactor. Anywhere close to this would indicate that either the devs massively underestimated the complexity of the job or their own competence, or something else in the process is broken, such as letting the senior estimate and the junior implement the change. The vast majority of refactorings are in my experience non-events, simply because I'm by now used to working with thoroughly tested systems.

Sounds like you are saying that refactoring is usually incompetently done to me.

Not at all intended on my part. Nor would I say it is usually what went wrong.

The primary root cause is an underestimation of the true complexity of the problem. The details of which only start to become apparent after you've begun the rewrite.

An inevitable secondary cause is organizational pressures to add features to the rewrite. This happens after frustration builds because other departments have been unable to get features into the legacy code. I can't fault developers for lack of skill in managing these organizational pressures. That skill is not a core competency for developers, but it generally is for the people who are trying to get their agendas into the development roadmap.

If there is any additional challenge from the lack of skill of the developers, then you had much bigger problems from the start.

Refactoring is usually the modification of existing code while maintaining existing functionality in order to make the code easier to maintain and reason about for future developers.

Furthermore, if you're given points for refactoring (as you should be) your velocity is very unlikely to go down in my opinion. I will say that many teams and managers do not do this, but that's because they're poor managers.

If you have tests in place you will cause fewer bugs by refactoring. If you don't you will still create a few bugs as you refactor. But imo, fixing the bugs created by refactoring is just... part of refactoring. If that means the task requires an even higher number of points, so be it.

As a manager, there's no point in forcing the team to accept a reality they know isn't possible. It's not beneficial for anyone.

Small refactors happen all the time.

Er...that's not a "refactor". I know the term nowadays gets used liberally for any kind of rework, but refactoring involves making the tiniest of steps, often automatic or automatable, that improve the structure of the code without affecting functionality, all under the umbrella of a comprehensive test-suite that catches violations.

Do you mean during the refactor, or after they claim it's finished?

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.

I've found those result are just as likely to come from a team with low morale. Still a management problem, but if people do not feel valued and don't believe their work matters, they tend to not care about quality. In those cases, improving communication to get to the root cause of problems, re-establishing trust, and making people feel better about their team, role, and work does have an improvement on the velocity and quality of the work.

Of course that will erode the team's morale. Of course that will reduce the team's velocity in the long run. But it's on management to understand that and realize when a short-term intense burst of effort is necessary to hit an important deadline and update the plan accordingly to include both the short-term burst of effort and the recovery downtime afterwards for the team to relax and for technical debt to be cleaned up.

If management can't (or won't) recognize the basics of planning and pacing, phrasing one's concerns using NVC isn't going to suddenly enlighten them. The way I see it, NVC is just tone-policing dressed up in psychobabble. It becomes yet another excuse for management to dismiss engineers for "not having great culture fit", when the reality is that the expectations from the leaders create the culture and it's those expectations that need to change.

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 disputes.

And yes I like NVC: someone else on the thread mentioned they want to talk about their feelings with their SO, not their PM. It doesn't have to be that kind of wishy washy conversation or feel like bullshit. Here's an example:

"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"

It's a good methodology, but agreed completely on the terrible name.

That is not violent.

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.

1) I completely agree that the title 'Nonviolent' is awful. It doesn't even follow the NVC principle of 'say what you want, not what you don't want'. The original author conceded to this. However, you shouldn't judge NVC by its title.

2) NVC doesn't purport to resolve the issue of the bugs or velocity, it aims to help resolve the conflict between the sales manager. Gosh, if NVC actually changed reality that would be awesome. Instead, it helps you find solutions given reality, which is actually very helpful.

3) I sense a lot of irritation and frustration in your tone because you want to be spoken to like an adult. Fair enough—that is a universal need. If you'd like to get your boss to 'give it to you straight', you could NVC to get what you want, without sounding self-righteous :)

Hope this clarifies.

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.

> More seriously, this article reinforces my view of NVC as a fundamentally hostile communication framework. By framing itself as the "non-violent" option, it makes any other form of communication "violent" by default, allowing the first person to wield NVC to claim an advantage.

This is a rather large logical fallacy. It is a non-violent option. Not the violent option. And on top of that, dismissals due to semantics are usually insincere.

Edit: Wow. Kind of sad that my lowest effort comment for this submission both got the most responses and the most upvotes.

I'm sure I'll hit my comment limit if I respond to each response individually, so I'll respond to them here:

> But the engineer has a BATNA here - find another job with a better boss. It's such a common BATNA that "people don't quit jobs, they quit bosses" is a catchphrase. The engineer can get extremely far in solving their "unmet universal needs" like fun and safety by finding another job. It's in the company's interest, one would hope, to keep them.

I don't disagree with any of this. We seem to be discussing different things. Of course, if your boss/job is problematic finding a different one solves that problem. What I was referring to is the inability to have an effective conversation about the need. Exactly what is your problem with a manager who spouts mindless psycho-babble? What is your problem with technical debt? What is your problem with no unit testing?

Imagine you're saying these things to someone who has never dealt with this problem (e.g. someone not in SW). Stating these is not helping the person understand you at all. I come from the engineering (non-SW) world. You will find little sympathy for technical debt and unit testing issues, and will get a response of "Perfect is the enemy of good".

Merely explaining that technical debt makes it harder to add features and will lead to longer timelines isn't explaining your needs. It just leads to more questions: Why is that a problem? You're getting paid for it, aren't you? And so on.

And please, the whole "manager spouting psycho-babble" is not going to get you far. Everyone has an imperfect boss, imperfect spouse, imperfect other. We all know it. After a while in industry, it is tiresome to hear someone complain about an imperfect manager. We all know it's true, and we all differ in what managerial problems one should put up with. Lots of employees are OK with such managers. And again, it's because different people have different needs. If you can describe how you differ from those employees, people are more likely to understand you.

And finally, possibly veering off topic, employers will always find the employee who effectively confronted the problems with the manager instead of running away to be more valuable. Now thankfully the SW world has a lot of mobility so I wouldn't always recommend it, but this looks a lot better on your resume than knowing React.

> Sure, nobody likes a full on attack but a perfectly sweet sugar coated message isn’t always great.

Every discussion I've seen about communications involves this fallacy: False dichotomy. In fact, one other book I've read even gave a name for it: The Fool's Choice (the notion that if you don't sugarcoat relationships will get hurt). NVC isn't suggesting you sugar coat. In fact, it suggests the opposite. Know the problems. State them. Be direct.

> I’m just going to say that we got man on the moon without NVC.

The elements of NVC have likely been around since people started talking, so I'm not sure you're right.

And I'll also point out we got men on the moon without debuggers, source code control, automated testing, etc. We also accomplished a lot without fundamental freedoms (speech, worship, etc). So what?

> I personally find NVC to be degrading and belittling. It presumes I am not a grown up who can handle important criticism, which infantilizes me.

I don't understand where you get the idea that it presumes you cannot handle criticism.

> but it is very violent in other domains like undermining valid criticisms, changing the conversation so it’s not about the problem

In a significant percentage of heated discussions I've seen, there is fundamental disagreement about what the problem is. I wonder if you're merely blaming NVC for something that is independent of NVC. NVC does try to get all parties to understand what the problems are, and I also wonder if that is making you believe it is trying to divert from your problem merely because it is trying to highlight that your problem is not the only one in the discussion.

Of course, without concrete examples, I cannot say.

> and very often the engineer doesn't know the manager well enough to know how they would react to a statement like, "I feel belittled by the fact that you constantly ignore my feedback and impose unreasonable deadlines because a salesperson put you on the spot in front of the VP."

I do hope people have relationships with their managers such that they are free to say stuff like this (I've seen it in person).

However, this is orthogonal to NVC. Your statement to the manager pretty much violates NVC's guidelines. It also violates the guidelines in Difficult Conversations and in Crucial Conversations. Sure it would be awesome to be able to say stuff like that to most people (it's not just about power relationships), but that's not the reality. These books exist to give you a way to get your point across without phrasing it that way.

Belittling is not a feeling. It is a story you are telling yourself. His ignoring feedback is not a fact, but a story you're telling yourself. Claiming the deadline is unreasonable is merely an opinion, and you did not back it up. Saying it's because of salespeople is also a story you are telling yourself, and not a fact. Pretty much every element of what you said can trigger defensiveness. Your statement implies you know everything, and doesn't have the posture of you attempting to validate what you think you know. What kind of conversation do you expect will happen? If you are wrong about any of the above, it will put the manager in a position of having to defend his actions, which is the very definition of defensiveness.

You can say this type of stuff without hurting feelings to only people very close to you (true buddies). Most people are not dealing with true buddies.

I think this is true in certain contexts where you don't have much power over the situation itself (which ranges from resolving conflicts between family members to resolving conflicts between leaders of non-allied countries). But the engineer has a BATNA here - find another job with a better boss. It's such a common BATNA that "people don't quit jobs, they quit bosses" is a catchphrase. The engineer can get extremely far in solving their "unmet universal needs" like fun and safety by finding another job. It's in the company's interest, one would hope, to keep them.

And this still isn't being judgmental: the engineer simply needs management who understands the process that they are managing. The engineer is not only allowed but expected to exercise technical judgment in determining whether that's happening, same as an engineer should exercise technical judgment in determining whether a proposed vendor product fills the need (and would not be doing their job if they refrained from analyzing the vendor product for fear of being judgmental). Perhaps the manager doesn't have the requisite technical background to make proper product decisions. That doesn't mean "the manager is a bad person" - that means that the manager isn't (by themselves) the right person for the role. Maybe they should seek a technical team lead, or promote a manager within the team, or something.

This is not universally true, but you state it as if it is.

>Your problems are valid, but you have to be able to communicate them in ways that don't trigger defensiveness.

Wrong. Triggering defensiveness is something which happens as a matter of degree, and there is no problem with triggering small amounts of defensiveness if the other party is an emotionally mature person who has perspective on their own defensiveness.

This isn’t the only choice, but it’s presented as though it is. Communication goes both ways, the people on the team can also choose to not get defensive.

Sure, nobody likes a full on attack but a perfectly sweet sugar coated message isn’t always great.

In bad situations it’s ok for people to feel bad.

There's an important distinction. You can't control whether your teammates tend to get defensive, or how much it takes to make them defensive. However, you can control how you deliver your message to optimize for getting what you need, which requires steering around their defensiveness long enough for them to understand your point. (Try telling someone to stop being defensive... that's never worked for me. However, anecdotally, conflict resolution and mediation focused around mutual understanding of communication style, working style, and project related needs has worked most of the time.)

Communication goes both ways, but effective communicators understand that they have personal agency in the matter and that exercising it is good for getting what they want.

As a manager I've told direct reports something like this about working with people on other teams who were being difficult. It's not strictly their fault that the counterparty got defensive, but they're a lot more effective (and more likely to be promoted) if they can work through it without me intervening, because that means I can trust them to work autonomously on projects with lots of stakeholders.

It is also a political weapon. It may be non-violent in one domain (the tone and language presentation) but it is very violent in other domains like undermining valid criticisms, changing the conversation so it’s not about the problem but instead filibustered with metaproblems about who is / isn’t being kind in someone’s made up subjective & political definition of verbal discourse.

Just because it says “non-violent” in the name doesn’t mean it’s true. In fact it’s rather suggestive. If you have to be defensive and _define_ your communication as non-violent, that’s pretty suspect and belies dangerous motives.

It’s “politeness theater” in a way similar to how the TSA uses security theater. You can _say_ it’s effective for a stated purpose all you want, but that doesn’t make it true.

In my experience, that describes very few business settings. There is a massive power differential between the manager and the engineer (after all, the manager can fire the engineer, but the engineer cannot fire the manager) and very often the engineer doesn't know the manager well enough to know how they would react to a statement like, "I feel belittled by the fact that you constantly ignore my feedback and impose unreasonable deadlines because a salesperson put you on the spot in front of the VP."

As I see it, a work environment that's safe enough for NVC to be useful is one where the lines of communication are open and honest enough for NVC to be unnecessary. As a result, whenever I see or hear someone speaking NVC phrases at me at work (especially if they have never done so in the past), I am immediately on guard, because I know they're trying to slip a fast one by me.

There's one quick way to find out how they'd react! Seriously though, I generally find myself respected in the organisations that I work in, and I think it's at least partly because I'm willing to be forthright in calling people out and telling them what I think, regardless of their position. Of course, some may take it badly, but that's not the kind of organisation I want to work in (and in my experience, most people react well to honesty).

In that situation, your manager doesn't really have much power over you. What's the worst they can do, fire you?

But a lot of people don't feel confident of finding another job and are basically afraid of losing the one they have.

That's what makes it a significant power difference. They're afraid because they aren't secure.

Could you suggest a general approach to mitigating conflict when there is inequality in power without getting to the specifics, listening to both sides, and attempting to find a win-win?

If the less-powerful don't try to get what they want, the more powerful wins by default.

> "I feel belittled by the fact that you constantly ignore my feedback and impose unreasonable deadlines because a salesperson put you on the spot in front of the VP"

Let's work with this. Are you feeling resentful because your need to be listened to? If the answer is yes, how about we take 15 minutes and you can explain the extent of the issues? If not, I haven't understood—could you try again?

I'm not sure what you're trying to show here, because just because you can write a positive reply to that here on Hacker News does not in any way change someone's actual trepidations with expressing that to their actual manager.

Plus the entire subtext of that reply is just "I don't want to acknowledge the possibility that I have made any mistakes, and so I am going to reduce your problems down to cliches."

> “ Let's work with this. Are you feeling resentful because your need to be listened to?”

comes off as quite infantilizing and degrading. If I received this reply, I would feel you are not treating me with respect and you’re trying to undercut me by appealing to an emotion (resentfulness) and shifting focus onto that instead of dealing with the actual problems.

The only part of your reply that contains non-belittling words is the first sentence where you admit, “I honestly don’t understand your point.”

Example: http://www.sandraandwoo.com/2019/08/22/1108-republics/

https://es.wikipedia.org/wiki/Corea

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.

Take a population of 100 people. 10 of them are emotional. 40 of them are emotional amplifiers. 10 are combative. And 40 are combative amplifiers.

In this system, it tends to chaos when communication is too combative because of the population set (regardless of any ideals or moral judgments of what you think).

Nvc is a set of rules that, if a subset of the 100 population follows it, lowers the chance of communication blowing up into chaos. That's about it.

It's the best communication style for nullifying others bad communication when bad communication is the root cause of tension or problems.