Communication Breakdown — why teammates disagree and how to reach consensus faster
Recently a developer told me a story about how frustrated he got each time he sent his Pull Requests for a review. The team lead would leave 20+ comments on every PR and the dev — let’s call him A. — got terribly angry each time. But A. never said a thing, never shared his frustrations.
That’s a typical example of conflict in an early-stage product team. When there are not yet established agreements about the approach to development, each team member has their own understanding of what good code looks like. This understanding sometimes differs and causes friction.
Common early-stage product team disagreements
We can split typical disputes into two main groups — internal conflicts within the team and external ones with partners/founders/users involved.
Internal conflicts usually revolve around:
- Exactly how a feature should be developed (technical implementation).
- How long development will take (estimation of features, or groups of features, or a specific story).
- Whether the proposed business logic is optimal for solving the specific user problems.
- Whether the proposed design is good.
External conflicts at the early stage occur when:
- Founders want a specific implementation or technical approach — but the team does not agree with this approach.
- Product owners suggest designs that the team deems inappropriate.
- Users have ideas about how exactly their needs should be satisfied and how the app should look. The team believes that the approach is either too hard to implement or no one will actually use such functionality.
- Founders want to define the internal processes of the team — the team wants self-management.
- Founders offer tools (for time tracking, task management or documentation) that are not suitable for the team.
- Founders and the team don't agree on the tech stack.
Interestingly, all of these conflicts appear for just two reasons: the team being really attached to the product or the struggle for power between team members.
Let's take a closer look at how it happens.
Causes of friction in teams and with stakeholders
In general, any conflict arises only if there is an intersection of interests and values. If something is important to both you and your opponent — and at the same time you have different views on the approach to this important phenomenon — this is where you will find conflict.
If you don't care whether you use a relational database or a non-relational one — will you argue with a colleague about a database? Why should you waste any minute of your time on this?
And this is actually good news for your team. If you are arguing about a product, it means that both you and your opponent care about the product and it is valuable for you.
If the team is arguing about which design is better, then the team members care about the design. Any hour-long debate about how implement a feature is a debate between those who are keen to find the best approach. Because the product matters to them.
Of course, sometimes a conflict is just an attempt to figure out who has more power in the room. There are people who just like to know (or prove) that they are the most important figures. But even they often still care about the product and want to prove their power in order to then make the best decision.
Given the above — how can conflicts be handled so that they lead to better product development, and not paralyze it?
Steps to problem solving
Every person has a dominant/preferable conflict style, a behavior we tend towards when we are involved in a conflict. And in total there are five main styles - Competing, Avoiding, Compromising, Accomodating and Cooperating.
Each of them means what is hidden in the name:
- Competing: competition, argument, a tendency to prove that "my way" is correct.
- Avoiding: the exact opposite, avoiding conflict, denying the search of a solution — there is "no way".
- Accomodating: making concessions — renunciation of one's own interests, let's take "your way".
- Cooperating: finding a common path suitable for all — "our way".
- Compromising: something in between, a search for a solution that does not suit both sides — "their way".
In fact, each of these approaches has the right to life and is even effective in certain situations. The effectiveness of the approach is determined by two factors: the value of the subject of the conflict and the value of one’s relationship with the other party in the conflict.
Depending on the value of the subject and the value of the relationship, it is optimal to choose perhaps not your typical conflict style, but the most suitable one.
Thus, competing is best suited for situations where the subject of the dispute is important to you, but the relationship is not. And avoidance is only suitable for situations where both the subject of the dispute and the relationship are not important to you.
But any product team is a group of people who work together for a long time. So the relationship within the team or between the team and the product owner/founders is always important.
Choose: Cooperation or Accomodation
Therefore, the only approaches relevant to team conflicts are cooperation and accomodation. This means that in any conflict within the team, the best way through will be:
- if the topic of the dispute is really important to you, look for a solution that will suit both parties.
- and if the topic is not very important, give way to the opponent (and move on without resentment).
And I specifically do not consider compromise as a worthy approach.
In fact, compromise is the worst way to resolve the conflict because both parties remain unsatisfied — and the best solution has not been found.
Accommodation is the easy go-to — just decide not to debate anymore — and bingo, no more conflict! But what if something is important to both you and your opponent and you don’t want to give up?
Here it is important to go back to the beginning and remember that you are both fighting for the product. You have at least one common point — you both want the product to become better. This is a good start.
Then you can analyze together or with the help of an independent third party which is the best way to improve the product. It’s vital to constantly remind yourself that not only you are fighting for the quality of the product.
Your opponent is doing exactly the same, just from another perspective.
Usually this is enough to easily find a solution that suits everyone.
Mitigating future disagreements
The best advice I have about mitigating future team disagreements is not to mitigate them. Our society tends to be afraid and silent about conflicts. But in fact, any dispute or conflict in the team is a clear indicator that the team is interested in the product.
If the conflict becomes exclusively personal, you need to look for hidden motives, reasons, old grievances that cause the current disagreement. In a situation of acute conflict between team members, you cannot do without a mediator — a calm third party that can sort out the conflict.
But if you or your colleagues like to argue about design — rejoice, your design will be brilliant. Just remember that you share common goals. In any incomprehensible situation, look for ways to cooperate.
So yes, if your team members leave 20+ comments on each pull request - make sure everyone in the team understands it’s a perfectly good thing. This means they really review the code and are interested in the final product.
Want a real example of how improving communication helps early-stage teams ship faster and build better? Have a look at our latest collaboration with Lighthouse.
