Лучший разработчик — худший тимлид

В IT часто кто-то получает повышение, которое ломает команду. Лучший инженер становится тимлидом и продукт начинает тормозить. Не потому, что человек плохой. Потому что его поставили не на ту позицию и ждали от него не того.

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

Что происходит вместо этого: 1. Тимлид продолжает писать код, потому что там он чувствует себя компетентным, а с управлением людьми - нет. 2. Команда перестает думать самостоятельно - зачем, если лид все равно переделает лучше? 3. Бизнес теряет и продуктивного разработчика, и нормально работающую команду.

Что я делаю, когда вижу такую ситуацию? Составляю прямой разговор: «Ты понимаешь, что твоя работа теперь не код, а люди?» Большинство отвечают «да» и на следующий день снова сидят в pull request до ночи. Тогда жесткий выбор: либо реально меняешь роль, либо возвращаешься в разработку. Без обид. Просто честно.

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