Post #1054

Как определить, стоит ли инженеру расти в тимлида Про золотой стандарт нашей индустрии в виде «подойти к самому сильному разработчику в команде, похлопать по плечу и назвать новым руководителем» знают все – кто-то прошел через него сам, кто-то смотрел сбоку, а у кого-то был как раз такой руководитель. В статье разбирается более разумный способ определения, готов ли разработчик расти в тимлиды. Если не вдаваться в детали, то автор советует такой алгоритм: 1️⃣Посмотреть, умеет ли кандидат строить процессы, потому что в этом и будет заключаться большая часть его работы. 2️⃣Посмотреть, что у него с мотивацией людей – есть ли шанс, что он сможет повести людей за собой, и насколько велик риск, что команда с ним распадется. 3️⃣Оценить, насколько сам человек готов переключиться с инженерной работой на руководство. 4️⃣Делает ли он уже сам какие-то шаги в сторону менеджерской работы – берет на себя ответственность за крупные проекты, что-то читает по теме. 5️⃣Насколько он вникает в суть того, что и зачем делает. Действует ли строго в рамках выданной задачи, или ориентирован на результат. 6️⃣Насколько он открыт и конструктивно говорит о проблемах. У меня алгоритм вопросов не вызвал, и показался довольно разумным. Отдельно хочу отметить четвертый пункт – я всегда топил за то, что плохая идея назначать тимлидом того, кто уже не начал вести себя, как тимлид.