Привет, Хабр! Меня зовут Андрей Бирюков. Я являюсь независимым экспертом в области ИТ и ИБ, преподаю в учебных центрах и пишу книги. Каждая компания‑разработчик хочет иметь в своей команде сильных специалистов, и зачастую поиск и найм таких спецов ограничивается только бюджетом. Однако в этой статье мы рассмотрим ситуацию, в которой у нас была возможность нанять гениального одиночку, но в итоге мы получили токсичный актив, разрушивший всю команду.

Перспективная история с грустным концом

Итак, у нас есть команда из 6 разработчиков среднего уровня, работающих над флагманским продуктом. Скорость — нормальная, качество — приемлемое, но есть одна проблема: архитектура старого модуля трейдинга тормозит развитие. Руководитель — опытный тимлид, которого наняли полгода назад, чтобы «ускорить команду».

Тимлид принимает решение, которое кажется ему идеальным. Он находит на рынке разработчика с 12-летним опытом, который раньше работал в крупной западной компании, писал высоконагруженные системы и знает три языка программирования на уровне эксперта. Этот разработчик произвел прекрасное впечатление на собеседовании: он решает сложные алгоритмические задачи быстрее всей панели интервьюеров вместе взятых.

Чтобы заполучить этого разработчика, тимлид выбивает зарплату в два с половиной раза выше средней по команде. Логика простая: «Рок‑звезда вывезет сложный модуль за три месяца, а потом подтянет остальных».

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

Но через пару месяцев начинаются проблемы. Наш вундеркинд категорически отказывается писать документацию («Код сам себя документирует для тех, кто умеет читать»). Code review от него выглядит одинаково: «Это не работает, перепиши с нуля» — без объяснений. Джуниор, попросивший помощи, услышал: «Читай документацию к фреймворку, я не репетитор».

Дальше — хуже. Модуль, который он разрабатывает, работает идеально, но никто в нём не может изменить ни строчки — слишком неочевидная архитектура и плотный, переусложнённый код. Остальные разработчики чувствуют себя некомпетентными и перестают предлагать идеи на планерках. Два инженера, которые раньше были лидерами команды, подали заявления — «атмосфера больше невыносима».

И что же мы получаем через полгода. Наша рок‑звезда работает по 60 часов в неделю, потому что всё замыкается на нём. Он выглядит измотанным, несколько раз на стендапе огрызался на вопросы. Тимлид понимает, что допустил ошибку, но не знает, что делать: уволить гения — потерять единственного человека, понимающего новый модуль; оставить — потерять остальную команду.

Это классический сценарий ошибки найма «рок‑звезды». Теперь давайте разбираться с тем, кто и в чем допустил ошибку и что теперь делать.

Ошибка руководителя

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

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

Далее идет недооценка культурных навыков. Мы нанимали «архитектора‑спасателя», не проверив его готовность к наставничеству, документации и pair programming. На собеседовании спрашивали о сложных алгоритмах, но ни разу не спросили: «Как ты объяснял сложную тему коллеге? Как реагировал, когда код новичка не проходил ревью?»

Еще одна ошибка — это игнорирование превентивных индикаторов. Уже на второй неделе наш гений отказался писать документацию. Это был первый звоночек, но тимлид не придал ему значения — «главное, чтобы код был». Звоночки копились, а руководитель списывал их на «особенности творческой личности».

И наконец, отсутствие системы онбординга для «звёзд». Разработчика бросили в команду без чётких правил и ожиданий. Ему никто не сказал: «Мы ценим твою скорость, но у нас есть правило — код без пояснительных комментариев и документации не принимается». Руководитель создал вакуум, который наш «мегаразраб» заполнил своей моделью работы.

То есть, в итоге, у нас получается, что руководитель купил «супер‑код», не осознавая, что платит за это демотивацией всей команды и созданием bus‑фактора (один человек — единственное звено, при котором система не развалится).

Автобус… и другие риски и последствия

Поговорим о том, какие риски и проблемы мы получили в итоге. Начнем с так называемого bus‑фактора. Если нашего мегагения завтра собьёт автобус (или он уволится), проект останавливается на 2–4 недели минимум. Никто другой не понимает его модуль. Количество людей, способных безопасно задеплоить изменение, равно одному. Это прямое следствие отказа от документации и от совместного написания кода.

