Второй вариант — назначение руководителем опытного менеджера со всеми необходимыми для лидера качествами. Но здесь тоже не все гладко — если у него недостаточно навыков именно в разработке, то такой менеджер просто не сможет полноценно контролировать работу членов своей команды. Менеджер, который умеет управлять, но имеет небольшой технический бэкграунд, не сможет принимать технические решения, поскольку у него нет необходимых компетенций. Еще один момент — на менеджера удобно давить как руководству, так и клиентам. Спеша выполнить задачу, такой руководитель может (и скорее всего, будет) принимать неверные решения, которые повредят и команде, и проекту, и компании.
нереально полезная статья, спасибо!!
Рад, что пригодилось :)
Отличная статья, спасибо. Прочувствовал весь объем ответственности ТЛ)
И вам спасибо, что прочитали и нашли время на комментарий :)
Вместе с большой ответственностью приходят и большие возможности ;)
Глубоко убеждён, что ветка развития с тимлидами- тупиковая. Так как тимлид это иерархия, где ошибки верхних уровней внизу не исправить. Плюс поддержание идеи - не можешь решить, ну, тимлид найдёт решение.
Гораздо перспективнее выглядят плоские структуры, с распределённым лидерством и групповой подотчетностью - они устойчивее, поощряют инициативу по умолчанию и в них минимально количество неисправимых ошибок.
Поработав в гибком окружении, понимаешь, что огромное число советов для менеджеров это советы как преодолеть трудности, которые присущи только иерархии. В бирюзе их тупо нет. То есть классический менеджмент героически создаёт себе проблемы, а потом не менее героически превозмогает.
Поэтому даже самый лучший существующий тимлид может быть проблемой для команды. Так как идеальный тимлид - это тимлид, который ненужен.
А я больше склоняюсь к мнению, что категоричность всегда идет рука об руку с недостатком опыта или максимализмом :)
Нет ничего абсолютного: нельзя утверждать, что иерахичная система - the best, также как и не стал бы я утверждать, что бирюза везде будет еще лучше.
У вас видимо были свои примеры из опыта, у меня свои.
Я например знаю одну очень крутую компанию которая выросла из стартапа с такой вот бюризой, а теперь когда столкнулись с ростом и сопутствующими проблемами как лекарство "открыли" для себя рациональный менеджмент и иерархии, хотя вот уж казалось бы :)
И то и другое (и классические иерархичные системы управления и гибкие) надо уметь готовить, так же как и в методологиях разработки ПО: если заставить менеджера/тимлида/специалиста который всю жизнь работал по T&M провеести проект по waterfall (или наоборот) - скорее всего он его завалит.
А развитие в тимлида для специалиста никак не может являться тупиковой веткой развития, т.к. эта должность априори учит брать ответственность на себя, принимать сложные решения, усмирять свою гордость в угоду общему делу - а из этих вещей формируется характер, и формируется стержень. За такими людьми потом идут другие, ведь они - лидеры.
В какой бы компании потом такой человек не работал (в бюризовой или нет) - эти навыки и опыт однозначно будут ему полезны.
И тут Гикбрейнс...
Но речь не об этом, кажется, что сейчас у ТЛ большая часть работы — это коммуникация, а ведь когда-то мы кодили