Что такое CTO от стартапа до IPO, или трансформация роли CTO по мере роста компании

В этот вторник я выступал на конференции Highload++. Ниже видео выступления, а дальше его текстовая версия.

Интересно, что доклад прошел долгий путь — впервые идея о нем появилась около 2х лет и звучала изначально так

После недавнего посещения митапа для руководителей разработки, я осознал, что хотел бы еще раз сходить на #highload на CTO-трек. И там поговорить со сцены про управление сложностью в разработке ПО, важность абстракций и правильного уровня детализации для каждого уровня специалиста от линейного разработчика до ИТ-директора.

Хотелось бы обсудить как при росте компании от стартапа из 2х друзей до корпорации из тысяч сотрудников технический директор должен отходить от знания деталей реализации (например, описания полей в табличках) к концептуальным вопросам относящимся к архитектуре, атрибутам качества, ограниченным контекстам, в рамках которых работают части его системы. Интересно, что на этом пути роль технического директора меняется зачастую с изменением человека, который ее исполняет, т.к. редко кто может одинаково эффективно исполнять эту роль на всех этапах развития компании:)

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

  • как выглядит карьерный рост в ИТ?
  • стоит ли расти до руководителя команды и дальше?
  • и если стоит, то как это сделать правильнее?

Ну а мне будет интересно поделиться своим опытом, рассказать про путь “моего друга” и дать рекомендации как вам можно по нему пройти, собрав поменьше граблей. Про свой путь к позиции руководителя разработки я рассказывал года 3 назад на митапе в Яндексе. С тех пор моя должность поменялась и сейчас я CTO управления разработки цифровых экосистем в Tinkoff, которое отвечает за 2 платформы: онлайн привлечение и мобильный банк для физлиц.

План нашего общения

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

Жизненный цикл организации

Позиция CTO сильно отличается от компании к компании. Сильно влияют несколько факторов:

  • насколько компания it-емкая
  • компания продуктовая или аутсорс/аутстаф
  • на какой фазе жизненного цикла она находится

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

По горизонтали представлено развитие организации во времени, когда она последовательно развивается и переходит от одного этапа к другому. По вертикали мы видим некоторые абстрактные количественные показатели (выручка, прибыль, штат организации). Основная мысль моего доклада в том, что переходы между этапами являются некоторыми переломными моментами как для самой организации, так и для топ менеджмента, одним из представителей которых является CTO. Давайте пройдемся по этапам и посмотрим на специфику каждого этапа и посмотрим на роль CTO в рамках него

Startup

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

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

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

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

Кстати, я сам напрямую в создании отдельной компании сам не участвовал, но помогал с запуском подобных активностей внутри большой компании. Похожим образом создавался Тинькофф Журнал, технические подробности эволюции мои коллеги рассказывали в своем докладе на Python Conf. Если подытожить, то это интересный этап, но потенциально опасный — много стартапов его не проходят, но если проходят, то наступает следующий этап.

Growth

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

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

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

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

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

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

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

В итоге, масштабирование выглядит так:

  • у CPO (Chief Product Officer) есть группа продактов, которые отвечают за разные части продукта и ведут независимые бэклоги
  • у CTO есть несколько автономных команд разработки, которые способны самостоятельно решать задачи из соответствующих бэклогов

Maturity — формализации структуры и управления

После ударного роста наступает стадия зрелости организации. В которой можно выделить 2 части формализации структуры и управления, а также усложнения сложности.

Во время формализации деятельности важно стабилизировать рост организации, например

  • формализовать роли и грейды в рамках них
  • стабилизировать структуру организации
  • выстроить работу с акцентом на эффективности, например, внедрить OKR, performance review, …

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

На первом этапе у нас был CTO типа Startup Coder, в команде которого было до 10 человек. Он отлично справлялся с техническим развитием продукта + лично управлял небольшой командой.

На втором этапе количество сотрудников у нас подросло до ~50 человек. На этом этапе Engineering Manager переключается на агрессивный найм и сетап команд. Он меньше думает про технику и больше про сбалансированность команд и обеспечение их работы.

На этапе “Maturity — формализации структуры и управления” у CTO команда уже порядка 150 человек и ему достаточно сложно совмещать техническую и процессную историю. Он занимается причесыванием оргструктуры после бурного роста, формализует роли и грейды сотрудников, внедряет performance review и т.д. В итоге, к нему на помощь могут прийти delivery manager для помощи по части процессов и/или Architect для помощи по технической части. Ну и потенциально наш CTO может быть уникальным единорожкой “All-in-One CTO”, который справляется со всем этим самостоятельно:)

Maturity — усложнение сложности

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

Интересно посмотреть на пример из банковской индустрии (по книге “Bank 4.0”), где банкинг прошел 4 стадии:

  • Банк 1.0 — традиционный банкинг, сфокусированный вокруг отделений
  • Банк 2.0 — банк с самообслуживанием через банкоматы, веб
  • Банк 3.0 — мобильный банкинг, channel agnostic
  • Банк 4.0 — вездесущий банкинг в реальном времени с контекстным опытом, простым вовлечением и подсказками

Теперь посмотрим на то, как развивалась группа компаний Tinkoff

