Навеяно комментариями к прошлому моему посту или синдром диванного эксперта в IT-командах.

Задумайтесь, как влияют на команду люди, которые щедро раздают советы, но не берутся за их реализацию? Замедляют ли они прогресс, подрывают ли мотивацию коллег или приносят пользу?

Замечали, как часто в IT‑командах, да и не только в IT, сотрудники охотно высказывают критику, но редко подкрепляют её реальными действиями?

Почти любой разработчик может с ходу назвать десяток недочётов: архитектура слишком сложная, система не масштабируемая, комментарии к коду неинформативны и т.д. и т.п. Коллеги легко находят изъяны в чужом коде, дизайне интерфейса или плане проекта и щедро делятся мнением.

Парадокс в том, что многие из таких «экспертов» сами не спешат брать задачу в работу. Почему так происходит?

Причин несколько:

Зона комфорта. Предлагать правки со стороны проще, чем вникать в чужой код, разбираться в зависимостях и писать код самостоятельно. Сотрудник остаётся в безопасной позиции наблюдателя.   Страх ошибки. Критикуя со стороны, человек не несёт прямой ответственности за решение. Если же взять задачу в работу, придётся отвечать за результат, а это вызывает тревогу, если не страх. Признайтесь честно, бывало ли у вас так, что вы предпочли промолчать, чтобы не брать на себя лишнюю ответственность?   Отсутствие полномочий. Хорошая идея может не пройти без одобрения тимлида или архитектора. Было так в вашей практике, что ваш руководитель не пропускал вашу идею? Как это повлияло на мотивацию?   Иллюзия экспертности. Некоторые сотрудники подсознательно выстраивают картину мира по принципу «у них всё плохо, а у меня хорошо». Это создаёт ложное ощущение превосходства. Они фокусируются на чужих ошибках, не замечая собственных пробелов или зон роста. Читал, что психологи связывают это с эффектом Даннинга‑Крюгера - люди с поверхностными знаниями склонны переоценивать свою компетентность и потому охотно критикуют других.   Мышление «синкеров», а не «дуиров». Часть сотрудников застревает на стадии размышлений и критики (thinkers), вместо того чтобы переходить к действиям (doers). Им комфортнее анализировать и указывать на недостатки, чем брать на себя риск реализации. В условиях неопределённости такой подход особенно выгоден. Всегда проще объявить задачу «невыполнимой» или «некорректной», чем искать пути её решения.   Социальное подкрепление. Часто критика становится способом завоевать признание в коллективе. Высказав замечание, сотрудник получает внимание и даже одобрение коллег. Это формирует привычку вместо реальных действий выбирать лёгкий путь «экспертного» комментария. Замечали ли вы, что кто‑то в команде использует критику как способ привлечь к себе внимание, повысить свою значимость?   В итоге критика повисает в воздухе. Замечания есть, а ни изменений, ни улучшений нет.   Мой подход – не просто указывать на проблемы, а предлагать конкретные шаги её решения. Это может быть мини‑план рефакторинга, пример подходящего паттерна проектирования, прототип интерфейса или хотя бы такая формулировка: «Я вижу здесь риск, давайте обсудим, как мы можем его нивелировать?».

Так критика превращается из самоутверждения в конструктивный вклад. Команда движется вперёд, а не тратит время на бесконечные обсуждения.   Поделитесь, есть ли в вашей команде «диванные эксперты»? Как они влияют на общий настрой и продуктивность? Какой подход помог вам превратить пустую критику в реальные улучшения?

#управлениекомандой #управлениекомандами #финтех #ИТ #разработкаПО