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

    Введение.


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


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


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


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


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


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


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



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


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


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


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


    Выводы


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


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

    Комментарии 10

      +2
      >Мы пришли к выводу, что тимлид — это не должность, а роль.
      Какой неожиданный вывод :) Мне кажется, вообще нет единого понимания, что такое тимлид, должность ли это или роль, и в чем состоят его обязанности. Поэтому если у вас эту роль смог выполнять сотрудник, технические навыки которого средние, а не высшие в команде — то и хорошо. Зато у этого человека возможно есть склонность быть мотиватором, дипломатом, если угодно, и т.п. — а ведущий разработчик ярко выраженный интраверт со сложным характером.

      У нас кстати была похожая ситуация, когда нужно было на время заменить PO в проекте. Мы рассматривали варианты перераспределения обязанностей на разных людей. У нас такое не получилось, но идею попробовать на определенную роль всех людей из команды вы точно придумали не первыми.
        0
        Согласен что не первыми придумали, но наша практика показывает, что это работает.
          0
          Главное — правильно обязанности распределить )
        0

        не быть сеньору помидором

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


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

          Простите, что?
          старший сеньор разработчик за свою карьеру не научился себя мотивировать, развивать себя, решать проблемы (это вообще капец), находить с бизнесом общий язык, планировать много дел?
          Что это за инфантильный старший разработчик, он вообще чему-либо научился, или в вашем абстрактном представлении сеньор-разработчик это просто тот, который дочитал документацию до конца?
            +2
            >не научился себя мотивировать
            Ну, мотивировать себя и других — это все же две большие разницы. Хотя многие другие из этих тем все же должны входить в обязательную программу синьора.
              0
              вот и я о чем. Без мотивации нормальным сеньором стать практически нереально. Особенно таким, которого хотят сделать тимлидом. То есть человек уже на практике пережил довольно продолжительную карьеру, где неоднократно приходилось брать себя в руки и мотивировать на дальнейшее развитие.
              Это — ценный опыт и знания, которые не получишь на курсах или в универе.
              +1
              Видится, что позицию старшего программиста девальвировали раза в 2. Зачастую, разработчика повышают авансом на позицию синьора, это как способ мотивации, так и удержания в компании. Или же, приходится повышать заработную плату, но запрашиваемый оклад находится в другой вилке, и нужно повышать грейд. И не повышать оклад/грейд, бизнес не может, так как на рынке есть компании, которые готовы и платить больше, и лычку синьора давать.
              +3
              Все противоречия снимаются если разделить роли тимлида и техлида. Тимлид это главный менеджер команды (уж насколько я не люблю слово менеджер но вынужден признать). Его задача состоит в том чтобы быть буфером между бюрократическим щитштормом и разработчиками и давать разрабам спокойно заниматься своим делом, а также в том чтобы нарезать задачи команде в соответствии с потребностями/задачами компании, следить за их выполнением и решать проблемы команды когда они возникают. Техлид же — человек который решает технические вопросы которые возникают у команды в процессе выполнения задач. Т.е техлид — самый крутой разраб. Тимлид — человек который оркестрирует техлида и команду.
              Собственно все что я написал выше — личный опыт сеньора ставшего тимлидом.
                +1

                Аналогичное видение. Проработав в качестве тимлида в 3 компаниях, вернулся обратно в техлидерство, и дело не столько в значительно возросшей нагрузке (когда архитектурирование некому делегировать, а количество обязанностей по пипл+таск-менеджменту и общению с бизнесом начинает зашкаливать), сколько в совмещении двух плохо сочетаемых областей — кодерской и менеджерской. Видел компании, в которых сделано грамотно, и техлид и тимлид разные люди, но в большинстве контор все-таки ради экономии пытаются совмещать, что приводит к выгоранию.


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

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое