Что должен делать Тимлид?
Кто есть кто
Тимлид ≠ Техлид
Иногда эти роли совмещаются и я думаю, что из-за этих совмещений пошло заблуждение, что тимлид обязан быть техническим экспертом.
Техлид
Самое явное отличие в том, что у техлида нет дисциплинарной ответственности. Техлид не увольняет и не нанимает людей. Строго говоря задача техлида – стратегическое планирование видения технической реализации продукта.
Техлиды пишут дизайн документы, создают прототипы системы, разбивают систему на модули и контролируют реализацию модулей другими программистами. В то же время техлиды обычно пишут самые сложные куски системы или фреймворки.
Тимлид или менеджер
Тимлид отвечает за команду и процессы. Планирует загрузку команды и, с помощью техлида, ищет компромисс между тем, что нужно бизнесу и тем, что команда реально может создать в обозначенный срок.
Я буду использовать тимлид и менеджер взаимозаменяемо.
Обязанности
Процесс
Отлаживать процесс. Вводить процесс где требуется и убирать процесс там где он не нужен.
Процесс — довольно обширное понятие. По большому счету это просто инструкция работы команды. Как планируется работа, как декомпозируются задачи. Пишутся ли дизайн документы и если пишутся кто их проверяет и утверждает.
Какие собрания или митинги проводятся регулярно, какие по мере надобности. Протокол проведения собраний. Какие документы / тикеты и тд. по результатам этих собраний создаются.
Управлять динамикой команды. Давать обратную связь.
Кто виноват когда команда работает не так, как ты себе представлял?
Конечно виноват ты. Самая важная задача тимлида – устанавливать четкие и измеримые ожидания.
Например, если у вас есть дежурство. То твоя задача написать инструкцию и поднять всю важную информацию на панель управления или Dashboard.
Защищай команду
Так же работа менеджера — защищать команду. Менеджер который кидает свою команду под автобус раз за разом — плохой менеджер.
Хороший менеджер старается чтобы команда была загружена равномерно процентов на 50-70%.
Бывают случаи, когда необходимо работать на 120% именно для этого менеджер и консервирует энергию и свою и команды, об этом чуть позже. Однако такие ситуации не должны стать регулярными и не могут длиться больше чем 1-2 месяца.
С другой стороны защищать команду — не значить позволять программистам съезжать на нейтралке. Везде важен баланс.
Не благодари
На самом деле работа менеджера неблагодарная. Если у команды проблемы — то какахи летят в сторону менеджера. Если команда заруливает любой проект в срок — про менеджера никто и не вспомнит.
Как мне сказал мой босс в назидание:
Твои идеи будут возвращаться от других людей и без твоего имени под этими идеями.
Если ты с этим не можешь смириться, то скорее всего менеджмент не для тебя.
У меня по этому поводу своя мантра. Я ее позаимствовал у пингвинов с Мадагаскара.
Потому что иногда Титанику нужно дать влететь в айсберг. Люди должны набить свои собственные шишки. Люди должны сделать вещи по-своему.
Разумеется ты вмешиваешься если это начинает угрожать проекту или компании.
Микроменеджмент
Я думаю, что микроменеджмент идет от неуверенности в себе. Уверенный в себе и команде менеджер с отстроенными процессами никогда не будет докапываться до программиста или давать супер детальные указания.
Микроменеджмент возникает когда тимлид чувствует, что теряет контроль.
На самом деле если процессы выстроены правильно, то метаинформации о работе команды должно быть более чем достаточно чтобы понять кто чем сейчас занимается.
Опять же микроменеджмент может возникать когда у менеджера низкий сезон и ему нечего делать. Или когда менеджер эксперт и никак не может отпустить разработку и постоянно хочет учавствовать в написании кода или в ревью кода.
Интенсивность работы
Если представить интенсивность работы простым графиком где на оси X время, а на оси Y интенсивность от 0 до 100, то для программиста интенсивность должна колебаться около 50. Т.е. программист в идеале должен быть равномерно загружен, но не по самые помидоры, а чуть больше чем на половину.
Однако интенсивность работы тимлида не бывает такой равномерной. Бывают дни когда кажется, что ты не делаешь ничего. Главное в такие дни смириться с этим и не пытаться изобретать работу или новый процесс. Это может только навредить команде.
Это время лучше потратить на изучение вашего продукта, технологии, с которой вы работаете или смежных технологий.
Почему важно в это время не перенапрягаться, потому что придет время когда надо будет работать на 100 и очень важно соблюсти баланс чтобы не работать на 100 постоянно.
Экспертность
Успешному тимлиду не обязательно быть экспертом в том, чем занимается команда. Другим словом не нужно быть сеньором Java чтобы управлять командой Java программистов.
Так или иначе еще можно встретить случаи, когда тимлидов делают из лучших программистов теряя хорошего программиста и получая плохого тимлида.
Когда ты эксперт
Когда ты эксперт тебе очень легко доказать свою полезность команде. Можно всегда засучить рукава и все исправить, но это путь в никуда.
Если тебе регулярно приходится помогать команде, то в команде проблемы. Процессы планирования могут быть выстроены не правильно. Команда может быть просто перегружена.
Помогая команде кодом или архитектурой главное не забирать у людей шанс вырасти в этой области. Людям нужно дать шанс попробовать, облажаться, помочь исправить и в результате отдать все лавры им.
Когда ты не эксперт
Гораздо легче не навредить когда ты не эксперт, но в таком случае команда может просто не понимать нафига ты им нужен. Не стоит тратить вечера и выходные чтобы наверстать экспертность, твоя работа не про это. Однако ты должен понимать специфику предметной области и инструментов.
Мультипликатор
Тим лид должен быть мультипликатором больше 1. Если твой мультипликатор меньше 1 или 0 – расскажи в комментариях как ты вообще попал на эту должность.
Неправильно уделять время только отстающим. Задача тимлида – производительность команды, а не отдельных людей.
Предположим, что тимлид – это 2 и есть 2 человека: 0.5 и 3. Помогая 0.5 на выходе будет 1 помогая 3 на выходе будет 6. Нельзя помогать только одному или другому человеку. Помогая только 0.5 не будет достигнута оптимальная эффективность, помогая только 3 – 0.5 никогда не раскроет свой потенциал.