Личный опыт: перезапуск тимлидства в растущей IT-компании. Часть 1

Как вы понимаете, что у вас в компании хорошо развит институт тимлидства? Как тимлиды понимают свои функции, выполняют, что должны, растут и не выгорают? Мы вот однажды поняли, что у нас примерно никак. Вернее, как-то, но как именно — мы не знаем. 

Я Саша Хрущев, технический директор IT-компании WINFOX. Рассказываю, как мы пересмотрели свой подход к тимлидству, с какими трудностями столкнулись в процессе и какие результаты это дало. 

Как было устроено тимлидство раньше

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

Набрав достаточное количество тимлидских функций, сотрудники становились тимлидами по факту. Однако мы не делали никаких заявлений из серии «Вася теперь у нас тимлид. Он будет делать то-то и то-то. Слушайте Васю». Да это и не нужно было — всем и так все было понятно.

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

• Набор функций тимлидов в разных командах отличался. Кто сколько задач на себя взвалил, тот настолько и тимлид. 

• Самые-самые тимлиды, набирая себе тимлидских задач, надолго вываливались из написания кода. Срабатывало правило «Кто не кодит — тот и тимлид». 

• Новые сотрудники не сразу понимали и принимали такой эволюционный подход к тимлидству. Они считали, что тимлидов у нас и вовсе нет.

• Новые направления и команды оставались без лидов. Все потому, что процесс становления тимлида занимает время.

Почему мы решили поменять подход к тимлидству 

Однажды солнечным августовским днем CEO, CTO, руководитель проектного офиса   и менеджеры проектов собирались на очередной митинг, посвященный проблемам исполнения производственного плана. В ходе подготовки мы заговорили про тимлидство. 

В рамках краткой полемики мы пришли к выводу, что каждый из нас по-разному понимает функции тимлида, его личность и роль в компании. Вот как воспринимал тимлидство каждый из нас.

Как видит тимлидство CEO:

• тимлид — это руководитель со всеми вытекающими полномочиями, ответственностью и т.д.;

• тимлид следит за соблюдением сроков по задачам, этапами и проектами в целом;

• тимлид отвечает за развитие команды. 

Как видит тимлидство CTO:

• тимлид — это наставник; 

• главная задача тимлида — развитие команды;

• тимлид отвечает за демонстрацию экспертизы коллегам и заказчикам;

• тимлид занимается оценкой проектов и отдельных задач;

• тимлид отлично знает стандарты работы в компании и контролирует их соблюдение.

Как видит тимлидство руководитель проектного офиса:

• главная задача тимлида — поддержание производственной дисциплины;

• тимлид контролирует соблюдение сроков;

• тимлид занимается декомпозицией и распределением задач;

• тимлид отвечает за взаимодействие между командами и создает рабочую атмосферу в команде. 

Выходило, что каждый из нас помимо общепринятых функций ожидал от тимлида то, что нужно лично ему для выполнения своей миссии в компании.

Поэтому мы решили провести мозговой штурм среди команды разработки: сами лиды, мидлы и джуны определенно должны иметь особый, отличный от нашего взгляд на тимлидство. Вот к каким интересным результатам мы пришли в процессе этого штурма. 

Лиды считают, что тимлид — это золотая середина между распределением задач и менеджментом. Вот что делает тимлид по их мнению:

• назначает задачи разработчикам исходя из скиллов;

• оценивает задачи по времени;

• организует взаимодействие между командами при участии ПМ;

• делает код-ревью;

• формирует видение процесса разработки на будущее;

• решает сложные вопросы;

• помогает разбираться в сложных задачах другим разработчикам;

• не контролирует сроки исполнения задач.

Мидлы уверены, что тимлид — это человек, который выслушивает всех участников проекта и принимает взвешенное решение. Вот что еще делает тимлид по мнению мидлов:

• не выполняет функции менеджера: не следит за сроками, не планирует ресурсы, но в конце недели понимает, сколько сделано по задачам команды;

• имеет право последнего слова;

• следит за соблюдением стандартов кодирования;

• настоящий КМС по ревью: ревью кода, ревью дизайна, ревью спецификации бэка, ревью оценки задач;

• делает ретроспективу проекта;

• делает ретроспективу этапа: анализ фидбека от тестеров и анализ фидбека от заказчика;

• отвечает за шаринг экспертизы;

• курирует медианаправление: пишет экспертные статьи;

• выступает представителем на совещаниях со спецами заказчика;

• следит за выгоранием и нагрузкой;

• определяет исходную архитектуру проекта;

• имеет доступы админа и девопса и оперативно что-то шатает, если нужных спецов нет на месте;

• обеспечивает комфорт в команде;

• решает проблемы личностного характера и поддерживает инициативы сотрудников;

• всегда на связи. 

