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.