Друзья, сегодня поговорим о становлении и развитии лидера и руководителя в разработке ПО. Для начала несколько слов обо мне.
Сейчас я работаю в Wildberries, руковожу несколькими командами разработки. Мы делаем новые для компании финансовые сервисы. И помогаю студентам Практикума становиться лидерами для разработчиков на курсе Управление командой разработки.
Мой путь в IT начался в 2003 году, когда мы с партнёром решили сделать браузерную MMORPG, они тогда входили в моду. Я начинал как геймдизайнер, но в маленьком стартапе не хватало финансирования, поэтому я занялся разработкой на PHP и JS, а позже на Java. Уже тогда я познакомился с гибкими методологиями разработки ПО и получил опыт управления людьми. Но, как и большинство маленьких стартапов, наш не выжил. И я продолжил карьеру в разработке ПО.
В 2007 году я занял тимлидскую позицию в IT-компании, хотя называлась она «архитектор Java». Далее весь опыт был так или иначе связан с лидерством и руководством людьми в разработке. Я работал в «Ренессансе», DB, Grid Dynamics, Сбере и «Райффайзен Банке». Команду в «Райффайзене» я считаю своей вершиной тимлидства.
В 2021 году я покинул «Райффайзен» и пришёл в «Тинькофф», где возглавил отдел из шести, а позже восьми команд. С этого момента мой опыт был связан с управлением несколькими командами.
Инженер, лидер, руководитель
Когда заходит речь о переходе разработчика на руководящую позицию, говорят, что руководитель должен уметь делегировать и меньше работать с кодом. Если пойти по этому пути, команда теряет хорошего инженера и получает плохого руководителя.
Я из своего опыта сделал обратный вывод. Для меня тимлид — это в первую очередь сильный инженер, который своим примером показывает, как хорошо писать код, тестировать и так далее. Тут кроется ключевая разница между руководителем и лидером.
Руководителем для разработчиков может быть и project manager, и кто-то из топ-менеджеров в маленькой компании. Он поставит задачи и оценит результаты. Даст премии и уволит того, кто не справляется. Но он будет чужим. Лидер — это свой и лучший из нас. Тот, кто организует группу для достижения общих целей и берётся за наиболее ответственный кусок работы. Это Акела, который не промахивается.
С лидером на 1:1 намного охотнее будут обсуждать то, что волнует. Лидеру серьёзно и подробно расскажут об инженерных проблемах, потому что он поймёт их и может подсказать решение.
От лидера ожидают поддержки, защиты и помощи в развитии. От руководителя ожидают оценки — если повезёт, справедливой. Целей, задач, наград за достижения и наказаний за провалы.
В реальности обычно приходится совмещать роль лидера и руководителя. Я стараюсь выдерживать баланс 90/10.
Функциональные и кросс-функциональные команды
Следующий важный вопрос для понимания того, что требуется от тимлида:
Что у него за команда?
Тимлидом могут называть человека, с которым работают ещё два инженера в его же функции — например, команда из трёх разработчиков на Java. Или команда из 16 человек, включающая разработчиков бэк, web, Android, iOS и QA-инженеров. Это будут очень разные истории тимлидства.
Я сторонник кросс-функциональных команд; чтобы перечислить все причины, нужна отдельная статья. Для лидера кросс-функциональной команды первый очевидный вызов — вызов других компетенций: как же я буду лидером для iOS-разработчиков, если я джавист или даже QA? Серебряной пули не существует, придётся вникать во все функции. T-Shape наше всё.
В «Райффе» у нас были Java, React и QA. Моя основная техническая компетенция — Java, но и React я знал на некотором уровне. Я сразу при построении команды решил, что мы будем работать в режиме full stack. Я не был сильным специалистом в тестировании, но имел представление о нём и мог осмысленно участвовать в выработке решений. Таким образом я был лидером для всей команды. Когда я ушёл, я оставил команду старшему QA. Ему было сложнее, но и он справился.
В команде с отдельными функциями тимлиду будет тяжелее, чем другим инженерам, — когнитивная нагрузка значительно больше. Придётся держать в голове контекст всех функций и специфичные лидерские задачи.
Если хотите понять, какие навыки решения управленческих и бизнес-задач являются вашими сильными сторонами, а какие — требуют развития, пройдите бесплатный тест-ассессмент от Практикума.
Вы получите подробный отчёт с результатами и рекомендациями по развитию навыков — конкретные шаги со списком ресурсов для обучения.
Что делает тимлид
Главный драйвер развития руководителя разработки — готовность и желание взять больше ответственности
Итак, мы определили, что тимлид остаётся инженером. Но чем он занимается кроме кода? Тимлид создаёт команду, если её нужно создать с нуля, налаживает работу, поддерживает атмосферу в команде. Организует, а иногда и просто ведёт коммуникацию команды с внешним миром.
Атмосфера
Тимлид создаёт атмосферу в команде
Когда ты инженер, этот вопрос не твоя зона ответственности. Твоя — улавливать задачи и выдавать по ним результат. Ты выбираешь команду, которая тебе нравится, подстраиваешься под атмосферу и уходишь, если атмосфера меняется и это тебя не устраивает.
Когда ты тимлид, атмосфера в команде — именно твоя зона влияния. При этом у тимлида и СТО (или другого руководства) могут не совпадать ценности, взгляды на построение атмосферы и представления о том, «что такое хорошо, что такое плохо».
Атмосфера и культура в разных командах одной компании может различаться — и чем больше различия, тем больше будет «искрить» коммуникация между этими командами. Приходя в компанию, постарайтесь понять, насколько вам близка её культура. Если совсем не близка, стоит расстаться в период испытательного срока. Бывает, что компании меняются, и вы становитесь частью этих изменений.
Приходя в Сбер в 2016 году, я хорошо понимал, что культура компании (as is) мне не нравится. Но с руководителем IT-департамента у нас было близкое видение того, что мы хотим выстроить (to be). Участвовать в трансформации, конечно, интересно, но это всегда сложнее, чем работать в близкой компании. Часто трансформации приносят меньше изменений, чем ожидалось, и лидеры этих трансформаций уходят из компаний.
Интересы команды разработки и бизнес-подразделений тоже часто различаются. По идее мы вместе делаем общее дело, но на практике инженеры хотят поиграться с технологиями и чтобы их не трогали, а бизнес — просто требовать больше или переложить на инженеров ответственность.
Тимлид обычно оказывается мостиком между командой разработки и бизнесом. В случае конфликта интересов ему нельзя занимать ни одну из крайних позиций:
просто транслировать требования — команда перестанет воспринимать его как лидера;
пытаться игнорировать бизнес — его просто заменят.
С другой стороны, если найти баланс, можно укрепить управляющую позицию — вместе с командой приносить бизнесу хорошие результаты и защищать команду от неразумных требований. Такое управление будут ценить обе стороны.
Говоря об атмосфере, часто говорят о балансе между формальным и неформальным общением. Мой баланс максимально смягчён в неформальное — всегда на ты, максимально возможное поддержание однорангового контекста. Да, я могу быть руководителем и есть вопросы, которые я решаю единолично, но в остальном — мы команда, у которой есть проблемы/задачи и которая совместно вырабатывает решения. Я минимизирую количество решений, которые я принимаю сам. Остаются увольнение и найм, хотя и тут я стараюсь привлекать коллег к fit interview.
Я придумываю нерабочие занятия: беседы о мировоззрении, в «Тинькофф» собирали команду на квиддич; стараюсь налаживать контакт вне работы — вместе побегать, поиграть в настолки и так далее. Считаю ценным создавать пространство, где мы — равные люди.
К атмосфере в команде я отношу и язык, на котором в команде обсуждают руководство и соседние команды. Тимлиду важно подавать пример и корректировать то, что он считает неуместным.
1:1
Я считаю, что 1:1 — очень важная и много где недооцененная практика. Работая в «Тинькофф», половина всего полезного, что я сделал, — сделал за счёт работы с лидерами моих команд 1:1.
Часто бывает, что какую-то идею или новый элемент процесса команда встречает серьёзным сопротивлением. В таких случаях я отступаю и обсуждаю эту идею с каждым по отдельности — 1:1. В приватном контексте проще разобраться в сути сопротивления и выработать решение, которое устроит всех.
Контакт, сформированный 1:1, помогает серьёзно работать с мотивацией и решать другие проблемы.
В ведении 1:1 есть важные ключевые вещи:
Регулярность
Лид команды инженеров может проводить встречу раз в 2 недели на час или 30 минут. Будучи руководителем тимлидов, не работая с ними так плотно каждый день, я ставил часовой 1:1 каждую неделю.
Приватность
На первом 1:1 проговаривается правило приватности, и оно строго соблюдается. Это позволяет вам обсуждать важные, чувствительные вещи.
Контекст
Договорённости фиксируются и по возможности исполняются. Это не формат по…трепались-разошлись.
Время подчинённого
Если 1:1 ведёт руководитель или лид, то это время принадлежит подчинённому. В первую очередь обсуждаются вопросы, важные для него. Это совсем не отчётная встреча по задачам.
Коммуникации с внешним миром
Product Owner — главный человек для тимлида, он скорее партнер, чем заказчик. Это две головы, которые вместе ведут бизнес вперёд. Доверяют друг другу в своей области и пробуют челленджить друг друга. Кстати, 1:1 тимлида и PO — очень полезная практика, которую мы в «Райффе» выработали намного позже, чем следовало бы.
Современный подход — инженеры могут конструктивно критиковать задачи PO. В «Райффе» в 9 из 10 случаев РО объяснял, почему нужно делать так, а в 1 из 10 говорил: мне неважно как, важно достичь цели, если вы видите путь лучше, выбирайте его, я не настаиваю.
Часто заинтересованные лица — это пользователи: администраторы, поддержка, operations, нужно вникать в их потребности. Если РО сфокусирован на внешней стороне продукта (клиенте), то тимлид занимается тем, как процесс идёт изнутри.
Планирование
Не ресурсы, а люди
Моё мнение: подход к людям как к ресурсу — заранее плачевная стратегия. Команда чувствует, что они всего лишь средство для достижения целей, падает мотивация, теряется контакт с руководством. В первую очередь все мы — люди.
Планирование ресурсов я заменяю на самоорганизацию команды. Главный индикатор: команда выполняет задачи или объясняет, почему не делает этого. Это важно оценить, тут вам поможет коммуникация внутри команды.
Становиться начальником и следить за каждым рабочим часом каждого инженера — только разрушит доверие и навредит процессам, сорвёт планы и снизит результаты. Если кажется, что получить хоть какие-то результаты от команды можно только так, обычно лучше расформировать команду, обычно вместе с тимлидом.
Что касается формирования планов для команды, я для себя понял следующее. SCRUMовское планирование спринта, обычно 2 недели, — полезная штука. При должной настройке даёт приличные результаты. Тут же работает экспресс-оценка сторей лидом и прикидка предварительного Roadmap.
Вполне можно делать подобную процедуру с командой на квартал. Относительные погрешности будут больше, но работает лучше многих альтернатив.
На горизонте года, если мы способны хоть как-то планировать на этом горизонте, я предпочитаю OKR. Это не совсем план, но выполняет большинство его функций.
Управление временем
У рядового инженера в норме не должно быть проблем с управлением временем. У него есть основная задача в работе, обычно одна. Большую часть рабочего дня можно ей посвятить. Бывает, надо с кем-то пообщаться, бывает, посмотреть PR — но этого немного. Если у вас инженеры завалены встречами, что-то явно идёт не так.
У меня в управлении несколько команд, которые обычно работают более чем над одним продуктом, поэтому полностью забитый календарь — это моя норма жизни. Поработав в этом режиме, я понял для себя:
Календарь — это святое!
Если держать в голове, в устных договорённостях и каких-то чатиках около 50 встреч в неделю, больше ни на что головы уже не хватит. Поэтому важно внести все встречи в календарь. Ответить на приглашения — пойду/не пойду/возможно, и самое главное — соблюдать эти договорённости. Тогда и вы, и ваши коллеги смогут использовать голову, чтобы думать о рабочих вопросах, а не о том, кого и сколько раз надо пнуть в каком мессенджере, чтобы важная встреча таки состоялась.
В «Тинькофф» я выработал скил: какой бы важности люди на встрече ни были, когда закончилось время встречи (а разговор часто ещё в разгаре), а у меня начинается следующая, — я «нажимаю кнопочку» и выхожу из созвона. Важно удержать эту позицию. Этот навык очень полезен для тимлидов, хоть и поначалу может быть не очень комфортно. Для разработчиков неумение нажимать на кнопочку не так критично, у них не так много встреч, особенно подряд.
Тимлид — это в первую очередь сильный инженер, и, чтобы оставаться таковым, ему нужно выполнять инженерные задачи вместе с командой. Я считаю, что тимлид должен работать с «кодом» (тестами, настройками СI, логами с прода … ) не менее 50% своего рабочего времени, соответственно, ему нужно не менее 50% свободного календаря. И это его задача — поддерживать календарь свободным.
Не стоит ходить на встречи «за компанию», «послушать» или «чтобы быть в курсе». Попросите переслать минутки, прочитать их намного быстрее. Модерируйте свои встречи и просите модерировать других, чтобы вопрос, который можно решить за 10 минут, не обсуждался час. Прежде чем собирать встречу, попробуйте выработать решение сами и предложите то же коллегам. Если много встреч, где обязательно кто-то должен представить команду, делегируйте их другим опытным инженерам.
Мотивация, Энергия и Выгорание
Важный аспект деятельности тимлида — работа с людьми (people management). И это не про согласование отпусков и даже не про ИПР. Чтобы люди вносили вклад в создание интеллектуального продукта, надо, чтобы они хотели (мотивация) и могли (энергия) работать головой. Обеспечить выполнение этих двух условий — и есть работа с людьми тимлида.
Мотивация — большая тема, не хочу углубляться в неё в этой статье. Но вот пара ключевых мыслей.
«Финансовая мотивация» — это не мотивация.
Деньги сильно влияют на то, где человек будет работать (или лениться), — мало кто в индустрии отклонит предложение на х1.5. И также деньги слабо влияют на то, будет человек работать или лениться. Это подтверждают исследования. Поэтому премии, привязанные к KPI, — зло. Чтобы сохранить хорошую команду, нужно платить им достойную рыночную зарплату. Деньги — фактор необходимый, но недостаточный.
Реальная мотивация возникает, когда мы разбираемся в том, чего человек сам для себя хочет, от чего его «прёт», и связываем это с работой и успехами в ней.
В вопросах работы с энергией и выгоранием я опираюсь на терминологию Анны Обуховой. Её курс «Энергия лидера и Команды» я прошёл в 2020 году, работая в «Райффайзен Банке», и очень благодарен ей за этот опыт. Для глубокого изучения темы рекомендую обратиться к первоисточнику.
По Обуховой лидер — это человек, у которого уровень энергии выше, чем у группы. Поэтому первое, что важно для тимлида, — это поддерживать собственный уровень энергии. А обнаруживая проблему у себя, решать её и не бояться показать. Не стоит изображать железного человека. Работая в WB, я запомнил случай: в 20 вечера я закончил последнюю встречу и открыл в Телеграме папку «Работа», чтобы проверить, кому что от меня нужно. Я увидел около 20 непрочитанных чатов, в 4 или 6 из которых я был тегнут. Посмотрев на это, я понял, что энергии/мозга (или мыслетоплива по Дорофееву) осмысленно это разобрать у меня нет, и решил закрыть компьютер и вернуться к этим вопросам завтра. Эту историю я спокойно рассказываю коллегам.
Работая с людьми, важно узнавать симптомы выгорания и вместо агрессии и претензий помочь им разобраться с их ситуацией. Иногда это будет означать пойти к их руководству и попросить не давить на них :-)
Уровень энергии определяет также способность соображать и рационально действовать в стрессовой ситуации. Стрессоустойчивость — это во многом запас энергии. Я наблюдал, как, реагируя на одну и ту же неприятную новость (стрессор), коллеги из одного отдела (где были проблемы с выгоранием) впадали в истерику, выкрикивали вопросы и не слушали ответов. В то же время другие сохраняли спокойствие, обдумывали проблему и предлагали варианты решения.
А ведь упавший прод — это стрессор посерьёзнее неприятной новости.
Настраивая процессы, важно понимать, на какой уровень энергии людей, в них участвующих, вы рассчитываете. Люди с высоким уровнем энергии, оказавшись в ситуации, когда каждый шаг регламентирован, будут чувствовать себя винтиком, неспособным влиять на что-либо. Люди с низким уровнем энергии, выпущенные в чистое поле с «амбициозными целями», будут паниковать или впадут в ступор.
Мягкость и воля: мой подход
Важно совмещение (а не компромисс) мягкости и воли — готовность вникать в идеи и желания людей, не навязывать своё мнение; при этом проводить изменения и выстраивать структуру и атмосферу, которые ты считаешь правильными.
Только мягкий и всем приятный лидер создаст болото, где с результатами не очень. Только воля без способности найти контакт — это жёсткий начальник, команда которого объединяется не общим делом, а защитой от него и от необходимости работать. Эффективность тут тоже так себе.
Лидер отличается от окружающих его людей тем, что способен организовать их деятельность для достижения их целей. И нужен он окружающим ровно потому, что чаще всего мы не можем достигать целей самостоятельно. Механизм лидерства сформировался примерно, когда наши предки охотились на мамонта. Ни один охотник не мог убить мамонта сам.
У лидера должно быть видение того, как мы будем достигать наших целей. Видение — не догма, его можно обсуждать, нужно слышать критику, но оно не определяется демократически. У лидера должно хватать воли реализовывать это видение. Иногда это может выразиться жёсткой модерацией встречи, а иногда решением расстаться с членом команды, который неплохой инженер, но не вписывается в культуру. И культуру даже не текущей команды, но той, которую лидер хочет построить.
Мягкость лидера вытекает из той же основы. Окружающим нужен лидер, чтобы достигать своих целей. Они ему доверяют. Чтобы оправдать это доверие, лидер должен приблизить каждого члена команды к его цели. И в большей мере, чем человек мог бы сделать это сам. Для этого надо эти цели для начала хорошо понять.
Заключение
Чтобы быть на одной волне с командой, недостаточно быть хорошим менеджером. Нужно знать процессы разработки изнутри, понимать, на каком языке говорит команда и в каком мире она живет.
Если управлять командой и не заниматься личным кодингом — можно превратиться в начальника, а это не то, что требуется от лида команды разработчиков. При этом, если заниматься только разработкой и не прокачивать лидерские качества, можно потерять доверие команды.
Моё мнение — 50 на 50 должно быть в отношении личного кодинга/управления и мягкости/воли. Приглашаю обсудить в комментариях опыт.