Привет! Меня зовут Сергей, я руководитель отдела разработки компонентов опорной сети 5G в YADRO. Когда меня пригласили на эту роль, я не знал, как работают протоколы управления сессиями и чем конкретно LTE отличается от 5G, но точно знал, как выстроить процессы в команде, где каждый второй — инженер с десятилетним стажем.
Как вы уже поняли, стать руководителем в телеком-команде без опыта в телекоме можно. Навыки здесь нужны те же, что и руководителю в любой IT-компании: выстраивать процессы, работать с людьми, принимать решения, управлять сроками и рисками. Предметная область подтягивается по ходу, а вот к масштабу задач придется привыкать. Сложно ли было не «поплыть» и пришлось ли зубрить спецификации 3GPP на ночь, я расскажу далее.
Жизнь до телекома
Когда я поступал в вуз, сразу выбрал специальность «Информационные системы и технологии» — по сути, я учился на классического программиста. До второго курса практически все мое свободное и несвободное время занимал матан и его окружение. А потом мой близкий друг стал делать сайты, и я присоединился к нему — в результате уже на третьем курсе у меня был более-менее регулярный фриланс и опыт разработки.
Бакалавриат близился к концу, когда ко мне подошел мой научный руководитель: «Сергей, у меня есть контакт человека, который ищет молодые таланты и, возможно, предложит работу. Хочешь сходить на собеседование? Нужен хороший английский». У меня был уверенный Intermediate, так что я согласился.
Загадочным контактом оказался американец, который открывал офис в моем городе и набирал команду. Интервью было не одно, а три, и все с коллегами из Америки. На техническом этапе мне показали программу на C++: попросили объяснить, как она работает, и внести небольшую доработку. Справился я лучше, чем ожидали от студента, и меня взяли на работу. Формально — в отдельной локальной компании, а по сути — в Macnica Americas, американском подразделении японской Macnica. Там я провел практически восемь лет.
Сначала я был разработчиком: писал на Node.js и C++ для устройства, которое передает 4K-видео по IP-сетям (в своей финальной форме это модуль MPA1000). Года через четыре мне стало тесно в коде, и я вызвался навести порядок в требованиях и добрал себе «бейджик» бизнес-аналитика. Первое время совмещал новое направление с разработкой, а потом полностью ушел в аналитику и управление проектом — с командировками на демо и воркшопами от Японии до Канады.
Летом 2022 года наш директор вернулся в Америку, я принял его дела, возглавив наше подразделение из 20 человек. Вместе с руководством компании организовал переезд команды в Грузию. В 2024 году мы доработали продукт до стабильной версии, и глава моей жизни под названием «работа на американскую компанию» закончилась.
Скучал я недолго: коллеги позвали в проект, где мы делали ИИ-агента для написания кода — по сути, это аналог сегодняшнего OpenCode. Роль у меня была необычная: не менеджер и не разработчик, а скорее методолог. Я руками исследовал, как строить разработку с помощью ИИ: где он силен, где врет, как его промптить, как собирать цепочки и оркестрацию агентов. Было интересно, но в мою жизнь снова вмешался случай: бывший коллега устроился в YADRO, оценил размах проектов и четкость процессов и предложил мне попробоваться на вакансию руководителя. И я попробовал!
Как проходил отбор
Коллега, который позвал меня в YADRO, работал в направлении RISC-V, и сначала я откликнулся на роль руководителя в эту команду. Оказалось, для этой роли нужен сильный технический бэкграунд именно в разработке процессоров. Но рекрутер предложила мне попробоваться в другое направление — телеком, и я согласился.
Ввиду роста команды и масштаба проектов в дивизион Телеком искали руководителей сразу в несколько отделов. Нужны были сильные управленцы, которые умеют выстраивать процессы и работать с большими разношерстными командами. Разбираться в домене было необязательно.
Как мне объяснили позже, в командах телекома сильный стек технических специалистов и продакт-менеджеров, поэтому от руководителя отдела принимать решения в «техничке» не требуется — по крайней мере, на первых порах. В команде всегда есть люди, которые знают свою тему назубок. Если нужна какая-то информация по проекту, чтобы принять верхнеуровневое решение, ты идешь и общаешься с коллегами. Спойлер: эта схема действительно прекрасно работает.
До получения оффера я прошел четыре интервью.
→ Первое — традиционный скрининг с HR-специалистом.
→ На втором несколько опытных руководителей в телекоме оценивали мои управленческие навыки, в том числе через решение кейсов. Кейсы, в целом, классические: «Два тимлида месяц воюют из-за архитектурного решения, команды разделились на лагеря, сроки едут, и каждый по-своему прав. Как разруливать?». Или «За две недели до релиза выясняется, что ключевая фича не успевает, а команда предлагает срезать тестирование. Что выберешь?» Конечно, правильных ответов на такие вопросы нет и быть не может: оценивают ход мыслей, скорость реакции и широту опыта.
→ Выше я уже писал, что в телеком искали сразу нескольких руководителей. На третьем интервью представители департаментов, куда набирали руководителей, приходили познакомиться с кандидатом, который прошел первые этапы.Помню, спрашивали, люблю ли я работать, когда все тихо и спокойно, или мне больше нравится находиться в эпицентре движа. Я, в свою очередь, тоже мог задавать вопросы: выяснять детали о департаментах и проектах. Чтобы понять, а где мне самому было бы интересно работать.
Тогда я и познакомился со своей нынешней руководительницей — директором департамента проектирования и разработки пакетного ядра сети. Меня впечатлило, как она отзывается о своей команде и гордится ее результатами, какие вопросы задает и как рассказывает о своем проекте. Отдел разработки компонентов опорной сети 5G, которым я сейчас руковожу, как раз входил в ее департамент — и заинтересовал меня больше других команд.
Раньше я отвечал за целое подразделение, но весь продукт делали около тридцати человек. В YADRO же столько человек может трудиться только в одном-двух отделах. И все это ради продуктов, которыми будут пользоваться миллионы абонентов. Именно за таким масштабом я и шел.
→ Мое четвертое интервью, финальное, было уже с выбранной командой. На встречу пришли руководители отделов департамента, Agile Team Leader (об этой роли я еще расскажу) и Technical Product Manager. На этом интервью оценивали, насколько хорошо я встроюсь в работу всей команды.
Дальше все было стремительно: оффер мне прислали буквально на следующий день после финального интервью. Я принял его и вышел на работу через две недели — как раз успел выдохнуть и настроиться на новое место.
Как устроен онбординг
Напомню, что я был довольно далек от мира телекома. На собеседовании честно признался, что все мои знания предметной области ограничиваются получасом изучения официального сайта YADRO (считаю, честность спасет мир). В ответ услышал, что это не страшно, но наверстать придется. Погружаться я начал уже в рамках онбординга — стал интенсивно осваивать дивный новый мир 5G Core буквально с нуля.
В целом, онбординг я могу поделить на три части:
адаптация как руководителя;
погружение в телеком-матчасть;
погружение в процессы компании: для этого в YADRO есть подробные гайды на все случаи жизни.
Расскажу про каждый из них.
Адаптация как руководителя
Если вычесть обязательную программу — выдачу техники, доступов и инструктажи, мой первый рабочий день начался со встречи с руководителем. Я получил знания, необходимые для старта: что стоит сделать в первую очередь, какие задачи в приоритете, чего от меня ждут как от руководителя. Не разжевывали каждый шаг, а, напротив, дали сетку контактов, чтобы дальше я разбирался, к каким людям по каким вопросам сходить, какие процессы настроить.На позиции лида от тебя ожидают проактивности.
Далее у нас были еженедельные 1:1 с руководителем: на них я мог уточнять все, что было непонятно. Помню, что вопросов по процессам у меня было немного, большинство сложностей вызывали различные аббревиатуры — TGM, TPdM, OAM, NMS, BS. Я постоянно слышал их на встречах, но не понимал, о чем идет речь. Выписывал, чтобы уточнять значения. Скоро у меня появился целый словарь таких сокращений, а через полгода я уже перестал в него заглядывать — сам постоянно использовал эти сокращения.
Кроме руководителя, у меня был Спутник — человек, который отвечает на твои вопросы и помогает тебе адаптироваться. В моем случае это был руководитель смежного отдела. К ней я ходил за контекстом: по сотрудникам, их зонам ответственности и так далее.
Контекста требовалось много, так как мне передавали сразу две команды. Одна делает непосредственно компонент 5G Core — SMF, вторая занимается common-частью: инструментами для других разработчиков — от логгеров и трейсинга до фильтров. Приходилось изучать оба мира параллельно: какие задачи и цели у сотрудников, сильные стороны и т.д.
На старте работы у меня был страх: как руководить людьми, которые разбираются в предметной области лучше тебя? Готовился к скепсису и проверкам на прочность — и зря, страхи не оправдались. Наоборот, мне заботливо объясняли моменты, где я чего-то не понимал.
Я и сам не изображал телеком-эксперта: несколько раз просто собирал звонки с разработчиками и расспрашивал их про наши компоненты и решения в целом. Оказалось, опытным инженерам — по крайней мере, моим — не нужен руководитель, который знает SMF лучше них. Им нужен тот, кто честно и хорошо выполняет свою управленческую работу.
Еще один «культурный шок», который меня ждал в телекоме, — это «нестандартный» набор ролей в команде. Классическая продуктовая команда в IT: бэкенд- и фронтенд-разработчики, тестировщики, один-два DevOps-специалиста, возможно, «встроенный» в команду ИБ-специалист. Владелец продукта, или Product Manager, бизнес-аналитик, который общается с заказчиком, в некоторых конфигурациях — техлид.
В YADRO же к «классическому» набору прибавляется еще несколько ролей. Добавлю, что в департаменте проектирования и разработки пакетного ядра сети, в который входит мой отдел, работают 20 команд (от 4 до 10 сотрудников). Итак, что это за роли:
у каждой команды есть свой Agile Team Leader — человек, который держит процессы в тонусе и помогает команде самоорганизовываться. Внутри команды — это про понятный ритм работы и прозрачность, на стыке со смежными командами — про ясность, кто именно и что конкретно делает.
-
еще есть продакты, и их сразу несколько:
Business Product Manager живет в мире заказчиков: общается с ними, выясняет боли, согласовывает ожидания.
Technical Product Manager живут (да-да, он не один) в мире инженеров: вместе с архитекторами и лидами команд превращают ожидания заказчиков в роадмап разработки.
Все эти роли и их зона ответственности четко прописаны. И это не про бюрократию, а про прозрачность: ты всегда знаешь, к кому обратиться по своей задаче.
Погружение в предметную область
Итак, работать в дивизион Телеком я пришел без опыта работы в этой сфере. Для трудоустройства это не было проблемой, но в ходе работы знание матчасти, безусловно, было полезным, так что это стало частью моего онбординга.
В целом, весь испытательный срок я опирался на чек-лист новичка (про него я расскажу чуть ниже). В нем было четко прописано, что мне стоило сделать, получить, изучить. В списке были и ссылки на видеоматериалы внутреннего курса по телекому на корпоративной платформе для обучения. Смотрел их несколько месяцев параллельно с основными задачами: изучал поколения связи, 5G Core, SMF, разбирался в архитектуре, спецификациях, разбирал компоненты, которыми занимается моя команда.
Я бы очень хотел сказать, что однократное прохождение курса полностью закрыло вопрос изучения доменной области. Но новые знания действительно закрепились только со временем и с практикой: когда слышишь о каких-то новых компонентах буквально каждый день в течение двух месяцев, сложно не начать в них разбираться. Подсчитываешь задачи, которые выполняет твоя команда, смотришь, какие фичи планирует на следующий квартал, — и постепенно в голове складывается общая картинка.
Выхлоп от погружения в тему я стал замечать практически моментально. Сначала я слушал, как коллеги рассказывают про фичи, и плохо понимал, что происходит. Через три месяца уже был «в теме».
Без конфузов на старте, конечно, не обошлось. Как-то после очередного звонка у меня осталось полстраницы заметок с экшн-айтемами, ведь я свято верил что обсуждали компонент моей команды. А на деле я перепутал AMF и SMF, и речь шла вообще не про нас. Худшие страхи сбылись, но ничего, все выжили :)
Я убедился на практике: руководителю в дивизионе Телеком не нужно понимание сетей на инженерном уровне. В приоритете все еще навыки лида: стратегическое, аналитическое мышление, риск- и people-менеджмент, управление проектами и т.д. Для того, чтобы начать говорить с инженерами на одном языке, онбординговых материалов более чем достаточно.
Когда руководители слышат про телеком, часто думают, что первые полгода уйдут только на погружение в основы. У меня эти полгода случились, но параллельно с работой, а не вместо нее.
Погружение в техническую часть работы своей команды не мешало мне заниматься тем, ради чего меня наняли. Сильные навыки в people-менеджменте помогли быстро подхватить работу с командой и построить индивидуальные годовые цели с каждым сотрудником еще в первый месяц работы. Мне нужно было быстро наладить контакт, понять, куда стремится человек и на каком уровне работает. Незнание аббревиатур на старте никак не помешало мне погрузиться в процессы команды: подключаться там, где начинался пожар или всплывал нестандартный кейс взаимодействия. В итоге я помог командам успешно закрыть квартал и приступил к планированию нового.
Погружение в процессы
На время онбординга в YADRO мне выдали чек-лист новичка — это список задач со всеми необходимыми ссылками на ближайшие три месяца. Перечень немаленький (там около 80 пунктов), но ты быстро понимаешь, насколько это удобно. Когда идешь по чек-листу, весь миллион вопросов, который у тебя есть на старте, сокращается с каждой закрытым пунктом.
По сути, этот чек-лист учит тебя «жить» в компании. Ты настраиваешь рабочее пространство, получаешь доступы, смотришь, какие процессы тебе нужно освоить за неделю, месяц и три месяца, как вести задачи, какие у команд есть доски и эпики в корпоративном таск-трекере. Здесь же есть базовые инструкции, как оформить командировку себе или сотруднику, отпуск, больничный, забронировать парковку.
Позже я узнал, что для каждой позиции существует свой чек-лист. У меня был специальный подраздел для руководителя: мини-пространство с руководством к действию в ситуациях, с которыми сталкивается почти каждый руководитель. Даже если у тебя большой опыт в руководстве, у тебя есть возможность понять специфику работы и руководства именно в этой компании.
Совокупность этих вещей: помощь руководителя и Спутника, образовательный курс, чек-лист новичка — закрыла львиную долю моих вопросов. Безусловно, не всех: тот же местный язык сокращений не зашит ни в один гайд. Но все равно на каждом этапе я чувствовал, что в компании позаботились о том, чтобы ты не мучился, разбираясь в мелочах в одиночку, и не обрушивал кучу вопросов на коллег.
Чем я занимаюсь как руководитель
Я работаю руководителем отдела в YADRO уже полтора года. Внутри дивизиона Телеком эта роль называется Team Group Manager, тот самый TGM из моего словарика сокращений. В моих командах сейчас более 30 человек, и в первую очередь я несу ответственность за их результат и помогаю им достигать поставленных целей. Главный мой инструмент — работа с людьми и процессами.
Я оцениваю эффективность работы команды, выстраиваю процессы, где их нет, провожу командные встречи и 1:1, нанимаю сотрудников и интегрирую их в команду. Знаю сильные и слабые стороны каждого сотрудника, его карьерные цели и то, как он к ним идет.
Например, хочет инженер стать архитектором, но никто, кроме него, об этом не догадывается. В итоге к этой цели он может идти неоптимальным путем (а может, и не идти к ней совсем). В компании мы рассматриваем лида как наставника, поэтому на 1:1 с сотрудниками часто обсуждаем их профессиональные цели, прорабатываем план, как к ним прийти. Иногда даже «приходится» немного побыть психологом и «повытаскивать» из человека амбиции, о которых он по какой-то причине не решился сказать прямо. Это не редкость, когда сильные специалисты готовы расти, но молчат об этом. Моя задача, среди прочего, помочь ему и поддержать, ведь это напрямую скажется на его результатах работы и лояльности к компании.
Другая сторона работы — это, когда думаешь не про отдельных людей, а про команду в целом: кто у тебя техлид, почему именно он, кто его заместитель? Если этот лидер заболеет или уйдет в отпуск, кто продолжит его работу так, чтобы процессы не поломались? Достаточно ли эффективно твоя команда взаимодействует с другими командами в департаменте, компании или с партнерами? То есть ты смотришь на команду комплексно, как визионер, определяешь ее сильные и слабые стороны, планируешь расширение ресурсов или наоборот.
Ты делаешь шаг на ступеньку выше, когда полезен не только в команде, но и в рамках всего департамента.
Основной пласт моей работы связан с людьми, но это не единственное, чем я занимаюсь. Когда я освоился на новом месте, мне стало интересно брать дополнительную ответственность. Обсудив это желание с руководителем, понял, что вариантов дополнительной реализации немало — например, можно углубиться в тестирование продукта или взять в управление определенную часть проекта.
Я выбрал управление релизным процессом. Я подхватываю релиз с момента, когда имплементация фич завершена: дальше подготовка релизной ветки, функциональное тестирование и багфикс, документация, проверки безопасности и финальная приемка из двух регрессов. Организация и координация этого процесса на мне — как и ответственность за результат. Как можно догадаться, здесь больше всего именно классического проджект-менеджмента.
Другой пример: сейчас мы анализируем интеграцию искусственного интеллекта в работу команд. Где это эффективно, а где надежд на ИИ пока больше, чем потенциальной пользы от его использования. Я вызвался этим заниматься — не зря между работами исследовал ИИ-агентов — и теперь оцифровываю цели и оцениваю эффективность ИИ-инициатив в пределах нашего департамента. На мой взгляд, самый ощутимый рост всегда происходит в новых задачах и зонах ответственности.
Напоследок позволю себе дать совет руководителям, которые задумываются о смене сферы: не бойтесь другой предметной области и большего масштаба задач.
Требования к управленческим навыкам в разных компаниях примерно одинаковые: работа с людьми, проджект-менеджмент с его рисками и изменениями, — а знание предметной области всегда можно наверстать.
Не уверен, что мой опыт универсален, но мой переход из AV-over-IP-разработки в телеком стал сильным карьерным толчком: легкой прогулкой этот опыт не назовешь, но я ни разу не пожалел о своем решении.
Если моя история вас вдохновила, у нас в дивизионе открыты несколько менеджерских вакансий:
→ руководитель отдела разработки инфраструктуры,
Еще больше карьерных возможностей вы найдете здесь.