Можно заметить, что уже значительное время происходит диверсификация рынков, появляются новые продукты и значительная доля прибыли приходит с некредитных продуктов. Ну и стадия вездесущего банкинга из книги Банк 4.0 на этом графике наступает после появления в 2019 году Super App, объединяющему финансовые продукты в одном приложении.

Для такого развития компания работает в рамках отдельных бизнес-вертикалей, у каждой из которых есть отдельное IT управление, которое входит в департамент IT. Также есть отдельные истории с платформенными и сервисными линиями, которые предоставляют централизованные сервисы, которые нужны всем. И у этих платформенных и сервисных линий есть свое отражение в соответствующих IT управлениях.

Теперь взглянем на то, как меняется роль CTO в таких крупных организациях, которые проходят этап усложнения сложности.

По-факту, наш All-in-One CTO морфирует в трехголового Змея-Горыныча, который состоит из 3х ролей: CIO, CTO, VP of Engineering. Конкретные обязанности этих ролей сильно зависят от конкретной организации, также как наличие отдельных людей под эти роли или совмещение части из них в одном человеке. Давайте приведем одну из конфигураций зон ответственности (кстати, в Tinkoff конфигурация отличается):

CTO

  • Фокусируется на построении архитектуры и видении компании
  • Общается с инвесторами, клиентами, аналитиками и государственными агентствами
  • Нанимает новых разработчиков
  • Распределяет бюджет и управляет ресурсами
  • Оценивает новые технологии и применяет их в компании

CIO

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

VP of Engineering

  • В ответе за менеджмент команд и ежедневные операции
  • Ставит цели командам разработки
  • Организует процессную составляющую работ (Scrum, Kanban, проектный менеджмент)
  • Обеспечивает visibility происходящего в командах
  • Помогает и тренирует инженеров в командах разработки
  • Отвечает за расписание деплоев и роадмапы важных проектов/продуктов

В Tinkoff конфигурация отличается. По-факту, руководит всем департаментом IT наш CIO, который входит в правление компании. Ему репортят руководители управлений, которые эффективно являются CTO конкретных бизнес-вертикалей, платформ или сервисных линий.

Decline

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

Подводим итоги

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

Но нас интересует не просто она, а маппинг CTO разных уровней на эти этап

  • на этапе Startup у нас CTO вида “Startup Coder” сфокусирован на создании ценности собственными руками или с помощью небольшой команды. Это может быть просто хороший разработчик, ушедший в стартап сооснователем. Или тимлидом, который тоже решил пойти пилить стартап. В зависимости от стартапа у этого человека может быть или не быть команда, но нужно быть готовым, что придется заниматься всем, включаю сбор требований, разработку, инфраструктуру и т.д. Обычно он хорошо разбирается в технике, но при переходе на следующий этап ему пригодятся знания из общего менеджмента и управления процессами разработки. Про лидерство можно почитать книгу “The Art of Leadership: Small Things, Done Well
  • На этапе Growth я назвал нашего CTO Engineering Manager. У него начинается рост компании и штата, который он обеспечивает, работая в тесной связке с hr’ами. Количество людей растет — их надо объединять в автономные команды, часто с тимлидами во главе, чтобы CTO не требовалось погружаться в операционные вопросы команд. Техники в жизни CTO становится меньше — он решает вопросы с наймом, бюджетом, инфраструктурой, процессом разработки. И все это накладывается на бешеные темпы роста — очень интересная стадия, но изматывающая. Для подготовки к переходу на следующий уровень рекомендую изучить книги “Team Topologies” и “Technology Strategy Patterns”. Первая поможет с дизайном структуры команд, а вторая поможет находить общий язык с бизнесом при обсуждении технологической стратегии развития компании.
  • На этапе “Maturity —Формализация структуры и управления” наш All-in-One CTO участвует в формализации управления и структуры. Внедряются OKR’ы, performance review, грейды сотрудникам. В общем, много работы над процессами и структурой — поэтому времени на детальное погружение в технологии не остается.
    Если только по ночам.Часто на этом этапе у CTO появляются помощники в виде
    -Деливери менеджеров, помогающих с процессами
    -Архитекторов, помогающих с технической стороной дела
  • На этапе “Maturity — Этап усложнения структуры” наш All-in-One CTO распадается на 3 роли CTO, CIO, VP of Engineering, каждая со своей зоной ответственности. Зона ответственности сильно зависит от компании, как и наличие или отсутствие выделенного человека под каждую из ролей.
  • На этапе “Decline” все достаточно грустно и CTO приходится заниматься оптимизацией расходов, чтобы пережить спад выручки. Требуется бороться с утечкой кадров, причем не всех, а самых ценных. Все это приводит к очередной серии реструктуризации структуры.

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

Источники

  1. Презентация к этому докладу
  2. Статья “Жизненный цикл организации
  3. Книга “Team Topologies
  4. Книга “Technology Strategy Patterns
  5. Книга “The Art of Leadership: Small Things, Done Well
  6. Книга “Digital Transformation Game Plan
  7. Статья “What separates a CIO, CTO, and VP of engineering?
  8. Статья “What Does a CTO Do?
  9. Teamlead Conf 2018 “Рост команды на порядок
  10. Статья “Эволюция процессов в привлечении Tinkoff
  11. Книга “Bank 4.0
  12. Статья “SOLID’ный тимлид, или основы менеджмента для технарей

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store