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