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

[@sshikov]

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

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

[@beezy92]

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

[@sshikov]

Главное — правильно обязанности распределить )

[@keha391]

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

[@saboteur_kiev]

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

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

Простите, что?
старший сеньор разработчик за свою карьеру не научился себя мотивировать, развивать себя, решать проблемы (это вообще капец), находить с бизнесом общий язык, планировать много дел?
Что это за инфантильный старший разработчик, он вообще чему-либо научился, или в вашем абстрактном представлении сеньор-разработчик это просто тот, который дочитал документацию до конца?

[@sshikov]

>не научился себя мотивировать
Ну, мотивировать себя и других — это все же две большие разницы. Хотя многие другие из этих тем все же должны входить в обязательную программу синьора.

[@saboteur_kiev]

вот и я о чем. Без мотивации нормальным сеньором стать практически нереально. Особенно таким, которого хотят сделать тимлидом. То есть человек уже на практике пережил довольно продолжительную карьеру, где неоднократно приходилось брать себя в руки и мотивировать на дальнейшее развитие.
Это — ценный опыт и знания, которые не получишь на курсах или в универе.

[@beezy92]

Видится, что позицию старшего программиста девальвировали раза в 2. Зачастую, разработчика повышают авансом на позицию синьора, это как способ мотивации, так и удержания в компании. Или же, приходится повышать заработную плату, но запрашиваемый оклад находится в другой вилке, и нужно повышать грейд. И не повышать оклад/грейд, бизнес не может, так как на рынке есть компании, которые готовы и платить больше, и лычку синьора давать.

[@Vaakom]

Все противоречия снимаются если разделить роли тимлида и техлида. Тимлид это главный менеджер команды (уж насколько я не люблю слово менеджер но вынужден признать). Его задача состоит в том чтобы быть буфером между бюрократическим щитштормом и разработчиками и давать разрабам спокойно заниматься своим делом, а также в том чтобы нарезать задачи команде в соответствии с потребностями/задачами компании, следить за их выполнением и решать проблемы команды когда они возникают. Техлид же — человек который решает технические вопросы которые возникают у команды в процессе выполнения задач. Т.е техлид — самый крутой разраб. Тимлид — человек который оркестрирует техлида и команду.
Собственно все что я написал выше — личный опыт сеньора ставшего тимлидом.

[@DmitryKazakov8]

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

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