Как разделить подразделение из тысячи инженеров и передать управление

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

У Александра уже был опыт другого разделения. Продуктовые команды мобильного банка и API перешли в бизнес-направления, которые отвечали за кредитные, дебетовые и другие продукты. Общие компоненты остались у платформенных команд. В 2023 году похожую задачу пришлось решить на уровне нескольких крупных блоков. Каждый блок должен был получить достаточно связную работу, чтобы большую часть решений люди принимали внутри, а на границах договаривались о понятных интерфейсах.

Выделили клиентские интерфейсы, привлечение и маркетинг, социальные платформы, цифровую экосистему и продуктовую аналитику с A/B-тестированием. Последний блок был небольшим. Он объединял инструменты, с помощью которых продуктовые команды могли размечать события, формулировать и проверять гипотезы, дожидаться значимого результата и подводить итоги эксперимента.

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

Различался и способ задавать приоритеты. На главную страницу претендовало много продуктов. У цифровой экосистемы была задача оценивать, что там полезно клиенту и как совместить уведомления, продвижение и основные сценарии. Бизнес-руководитель напрямую определял эти приоритеты. От платформы он ожидал стабильной работы и своевременной поставки компонентов. План развития платформы при этом складывался из потребностей нескольких команд и долгосрочной инженерной работы.

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

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

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

К осени 2023 года определили технических директоров и обсудили на стратегической сессии границы направлений и планы на 2024 год. Дальше шла работа с командами и обязательствами. Новый CTO знакомился с бизнес-руководителями, разбирался в действующих проектах, проверял планы и обсуждал с Александром свои наблюдения на встречах один на один.

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

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

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

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

К концу 2024 года новые CTO получили доступные для передачи бюджеты, найм и согласования. Они вели свои направления почти автономно. За надёжность, безопасность, общие бюджеты, согласование целей и оценок работы всё ещё требовалось договариваться между блоками. Александр сохранял ответственность за общий результат и участвовал там, где для решения требовалась информация или полномочия с нескольких сторон.

По его оценке, передача состоялась: у бизнеса появились технические руководители, способные вести свои направления самостоятельно. В 2025 году следующий общекорпоративный редизайн изменил эту конфигурацию. Поэтому автор оценивает этот этап по тому, какую работу новые CTO смогли взять на себя к концу передачи.