Слово «тимлид» звучит как очевидная следующая ступень для сильного разработчика. На практике это отдельная профессия со своими задачами, инструментами и рисками.
Кто такой тимлид и почему это не «повышенный сеньор»
Если объяснять роль человеку вне отрасли, то проще всего начать с того, что в инженерной команде есть два разных управления. Первое техническое. За него отвечает технический лидер: он лучше всех понимает, как устроена система, держит ее в голове целиком и ведет команду вперед в инженерном смысле. Второе – управление людьми. Это и есть зона тимлида.
Тимлид работает с людьми напрямую. Он встречается с каждым один на один, развивает разработчиков, понимает, куда они растут и что им интересно. Создает условия, в которых человек правильно применяет свои возможности и для себя, и для компании. Когда команда растет с трех человек до семи и десяти, именно тимлид решает, как поделить ее на группы, как распределить ответственность, где проходят границы между зонами. У него может быть инженерный бэкграунд, но первая его сильная сторона – это умение собрать и удержать команду.
Здесь и есть главное отличие от сеньора. Сильный разработчик прекрасно умеет закрывать задачи. Тимлид умеет складывать людей в работающую команду. Это разные навыки, и одно не является следствием развития другого.
Хорошему разработчику говорят: ты классный, будь нашим лидером. И он мгновенно превращается в начинающего тимлида, который не понимает свою зону ответственности и не владеет инструментами управления. В итоге компания теряет очень хорошего разработчика и получает очень слабого лидера.
Отсюда следует контринтуитивный вывод: сильный разработчик, не значит сильный тимлид. Сильные тимлиды получаются, как правило, из средних разработчиков с хорошими коммуникациями и высоким уровнем доверия со стороны коллектива. Практика показывает, что сильные разработчики, как правило не самые коммуникативные.
В России это поняли не сразу. Около десяти лет назад был отдельный хайп: считалось, что сеньор обязан стать тимлидом, и появление собственных подчиненных воспринималось как признание. Через несколько лет на конференциях пошла обратная волна докладов о том, как перестать быть тимлидом и снова стать хорошим разработчиком, как пережить выгорание после такого перехода. Индустрия пришла к выводу: тимлидство это смена профессии, а не ступень роста сеньора.
Что тимлид делает каждый день
Единого «дня тимлида» не существует, он зависит от зрелости команды. В незрелой команде тимлид постоянно тушит пожары: разбирает конфликты, выясняет, что на самом деле нужно сделать, какие границы ответственности и ищет тех, кто формирует ожидания. В зрелой команде разработчики сами планируют работу и проводят встречи, а тимлид занимается в основном внешней коммуникацией, согласованием работы с соседними командами.
Если описывать типичный набор дел, получается примерно так. Кого-то нужно нанять и провести собеседование. С кем-то встретиться один на один, узнать, как дела, все ли в порядке. С кем-то построить план развития. Где-то возникла проблема: одна команда не может договориться с другой, и тимлид идет ее решать. Большую часть времени тимлид разговаривает. Коммуникация – это его главный рабочий инструмент.
На код почти не остается времени. Есть практика, при которой тимлиды продолжают писать код, но встречается она в редких компаниях с высокой инженерной культурой, и такие роли честнее называть инженерными менеджерами. И даже там речь скорее не про продуктовые задачи, а про DX и тулинг вокруг процесса работы. Когда основной инструмент это коммуникация, на программирование физически не остается ресурса.
Обязательная гигиена роли это регулярные встречи один на один, дейлики и ретроспективы. Без one-to-one тимлид не знает, какое настроение у членов команды, какие у людей проблемы и чего они на самом деле хотят. В какой-то момент это выстреливает: человек уходит со словами «меня никто не спросил, я хотел вот этот проект, а его отдали другому». Без ретро у команды копятся невысказанные проблемы. Без дейли тимлид узнает о сорванной задаче только в конце спринта, когда уже поздно.
При этом формально тимлид никому ничего не должен по списку ритуалов. Если в команде есть люди, которые сами хорошо планируют работу и сами проводят ретро, тимлид может туда не ходить. Его задача быть там, где плохо и где последствия наиболее болезненны и нужно лечить процессы, команду, договоренности и ожидания. Везде одновременно быть нельзя, поэтому приходится выбирать, куда потратить свое внимание.
Идеальный конечный результат работы тимлида наступает, когда команда стала автономной и научилась работать сама. Когда она в тимлиде больше не нуждается.
Сверх роли тимлиду регулярно пытаются навалить чужие зоны. В одних компаниях добавляют техническое лидерство («ты же разработчик, заодно разберись, как мы все это строим»), так появляются совмещенные тимлид-техлиды. В других добавляют продуктовую часть, и тимлид команды из пяти-семи человек оказывается еще и ответственным за продукт. Разовое участие в смежных задачах это нормально. Системное перекладывание чужой работы это ошибка: пока делаешь чужую, твоя собственная стоит.
Иерархия в бигтехе
Почти все крупные технологические компании пришли к двуглавию. Есть два главных человека: технический директор и директор по продукту. Без технического директора компания не знает, как производить. Без директора по продукту не знает, что производить. Все остальное в разработке строится вокруг этих двух функций.
Из этого двуглавия вырастает матрица. По одной оси идет функциональное подчинение: фронтендеры, бэкендеры, аналитики, тестировщики, девопсы. По другой продуктовое: конкретные продукты и направления. Продуктовая вертикаль отвечает на вопрос, что мы делаем, чтобы заработать, и на какие метрики работаем. Функциональная отвечает на вопрос, как мы это делаем, какой у нас стек, как развиваем общие сервисы. Команды живут на пересечении этих осей. Эту модель в свое время описали аджайл-коучи Spotify в 2012 году (с тех пор с ней случилась ирония: сами Spotify по ней в чистом виде никогда не работали, — а вот словарь (трайбы, чаптеры) и сама идея матрицы «продукт х функция» разошлись по индустрии повсеместно, от европейских банков до российского энтерпрайза и экома).
Внутри матрицы роли вкладываются друг в друга. Чем больше компания, тем больше уровней вложенности, потому что один человек способен держать в прямом подчинении ограниченное число людей. Несколько команд объединяются в кластер, у которого есть свой IT-лидер и бизнес-лидер. Группа кластеров это трайб или дивизион, а еще они могут быть объединены в юниты и блоки сверху (в разных компаниях называют по-своему, но логика остается). Вокруг тимлида в такой структуре находятся продуктовые лидеры (рядом PO, и над ними CPO), руководители функциональных направлений, которых иногда выделяют в отдельных chapter-лидов, а также руководители разработки и технические директора. Кому именно подчиняется тимлид, зависит от устройства компании: это может быть тимлид над тимлидами, руководитель разработки или IT-лидер кластера.
Отдельный важный вопрос, кто принимает технические решения. В здоровой системе их принимают технические лидеры. На практике бывает, что бизнес забирает это себе: «принесите мне развилки, я сам решу». Тогда решения принимаются вне центра компетенции, и технари их только исполняют.
Когда технические решения принимаются вне центра компетенции, плохие решения накапливаются. В какой-то момент за них придется заплатить, и заплатить по-крупному.
Ответственность между несколькими тимлидами в одном продукте нарезается по зонам. Большой продукт вроде интернет-банка для юрлиц разбивается на куски: рублевые платежи, валютные платежи, депозиты, дипозитарий, зарплатный проект, базовый набор сервисов, права доступа и авторизация. За каждый кусок отвечает своя команда, а значит, ее тимлид. Нарезать большой продукт на зоны правильно это сложная задача, о том, как нарезаются команды продуктовые зоны ответственности, на команды-енейблеры для них и платформенный слой, есть отдельная книга, Team Topologies.
Наконец, в больших компаниях появляются процессы, которых нет в маленьких. Performance review, KPI, квартальное планирование, стратегия, всё это инструменты управления большими коллективами. Когда в команде 12-15 человек, тимлид и так знает, кто как работает, и эти системы ему не нужны. Чтобы справедливо оценить 300 человек, продвинуть тех, кто хорошо работает, и расстаться с теми, кто тянет вниз, уже нужны системы оценки, позволяющие объективно это сделать. Сюда же относится бытовая бюрократия: в маленькой компании старый ноутбук просто меняют, в большой же оформляют пересмотр нормы обеспечения, ждут тендер и поставку. Жить в большой компании без этих механизмов нельзя, иначе наступает хаос.
Тимлид в стартапе и небольшой компании
Здесь действует простое правило: чем меньше компания, тем шире спектр ответственности тимлида. В большой компании вокруг него выстроена инфраструктура: отдельные HR под найм и под программы развития, HR-партнер по задачам бизнеса, выстроенная культура собеседований, обученные интервьюеры. Тимлиду остается посмотреть на кандидата, пообщаться и вернуться к своим делам.
В маленькой компании всего этого нет. Нанять надо, а HR нет, и тимлид сам придумывает, как оценить человека: практики крупных компаний на него не налезают, они слишком тяжелые. Дальше идет онбординг нового сотрудника, выдача прав доступа в системах, настройка контроля версий, сброс паролей. По факту тимлид в маленькой компании занимается всем подряд, иногда вплоть до задач системного администратора. Поэтому работа тимлида в маленькой компании больше похожа на человека-единорога, надо делать все, везде и сразу.
Потребность в тимлиде появляется довольно рано, примерно когда людей становится больше трех. Кто-то должен взять на себя базовое планирование и организацию работы. Когда работают двое, договориться можно у кулера. Когда трое, кто-то уже должен поставить встречу, найти время, всех собрать.
Может ли команда работать без тимлида? Может, но роль все равно существует, просто в неявной форме. Она может быть не названа, может перетекать от человека к человеку, но кто-то все равно ее исполняет: если двое поссорились, кто-то идет с ними поговорить; если не получается спланироваться, кто-то берет планирование на себя. Вопрос лишь насколько сильно эта зона ответственности будет пущена на самотёк.
Решения, сроки и зоны ответственности
За срок отвечает команда, она неделимая единица работы. Если сроки сорваны, сорвала их команда. Но крайний все равно тимлид, потому что он лидер и внешний интерфейс для коммуникации. Когда над одной задачей работают несколько команд, к согласованию обычно подключают проджект-менеджера; если его нет, договоренности между командами вытягивает кто-то из продуктовой вертикали или сам тимлид. Распределение здесь подвижное, но ответственность за результат остается на команде, а лицом перед всеми выступает тимлид.
Отдельная типовая ситуация, когда бизнес требует невозможного. Правильный ответ один: объяснить, почему это невозможно. Иногда бизнес действительно заблуждается, и его можно переубедить наглядно. Например, одна женщина вынашивает ребенка девять месяцев, но девять женщин не выносят его за один. Чтобы такое объяснение сработало, тимлиду нужно показать структуру работы: какие этапы нельзя поменять местами, какие риски требуют буфера в оценке, какими последствиями обернется спешка.
У этой же наглядности есть обратная сторона, которая играет на руку тимлиду. Разбор работы по шагам показывает не только жесткую последовательность, но и места, где ее нет. Борщ нельзя сварить раньше, чем нарезана капуста, но мясо вполне можно ставить вариться, пока капуста режется. Когда тимлид раскладывает процесс на этапы, у бизнеса появляются резонные вопросы: зачем делать эти шаги строго друг за другом, если часть из них может идти параллельно и что нужно сделать, чтобы запустить их параллельно. В разработке та же логика: считается, что бэкенд нельзя вести одновременно с фронтендом, хотя на практике можно. Поэтому жесткий срок иногда работает как инструмент, который заставляет пересобрать процесс и найти, что распараллелить, а сам спор о том, реально это или нет, рождает хорошие решения и более точное понимание сроков с обеих сторон.
Прием этот тонкий, и грань здесь важно не переходить. В расслабленном режиме работать удобно, но медленно, а давление действительно помогает найти резервы. Но учить команду работать быстрее это одно, а требовать физически невозможного совсем другое, и второе быстро превращается в потерю доверия.
Что тимлид решает сам, а что согласует, зависит от границы его зоны ответственности. И ключевая мысль здесь такая: ответственность не выдают, ее забирают.
Ты приходишь и говоришь: с тестированием беда, дайте я разберусь, мне нужны полномочия и два тестировщика на три недели. Построил план, исполнил, проблема закрылась. Вот так тимлид и забрал ответственность за то, как работает тестирование.
В организационной структуре важно понимать, где проходит твоя граница, потому что часто ее прямо не проговаривают. Слабый тимлид отмахивается: «это не мое, это эйчары». Но если в команде принято, что тимлид нанимает и отвечает за качество найма, то отказать слабому кандидату и взять сильного это его решение и его ответственность, а мнение HR это рекомендация. Эту зону тимлид во многом устанавливает сам, проактивно.
Сюда же относятся два частых сюжета. Первый про разработчика, который регулярно тормозит команду: задача тимлида понять, что мешает, и помочь, а не отстранить его от сложного. Второй про конфликты внутри команды. Их часто способен разрулить даже не тимлид, а внимательный разработчик: свести две спорящие стороны, разобрать, что конкретно мешает каждой, и помочь договориться. Именно из таких людей, которые создают условия, в которых проблема начинает решаться сама, и вырастают будущие тимлиды.
Как стать тимлидом и кому туда не стоит
Чаще всего тимлидами становятся через неявное лидерство. Человек приходит в команду, помогает один раз, второй, третий, к нему начинают ходить за советом. Он умеет дотянуться до соседней команды или до руководителя разработки, потому что выстроил отношения, и начинает эффективно решать проблемы команды. В какой-то момент к нему приходят и говорят: будь нашим тимлидом. Критерий тут один: тимлид это тот, кому доверяют. Тот, к кому можно прийти с проблемой, зная, что выслушают, дадут совет, а возможно, и решат.
Поэтому хороших тимлидов не ищут, их делают явными. Самые сильные получаются из неявных лидеров, самые слабые из замкнутых, не умеющих разговаривать, но очень результативных разработчиков. Будущему тимлиду дают пилоты: небольшую организационную ответственность, роль технического лидера в проекте между несколькими командами, шефство над джуном. Дальше смотрят, с чем он справляется и от чего загорается. Если человек затащил проект, договорился с соседними командами и получает от этого удовольствие, из него надо делать тимлида.
Навыки, которые стоит качать заранее, лежат в плоскости работы с людьми. Это умение разговаривать, договариваться, выстраивать отношения, замечать состояние команды.
Самые частые ошибки новичков предсказуемы. Новый тимлид, недавно бывший сильным разработчиком, начинает учить команду писать код, не подпускает ее к самым сложным задачам («я же справлюсь лучше») и скатывается в микроменеджмент. Поначалу качество кода действительно может просесть, это нужно принять и не паниковать. Следующий шаг это задать себе вопрос: что мешает команде принимать такие же технические решения, как ты? Часто ответ в том, что у команды просто нет твоего контекста, общения с бизнесом, понимания, куда все движется. Этот контекст и нужно ей компенсировать, тогда команда выйдет на нужное качество и станет самостоятельной.
Куда расти после роли тимлида
Путей несколько. Самый прямой ведет вверх по менеджерской лестнице: тимлид над тимлидами, дальше руководитель разработки. Можно уйти вбок в продукт, особенно если продукты технические: пока управляешь командой и вовлекаешься в продуктовые задачи, в какой-то момент логично стать продакт-менеджером. Можно стать функциональным лидером и отвечать уже не за команду в пять человек, а за все направление, например за весь бэкенд из сорока человек. Реже тимлиды уходят в проджекты, это подходит тем, кому действительно нравится собирать проект, риски и план.
Отдельно стоит сказать про возврат в разработку. Та самая волна докладов «как перестать быть тимлидом» выросла не на пустом месте: для части людей управление оказывается не своим, и вернуться в инженеры это нормальный сценарий, а не провальный. Особенно я наблюдяю сейчас тенденцию, когда руководители с штаткой под сотню человек отказываются от менеджмента и возвращаются к разработке, но с агентами. У меня в окружении стало пугающе много таких. Это называется путь индивидуального контрибьютора (IC) и технического лидерства. Таких ролей меньше, особенно в России, где не везде готовы платить большие деньги специалисту на уровне больших руководителей, который никем не управляет, но они существуют. На эту тему можно посмотреть круглый стол «Техлид и развитие в Individual Contributor: как превратить код в карьеру».
Кому не стоит идти в тимлиды
Категорически не подходит роль людям без эмпатии. Если человек не считывает, что чувствует собеседник, он будет избыточно жестким и начнет демотивировать команду, часто сам того не замечая. В любой нештатной ситуации такой руководитель скатывается в обесценивание и давление, и в пределе люди от него просто разбегаются. Управление командой держится на способности понимать людей, без нее технически сильный человек принесет больше вреда, чем пользы.
Итоговый ориентир простой. Если ты получаешь удовольствие от того, что твои люди складываются в сильную команду и выдают результат, иди в тимлиды. Если хочешь делать сложную инженерную систему собственными руками и вести людей за собой инженерно, иди в техлиды, эта ветка существует, но будь готов, что в ней сложнее расти. И главное помнить: тимлидство это другая профессия. Пересаживаясь в нее с разработчика, придется во многом забыть прежние привычки и перестать лезть к команде с техническими мнениями.
Коротко: вопросы и ответы
Чем тимлид отличается от сеньора?
Сеньор закрывает задачи, тимлид складывает людей в работающую команду.
Сколько тимлид пишет кода?
Почти не пишет. Его главный инструмент это разговоры, на программирование времени не остается.
Кому подчиняется тимлид?
Зависит от устройства компании: тимлиду над тимлидами, руководителю разработки или IT-лидеру кластера.
Как становятся тимлидом?
Чаще всего через неявное лидерство, его замечают, дают часть ответственности, где он вырастает, потом – доверяют команду
Кому не стоит идти в тимлиды?
Людям с плохими коммуникационными навывками и увлеченным инженерам (если вы хотите разрабатывать, вас будет возвращать в разработку и вы будете недорабатывать свою зону ответственности).
Можно ли вернуться из тимлида обратно в разработку?
Да, это нормальный сценарий. Для части людей управление оказывается чуждо, и возврат в инженеры это правильное решение.