Healthy, productive compromise IS NOT:
Healthy, productive compromise IS:
You’re the mediator who has to resolve conflicts between two engineers. Lucky you. Let’s run some scenarios.
What would you advise that they do?
Bad compromise would be splitting the difference and only adding 2 out of 4 dependencies. For obvious reasons, thats completely ridiculous in this context, but it can be harder to spot elsewhere.
Story time. Years ago, I wanted to adopt Prettier with some colleagues. Some were yay, others were nay. I offered a silly, short-sighted compromise and said:
“I’ll add the Prettier config file and dependency, and those who want to use it can use it. Others can ignore it.”
But that kinda defeats the whole purpose. We did get some partial benefits, but in order to leverage the order-of-magnitude-increase in value that Prettier offers, it has to be a team-wide effort.
Partial adoption leads to, “hey, this code formatter is handy.”
Full adoption leads to, “wow, we do not have to waste time at all on discussing codestyle during code reviews.”
Partial “right down the middle” often isn’t really a compromise at all, it’s just a half-measure, when a full-measure is needed.
Use time as a factor in these discussions. Let’s revisit the same scenario above, pasted below for convenience:
In this case, if Engineer A’s proposal does offer some value, how might we use time as a tool?
Consider: Engineer A and B agree to a trial period. Engineer A offers to take ownership of the project and get it set up, with the understanding that in n weeks, they’ll revisit the tool’s value after taking some metrics:
Looking at these metrics can help answer the simple, but million dollar question:
What’s the right call?
Immediately, we’re faced with the obvious: there’s usually no one right call, but many options with their own pros and cons. Circumstances differ spectacularly from case to case. Either party could be 100% wrong here.
In tie-breakers like this, the decision shouldn’t be left just to a single mediator. While “death by committee” (where an overload of clashing opinions paralyzes the decision-making process altogether) is an ever-present threat, the discussion should ideally involve other voices.
It’s critical, too, that in the ensuing the discussion, the emphasis is not on finding the right answer, because it’s likely that both parties will have strong arguments to support their side. Rarely is one so fantastically wrong that they can be overruled outright. Rather, the discussion should be had with an emphasis on the best implementation to try first.
In the worst case scenario, a manager can leverage their authority to push a decision forward, and in x weeks or months, we can pivot to the same follow-up routine as before: assess the success of the decision and revisit the conversation.
Iteratively and constantly revisiting and improving your workflow should be baked into the conflict-resolution process. In embracing an iterative mindset, “compromise” becomes less an arbitrary, absolute battle of wills - with all of the inevitable politics and bitterness - and more of a collaborative effort, where the shared priority is the efficiency and benefit of the entire team. And in fact, in yielding tactfully to another engineer, you absolutely do bolster your own reputation as being a team player - not with cheap lip service but with action and sincere humility. Win win.
View All Posts