Как осознать себя в роли руководителя тимлидов
Привет, я Сергей Баранов, и с недавнего времени я Technical Unit Leader в Авито, проще говоря — тимлид тимлидов. Когда‑то я начинал как обычный разработчик, а потом стал лидером маленькой команды из четырёх человек. Сейчас в моем юните четыре команды. В этой статье я расскажу, как изменился мой образ мышления в новой должности.
Ситуация на старте и реорганизация юнита
Когда мне предложили руководить юнитом, в нём были две команды. В первой я был тимлидом до повышения. В ней было 10 человек: фронтенд-, бэкенд- и мобильные разработчики, QA. В итоге ребята остались без тимлида: я не занимался подготовкой преемника, а доверить большую команду новичку было нельзя.
Вторая команда юнита занималась другим сервисом, состояла из шести человек и в ней тоже не было тимлида.
Кроме того впереди была реорганизация — процесс, когда меняется зона ответственности у юнитов. В итоге у маленькой команды из моего юнита забрали сервис, над которым они работали, а мне добавили незнакомую команду из восьми разработчиков. К счастью, у них уже был тимлид.
Под моим руководством оказались три команды: большая; маленькая, но без своей зоны ответственности; и незнакомая
Мой руководитель поставил четыре задачи, которые я должен был решить как тимлид тимлидов:
Не развалить то, что уже работает.
Принять под своё руководство новую команду.
Провести реорганизацию.
Сформулировать для команд долгосрочные цели.
Мне нужно было сделать команды более управляемыми, найти новых тимлидов и составить сетап, в котором тимлидам без большого опыта будет легко онбордиться. Ещё мне хотелось оставить место для дальнейшего масштабирования юнита.
Я вспомнил первый опыт руководства, когда в команде было всего четыре человека и понял, что начать стоить с реорганизации команд. Маленькой командой проще управлять: у тебя меньше проектов и больше времени на то, чтобы развиваться и погружаться в происходящее.
Ещё одна моя идея — выделить мобильных разработчиков в отдельную команду. Запрос на это был внутри команды ещё до моего повышения и хорошо ложился на планы юнита. Согласовать эту идею с руководством продуктового направления было непросто: пришлось искать аргументы и отрабатывать возражения. Но мне удалось убедить всех, что этот вариант реорганизации пойдет на пользу.
У меня получилась структура из равномерно распределенного количество разработчиков и отдельная мобильная команда
Второе правило инженера гласит: «Не крути две ручки одновременно». Но я сделал именно так. В новой структуре изменялось количество команд, их привычные зоны ответственности, роли инженеров и процессы.
Анализируя свой опыт сейчас, я понимаю, что менять столько всего сразу было не лучшим решением. Когнитивная нагрузка оказалась огромной. Когда ты тимлид и работаешь в готовой структуре, кажется, что по-другому быть не может. Но чтобы эту структуру создать, нужно проделать большую и незаметную со стороны работу.
Как я учился быть руководителем юнита, а не тимлидом
Фактически я запустил четыре новых команды, в каждой из которых нужно было назначить людей на роли, определить для них задачи и отладить процессы. И самое важное: мне нужны были три новых тимлида.
Я начал искать амбициозных и смекалистых ребят внутри своих команд. Получилось найти одного, а двумя оставшимися командами я временно решил управлять сам. Так я стал дважды тимлидом и руководителем юнита одновременно, а в сутках всё ещё оставалось только 24 часа.
Что делать в качестве тимлида команды, мне было понятно. Я отвечал за производительность, ментальное состояние, развитие, технические показатели, процессы. Если возникала проблема или появлялся баг, я приходил с вопросами к инженерам, чтобы пообщаться с ними и найти решение.
С двумя другими командами, в которых были свои тимлиды, оказалось сложнее. Я уже не мог напрямую обращаться к инженерам по каждому багу. Если бы я влезал в работу команд, это мешало бы развитию тимлидов, подрывало их авторитет и завязывало решение всех проблем на мне. Ещё это требовало времени, которого и так не хватало.
Какие метрики я использовал для быстрой оценки ситуации
Чтобы не вникать в каждый нюанс, я начал использовать метрики. Они не требуют глубокого вовлечения, но помогают понять, что происходит в команде. Для регулярной оценки я выбрал три типа метрик: бизнесовые, процессные и метрики качества.
Бизнесовые метрики. С ними в Авито всё просто: у нас есть дашборды, где можно посмотреть нужные данные, например количество активных юзеров, средний чек, конверсия, попадание в воронку.
Процессные метрики. С их помощью я отслеживаю, достигает ли команда целей в спринтах. Например, Scope Drop показывает, сколько мы не сделали из того, что запланировали. Если эта метрика стабильно высокая, значит, нужно уделить больше внимания планированию спринтов. Возможно, команда берёт больше задач, чем может выполнить.
Если Scope Drop стабильно равен 0, это может быть признаком, что команда наоборот планирует на спринт слишком мало задач. Тогда стоит разобраться в причинах — может быть, кто-то выгорел и не хочет работать.
Ещё я использую процессную метрику — «прогрумленность» бэклога. Она показывает, сколько задач из общего списка уже имеют оценку в Story Point. Эти задачи команда может запланировать на следующий спринт или взять на замену в текущий, если спринт дропнется.
Метрики качества. В первую очередь, это количество возникающих багов и их приоритет. Ошибки — нормальная часть жизни команды, но если регулярно появляются баги с высоким приоритетом, надо разобраться в причинах и попытаться помочь. Ещё для оценки качества я смотрю SLA по сервисам и объём технического долга.
Метрики помогают оценить развитие команд и тимлидов, прогресс по задачам. В самом начале я отслеживал их сам. Но в итоге я понял, что регулярный контроль метрик нужно передать тимлидам, а самому в освободившееся время регулярно общаться с командами.
Как я остаюсь в курсе дел внутри команд
Стандартный подход, который я скопировал у своего прошлого руководителя — регулярные встречи 1-to-1 с членами команды. Но когда со всеми познакомился и пообщался, стало понятно, что повестки для обсуждения с каждым разработчиком не набирается. Разговоры быстро переросли в пустую трату времени и я решил частично отказаться от них.
В итоге у меня остались только встречи с тимлидами. Их время выросло с 30 минут до 1 часа за спринт, а в повестку я включил блок операционного ревью.
С тимлидами я обсуждаю метрики и текущий прогресс по проектам, достижение ключевых целей и результатов (OKR). Также разбираем с ними инциденты на продакшене, которые повлияли на работоспособность проекта. В Авито мы давно практикуем обсуждение инцидентов, в том числе на локальном уровне юнита или команды, как делаю я.
Чем отличается планирование с точки зрения тимлида и руководителя юнита
Одна из моих целей в новой должности — понять, чем будут заниматься команды юнита. Обычно тимлид планирует максимум на квартал вперед, отдельные проекты очень редко занимают до полугода. Мне нужно было определить задачи для всех четырёх команд на год и больше.
Для руководителя тимлидов целеполагание и планирование — важные составляющие работы. Принимать решения приходится в условиях, когда есть только вероятности: исход может быть любым.
Чтобы уменьшить неопределённость, я начал проводить 1-to-1 с владельцами продукта. Они отвечают за развитие продукта и лучше других понимают, каким он должен стать в будущем. Мы обсуждали планы, идеи, мысли о том, что гипотетически ждет Авито. Также я просил обратную связь по готовой части проекта для команды разработки.
С новой информацией я шёл к тимлидам или к инженерам в команду, где руководил сам. Мы разбирали, что нужно, чтобы добиться целей и привести продукт в нужному виду. Искали, где нужно перестроить архитектуру проекта, где не выдерживаем нагрузку или тонем в legacy-коде.
Благодаря тому, что теперь у меня был взгляд на проект с разных сторон, получилось сформулировать план для юнита, отразить в нём блокеры, которые нужно устранить, прописать шаги для реализации.
Что было самым сложным на пути из тимлида в руководителя юнита
Мне было тяжело отпустить контроль за командами. Я привык быть в тесном контакте с инженерами, а в новой должности нужно было делегировать обязанности тимлидам. Это было необходимо и мне — чтобы успевать выполнять задачи руководителя, и командам — чтобы новые тимлиды могли развивать их и развиваться сами.
Было непривычно отвечать за результат там, где лично не участвуешь в работе, не пишешь код. Но намного сложнее оказалось быть уверенным в решениях и принимать риски. В этом мне помогла поддержка руководителя продуктового направления и команды.
Советы тем, кто только начинает руководить
Я советую вам найти ментора, который будет обсуждать с вами идеи и валидировать их. Он может показать вам разные варианты решений. А принимать и применять ли их — это уже ваш выбор и скилл, который нужно прокачивать.
И не бойтесь искать поддержки среди коллег, ведь вы все вместе работаете над одним продуктом и заинтересованы в результате. У вас всё получится!
Предыдущая статья: Работаем с PostgreSQL в Go. Опыт Авито
