Руководить в бигтехе: будни СТО

Расспросили технического директора МТС OmniChannel, чем он занимается на работе. Спойлер: в статье ни слова про код и разработку.

Всем привет! Меня зовут Глеб Тильтиков, я СТО платформы омниканального маркетинга МТС OmniChannel. Давно хотел рассказать, чем действительно занимается технический руководитель в проекте и как это сочетается с привычным пониманием должности.

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

Немного юмора, много практики. Погнали!

Содержание:

СТО — это не станция технического обслуживания и не стандарт организации. Хотя это первое, что обычно приходит на ум (нейросетям тоже).

СТО или Chief Technical Officer — технический директор, который определяет технологическую стратегию компании для достижения финансовых и стратегических целей бизнеса.

За моими плечами почти 10 лет опыта руководителя, в команде — более 50 сотрудников. Мой продукт — МТС OmniChannel — платформа омниканального маркетинга, позволяющая бизнесу делать рассылки по своей базе через множество каналов: SMS, Telegram Ads, WhatsApp, Viber, email.

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

Чем выше руководитель, тем более стратегические задачи он решает. В большой компании C-level — CEO, CPO, CTO — управляет всей корпорацией, но не каждым отдельным её продуктом.

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

В МТС Диджитал одновременно разрабатывают несколько сотен IT-продуктов — разного размера, уровня зрелости и степени влияния на бизнес.

Часто внутри компании мы являемся клиентами друг друга. Нам создали «Общую авторизацию», мы помогли с SMS и push-уведомлениями. Мы разработали соседнему продукту функцию триггерной рассылки, а они нам создали систему мониторинга.

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

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

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

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

Нашим внутренним бизнесом управляют CPO и СТО, согласно принципу продуктовой разработки.

Чтобы лучше представить зоны ответственности, можно использовать метафору:

Итак, CPO, в интересах владельца груза, ставит задачу CTO-капитану: «Перевези груз из порта A в порт B на своём судне». CTO знает, как управлять судном, понимает, где могут быть мели, а где безопасный путь. Он координирует экипаж, решает технические вопросы, следит за состоянием судна и обеспечивает выполнение задачи в срок.

«Экипаж моряков» — это команда инженеров. Сейчас расскажу, какие задачи по работе с этой командой я решаю.

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

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

Если воронка с кандидатами не соответствует ожиданиям, учитывая дефицит кадров в IT, я считаю правильным дать людям шанс.

В здоровой IT-команде HR-машина должна работать всегда

Поэтому я лично:

При этом необязательно присутствовать на всех интервью и тратить рабочий день на собеседования. Я делегирую эту задачу и оставляю за собой финальное решение.

Хорошая команда включает специалистов с разным уровнем опыта

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

Часто выбор делается в пользу кандидата с очевидным талантом.

При формировании новых команд ежегодно пересматриваю подход к их организации:

✔ объединяю вокруг задач — чтобы максимально сфокусироваться на конкретной цели

✔ объединяю вокруг специализации — чтобы использовать экспертизу сотрудников для достижения наилучших результатов.

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

Когда в распоряжении CTO до 150 сотрудников, важно выстроить структуру отделов и участвовать в формировании команд. Не менее важно знать каждого «моряка» в лицо — понимать специализацию, сильные и слабые стороны. Это помогает эффективно распределять задачи и строить продуктивное взаимодействие внутри команды.

Если команда небольшая, можно позволить себе роскошь регулярных встреч one-to-one с каждым сотрудником. С увеличением штата это становится невозможным, и приоритет отдаётся встречам с новыми сотрудниками, которые проходят онбординг.

С ростом стажа в команде увеличивается интервал между регулярными встречами: сначала раз в две недели, после года работы — раз в два месяца и так далее. Мне важно оставаться в контакте, поэтому one-to-one встречи были, есть и будут.

Иногда приходится становиться психологом для «экипажа». У каждого из 50 сотрудников свои переживания, мотивы и проблемы, которые могут влиять на продуктивность и настроение.

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

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

Поэтому СТО должен оградить сотрудников от факторов, которые могут негативно повлиять на внутреннюю среду, доносить до команды только полезное и конструктивное.

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

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

До новых встреч на VC! На вопросы отвечу в комментариях.