Переход на роль CTO в стартапе: какие вопросы задать сначала

Почему эта роль может быстро пойти не так

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

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

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

Тревожные сигналы видны рано. Люди описывают роль лестно, но расплывчато и не могут назвать ваши права на решения. Никто не может объяснить кодовую базу простыми словами. Компания требует быстрой доставки, но скрывает сбои, пробелы в безопасности или сильную зависимость от агентства. Все говорят: «нам нужен CTO», но каждый имеет в виду разную работу.

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

Что спросить о runway и деньгах

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

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

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

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

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

Представьте, что фаундер говорит, что у компании есть год runway, но следующий раунд зависит от запуска enterprise-функции через четыре месяца. Расходы в AWS пересматриваются, один счет от вендора просрочен, а нанимать может только CEO. Это не стабильные деньги. Это отсчет времени.

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

Кто на самом деле владеет продуктом

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

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

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

Задавайте простые вопросы. Кто ставит еженедельные приоритеты для команды? Могут ли фаундеры добавлять работу посреди спринта? Кто может отклонить срочный запрос в последний момент? Что происходит, когда дорожная карта сталкивается с дедлайном?

Слушайте прямые ответы. Если люди говорят о совместном процессе, но не могут назвать человека с финальным словом, вопрос владения продуктом все еще не решен.

Как проверить доверие фаундера

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

Начните с истории. Спросите, кто раньше руководил инженерной командой, почему этот человек ушел и что пошло не так. Если все прошлые проблемы были «виной CTO», будьте осторожны. Фаундер, который не может признать свою роль в плохих рабочих отношениях, обычно хочет подчинения, а не суждения.

Задавайте прямые вопросы. Что произошло, когда технический лидер возразил против срока? Кто принимает решение, если цели продукта и технические риски расходятся? Когда фаундер в последний раз менял мнение после технического совета? Какого именно несогласия он ждет от CTO?

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

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

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

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

Какой доступ нужен до первого дня

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

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

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

Проверьте видимость по четырем областям: исходные репозитории и история CI/CD, backlog и трекер багов, владение production и облаком, а также аккаунты, за которыми закреплены домены, DNS, секреты и биллинг. Последний пункт постоянно забывают. Если облачный аккаунт принадлежит фрилансеру или домен компании лежит в логине регистратора бывшего сотрудника, у вас уже в первый день есть реальный бизнес-риск.

Вам также нужна ясная картина операционной работы. Спросите, кто получает оповещение, когда падает production, как фиксируются инциденты, кто утверждает откаты и кто потом разбирает сбои. Даже у маленького стартапа должен быть какой-то порядок. Он может быть простым. Но он не может быть хаосом.

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

Где зависимость от вендоров может ударить по вам

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

Попросите фаундеров и команду назвать всех вендоров, которые связаны с выручкой, входом в систему, хостингом, деплоем, данными, поддержкой клиентов, почтой и функциями ИИ. Не принимайте «AWS» или «Stripe» как полный ответ. Вам нужны конкретные сервисы, части, которые затрагивают production, и владелец каждого из них.

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

Страшный случай — не падение вендора. Страшно, когда компания построила половину продукта на одном закрытом API и не имеет плана Б. Если цена вырастет в три раза, условия изменятся или доступ закроют, сможет ли команда быстро перенести эту часть внутрь, сменить вендора или сократить объем, чтобы выжить?

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

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

Простой способ проверить роль

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

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

После этого попросите коротко показать продукт, команду и стек. Это должно занять 30–45 минут, а не полдня. Вам нужно увидеть, как работает продукт, кто выкатывает изменения, где лежит код и что ломается чаще всего.

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

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

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

Реалистичный пример перед тем, как согласиться

Фаундер показывает вам поспешно собранный MVP и предлагает роль CTO. На поверхности продукт выглядит прилично. У него есть несколько платящих клиентов, рабочий демо-ролик и питч-дек, в котором написано, что команда готова к масштабированию.

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

С доступом ситуация еще хуже. Git-репозиторий находится в аккаунте агентства. Облачный аккаунт принадлежит другу фаундера. Биллинг, аналитика и отслеживание ошибок живут в разных инструментах, и никто не может сказать вам, у кого права администратора. Если production сломается в воскресенье, проблема будет вашей, но войти и починить ее все равно придется просить трех других людей.

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

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

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

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

Ошибки, которые люди совершают, оценивая оффер

Самая большая ошибка — верить истории, а не проверять механику. Фаундер говорит: «Вы будете владеть технологиями», но вы все еще не можете увидеть банковский баланс, репозиторий, облачный счет или контракты, которые держат продукт на плаву. Обещания менее важны, чем доступ.

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

Люди также игнорируют конфликт между фаундерами, потому что продукт выглядит захватывающе. Сильная демо-версия или ранняя тяга могут скрывать плохие рабочие отношения. Если фаундеры каждую неделю спорят о приоритетах, вы будете тратить больше времени на урегулирование конфликтов, чем на строительство.

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

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

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

Быстрые проверки перед тем, как сказать да

Прежде чем соглашаться, остановитесь и проверьте оффер несколькими прямыми вопросами. Ответы скажут о многом. Как и паузы, расплывчатые ответы и обещания разобраться потом.

Начните с четырех проверок:

• Спросите runway в месяцах, исходя из текущего burn. Не соглашайтесь на «мы профинансированы» или «мы поднимаем раунд».
• Спросите, кто принимает финальное продуктовое решение, когда фаундер, продажи и инженерная команда не согласны.
• Попросите показать кодовую базу, процесс релизов и production-окружение.
• Назовите три главных риска, которые вы унаследуете в первый день, и запишите их.

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

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

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

Что делать дальше

Хороший финальный шаг — записать свое решение, пока детали еще свежи. Коротко. Одной страницы достаточно.

В заметке должно быть написано, что вы узнали о runway, доверии фаундера, владении продуктом, доступе к кодовой базе и зависимости от вендоров. Там же должно быть указано, чего вы все еще не знаете. Когда все записано, слабые ответы заметить проще.

Держите заметку практичной: что делает роль выполнимой, что может заблокировать вас в первые 30 дней, что должно быть правдой до согласия и из-за чего вы уйдете.

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

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

Это особенно важно на ранней стадии, где мало структуры. Оффер может звучать захватывающе и все равно быть плохим совпадением.

Если вам нужно второе мнение, возьмите его у человека, который руководил командами, инфраструктурой и продуктовыми компромиссами под реальным давлением. Oleg Sotnikov на oleg.is делает именно такую Fractional CTO-консультацию для стартапов и может разобрать роль до того, как вы согласитесь. Внешний взгляд может уберечь вас от «да» на работу без ясных полномочий, без доступа и без пространства, чтобы исправить настоящие проблемы.