Как определить, стоит ли инженеру расти в тимлида

Про золотой стандарт нашей индустрии в виде «подойти к самому сильному разработчику в команде, похлопать по плечу и назвать новым руководителем» знают все – кто-то прошел через него сам, кто-то смотрел сбоку, а у кого-то был как раз такой руководитель. В статье разбирается более разумный способ определения, готов ли разработчик расти в тимлиды. Если не вдаваться в детали, то автор советует такой алгоритм:

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

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