Как найти и проверить CTO, если вы не технарь

Начните с выбора формата: технический сооснователь, fractional CTO или штатный наём. У каждого свои условия, своя цена и свои места поиска. Когда кандидаты есть, проверяйте их конкретными вопросами о реальных проблемах. Пять диагностических вопросов ниже взяты из реальных проектов, где неправильное техническое решение стоило фаундерам месяцев и денег.

Сооснователь, fractional CTO или штатный наём?

Ответ зависит от стадии и финансирования.

Технический сооснователь. Если вы до раунда и строите технический продукт, это самая сильная позиция. Сэм Альтман пишет прямо: «Have at least one technical founder on the team», имейте хотя бы одного технического фаундера в команде (blog.samaltman.com). Майкл Сейбел, сооснователь Twitch и бывший CEO Y Combinator, ещё категоричнее: «Технический кофаундер — это плита. Без плиты рагу не сварить» (TechCrunch Disrupt SF, 2018). Сооснователь делит собственность и риск. Вы отдаёте долю, но получаете человека, чьи интересы полностью совпадают с интересами компании.

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

Штатный CTO. Имеет смысл, когда есть product-market fit (продукт нашёл своего покупателя), растущая команда и ежедневная потребность в техническом руководстве. На этой стадии вы нанимаете человека масштабировать то, что уже работает.

Вопросы ниже подходят для проверки любого из трёх вариантов.

Где искать

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

• YC Co-Founder Matching: бесплатная площадка, крупнейшая платформа для поиска сооснователей
• Wellfound (бывший AngelList): вакансии CTO и сооснователей в стартапах
• CoFoundersLab, Indie Hackers, r/cofounder: сообщества, где строители ищут партнёров
• Оплачиваемый тестовый проект: дайте кандидату реальную задачу. Несколько дней работы покажут больше любого собеседования

Подробный чек-лист оценки технического подрядчика — в гайде по выбору разработчика.

Пять вопросов, которые показывают, как CTO думает

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

«Как бы выглядела наша инфраструктура, если рассчитать её на тех пользователей, которые у нас есть сейчас?»

В одном проекте SaaS с примерно двумя тысячами пользователей тратил на облако больше, чем на всё, кроме зарплат. Предыдущий подрядчик спроектировал систему под масштаб, о котором фаундер мечтал: десяток отдельных сервисов, у каждого своя база данных. Деплой (выкладка новой версии) занимал 40 минут. Решение: объединить в одно приложение. Счёт за облако упал примерно на 70%, деплой сократился с 40 минут до пяти.

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

Тревожный сигнал: «нужно строить с расчётом на масштаб с первого дня» без вопроса о текущих цифрах. Избыточная инфраструктура на ранней стадии сжигает деньги на серверы вместо поиска product-market fit.

«Какие две части продукта дают большинство проблем, и нужно ли для их исправления переписывать всё?»

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

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

Тревожный сигнал: сразу соглашается с переписыванием или предлагает свой любимый стек, не спросив, что именно ломается. Джоэл Сполски назвал переписывание работающего кода с нуля «самой худшей стратегической ошибкой» для софтверной компании (joelonsoftware.com, 2000).

«Мы хотим строить это сами. Это та часть, за которую платят клиенты?»

Фаундер с только что закрытым раундом собирался нанять трёх ML-инженеров для собственного распознавания речи в нишевой отрасли. Только рекрутинг был запланирован на квартал. Но ценность продукта была не в распознавании лучше крупных провайдеров, а в том, что происходило дальше: превращение записей звонков в структурированные данные. Готовый речевой сервис со словарём отраслевых терминов справился с распознаванием. Один сильный продуктовый инженер заменил запланированную команду, и первая версия дошла до клиентов за шесть недель.

Хороший ответ: ставит под вопрос само решение «строить или купить готовое». Предлагает сначала оценить существующие варианты на реальных данных.

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

«Если наши разработчики исчезнут завтра, в какие аккаунты мы сможем войти?»

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

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

Тревожный сигнал: тема не поднимается вообще. CTO, который не думает об операционном контроле, оставит вас зависимыми от того, кто пишет код.

«Если инвестор пришлёт инженера посмотреть наш продукт завтра, что он найдёт?»

У AI-стартапа было три недели до технического due diligence (проверки инвесторами). Фаундер попросил посмотреть первым, чтобы не было сюрпризов. Нашлись: API-ключи (пароли к сервисам) в истории кода, деплоить умел только один человек, не было документированного ответа на вопрос, который инвесторы всё чаще задают AI-компаниям: что происходит с данными клиентов у провайдера модели. Команда ротировала все ключи, написала и протестировала деплой, который мог запустить любой, задокументировала путь данных. Ревью инвесторов прошло без красных флагов.

Хороший ответ: называет конкретные пробелы без защитной реакции. Есть план их закрыть.

Тревожный сигнал: «у нас код чистый, всё в порядке». У любого продукта на ранней стадии есть технический долг (накопленные недоработки). CTO, который его не видит, позволит ему расти, пока проблема не станет чужой.

Красные флаги до собеседования

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

Что бы я сделал на вашем месте

1. Определитесь с форматом: сооснователь, fractional CTO или штатный наём. Если не уверены, начните с оплачиваемого тестового проекта: он покажет, как работается вместе, до передачи доли или подписания контракта.
2. Запишите три главные проблемы вашего продукта до первого собеседования. Вопросы выше работают лучше, когда привязаны к вашей ситуации.
3. Опишите реальную проблему каждому кандидату и сравните подходы. Оплачиваемая рабочая сессия на вашем реальном коде покажет больше любого интервью. Подробнее — в гайде по выбору разработчика.
4. Берите рекомендации у фаундеров, не у инженеров. Вопрос, который имеет значение: «Что конкретно изменилось благодаря этому человеку?»
5. Код, облачные аккаунты, домены и аккаунты сторов — на вашу компанию с первого дня. CTO, который сам на этом не настаивает, не думает о вашей долгосрочной позиции. Если вы только начинаете и нужна помощь с определением, что строить первым, посмотрите гайд по запуску стартапа.

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

Free консультация