Почему лучший разработчик ≠ хороший тимлид?
Классическая ошибка роста в IT-командах: берем самого сильного инженера, который пишет гениальный код, и назначаем его руководителем.
- Ожидание: команда начнет работать так же круто, как он.
- Реальность: сроки горят, конфликты растут, тимлид выгорает.
Мы в АгроТех Авиа тоже набивали эти шишки. Человек, который выдавал великолепный результат в соло-режиме, получая команду, вдруг терял контроль над ситуацией.
Почему так происходит?
1. Ошибка проекции Сильный спец меряет всех по себе. Он привык к своему темпу, к своей глубине знаний и работоспособности. Ему кажется, что если он может сделать фичу за 2 часа, то и джун сможет. Спойлер: нет. Руководитель должен адаптироваться к скиллам команды, а не ждать, что все станут его клонами.
2. Люди как функции Инженерное мышление пытается превратить процесс в алгоритм: «На входе ТЗ — на выходе код». Но люди — не механизмы. У них есть эмоции, выгорание и личные особенности. Если управлять командой как набором функций, «механизм» быстро заржавеет и встанет.
3. Попытка «задебажить» конфликт Большинство крутых разработчиков (не все, но многие) интровертны. Им проще построить сложную архитектуру, чем разрулить ссору в команде.
Когда возникают проблемы с людьми, новоиспеченный лид пытается применить технические фреймворки и логические схемы там, где нужна эмпатия.
Умение слышать людей — это совсем другой стек технологий, который не учится по документации. И иногда лучше оставить крутого инженера в роли архитектора или TechLead без people management нагрузки, чем потерять и разработчика, и команду.