Что такое CTO от стартапа до IPO

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

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

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

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

Когда компания развивает несколько бизнесов, рядом существуют продуктовые направления, платформы и общие сервисы. Названия CTO, CIO и VP of Engineering в разных организациях обозначают разные сочетания обязанностей. В качестве примера приведён Тинькофф с техническими руководителями направлений и общим уровнем управления ИТ. Копирование названий должностей без понимания ответственности не воспроизводит эту модель.

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