Вопросы к роли CTO перед тем, как принять предложение

Почему вам нужно проверить роль самостоятельно

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

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

Плохие роли часто прячутся за срочностью. Фаундер говорит, что им нужен человек «еще вчера». Инвесторы хотят, чтобы перед следующим раундом уже был сильный руководитель. Команда устала, релизы срываются, клиенты жалуются, и теперь им нужен CTO, который быстро наведет порядок. Сама срочность — не всегда красный флаг. А вот давление без ясных ответов — обычно да.

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

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

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

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

Вопросы, которые вскрывают продуктовый долг

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

Начните с ближайших 12 месяцев. Спросите: «Чего этот продукт должен достичь за это время?» Настаивайте на результатах, а не на списке фич. Хороший ответ звучит так: «Нам нужно снизить отток в крупнейшем сегменте клиентов» или «Нам нужен self-serve онбординг, который человек может пройти без помощи отдела продаж». Слабый ответ — это десять несвязанных идей.

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

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

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

Один из самых простых вопросов по-прежнему один из лучших: «Как вы описали бы продукт в одном предложении?» Если есть возможность, задайте его CEO, руководителю продукта и главе продаж отдельно. Если вы получаете три разных ответа, продукт плывет.

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

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

Вопросы, которые вскрывают пробелы в полномочиях

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

Задавайте прямые вопросы. Когда фаундер говорит: «Технологии — на тебе», но не может объяснить, кто владеет дорожной картой, кто утверждает найм и кто принимает финальное архитектурное решение, роль еще не определена.

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

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

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

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

Спросите о своих первых 90 днях простыми словами. Можете ли вы изменить процесс спринтов? Заменить поставщика? Поставить на паузу слабый проект? Пересмотреть дорожную карту после технического аудита? Если везде ответ «возможно», ждите медленного движения и поиска виноватых.

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

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

Вопросы о команде и поставке

Сначала посчитайте команду, а уже потом оценивайте план. Компания может говорить, что ей нужен сильный CTO, но по факту у нее четыре инженера, два продакт-менеджера и девять подрядчиков, которые меняются каждый месяц. Это совсем другая работа, чем в стабильной внутренней команде.

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

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

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

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

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

Обращайте внимание на такие ответы: «У нас около 20 разработчиков», но никто не может объяснить роли или зоны ответственности. «Сроки срываются, когда инженерия застревает», но без deeper причины. «Все помогают после работы», что часто означает, что операционкой не владеет никто. «Спеки делаем вместе», когда никто не может назвать финального утверждающего.

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

Как проводить собеседование шаг за шагом

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

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

Начните с бизнес-цели. Спросите, что должно измениться в ближайшие 6–12 месяцев и что произойдет, если это не случится. Слушайте конкретные результаты: потерянную выручку, отток клиентов, медленную поставку или болезненную переработку продукта.

Потом переходите от боли к доказательству. Когда вам говорят о сбоях, проблемах с качеством или об «ИИ-движении», попросите один недавний пример. Кто почувствовал проблему, когда это произошло и что команда сделала после этого?

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

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

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

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

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

Реалистичный пример

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

Вы спрашиваете: «Насколько продукт сейчас здоров?» Фаундер улыбается и отвечает: «Мы работаем быстро, поэтому баги бывают, но команда у нас бойкая». Сначала это звучит нормально. Потом вы спрашиваете, сколько серьезных инцидентов было за последние три месяца, сколько времени ушло на исправление и что команда отложила из-за этих пожаров. И тут разговор становится туманным. У никого нет цифр. Никто не владеет этой проблемой. Это уже повод насторожиться.

Вы спрашиваете, кто расставляет приоритеты. Ответ: «CTO, конечно, будет отвечать за инженерию, но я все равно близко слежу за продуктом». Опять же, это может звучать нормально. Но потом фаундер добавляет: «У совета директоров тоже сильное мнение по roadmap, а корпоративные сделки иногда перескакивают через очередь». Теперь видно настоящую форму роли. Титул вам дадут, а финальное слово — не факт.

Следующий ответ звучит амбициозно: «Совет директоров хочет серьезный план по ИИ в этом году. Нам нужен ИИ в продукте, ИИ для внутренних процессов и более высокая отдача от команды. Бюджет увеличить пока не можем, так что CTO нужно быть изобретательным». Это не всегда стоп-фактор. Но часто это означает, что от вас ждут новую стратегию, новые инструменты, больше давления на поставку и без дополнительных людей.

Некоторые ответы заслуживают особого внимания: «Мы на самом деле не отслеживаем технический долг. Сильные инженеры и так знают, где он есть». «Найм сейчас заморожен, но мы все равно ожидаем более быстрой поставки». «CTO отвечает за uptime, но другие команды могут присылать срочные изменения». «Мы уже пообещали ИИ-дорожную карту, так что теперь нам просто нужно исполнение».

Любой из этих пунктов по отдельности может быть терпимым. Вместе они описывают роль, в которой вы наследуете продуктовый долг, несете риск за поставку и отвечаете за планы, которые не вы формировали. Если вы слышите такой набор, задайте еще один вопрос: «Что я смогу изменить в первые 90 дней, не прося разрешения три раза?» Ответ покажет, нужен ли им CTO или пожарный с более красивым титулом.

Ошибки, которые скрывают проблемы

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

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

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

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

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

Последняя ловушка — обаяние. Многие лидеры умеют убеждать. Это не значит, что роль здорова. Просите доказательства: один недавний тяжелый компромисс по продукту, один случай, когда проект остановили, один сорванный целевой показатель и что изменилось после этого, одно бюджетное решение, повлиявшее на поставку.

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

Короткая проверка перед тем, как сказать да

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

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

Используйте короткий тест. Могут ли они назвать три главные бизнес-цели на ближайшие 6–12 месяцев в одном и том же порядке, не давая разные ответы разным людям? Могут ли они сказать, кто принимает финальное техническое решение, когда не согласны engineering, product, founders и sales? Могут ли они простыми словами объяснить главные продуктовые риски — слабую надежность, медленную поставку, плохую безопасность или кодовую базу, к которой никто не хочет прикасаться? Могут ли они показать, как будет измеряться ваш успех — цифрами или конкретными результатами? Могут ли они описать, что хотят от вашего первого месяца, по неделям, без того чтобы вы угадывали сами?

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

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

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

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

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

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

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

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

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

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

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