Итак, кто такой вообще TeamLead? Вопрос, казалось бы, максимально глупый, так как ответ на него известен всем. Это сотрудник, в равной степени ценный как с точки зрения накопленных знаний и компетенций в используемом технологическом стеке, так и с умением управлять командой и развитием продукта.

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

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

1) Появится общее представление об очерёдности и приоритете того, что нужно сделать для получения результата

2) Будет продуман алгоритм действий на достаточно низком уровне, так, чтобы даже джун смог по этому алгоритму выполнить свою часть работы

3) Зародится возможность делегирования, потому что работнику на начальных этапах карьеры сложно увидеть всю картину, но он может сделать простую задачу. Значит, нужно декомпозировать так, чтобы задача виделась как простая и законченная

И я бы мог расписывать и дальше, но топ-3 список нам уже достаточен, чтобы узреть основной концепт. Да, порой на декомпозицию тратится столько же времени, а то и больше, сколько и на саму реализацию. НО. Во-первых, это исчезает с опытом, так как общий алгоритм дробления у всех задач примерно одинаков, а во-вторых, нам не всегда нужно "бежать" за скоростью, иногда стоит выдохнуть и посмотреть на результат. А результат будет виден только если чётко обозначена первоначальная задача и планируемый результат.

Тоже самое касается и остальных "менеджерских" процессов, останавливаться на каждом мы не будем, только если вы сами не попросите в комментариях, но хотел ещё отдельно поговорить о делегировании. Очень часто я видел ситуации, или же меня приглашали работать в такие компании, где тот, кого выбрали на роль TeamLead продолжает удерживать все компетенции на себе, замыкать все процессы и работу на себе, а значит, вся его команда вообще не представляет то, чем она занимается, какие системы обслуживает и для чего она это делает. Чёрт, да там доходит до того, что такой "руководитель" делает всё за свою команду. Команда тоже вроде чем-то занимается, но такой управленец после этого всё переделывает или перерабатывает и, в итоге, ещё сильнее замыкает всё на себе. Боязнь передать компетенции, лично по моим наблюдениям, вызвана двумя страхами:

1) Боязнь потерять контроль и/или качество - ещё часто такое объясняется тем, что "сам сделаю быстрее и лучше"

2) Боязнь потерять свою позицию в компании - почему-то часто считают, что если отдать свои знания и умения другим, то компания, в лице руководства, непременно уволит/понизит/урежет зарплату

И обе эти причины надуманные, так как количество того, что нужно обслуживать всегда неуклонно растёт и один человек физически не сможет обслуживать столько, сколько нужно будет компании (и вот тогда она начнёт задумываться о замене), плюс, если руководитель успешно делегирует задачи, то его рассматривают, как хорошего управленца, а хороший лидер - редкость на рынке труда. Поверьте, я таких видел очень мало за всю свою карьеру и каждый раз таких ценят. А плохих терпят. Поэтому если вам когда-то предложат стать TeamLead'ом - серьёзно задумайтесь, а хотите ли вы расти в эту сторону. Быть может, на самом деле, вы хотите и дальше заниматься своими продумываниями алгоритмов и наращиванием компетенций технологий. Потому что и в этой стороне есть куда вырасти. И имя этому росту - архитектор. Но сегодня не об этом.

На самом деле, на эту статью меня частично натолкнула собственная ситуация. У меня есть набор обязанностей, в которые входит полное обслуживание жизненного цикла ПО нескольких продуктов и я их TeamLead, но команды у меня нет. "КАК ТАК? Ты там чем тогда Lead, если без Team?" - спросите вы. А всё очень просто. Я - сам себе команда. Сам себе выставляешь требования, сам продумываешь процесс, сам его реализуешь и используешь для решения рабочих задач. Сам себя ругаешь за то, что опять не закрыл спринт так, как планировал и сам же хвалишь за то, что смог сделать очередной долгострой. И на вопрос "Как может быть TeamLead без team?", я отвечу "так же, как и с командой, просто без делегирования". Получается, что я сам себе - пример плохо TeamLead.

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