Еще одно последствие — это падение скорости команды. Да, рок‑звезда пишет код быстро, но все остальные… Замеры показывают: скорость принятия pull request от обычных разработчиков упала на 50%. Почему? Наш гений блокирует ревью своими саркастическими комментариями. Кроме того, остальные инженеры начали тратить время на безуспешные попытки понять его код или на рефакторинг того, что он набросал в спешке.

В итоге мы получаем рост текучки среди «середняков и перформеров». Самые ценные средние и сильные разработчики уходят первыми. Они видят, что их идеи не ценятся, а карьерный рост заблокирован. Гений занимает весь кислород в архитектурных обсуждениях. Формула: один «рок‑звезда» может вызвать увольнение 2–3 хороших инженеров за полгода. Стоимость замены каждого — 3–6 месяцев зарплаты.

Не стоит сбрасывать со счетов и скрытое выгорание самого нашего гения. Он работает один — 60 часов в неделю, без подстраховки, без обсуждений. Его код становится всё сложнее, потому что некому задать вопрос «а можно проще?». Через 6–9 месяцев такой нагрузки он либо срывается, либо уходит в другую компанию, где «больше амбициозных задач». Итог: вы потеряли и команду, и «звезду».

И в завершении мы получаем эрозию психологической безопасности в команде. Джуниоры и мидлы перестают задавать вопросы, потому что боятся услышать «ты что, этого не понимаешь?». Код‑ревью превращается в судилище. Атмосфера из «мы вместе» превращается в «Я Д'Артаньян, все … я один гений, а вы статисты«.»

Все эти последствия имеют количественные индикаторы, которые тимлид обязан отслеживать. Если они появились — ошибка уже совершена. Вопрос только в том, насколько глубоко вы внутри провала.

Итак, мы разобрались с проблемой, теперь давайте рассмотрим способы предотвращения подобной ситуации.

Как распознать «токсичную звезду» на собеседовании и в первые недели

Что можно спросить у соискателя на собеседовании для того, чтобы выявить описанные выше риски.

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

• Не принимайте ответы типа «я дал ссылку на документацию» или «я поправил его код сам». Ищите развёрнутое объяснение, терпение, описание того, как человек адаптировал сложную тему под уровень слушателя.

• Далее стоит спросить о документации: «Твой код через год будет читать другой инженер. Что ты сделал за последний год, чтобы ему было легче?»

• Если кандидат говорит «мой код самодокументируем» или «не пишу комментарии, они устаревают» — красный флаг. Документация бывает разной, но полный отказ от неё в командной разработке — это риск.

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

• Ищите не идеальный ответ, а отсутствие агрессивной защиты. Если кандидат рассказывает, как он объяснял, почему его решение лучше, и при этом не обесценивал мнение коллеги — хорошо. Если говорит «меня редко критикуют, потому что я пишу хорошо» — насторожитесь.

• Помимо собеседования, диагностировать «токсичную звезду» можно по первым неделям работы. Например, посмотрите на его реакцию на стандарты команды. Дайте ему почитать ваш гайд по кодстайлу и документации. Если он говорит «это бюрократия, я не буду этому следовать» — у вас проблема. Хороший инженер обсуждает стандарты, плохой их игнорирует.

Индикатор второй — первое общение с джуниором. Посмотрите, как новый разработчик отвечает на вопрос новичка (подойдите и послушайте, не предупреждая). Если ответ раздражённый или насмешливый — это не исправится само.

И еще один индикатор — это готовность к парному программированию. Предложите разработчику написать первую задачу в паре с кем‑то из команды. Если он отказывается («я быстрее один») — вы получили одиночку, и в командной разработке это минус.

Если вы видите хотя бы два красных флага из шести (три вопроса собеседования + три индикатора первой недели) — не нанимайте, либо нанимайте с чётким контрактом «ты делаешь X, Y, Z, иначе испытательный срок».

А если все совсем плохо

Теперь рассмотрим более сложный сценарий: ошибка совершена, наш rock star сидит в команде, и проблемы нарастают. В такой ситуации руководитель может начать с личного разговора (не обвинительного, а конструктивного) с проблемным сотрудником наедине. Говорите не «ты токсичный», а «у нас есть командные правила, которые я как руководитель не донёс до тебя в начале». Перечислите три незыблемых правила:

• код‑ревью не содержит личных оценок и требует объяснений;

• документация обязательна для любого публичного модуля;

• отказы от помощи коллегам не принимаются.

Далее, назначьте ему официального «менти» из джуниоров на 2 часа в неделю (это часть его рабочего времени, а не благотворительность). Объясните: «Мы наняли тебя не только писать код, но и растить команду. Это тоже твоя задача, и мы будем её оценивать».

И введите практику «парного ревью»: pull request нашего гения проверяет не только он (в смысле, он принимает), но хотя бы один другой разработчик. И наоборот — он комментирует чужой код, но не блокирует его без объяснения.

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

Если в течение 3–5 месяцев ситуация не меняется в лучшую сторону, введите персональные цели для данного работника на квартал, привязанные к командным метрикам. Например:

• написать документацию на два ключевых модуля;

• провести три тренинга для команды;

• снизить время ревью для чужих pull request до 24 часов.

Без выполнения этих целей — бонус не выплачивается.

Также документируйте случаи токсичного поведения (конкретные фразы, даты, отказ от помощи). Не для того чтобы наказать, а чтобы у вас была объективная картина. Поговорите с командой анонимно (опросник) — «как влияет на вашу работу присутствие нашего гения?».

А еще здесь нужен чёткий тайм‑бокс: через 4–6 недель вы подводите итог. Если метрики команды (скорость, количество инцидентов в его модуле при попытке изменений другими, удовлетворённость коллег) не улучшились — вы переходите к… да, вы правильно поняли, к увольнению.

Парадокс, но уволить «рок‑звезду» часто оказывается менее болезненно, чем оставить. Да, вы потеряете модуль, который он написал. Но вы сохраните команду из 5–6 хороших инженеров, которые без него сделают больше и лучше за 2–3 месяца.

Для увольнения без лишних проблем заморозьте новый функционал в его модуле на 2–3 недели. Команда за это время пишет документацию и тесты к тому, что он наделал (да, придётся разбираться, но это неизбежно). И параллельно ищите замену — не другую «рок‑звезду», а хорошего, стабильного инженера, который умеет работать в команде. Зарплата может быть средней, но с чёткими ожиданиями по коммуникации.

Увольнение по соглашению сторон (без скандала). Уже не нашему гению подойдёт другая компания, где ценят одиночек‑архитекторов. Ваша компания — командная. Это не хорошо и не плохо, это просто разная совместимость.

После увольнения проведите ретроспективу с командой. Не «какой гений был плохой», а «как мы позволили возникнуть такой ситуации и как не допустим повторения».

Выводы

Ошибка найма «рок‑звезды» — это не история про плохого инженера. Это история про руководителя, который не задал вовремя вопрос: «Как этот гениальный одиночка повлияет на остальных пятерых?».

Самый продуктивный разработчик в мире не стоит демотивации всей команды и создания bus‑факторов. Нанимайте сильных, но проверяйте не только IQ, но и умение усиливать других. И если ошибка уже совершена — не тяните с исправлением. Уволить «звезду» иногда бывает лучшим управленческим решением за год.

Если после статьи захотелось не просто кивнуть «да, так бывает», а понять, как такие ситуации диагностировать и не доводить до развала команды, присмотритесь к открытым урокам OTUS. Они бесплатные, проходят в рамках онлайн‑курсов и помогают проверить, насколько вам близок формат обучения.

• 20 мая, 20:00 — «Системная диагностика команды и группы команд». Записаться
  _{На уроке поговорим о том, как замечать проблемы в команде не по ощущениям, а по сигналам, метрикам и повторяющимся управленческим паттернам.}

• 2 июня, 20:00 — «От кода к людям: как вырасти в руководителя команды и не возненавидеть свою работу». Записаться
  _{Подойдёт тем, кто уже вырос из роли «просто сильного инженера» и хочет научиться управлять людьми, процессами и ожиданиями без хаоса и выгорания.}

Больше открытых уроков, подборок по IT‑направлениям и полезных материалов публикуем в нашем канале в MAX. Подписывайтесь, чтобы не пропустить новые вебинары, разборы и анонсы курсов.