Почти в каждой достаточно большой IT-команде рано или поздно появляется человек, про которого коллеги думают примерно одно и то же: с ним тяжело.

Самое интересное, что сам он совершенно не обязательно считает себя сложным человеком. Наоборот: он прямой, принципиальный, требовательный, профессиональный и просто переживает за результат.

Если перевести эгосинтонность на язык IT, получается довольно точная формула: окружающие уже видят баг, а внутри собственной системы человека он всё ещё зарегистрирован как фича.

Разработчик понимает, что не успевает, но молчит до последнего. Сильный специалист не делегирует, потому что другим не доверяет. Тимлид видит, что проблема выходит за пределы команды, но боится сообщить наверх.

Психологический процесс начинает влиять на работу раньше, чем появляется событие, которое мы уже называем проблемой. Разбираю, как замечать такие сценарии раньше — и почему профилактика начинается не только с сотрудника, но и с безопасной среды внутри команды.

«На тестах всё работало». Любой разработчик слышал эту фразу хотя бы раз. В психотерапии происходит нечто похожее: человек может прекрасно понимать свою проблему на сессии, но в реальной жизни снова автоматически реагировать по-старому. Используя аналогии из разработки, я попробую показать, почему настоящее изменение проверяется не в кабинете психолога, а в том самом «проде», ради которого человек вообще пришёл в терапию.

В 1968 году Филип К. Дик написал роман «Мечтают ли андроиды об электроовцах?». В мире книги эмпатия становится одним из признаков, по которым человека пытаются отличить от андроида. Для этого используется вымышленный тест Войта-Кампфа, проверяющий эмоциональные реакции.

Я начал эту статью с гипотезы об эмпатии разработчиков, но исследований, которые позволили бы подтвердить её, не нашёл. Зато обнаружил более интересный вопрос: как эмоции влияют на вполне рациональные инженерные решения и что происходит, когда мы этого влияния не замечаем.

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

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

Я называю это «синдромом Данилы-мастера»: специалист уже не просто решает задачу, а пытается доказать с её помощью собственное мастерство. Разберём, как перфекционизм связывается с самооценкой, почему очевидные советы о декомпозиции могут не работать и как небольшой законченный шаг возвращает человеку способность двигаться дальше.

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

Полезные качества руководителя иногда начинают работать против команды. Осторожность превращается в подозрительность, ответственность — в гиперконтроль, а опыт неудач — в ожидание очередного провала. Разбираю три психологических стиля управления и показываю, как поведение руководителя постепенно создаёт именно ту команду, которой он опасается.

Чем надёжнее разработчик, тем дольше окружающие могут не замечать, какой ценой ему даётся работа. Эта статья — практическая памятка о том, как вовремя заметить перегрузку, заканчивать рабочий день, не переносить инженерный режим в отношения и обращаться за помощью до того, как состояние станет критическим.

За годы управления инженерными подразделениями я совершал одну и ту же ошибку: больше внимания уделял тем сотрудникам, чьи проблемы уже были заметны. А самых надёжных оставлял в покое, считая это формой доверия.

Однажды один из сильнейших инженеров моей команды неожиданно пришёл с заявлением об увольнении. Только после долгого разговора выяснилось, что два месяца назад он просил отпуск, а я пообещал решить вопрос и забыл. Он же ни разу не напомнил.

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

Инженер может несколько дней перепроверять решение и выглядеть очень ответственным. Но иногда новые проверки уже не дают информации, а лишь ненадолго уменьшают сомнения. Разбираю, как анализ превращается в способ откладывать действие и какое условие выхода помогает остановить этот цикл.

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