> 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 discussed productively between the teams. Perhaps the underlying conclusion is you need more release engineering resources, and both teams might agree on that. (What did you end up discussing, anyway?)

Yep, the person who initiated the conversation was hoping to have precisely this kind of conversation. And no, he didn't get such a discussion. It's easy to say that this is what the conversation should have been. The reality was quite different. So the question is why did they not end up having a fruitful discussion?

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. The fact that a person has described his pain with a technical configuration, and the other party isn't explicitly acknowledging that pain usually will have negative consequences. Frankly, as a third party observer, I think both parties heard and understood the others' pain. But neither party indicated it to the other. And so every exchange in the conversation was a restatement of the pains they had with other's preferences. I catch on to this pretty well because I used to be guilty of the same. And my experience has taught me how frequently disarming it is to merely convince the other party that you truly understand the other's pain. It takes very little effort.

The issue is not resolved. The manager is likely going to step in and pick one solution. This is the worst way to resolve it as he is the one least impacted (at least directly).

> Just like "there are no technical solutions to social problems," there are no social solutions to technical problems.

Something I heard in my first or second year in the industry: "At top tech companies, there are no technical problems. Every problem is a social one. Even a problem that looks technical is really due to a social problem somewhere behind the scenes." Whoever said it was so right. I've worked on plenty of technical problems that arose because people did not get along.

So I must disagree. Solve the social problems, and you often solve the technical ones as well.

> The solution to "people keep breaking the build on trunk" has nothing to do with your feelings about the people who keep breaking the build - it has to do with your lack of a bot that runs tests and only pushes to trunk if the tests pass. (Nor is the reason that they keep breaking the build on trunk about their emotional needs - it's about the fact that they can't make use of such a bot because none exists.)

First: Feelings aren't "about people". My problem is not that people are breaking the build. My problem is that I don't have a clean build to work on. There's a difference.

Second, I've been in teams that allowed anything in the trunk (CI would fail later, but it worked off the trunk, so the damage is done). Yet every time someone proposed to switch the CI to reject things that broke the build, there was push back and it never got implemented. Why is that? How do you solve this?

We had the "technical" solution. That we could not implement it is a social problem. You are not going to succeed unless you deal with the social problem? No matter how bullet proof your technical solution is.

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

I'm not seeing how the choir director example relates to mine. In my particular case, if you mean someone like the manager is the choir director who decides: Well, at the moment he can't, as he isn't actively involved in the code base, so he doesn't know all the issues. He wants the team to discuss it (and he'll monitor the discussion) so that all the issues come to the table. Then with all the feedback, he can make an informed decision/suggestion.

But he's stuck at the stage where multiple people are arguing in a very non-constructive manner, and so he can't see all the issues on the table. How can he get the different parties to talk without merely repeating their stance?

There are clearly emotions involved. And yes, I do agree with you that it is not necessary for people to discuss them. However, if they are discussed well, then it makes the rest of the discussion easier. The "discussing well" is what many communications books are trying to address. Trying to get to the technical aspects that are causing these feelings is a good idea, but a lot harder if you don't know the feelings.

One person involved is quite senior, incredibly competent, and very rarely gets into arguments. He's definitely getting into one. So there are clearly strong emotions at play. If he's upset, he has a good reason. And at the moment he's refusing to engage and is building walls. Now this might be because the other party is perceived as being dismissive, so he doesn't want to waste time in the discussion.

When one person is appearing dismissive, and the other person is clamming up, how do you get them to talk so that the manager has all the factors to consider on the table? Note that the notion that one is dismissive and the other is upset are merely how I have observed the dialogue - and I may be off. Any attempt at starting a discussion where it is accepted that one side is being dismissive and the other stubborn is likely to blow up.