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

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

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

Дело в том, что с давних пор в Winfox работает немного доработанный принцип известного профессора бухгалтерского учета школы бизнеса Джеймса МакКинси «Up or Out» в формате «Up or Outstaff». Если разработчик, ставший сеньором, не растет в сторону тимлида или управленца, мы обычно переводим его на работу по модели аутстафа.

Тимлид — это человек, который одновременно отвечает и за результат работы команды, и за процессы, и за людей. Ближайшая аналогия тимлида для команды в иерархической лестнице — это генеральный директор для компании. Зона ответственности директора — это успех работы компании, а для тимлида — это успех работы команды. Для того, чтобы команда была успешной, нужны понятные цели. Получить эти цели у заказчиков — работа тимлида.

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

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

Важное отличие тимлида в Gett в том, что тимлид — это не самый опытный инженер. В других компаниях зачастую тимлид — это по существу техлид, который осуществляет технический контроль над продуктом. У нас же тимлид одновременно выполняет функции проджект-менеджера и пипл-менеджера. Совместно с проджект-менеджером тимлид адаптирует и внедряет процессы, принятые в компании, в отдельной команде, одновременно с этим заботясь о людях и их развитии. Для этого мы практикуем 1-1 встречи и планы развития для каждого сотрудника.

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

В e-legion есть разные роли тимлидов и наставников. Например, есть основной тимлид — руководитель отдела. Есть менторы — прокачанные аналитики с высоким грейдом, у них есть менти, которых они грейдируют. Менторы обычно минимум на два грейда выше своего менти. Они помогают осваивать новые инструменты и отвечают на вопросы, то есть тут идет речь именно о помощи с точки зрения профессионального развития.

Еще есть бадди — наставники на время адаптационного периода. Когда приходит новый аналитик, за ним закрепляется бадди. Он помогает именно освоится в компании, тут не важно какой у кого грейд, здесь важно, что человек погружен в процессы компании, знает, что как устроено и может в этим поделиться.

И есть тимлиды именно в командах на конкретных проектах. Они распределяют и контролируют задачи уже в рамках проекта.

Такая система помогает снимать нагрузку с руководителя отдела, а также развивать у сотрудников управленческие навыки и растить управленческий кадровый резерв.

Для меня тимлид — это человек, который несет экспертизу внутри компании. Это профессионал в своей предметной области, который в случае чего может помочь, подсказать и объяснить.

Также для меня тимлид — это тот, кто формирует климат в коллективе. А климат, в свою очередь, влияет на то, как развиваются сотрудники, как они себя чувствую в компании. То есть роль тимлида требует от человека, который ее выполняет, владения как «хардовыми», так и «софтовыми» скиллами.

У нас нет четкой вертикальной иерархии, когда есть тимлид, все с ним соглашаются и всегда на «вы». Когда я пришел в команду, то сразу сказал ребятам, что я такой же разработчик, как все здесь: со мной можно общаться о работе, на отвлеченные темы. Я не большой начальник, которого надо бояться, выполняя поручения.

Например, у нас в отделе iOS-разработки все строится на том, что каждый из нас — полноценная рабочая единицы со своими обязанностями и ответственностью. Такой подход мне кажется наиболее эффективным, потому что создается комфортная среда для работы. При такой открытости я как тимлид могу гораздо более оперативно заметить, что конкретного сотрудника что-то идет не так. Ребята открыты: если что-то не нравятся, они говорят. И я могу влиять на это, исправлять ситуации и помогать им возвращаться в комфортное состояние.

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

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

У нас в ICL Services матричная структура, и есть два типа тимлидов: линейный и проектный. Линейный — как тренер. Готовит к забегу, следит за тем, чтобы все использовали единую и принятую методику бега, делится лучшими практики бега, снабжает формой, отслеживает календарь марафонов. Проектный — это как раз тот самый pacemaker, который помогает команде хорошо бежать. Двухъярусная система работает за счет того, что одни тимлиды не заняты в операционной деятельности и могут создавать организационные условия для развития сотрудников, а вторые, наоборот в проекте — работают на заказчика, но не нянчат новичков до требуемого уровня, а просто получают готовых «бегунов» от линейных.

Чувство плеча и командообразование — основной в фокус в работе линейного тимлида в компании. Можно выделить четыре отличительных черты в ICL Services: тимбилдинги, нетоксичная организационная культура, этика правды и прозрачность.

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

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

