Обязательно ли назначать на должность Тимлида Старшего разработчика?

Введение.

В данной статье был проведен анализ рынка тимлидов и он показывает, что 63% компании закрывают позицию на должность тимлида внутренними сотрудниками, а 23% компании закрывают как внутренними, так и внешними сотрудниками.

Часто встречал такую картину, когда старшего программиста назначают на позицию тимлида, а старший разработчик получает больше удовольствия от написания кода и решения сложных задач, потому же он и старший разработчик! Когда старший разработчик получает позицию тимлида, он думает, что почти ничего не поменяется, команда знакомая, продолжит писать код, и пару встреч добавятся в календаре. Но со временем, он начинает замечать, что на код уходит все меньше и меньше времени, большая часть кода пишется уже без его участия, и он успевает лишь проводить code review.

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

Новые команды. Новые тимлиды.

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

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

Тимлид — капитан команды.

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

А ведь капитан команды, это хорошая аналогия для тимлида! Капитан команды, это такой же полевой игрок, у него нет особых привилегий. Его задача следить за духом команды, тренировками, кого и когда на какую позицию выводить.

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

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

Выводы

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

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