Not long ago, I was presented with a routine, even boring, workplace problem. We redesigned a part of our website and altered some basic functionality. Some colleagues learned of the change only when they went online, and were baffled by the new flow. And so began a tempest: Why was this change made? Who had given the OK? And wasn't the old way better, anyway?
This was just one small huff in the long history of conflicting opinions. But as a company grows, and decisions get more distant from the people who have to execute them, a different kind of conflict emerges. These disputes may seem like they're about a single decision with a specific adverse effect (the wrong redesign). But they're actually disagreements about process (Why wasn't I consulted?), not the decision. Learning to distinguish between the two is invaluable for any leader.
Here's how I've learned to map the difference. A decision conflict is one in which colleagues disagree about a choice that was made--anything from choosing a product strategy or a company priority or the wording of an email campaign. When someone disagrees, it's a pretty simple matter to determine if the objection has merit, or whether it's an opinion that will be duly noted but not addressed. You make the call and move on.
But a process conflict is a different beast. Disagreements over process emerge when a decision lacks expected input or participation from meaningful stakeholders, or where one decision (often made unilaterally) contradicts shared priorities or strategies. In these cases, protocol was not followed, and unpacking the problem requires chasing down what happened and why.
Here's what I've learned after about a decade of startups: These are distinct kinds of conflicts, but they get conflated all the time, and a process conflict gets treated as a decision conflict. This means that people waste time and energy trying to solve the wrong problem: They're second-guessing and litigating the decision, when the real grievance is that a process wasn't followed. Indeed, the aggrieved may not truly disagree with the decision at all, but are putting up a fight because they weren't consulted along the way.
And as obvious as the difference between a decision conflict and a process conflict might appear, in the heat of the moment most people struggle to disentangle the two. Often, leaders will reverse a decision but miss the opportunity to delineate a process that would help sort out disputes down the line. In other words, they solve the wrong problem.
It's essential for leaders, especially in rapidly expanding startups, to grow their organization's decision-making process in lockstep with scaling the organization. I've failed to do this myself. A few years ago, I was in a leadership meeting in which a new production process was presented for final executive approval. Despite being an executive, I was caught off-guard: The new process would require that I change the way I worked. My response, sad to admit, was to question the whole thing, creating more than a hiccup in the rollout. In time, I realized my issue wasn't with the new--and better--schedule, but with the fact that I hadn't really been given a heads-up about its requirements.
These days, when I'm presented with a grievance, I've learned to first hold the problem up to the light: Is this really about a failure in decision making, or is the issue a failure of process? More often than not, it's the process that went south. So, if you find yourself in this kind of situation, step back and make sure that protocols are heeded--or, if necessary, make those protocols clear for everyone. The distinction won't spell the end of conflicts in your organization. But it will help you better solve those that arise.