Я не перестал быть инженером, когда стал руководителем

Продолжение моей предыдущей статьи о том, как я из инженера радиосвязи стал тестировщиком базовых станций. Если коротко: десять лет я занимался радиосетями, потом перешёл в тестирование телеком-оборудования, а сейчас работаю в YADRO над базовой станцией, которую мы разрабатываем с нуля.

За это время я прошёл путь от инженера до руководителя группы, в которую входят две команды по восемь человек. Расскажу, как это произошло и что изменилось.

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

Почему и как я вообще пошёл в руководство

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

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

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

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

Первые месяцы: что изменилось

Задачи, которые мне как инженеру не особенно нравились, — заводить и актуализировать задачи в Jira, составлять описания — стали существенной частью работы. Это было ожидаемо, но в новой роли я посмотрел на них под другим углом: теперь они помогали мне организовывать работу команды, и отношение к ним изменилось.

Сложнее всего было перейти от «я сам знаю, как сделать» к «мне нужно помочь другим сделать хорошо». И да, хотелось сесть и решить задачу самому — иногда хочется и сейчас. Но со временем понимаешь: рук у тебя только две, часов в сутках 24, а кроме работы есть ещё и семья. Лучше потратить время и лишний раз объяснить, чем делать каждый раз самому. Хотя это про спокойное время. В кризисной ситуации главное — дойти до цели, и какие задачи ты в этот момент делаешь, уже не так важно.

Главная ошибка начинающего руководителя — кажется, что времени стало больше, и хочется помочь сразу всем и во всём, что-то сделать самому, чтобы разгрузить команду. Но так ты замыкаешь слишком многое на себе: это негативно сказывается на результате и не даёт расти участникам команды.

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

Как добавилась вторая команда

Когда мне предложили взять под руководство ещё одну команду, я согласился: это совпало с моим желанием расти.

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

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

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

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

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

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

Как я понимаю, что команда «здорова»

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

Есть и неформальный слой: на синках в течение спринта по тому, насколько люди включены в беседы и проблемы коллег, можно делать предположения о вовлечённости и возможных проблемах. Если замечаю их признаки — организую внеплановый 1-1, чтобы обсудить ситуацию.

Как устроены 1-1

1-1 провожу раз в три недели, формат зависит от ситуации. Можем начать с рабочих вопросов, если горячая пора и не успели обсудить раньше. Люблю поговорить о жизни: считаю важным понимать состояние человека, потому что личная жизнь влияет на работу. Когда я в курсе, что происходит у человека, мне понятнее, почему задачи буксуют или идут дольше обычного. Готов обсудить то, что важно сотруднику, обучить процессам, направить. Это время, когда я не отвлекаюсь на переписки и рабочие вопросы, а полностью погружен в общение. Даю обратную связь: команды у меня замечательные, поэтому чаще она положительная и подкрепляет хорошую работу. Но бывает и развивающая — чтобы в будущем не возникало вопросов и мы понимали ожидания друг от друга.

Что даётся тяжело

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

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

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

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

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

Что изменилось во мне

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

Что я перенёс из инженерии в управление

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

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

Из инженерного мышления я перенёс в управление умение фокусироваться на сути проблемы и решать её, а не общаться о светлом будущем без конкретного результата. И ещё одно: когда на доске в Jira нет задач, работы всё равно очень много — и не уверен, что она когда-нибудь закончится. Всегда есть на что обратить внимание и что улучшить.

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

Насколько важно руководителю технической команды оставаться сильным инженером? Думаю, всё зависит от типа личности. Мне легко с любым вопросом пойти к тому, кто разбирается лучше. Кому-то будет максимально дискомфортно, и он после работы сядет изучать непонятные вопросы.

Скучаю ли я по инженерии

Да, когда приходится постоянно переключаться между разными контекстами, хочется сесть и заняться чем-то одним. Но от предложения вернуться отказался бы: мне нравится вовлечение сразу во всё, и возможность сделать лучше или помочь большему числу сотрудников доставляет удовольствие. Хоть окружающие часто и не замечают изменений — они на самом деле происходят.

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

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

Что делать, если роль всё-таки не подошла? Знаю коллег, которые возвращались в инженерию и не пожалели: управленческий опыт никуда не девается, он делает тебя сильнее и как специалиста. Поэтому попробовать и откатиться — это не провал, а нормальный способ понять, твоё это или нет.

Если бы меня попросили дать совет инженеру, который вот-вот возглавит команду, я бы сформулировал его так:

• Забудь про желание сделать самому: времени на это не хватит.

• Будь честен с командой и не стесняйся просить помощи в решении задач.

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

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