The post has been translated automatically. Original language: Russian
In good code, logic is built on different conditions and scenarios. There is no complete agreement of opinion in a good team either.
Different roles, experiences, priorities, and ways of thinking inevitably create disagreements, so conflict in itself is not a bug. The bug starts when the team doesn't know how to work with it.
What is useful to remember
Google research has shown that one of the key factors in team effectiveness is psychological safety—the ability to ask questions, admit mistakes, offer ideas, and disagree without fear of being punished or ridiculed.
That is, a strong team is not one where no one argues.
And the one where the dispute does not destroy relationships and work.
What does a useful conflict look like?
A useful conflict is:
idea versus idea
but not:
man against man
A useful argument might sound like this:
→ "I see a risk here"
→ "I disagree with this decision because..."
→ "Let's check another option"
→ "What data supports this hypothesis?"
Not useful:
→ "You're complicating things again"
→ "It's impossible to work with you"
→ "I told you so"
The difference is not in the presence of voltage, but in where it is directed.
01. Discuss the problem, not the person.
Instead of: "You're not paying attention."
better: "The requirements were lost twice in this task."
Instead of: "You're constantly slowing down the project"
better: "At this stage, we are already going over the deadline for the third time."
The more specific the wording, the less a person has to defend themselves instead of solving a problem.
02. Add Data
The conflict quickly becomes emotional when the dispute is based on:
"I think"
against:
"But it seems to me otherwise."
They help:
→ numbers
→ verification results
→ User data
→ deadlines
→ System limitations
→ pre-agreed criteria
The data doesn't remove disagreements, but it makes them substantive.
03. Don't accumulate bugs in a relationship
Minor irritation is easy to put off:
"We'll discuss it later."
Then another episode happens. Then another one. And suddenly, the conversation is no longer about a specific task, but about all the problems over the past six months.
The same logic works with conflicts as with technical bugs: the longer it takes to sort them out, the more difficult it is to fix the situation later.
04. Not solving everything in correspondence
The text is great for:
→ transfer of facts
→ Short updates
→ fixing agreements
But a difficult conflict is not always. There is no intonation, pauses, or facial expressions in the correspondence. A neutral message can easily be read as aggressive. If there are more messages and less understanding, it may be time to start talking.
Sometimes 15 minutes of communication saves dozens of messages.
05. Check what the dispute is really about
The team can argue about the button.
But the real contradiction may be quite different.:
→ speed or quality
→ current result or long-term solution
→ independence or control
→ rapid effect or sustainability in the future
While the main contradiction has not been named, you can endlessly discuss the details.
A useful question is: "What are the two priorities clashing here?"
06. Fix the decision
After a good argument, it should be clear:
→ What have you decided
→ why
→ Who is responsible
→ what do we do next
Otherwise, the discussion can easily start over in a week.
Good consistency:
discussion
→ solution
→ action
But not:
discussion → discussion→ discussion
07. Don't always try to come to a complete agreement.
The team does not have to unanimously support every decision.
Sometimes it's enough:
→ I was against it
→ You've heard my arguments
→ the decision has been made
→ then I support the team.
The ability to disagree and move on anyway is a separate professional skill.
And if there are no conflicts at all?
This is not always a good sign. Sometimes everyone really agrees, and sometimes people just realized it wasn't safe to argue.
Therefore, the goal is not the complete absence of conflicts. Another indicator is much more useful: can we disagree with each other and then work together normally?
If yes, the system can handle it.
В хорошем коде логика строится на разных условиях и сценариях. В хорошей команде тоже не бывает полного совпадения мнений.
Разные роли, опыт, приоритеты и способы мышления неизбежно создают разногласия, поэтому конфликт сам по себе — не баг. Баг начинается тогда, когда команда не умеет с ним работать.
Что полезно помнить
Исследования Google показали, что одним из ключевых факторов эффективности команды является психологическая безопасность — возможность задавать вопросы, признавать ошибки, предлагать идеи и не соглашаться без страха быть наказанным или высмеянным.
То есть сильная команда — не та, где никто не спорит.
А та, где спор не разрушает отношения и работу.
Как выглядит полезный конфликт
Полезный конфликт — это:
идея против идеи
а не:
человек против человека
Полезный спор может звучать так:
→ «Я вижу здесь риск»
→ «Я не согласен с этим решением, потому что…»
→ «Давайте проверим ещё один вариант»
→ «Какие данные подтверждают эту гипотезу?»
Неполезный:
→ «Ты опять всё усложняешь»
→ «С тобой невозможно работать»
→ «Я же говорил»
Разница не в наличии напряжения, а в том, куда оно направлено.
01. Обсуждать проблему, а не личность
Вместо: «Ты невнимательный»
лучше: «В этой задаче дважды потерялись требования».
Вместо: «Ты постоянно тормозишь проект»
лучше: «На этом этапе мы уже третий раз выходим за срок».
Чем конкретнее формулировка, тем меньше человеку приходится защищать себя вместо решения задачи.
02. Добавлять данные
Конфликт быстро становится эмоциональным, когда спор строится на:
«Мне кажется»
против:
«А мне кажется иначе».
Помогают:
→ цифры
→ результаты проверки
→ данные пользователей
→ сроки
→ ограничения системы
→ заранее согласованные критерии
Данные не убирают разногласия, но делают их предметными.
03. Не копить баги в отношениях
Небольшое раздражение легко отложить:
«Потом обсудим».
Потом происходит ещё один эпизод. Потом ещё один. И внезапно разговор уже идёт не о конкретной задаче, а обо всех проблемах за последние полгода.
С конфликтами работает та же логика, что и с техническими багами: чем дольше их не разбирать, тем сложнее потом исправить ситуацию.
04. Не решать всё в переписке
Текст отлично подходит для:
→ передачи фактов
→ коротких обновлений
→ фиксации договорённостей
Но сложный конфликт — не всегда. В переписке нет интонации, пауз и мимики. Нейтральное сообщение легко прочитать как агрессивное. Если сообщений становится больше, а понимания меньше — возможно, пора перейти к разговору.
Иногда 15 минут общения экономят десятки сообщений.
05. Проверять, о чём спор на самом деле
Команда может спорить о кнопке.
А реальное противоречие может быть совсем в другом:
→ скорость или качество
→ текущий результат или долгосрочное решение
→ самостоятельность или контроль
→ быстрый эффект или устойчивость в будущем
Пока главное противоречие не названо, можно бесконечно обсуждать детали.
Полезный вопрос: «Какие два приоритета здесь сталкиваются?»
06. Фиксировать решение
После хорошего спора должно быть понятно:
→ что решили
→ почему
→ кто отвечает
→ что делаем дальше
Иначе обсуждение легко начинается заново через неделю.
Хорошая последовательность:
обсуждение
→ решение
→ действие
А не:
обсуждение → обсуждение→ обсуждение
07. Не стремиться всегда прийти к полному согласию
Команде не обязательно единогласно поддерживать каждое решение.
Иногда достаточно:
→ я был против
→ мои аргументы услышали
→ решение принято
→ дальше я поддерживаю команду
Способность не согласиться и всё равно двигаться дальше — отдельный профессиональный навык.
А если конфликтов вообще нет?
Это не всегда хороший знак. Иногда все действительно согласны, а иногда люди просто поняли, что спорить небезопасно.
Поэтому цель — не полное отсутствие конфликтов. Гораздо полезнее другой показатель: можем ли мы не соглашаться друг с другом и после этого нормально работать вместе?
Если да — система справляется.
Share
