The Origin of Conflict in a Team

Conflict management is a topic that many leaders and professionals discuss, offering a range of techniques and strategies on how to handle conflict effectively. You’ll often come across frameworks like the five techniques of conflict management, which are widely accessible and frequently referenced. However, rather than simply reiterating these methods, I want to dive into a real-life experience—a conflict that unfolded between a designer and a developer in my team. This isn’t just about what happened, but why it happened. What were the underlying causes? And how did I, as the project manager, contribute to both the escalation and, ultimately, the resolution of the conflict?

Why Conflict Exists

At the heart of this reflection is a belief I hold strongly: people are generally good-natured. In most cases, conflict arises not because someone chooses to be difficult, but because certain conditions push them to act in ways that are uncooperative or defensive. In corporate settings, we might label someone a “micromanager” or a “non-cooperative team member,” but these are just surface-level descriptions of deeper problems. The real question is, how does conflict form in the first place?

Conflict doesn’t appear out of thin air. It builds up gradually, in stages, often without people even realizing it. Here’s how I see that process unfold:

1. Belief Systems: Everyone comes into a situation with their own set of beliefs, shaped by their past experiences. These beliefs influence how they view their role, their work, and the expectations they place on others.
2. Assumptions: After belief systems are in place, assumptions begin to form. People start making assumptions about how others should behave, often without questioning whether these assumptions are fair or accurate. Assumptions are particularly dangerous because they’re shaped by personal biases and aren’t always based on facts.
3. Opinions: Over time, these assumptions solidify into opinions. At this stage, people begin to form judgments about others based on their assumptions, further reinforcing the divide.
4. Perspectives: Finally, these opinions evolve into fixed perspectives. Now, two people can look at the same situation but interpret it in completely different ways, leading to misunderstandings and conflict.

The Conflict Between the Developer and Designer

Let’s apply this process to the specific conflict I encountered between the developer and designer on my team.

• The developer had a strong belief that projects should run on a strict schedule. In his view, getting the assets on time was crucial for his ability to complete tasks efficiently.
• The designer, on the other hand, believed that creativity couldn’t be rushed. She needed space to perfect her work before handing it off to the developer.

From here, assumptions began to take root:

• The developer assumed the designer was being unproductive or simply not prioritizing the deadlines.
• The designer assumed the developer was being rigid and unsympathetic to the creative process.

These assumptions soon turned into opinions:

• The developer started seeing the designer as unreliable.
• The designer viewed the developer as demanding and overly strict.

Finally, these opinions formed conflicting perspectives:

• The developer believed his frustration was justified because he couldn’t move forward with his work.
• The designer felt stifled, believing her work wasn’t being valued for its quality, only its speed.

What began as a simple workflow issue—delayed assets and design standards not being followed—had now escalated into a full-blown conflict, each party locked into their perspective. This is how conflicts take shape: slowly, through a series of assumptions and misinterpretations, until they reach a point where collaboration becomes strained.

My Failures as a Manager

As the conflict reached its peak, I made a critical mistake—I took the developer’s side. To me, it seemed straightforward: the designer wasn’t delivering assets on time, and this was holding the project back. But I didn’t stop to consider the designer’s point of view, and in doing so, I inadvertently isolated her. I failed to address the root causes of the conflict, focusing only on what I thought was the immediate problem. In hindsight, this made everything worse.

Here’s where I went wrong:

1. Not Supporting Both Sides Equally: My first mistake was not creating a balanced environment where both the developer and the designer could voice their concerns. The designer felt singled out and unsupported, which only deepened the divide. It’s crucial for a manager to provide equal support to all parties in a conflict, so no one feels alienated.
2. Failing to Create a Safe Environment for Discussion: Instead of fostering a space where both individuals could express their frustrations and needs, I zeroed in on the problems. I should have ensured that both the developer and the designer felt comfortable discussing the situation without fear of judgment or blame. If people don’t feel safe to speak up, meaningful solutions will never emerge.
3. Not Documenting the Conflict: I also neglected the importance of documentation. I should have kept track of the ongoing conflict and the points discussed during our resolution meetings. Without documentation, it became difficult to pinpoint the core issues, and every conversation felt like we were starting over. If I had documented the conflicts early on, we could have focused on resolving the key issues rather than rehashing them.
4. Trying to Solve the Problem Myself: One of my biggest mistakes was assuming it was my responsibility to solve the conflict. I thought I had to fix everything, but in reality, the designer and developer knew the situation better than anyone else. As a manager, I should have facilitated the conversation, allowing them to collaborate on finding a solution, rather than imposing my own.
5. Overlooking Dependency Issues: I also missed a critical aspect of the designer’s struggles—she didn’t have all the necessary information to complete her tasks. She was forced to go back and forth between various parties to get what she needed, which delayed her work. Had I intervened earlier and removed these bottlenecks, I could have alleviated much of her frustration and prevented the conflict from escalating.

Lessons Learned: How I Would Handle It Differently

Looking back, I recognize that my approach contributed to the conflict’s escalation. But from this experience, I’ve learned several valuable lessons that have changed the way I manage conflict in teams.

1. Support Both Sides: In any conflict, it’s vital to support both parties equally. Even if one side seems more “right” on the surface, you need to dig deeper to understand the full picture. Both the developer and designer had valid concerns that needed to be addressed.
2. Create a Safe Space for Dialogue: Open, honest communication is key to resolving conflicts. In the future, I’ll focus on creating a safe environment where everyone feels comfortable sharing their thoughts without fear of blame or judgment.
3. Document the Conflict: Moving forward, I’ll make sure to document issues from the start. This prevents confusion and ensures that we’re addressing the real issues, not just getting caught in a loop of complaints.
4. Facilitate, Don’t Dictate: It’s not my job to come up with the solutions; my job is to help the team find the solution themselves. In the case of the designer and developer, they knew their work better than I did. By stepping back and allowing them to collaborate, we could have reached a resolution more quickly and effectively.
5. Address Bottlenecks Early: I now recognize the importance of identifying and removing obstacles that prevent people from doing their best work. If I had acted sooner to remove the designer’s dependencies, much of the conflict could have been avoided.

Conclusion: The Path to Better Leadership

Conflict is inevitable in any team, but how we respond to it makes all the difference. As leaders, we must be aware of our own biases, create an environment of trust, and facilitate open communication. We must also remember that conflict rarely arises from a single event—it builds over time, through assumptions and miscommunications, until it becomes a much larger issue. My experience with the developer and designer taught me that it’s not just about solving the conflict at hand, but understanding why it happened and how to prevent it from recurring.

While I made mistakes in handling this situation, I learned from them, and those lessons have made me a more thoughtful and effective leader. The key to managing conflict is to listen, support, and create the conditions for resolution, rather than imposing your own solution. In doing so, you foster a healthier, more collaborative environment where everyone feels valued—and where conflicts are addressed before they escalate.