Из важных практик, которые мы подметили исходя из опыты, это, конечно же, встречи 1-1 — личные разговоры с каждым сотрудником. Так же хорошо себя показывают еженедельные доклады (они у нас называются техно), которые позволяют держать руку на пульсе прогресса и давать пищу для ума всем сотрудникам. Это хорошо влияет на обучение и удержание сотрудников в компании.

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

Роль тимлида находится как бы на стыке разработки и менеджмента, поэтому помимо обязательных hard skills (например, для проведения код-ревью или менторства) у него должны быть хорошо развиты и soft skills. Например, умение принимать решения и брать на себя ответственность за них. Из этого вытекает другой навык — делегирование. Ну и конечно, никуда без дисциплины и тайм-менеджмента. Невозможно управлять проектом, командной, если не умеешь управлять личными ресурсами.

Я выступаю в роли тимлида около четырех лет и могу сравнить свою роль с «играющим тренером» или вожатым в лагере. Временами приходится не только продумывать архитектуру приложений, баз данных, проводить декомпозицию задач, быть скрам-мастером, следить за прогрессом проекта, составлять отчеты и сметы для клиентов, но и писать код, собеседовать кандидатов, быть ментором для новичков и старшим товарищем для любого в команде, при этом соблюдать сроки и требования бизнеса. Как говорится, и швец, и жнец, и на дуде игрец.

В нашей команде все построено на атмосфере открытости и доверия. Мы радуемся общим и персональным успехам и делимся неудачами, чтобы поддержать друг друга и не наступать на эти «грабли» в будущем. Мы регулярно проводим время вместе и вне работы, например отмечаем дни рождения, после напряженной недели ходим в бар или друг к другу в гости — играть в настольные игры. А пару раз я даже помогал коллегам в переезде – такой тимбилдинг неплохо сплачивает и позволяет понять, кто как работает в команде.

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

У нас в CoMagic нет четко зафиксированных тимлидов. В зависимости от проекта или продукта мы собираем команду с нужными компетенциями — и в ней вырисовывается лидер, который драйвит, пушит, мотивирует и ведет за собой остальных. Такой подход к тимлидству связан с тем, что каждый наш проект требует специальных компетенций, которые могут быть или не быть. Иногда, например, нужно сделать упор на фронтэнд, иногда — на логику в бэкэнд, иногда — на работу с базами данных.

В нашем понимании тимлид — это лидер, который может всех объединить. За ним другие пойдут и в лес, и в горящую избу. Тимлид разделяет ценности компании, ведет вперед команду или проект, объективно оценивает ресурсы и ситуацию.

Тимлид — это человек, который может быть полностью автономным и самостоятельным. Он в силах принимать решения на своем уровне и адекватно оценивать ответственность за них. Еще один из важнейших навыков — гибкое мышление: у тимлида должен быть готов аргументированный ответ на любой вопрос его команды. Стрессоустойчивость тоже очень полезна.

Основная задача тимлида в нашей компании — это создание процесса и контроль его выполнения. Выстраивая тимлидство, мы выбрали весьма нетривиальный путь. Для начала мы разобрали компетенции и наложили их на процессы и задачи, где нам нужны тимлиды. А параллельно с этим сформулировали требования к навыкам, которые мы бы хотели видеть в ребятах на позициях лидеров, кроме базовых (гибкое мышление, ответственность, стрессоустойчивость), приверженность ценностям компании. А теперь лайфхак. Мы определили лидеров мнений через внутренние чаты, посиделки на офисной кухне и внутренних мероприятиях. После такой фильтрации у нас осталось всего три кандидата. Любопытно, что каждый был хорош в рамках какой-то одной компетенции. Таким образом сформировалась команда линейного управления, в которой присутствует и порядок, и взаимовыручка.

Тимлид — это руководитель и технический специалист. Поэтому он должен отлично понимать процесс разработки и обладать большим техническим опытом, знать, как реализовать любую задачу.

Так же, как и в других компаниях, наши тимлиды организуют команду, строят рабочие процессы и знают, какие технологии лучше использовать. Но есть важное отличие. Поскольку во многих проектах мы используем Kotlin Multiplatform Mobile, нашим тимлидам нужно меньше усилий на синхронизацию Android- и iOS-разработчиков. Для обеих платформ вначале продумывается одна бизнес-логика, и таким образом команды автоматически синхронизируются.

В моем понимании тимлид в команде выполняет три основных функции.

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

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

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

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