P-006

Кейс из практики: ошибка руководителя в теме «Переход senior → teamlead»

Ситуация. Руководитель направления переводит сильного senior-разработчика в тимлиды команды из пяти человек. Договоренность: «Пробуй квартал, я на связи». Через три месяца — performance review.

Ошибка. Руководитель оценивает нового тимлида по старым метрикам. Считает лично закрытые ПРы, строки кода, количество коммитов. И констатирует: «Твоя личная продуктивность упала. Как разработчик ты приносил больше пользы».

Что происходит дальше. Тимлид возвращается к активному кодингу, сокращает время на 1-to-1 и планирование. Команда теряет фокус, сроки сдвигаются. Через полгода человек либо просится обратно в разработчики, либо уходит из компании.

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

Что делать. Перед переводом зафиксируйте новые критерии оценки на 3-6 месяцев: утилизация команды, время на онбординг новичков, количество инцидентов. И да, в первые месяцы личная продуктивность в коде упадет — это нормально, а не регресс.

—

А у вас было такое? Как вы переключали фокус оценки при переводе сеньоров в управленцы? Ответьте в комментариях — или пройдите мини-диагностику готовности команды к делегированию (ссылка в закрепе).