Коротко
Вопрос «нужен ли нам CTO» обычно всплывает не в теории, а после конкретного провала: подрядчик третий раз переносит срок, никто не может объяснить, почему сайт падает по пятницам, а на созвоне с инвестором директор не может ответить, на чём вообще написан продукт. Если вы гуглите этот текст — скорее всего, один из таких эпизодов уже случился.
CTO нужен не потому, что «в компании должна быть техническая должность». Он нужен, когда технические решения стали настолько частыми и настолько дорогими в случае ошибки, что ими больше нельзя управлять на глазок. До этой точки роль обычно можно закрыть дешевле — сильным тимлидом, архитектором на подряде или командой, где техническое руководство берёт на себя её senior-состав.
Три признака, что момент настал
Подрядчики буксуют, а вы не понимаете почему. Первый признак почти никогда не звучит как «нам нужен CTO». Он звучит как «этот подрядчик какой-то не такой, возьмём другого». Через две смены команд картина повторяется: сроки съезжают, архитектура каждый раз начинается заново, а внятного объяснения нет. Дело не в том, что вам не везёт с подрядчиками. Дело в том, что оценивать подрядчика может только человек, который сам разбирается в предмете — иначе вы каждый раз покупаете кота в мешке, просто у разных продавцов.
Технический долг стал темой на планёрках. Пока продукт маленький, любой код работает. Проблема начинается, когда каждая новая фича занимает больше времени, чем предыдущая, хотя команда та же. Разработчики говорят «здесь всё завязано так, что просто не трогали», релизы откладываются, багфиксы рождают новые баги. Без человека, который отвечает за архитектуру целиком, а не за свой кусок кода, технический долг растёт быстрее, чем продукт.
Начался найм, и оценивать инженеров некому. Первого-второго разработчика ещё можно нанять по рекомендации или интуитивно. С третьим это перестаёт работать: нужно проверить, действительно ли кандидат умеет то, что написал в резюме, выстроить код-ревью, договориться о стандартах. Нанимать инженеров без инженера в процессе найма — рискованная лотерея, и цена ошибки растёт вместе с зарплатой кандидата.
Есть и более прямой сигнал: если инвестор на встрече спрашивает, кто у вас отвечает за технологию, и вы не можете назвать имя — это тоже ответ на вопрос.
Чем CTO отличается от тимлида и архитектора
Путаница в терминах — отдельная причина, почему решение откладывается. Три роли решают разные задачи, и подменить одну другой нельзя.
Архитектор проектирует систему: какие сервисы из чего состоят, как они говорят друг с другом, на чём хранятся данные. Это техническая, предметная работа — она заканчивается, когда систему спроектировали и написали.
Тимлид ведёт команду день в день: раздаёт задачи, проводит ревью кода, разруливает конфликты в спринте, следит, чтобы люди не выгорали. Это операционная роль внутри разработки, без выхода на уровень бизнеса.
CTO работает выше обеих ролей. Он решает, куда вообще идёт технология компании на горизонте года-двух: какой стек не создаст проблем через год, каким командам расти, а какие процессы отдавать на аутсорс, сколько стоит технический риск в деньгах и как объяснить это не техническому совету директоров. Хороший архитектор не обязательно умеет разговаривать с инвестором на языке рисков и бюджетов. Хороший тимлид не обязательно способен решить, стоит ли компании вообще переписывать core-систему. CTO — это точка, где техническое решение превращается в бизнес-решение и наоборот.
Для нетехнического фаундера практический тест простой: если ответ на вопрос «а что нам делать с технологией дальше» каждый раз звучит как мнение случайного человека в чате — роли CTO в компании ещё нет, даже если кто-то формально называется техническим директором.
Full-time, fractional или команда с техруководством
Дальше встаёт второй вопрос — не «нужен ли CTO», а в каком виде его покупать. Здесь три рабочих варианта, и каждый закрывает свою стадию.
Full-time CTO оправдан, когда технология — это и есть продукт, команда разработки выросла за десять человек, и решения нужно принимать каждую неделю, а не раз в квартал. Это дорогой найм: в Казахстане и СНГ сильный CTO с опытом масштабирования стоит сопоставимо с топ-менеджментом, и его ещё нужно удержать, пока компания растёт медленнее, чем его амбиции.
Fractional CTO — на день-два в неделю — закрывает промежуточную стадию: стратегия и архитектура нужны постоянно, но не в объёме полной ставки. Это дешевле full-time и быстрее нанимается, но у него есть предел: fractional-директор не строит команду каждый день и не всегда доступен, когда прод упал в среду вечером.
Founder-led техруководство внутри подрядной команды — вариант, который часто не рассматривают, хотя он закрывает раннюю и среднюю стадию не хуже. Работает это так: у компании нет своего CTO, но техническое лидерство берёт на себя senior-инженер или основатель команды разработки, которая ведёт продукт — с самого начала, а не как надстройка сверху. Тогда архитектурные решения, ревью кода и разговор с фаундером на языке бизнеса происходят внутри одной команды, а не размазаны между вами, подрядчиком и человеком со стороны, который видит систему раз в неделю.
Для MVP и раннего продукта это часто разумнее, чем нанимать штатного CTO под неопределённый product-market fit: ставка на человека, которого придётся уволить, если гипотеза не взлетит, обходится дороже, чем ставка на команду, которую можно расширять или сужать вместе с продуктом. Мы в azamat.ai строим MVP именно так — запуск продукта идёт с senior-разработчиками, которые сами отвечают за архитектуру, а не ждут технического директора со стороны заказчика. В кейсе sellerbox.ai продуктовые сценарии и операционную логику с нуля вела инженерная команда, без отдельного нанятого CTO на стороне заказчика.
Как решить, если сомневаетесь
Если вы дочитали до этого места и всё ещё не уверены — вот порядок, в котором стоит проверять гипотезы.
Сначала посчитайте частоту решений. Если технический выбор нужно делать раз в квартал — fractional или подрядчик с техлидом внутри команды закроют вопрос. Если технические решения принимаются каждую неделю и от них зависит выручка — считайте бюджет на full-time. Отдельно сопоставьте эти цифры с тем, сколько вообще стоит внедрение ИИ в Казахстане — часто зарплата CTO на старте перевешивает бюджет самого пилота, и разумнее сначала проверить гипотезу с подрядчиком.
Затем оцените стоимость ошибки. Технический директор, который неправильно выбрал стек для MVP, обходится в потерянные недели. Технический директор, который неправильно спроектировал систему для продукта с транзакциями и данными пользователей, обходится в месяцы переписывания и репутационный риск. Чем выше цена ошибки, тем раньше нужен человек, который отвечает за неё персонально.
И наконец — не путайте наём CTO с решением проблемы подрядчика. Если текущая команда разработки не может объяснить архитектуру, буксует со сроками и не даёт внятных ответов на технические вопросы, замена подрядчика на нового с теми же критериями отбора не решит ничего. Прежде чем нанимать CTO или снова менять команду, стоит посмотреть, как вообще выбирать подрядчика по внедрению ИИ и разработке — часть вопросов из этого чек-листа снимается уже на этапе выбора команды, без найма отдельного директора.
Что делать в первый месяц, если решили нанимать
Если решение принято в пользу full-time или fractional CTO, первый месяц лучше потратить не на поиск идеального человека, а на три вещи. Зафиксируйте, какие технические решения последних полугода стоили дороже всего — это покажет, какой опыт реально нужен кандидату. Проведите техническое интервью с участием стороннего инженера, если внутри некому оценить компетенцию, — иначе вы снова нанимаете вслепую. И договоритесь на берегу, за какие метрики CTO отвечает через квартал: не «навести порядок», а конкретные вещи — время деплоя, частота инцидентов, скорость выхода новых фич.
Если после этого этапа окажется, что задач на полную ставку пока не набирается, а руки нужны уже сейчас — это нормальный повод присмотреться к разработке под ключ с командой, где техническое лидерство встроено в процесс, а не оставлено на совести фаундера.
FAQ
Можно ли обойтись без CTO вообще?
Да, если технология не критична для бизнеса или продукт простой: лендинг, базовая автоматизация, интеграция готовых сервисов. Тогда роль закрывает сильный подрядчик или тимлид на аутсорсе, а решения по стратегии фаундер принимает сам с консультациями точечно.
Тимлид может стать CTO?
Может, если растёт вместе с компанией и осваивает бизнес-часть роли: бюджеты, риски, разговор с советом директоров. Но это не происходит автоматически — тимлида нужно осознанно готовить к более широкой ответственности, а не просто переименовать должность.
Сколько стоит fractional CTO в Казахстане и СНГ?
Диапазон сильно зависит от опыта и загрузки, но ориентир — это ставка на день-два в неделю против полной зарплаты full-time директора. Практический смысл: fractional обычно оправдан, пока решений хватает на несколько часов в неделю, а не на полный рабочий день.
Как понять, что подрядчик уже фактически выполняет роль CTO?
Если senior-инженер подрядчика сам предлагает архитектуру, объясняет риски простым языком, участвует в планировании продукта и берёт на себя ответственность за технические решения — по факту функция закрыта, даже без должности в штатном расписании.
Если вы читаете это после третьего проваленного дедлайна — не спешите сразу нанимать CTO на полную ставку. Сначала разберитесь, откуда именно идёт сбой: из отсутствия технического руководства или из того, что текущая команда просто не подходит под задачу.