Cataloging Conflict

I spend a good bit of time in conflict resolution - either my own, people on my team or between groups. I’ve noticed that one of the most helpful things to do in these situations - aside from empathy, which is absolutely crucial - is understanding the type(s) of conflict being had. A lot of time is spent debating decisions. Each of these decisions has consequences but the nature of those consequences should be clearly understood to better assign value to the conflict.

What is Technical vs Stylistic Conflict?

Technical conflict has to do with the implementation of a solution that has real world consequences not only on the time to market, but also on its maintainability, resiliency and performance. When debating a solution all parties should agree, at least, whether the concern is technical or stylistic. A contrived example might help here.

💡EXAMPLE
In a code review, one reviewing engineer mentions that brackets should be in line with the expression and another does not feel that is true, we can safely put that into the style bucket. But what about if the reviewer says that there should be no brackets at all for one line blocks? In this case, you’ve crossed over into technical because you could argue that there is a maintainability concern with some engineer in the future not realizing that there was no bracket and adding a line to unbracketed block. Arguable for sure, but the nature of the argument has changed from stylistic to technical.

Resolution of technical conflict can fall back on best practice guidelines. Where a guide does not exist or this situation is not identified, then add whatever decision is made to the style guide for future use. Applying the decision consistently can itself be a technical benefit.

Stylistic and technical issues overlap for sure and some stylistic concerns do have real world implications for maintainability so it’s not perfect but it helps to check yourself when making an argument that may contain more opinion that logic.

What is Strategic Conflict?

Strategic conflict is wide ranging and has the potential for being very impactful over a period of months and years. Decisions that come out of strategic decisions could have implications that are difficult to reverse making these much more challenging. It’s also worth noting that some technical decisions have strategic consequences and vice versa.

In order to have a good chance to resolve strategic conversations, all parties have to start with a shared vision. If the vision for the organization is not shared then strategic alignment cannot be easily arrived at.

Additionally, philosophical division about approach can impede these conversations. For example, a risk-avoidance vs. a risk-reduction approach leads to very different solutions. The ability for groups to identify the root cause of the disagreement as philosophical allows the conversations to focus more on the core issue vs. debating trivialities that lead to churn and organizational paralysis.

When strategic conflict happens, it’s often a good idea to have a Plan A and Plan B. Falling back to Plan B - when certain milestones or KPIs for Plan A are not met - can help bring consensus. In order for that to work, you have to make sure that there is a clear understanding of the options that are at the core of the conflict.

Clarify the Conflict

Almost half of the conflicts I’ve been involved in have actually been driven by misunderstandings and miscommunication. Once we’ve realized we’re actually saying the same thing, the issue has been resolved but not after a lot of wasted time. For this reason, I use visuals heavily. I can’t stress the importance of visualization to quickly bring people together and to ensure we’re having the correct conversation. That is probably a post in itself.

Categorize the Conflict

Categorizing the conflict and sharing what you think the nature of the discussion can really help people get on the same page about the importance. If one person is having a strategic conversation and someone else is having a stylistic one, you will often see two very frustrated people - one because the other is not taking this seriously and one because the other is taking it way too seriously.

When someone sees a missing brace in the code they’re seeing a bug six months in the future that caused all sorts of trouble that could be avoided. A different person could see the same thing and just think the code looks prettier. No one is necessarily right or wrong here, but at least everyone should be clear about the value of the decision.