По версии джунов все обстоит примерно так:

• «О, а у нас есть тимлид?!»;

• тимлид консультирует других разработчиков и помогает им искать решения;

• тимлид получает большую ЗП;

• тимлид занимается шерингом экспертизы внутри команды;

• тимлид просто кайфует)

Внимательный читатель подумает: «Так… Лиды, мидлы, джуны высказались, а где сеньоры-то?». Дело в том, что с давних пор в WINFOX работает немного доработанный принцип МакКинси «Up or Out» в формате «Up or Outstaff». Если разработчик, ставший сеньором, не растет в сторону тимлида или управленца, мы обычно переводим его на работу по модели аутстафа. Не буду вдаваться в детали, так как эта модель — тема для отдельной статьи. 

Картина была бы неполной, если бы мы не спросили коллег и конкурентов, чем же занимаются тимлиды у них. Ответы были разные, начиная от «Эээ, не знаю» до вполне четкого перечня функций. 

Вот обязанности тимлида в разных компаниях, которые особенно удивили:

• отвечает вообще за все: за найм, рост, сроки, качество своей команды;

• организует рабочую атмосферу, включая досуг, тимбилдинги и посиделки;

• контролирует дисциплину и график работы.

Обменявшись мнениями, мы поняли, что настоящий тимлид — это сверхчеловек ростом под три метра с красным дипломом Хогвартса, который помнит число Пи полностью, дышит огнем и любит котиков. 

А если серьезно, именно в этот момент в компании наметилась тотальная нехватка тимлидов. И это стало прекрасным поводом для перезапуска института тимлидства.

Как устроено тимлидство сейчас

Мы серьезно пересмотрели подход к тимлидству и сделали три главные вещи: 

• урезали осетра минимально необходимый набор тимлидских функций до вменяемого и донесли их до потенциальных исполнителей; 

• ввели необходимый официоз: начали официально закреплять статус тимлидов в командах соответствующим публичным распоряжением;

• постарались, чтобы все работало: сформировали требования к тимлидам, довели их до исполнителей, определили KPI.

Рассказываю подробнее про каждый шаг.

Урезали минимально необходимый набор тимлидских функций

Мы выделили главные полномочия, которые пугают большинство наших текущих и будущих тимлидов, и убрали их. В итоге мы отказались от следующих функций тимлида:

• Медийность. Светить лицом, проводить митапы, выступать на конфах… Очень бы хотелось, чтобы наши лиды этим занимались, но подобный выход из зоны комфорта переживут не только лишь все. По крайней мере на первых порах.

• Умение решать конфликты и межличностные проблемы. Погасить конфликт или свести на нет личную неприязнь не входит в обязанности разработчика даже в статусе тимлида. Но умение распознать конфликт или проблему и сигнализировать о ней выше — бесценно.

• Умение жечь на пресейлах, продавая экспертизу. Скиллы быть профессионалом и уметь продавать свой профессионализм не часто уживаются в разработчиках.

• Способность работать за админа и девопса. С одной стороны, почему бы и нет? Но лучше не надо.

Убрав эти пункты и оставив только самые необходимые, мы получили следующий джентльменский набор необходимых качеств тимлида у нас в компании:

• наставничество;

• набор сотрудников: собеседования и тестовые задания;

• оценка задач;

• распределение задач;

• контроль сроков исполнения задач;

• развитие команды;

• код-ревью;

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

• шеринг экспертизы внутри команды;

• трансляция и поддержка инициатив от сотрудников наверх;

• обнаружение выгорания и конфликтов;

• выработка стандартов и контроль их соблюдения;

• право кайфовать и получать большую ЗП. 

Начали официально закреплять статус тимлидов в командах

Мы поняли, что необходим некоторый официоз. 

Молодые сотрудники путают тимлидство с наставничеством, воспринимая тимлида исключительно как своего наставника. А сами тимлиды на вопрос «А кто у нас тимлид?» не всегда могут уверенно сказать «Я». Плюс прочие проблемы с донесением информации в распределенных командах.  

Так мы начали официально закреплять статус тимлидов в командах соответствующим публичным распоряжением.

Заставили всю эту штуку работать

Это оказалось самым сложным. 

Мы сформировали требования, довели их до исполнителей и рассказали каждому в компании, как это все теперь работает. Но этого было мало. Так что мы ввели KPI, по которым можно оценивать эффективность тимлидства, управлять, корректировать и добиваться результатов.

Подробнее про KPI — в следующей статье. 

Во второй части я также расскажу, как мы строили работу дальше:

• кому доверили тимлидство;

• как мотивируем тимлидов;

• что нам дал перезапуск тимлидства.

А пока делитесь, как с тимлидством у вас? Рассказывайте про лучшие практики и не совсем удачные решения.