Чего боятся тимлиды и почему им пора перестать это делать

[@jetcar]

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

[@datacompboy]

ну Техлид и Тимлид это ж разные вещи.
Но да, часто путают…

[@marshinov]

Если тим-лид делает самые сложные задачи, все планирует и играет на дуде, то что-то не так в датском королевстве с делегированием

[@EvilsInterrupt]

Нет. От тим.лида не надо ждать, что он придет и запилит то, что другие не смогли. Но то что не хватило рук, с него можно спросить. Он должен четко понимать какие ресурсы были применены для решения текущих задач и почему именно именно эти задачи были взяты в разработку, а не та что не запилена? Он управляет разработкой некоторого участка разработываемого продукта. Другими словами он должен четко понимать, а вот текущего набора программиста хватает для решения типовых задач на его участке или нет? А если спросят его «кого можем сократить?» он должен знать ответ сколько по факту нужно разрабов и на основании этого четко ответить что можем уволить кого-то или наоборот надо нанимать?

[@Zedmor]

Это совсем плохая идея. Задача тимлида научить команду делать самые сложные задачи. В принципе я вижу свою работу как подметать пол, пока остальные работают — снимать блоки, быстро обнаруживать, что кто-то залип и реораганизовать его (попарить с другим, или сесть вместе, сделать митинг-обсуждение). Брать на себя сложные задачи = мешать развитию команды, а именно это «продукт» деятельности тимлида, а не software.

[@AlexSuslov]

1. выбрать как, что, за сколько(время или деньги)
2. порезать проект на задачи, скомпоновать в однородные
3. раскидать задачи по скинам
4. следить чтоб народ не залипал
5.

[@andrej_volokitin]

Спасибо за статью. До неё я и не подозревал, что у меня есть столько страхов. :)
Нет, они, конечно, проскакивали. Но сидели где-то в подсознании, и не отсвечивали. Теперь придётся их давить.

[@VanquisherWinbringer]

Сейчас вроде популярнее роль ТехЛиды. Менеджерскими задачами занимается прожект менеджер который и аналитиками и тестерами и разработкой управляет. Берут одного ТехЛида за 300к и к нему 7 мидлов или джунов за 100-150к и он для них задачи декомпозирует. Проводит код ревью. Помогает со сложными задачами или их сам делает. Всем остальным менеджер занимается. Для компании выгода в том что средний уровень качества кода повышается за счет него. ТимЛид по сути проджект менеджер. ТехЛид это самый лучший программист в команде, а для ТимЛида важнее уметь с людьми работать и тут профессиональный менеждер суть которого в этом может лучше с этой задачей справиться.

[@TyVik]

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

[@akimserg]

Спасибо за статью.
Хочу уточнить на счет

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

какие по вашему есть метрики для измерения работы тимлида?
Или кто вообще как измеряет работу тимлида?

[@aklimano]

Статья хорошая, лишь иногда выводы кажутся спорными:

Знаете ли вы как руководитель оценивает вашу работу?
9% не знаю
31% догадываюсь
37% знаю, но не проговаривали
24% точно знаю
Вывод: 75% не знают или не уверены

В зависимости от доказываемой точки зрения, можно легко подписать противоположный вывод. Следите за руками: 91% знают точно или догадываются.

Статистика — интересная вещь…