Поиск CTO для стартапа: найдите узкое место до найма

Почему фаундеры не видят настоящую проблему

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

Когда так происходит, боль превращается в туман. Кажется, что компании нужен взрослый senior technical person в комнате, и поиск CTO для стартапа начинается раньше, чем кто-то назовет настоящее узкое место.

Такая реакция понятна, но она часто приводит к неверному решению. Название должности выглядит конкретным. "CTO" звучит как ownership, скорость и порядок в одном найме. Но реальная работа устроена куда сложнее. Должность не чинит плохие handoffs, неясные продуктовые решения, слабое тестирование или процесс деплоя, который ломается каждую пятницу.

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

Фаундеры обычно читают симптомы как пробел в лидерстве. Медленные релизы выглядят так, будто команде нужен CTO. Повторяющиеся инциденты выглядят так, будто архитектуре нужен CTO. Непонятные инженерные апдейты выглядят так, будто коммуникации нужен CTO. Сорванные дедлайны выглядят так, будто execution нужен CTO.

Иногда это правда. Но часто — лишь наполовину.

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

Давление делает любую проблему стратегической. Инвесторы спрашивают про leadership. Кандидаты спрашивают, кто управляет engineering. Компании хочется взрослого названия в оргструктуре. А тем временем один сломанный workflow каждый день сжигает часы.

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

Сначала разберите некрасивый workflow

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

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

Начните с первого триггера. Это может быть lead form, support ticket, неудачный платеж или обещание, которое фаундер дал на звонке. Проследите работу по порядку — от первого момента до результата, который видит клиент.

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

У большинства команд неожиданно всплывают циклы. Работа переходит от sales к product, а потом возвращается назад, потому что не хватает деталей. Инженер просит фаундера выбрать между двумя вариантами. Фаундер занят, и задача лежит. Потом support снова находит ту же проблему, потому что корневую причину так и не устранили.

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

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

После такого упражнения поиск CTO для стартапа становится намного проще. Вы перестаете нанимать ради названия и начинаете нанимать ради блокера. Если решения застревают на архитектуре и trade-offs, вам может понадобиться senior technical leadership. Если настоящая проблема — в delivery flow, процессах и координации команды, другой найм может решить ее быстрее.

Именно здесь fractional CTO for startups может помочь. Сильные специалисты не начинают с великого плана. Они разбирают хаос, называют constraint и чинят то, что продолжает стоить вам денег.

Как обычно выглядит узкое место

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

Если выпуск продукта кажется медленным, посмотрите на путь от идеи до релиза. Простое изменение не должно лежать днями в ожидании, пока кто-то уточнит scope, починит сломанный handoff или нажмет deploy. Когда релизы снова и снова срываются, проблема часто в планировании и дисциплине delivery, а не в усилиях.

Частые баги говорят о другом. Если один и тот же тип проблемы снова доходит до пользователей, у команды обычно нет понятных правил ревью, базового test coverage или одного человека, который отвечает за качество. Busy team все равно может писать стабильный софт. Хаотичная команда выпускает сюрпризы.

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

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

Churn в найме легко понять неправильно. Фаундеры часто винят рынок или думают, что взяли не тех людей. Иногда так и есть. Но не меньше случаев, когда инженеры приходят в команду с размытым ownership, слабым coaching и без общего стандарта того, как движется работа.

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

Запишите, где появляется friction, кто застревает и что повторяется. Обычно это и указывает на узкое место.

Подберите роль под узкое место

Названия должностей скрывают настоящую проблему. Команде, которая застряла на одной сложной системе, нужен совсем не тот человек, что команде, которая каждую неделю срывает релизы. Хороший technical hiring for founders начинается с того, что вы называете узкое место простыми словами.

Если один участок продукта постоянно блокирует прогресс, нанимайте под этот конкретный разрыв. Возможно, вашему приложению нужен человек, который распутает платежную логику, ускорит медленную базу данных или приведет в порядок запутанный API. Это работа senior engineer. Executive title не нужен, если проблема сидит в одной сложной области и требует hands-on результата.

Когда команда пишет код, но каждый день уходит в сторону, чаще лучше подходит tech lead. Этот человек задает направление прямо в работе. Он ревьюит pull requests, дробит проекты на более мелкие задачи и не дает команде спорить о базовых вещах половину спринта.

Fractional CTO for startups нужен в другой ситуации. Фаундеры приходят к этой роли, когда никто не отвечает за технический judgment по всей компании. Scope продукта все время меняется, найм идет хаотично, подрядчиков становится слишком много, а инженеры работают много, но бизнес почти не двигают.

Иногда проблема операционная. Релизы продолжают падать. Uptime нестабильный. Команда выкатывает изменения в пятницу, а выходные проводит, исправляя alerts. Это не проблема vision. Это проблема execution вокруг деплоя, инструментов, мониторинга и реакции на инциденты. Некоторым компаниям больше нужна дисциплина релизов, чем новый код.

Простое правило помогает. Если один болезненный технический участок тормозится из-за глубокой сложности, нанимайте senior engineer. Если растущей команде не хватает повседневного направления, нанимайте tech lead. Если фаундерам нужна структура, последовательность и технический judgment, приглашайте fractional CTO. Если постоянно ломаются деплои, uptime и внутренние инструменты, нужен engineering leader с операционным мышлением.

И если единственная причина найма — выглядеть более "взросло", full-time CTO пока не нужен.

Такая ошибка встречается часто. Full-time CTO дорогой, а неудачный найм может добавить лишние уровни еще до того, как у вас появится повторяемый способ сборки продукта. Если компании нужен лишь более красивый org chart, подождите. Нанимайте человека, который убирает реальное узкое место.

Как вести поиск простыми шагами

Поиск CTO для стартапа становится проще, когда вы перестаете спрашивать: "Кто выглядит достаточно senior?" — и начинаете спрашивать: "Какой хаос этот человек должен убрать первым?"

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

Потом сформулируйте первую проблему, за которую этот человек будет отвечать. Сделайте ее до боли конкретной. "Сделать engineering лучше" — бесполезно. "Взять на себя наш процесс релизов, потому что выпуск занимает 10 дней и ему никто не доверяет" — это уже реальная задача для найма.

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

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

Давите на trade-offs. Любое исправление имеет цену. Спросите, что они бы отложили, что бы измерили первым и что пока не трогали бы вовсе. Вам нужен человек, который может сказать: "Я бы пока не перестраивал это" или "Сначала я бы починил тестирование, а потом уже нанимал больше людей". Большие обещания бесплатны. Ясный выбор — нет.

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

Именно поэтому technical hiring for founders в начале должен казаться немного узким. Вы не покупаете название должности. Вы нанимаете человека, который быстро уберет один блокер с той командой, которая уже есть.

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

Частые ошибки при найме

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

Описание вакансии часто только усугубляет ситуацию. Фаундеры описывают человека, который умеет нанимать, писать код, управлять продуктом, успокаивать инвесторов, чинить культуру и помогать sales закрывать сделки. Это привлекает отполированных говорунов и отталкивает людей, которым нравятся ясные задачи. Более сильная вакансия называет первую миссию простыми словами, например: сократить время deploy с двух дней до одного часа или нанять первых двух инженеров.

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

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

Некоторые warning signs видны сразу. У роли двадцать обязанностей и ни одной 90-day goal. У каждого фаундера свое представление о кандидате. Команда не может назвать первую проблему, которую должен решить этот найм. На интервью ценится уверенность, а не понятные trade-offs. Все хотят full-time leadership, прежде чем проверить fit.

Последняя ошибка стоит очень дорого. Спешный full-time найм может на год зафиксировать стартап в неправильной форме. Для многих команд более безопасный шаг — короткий тест с fractional CTO for startups. Шесть недель реальной работы скажут больше, чем десять отполированных интервью.

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

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

Они начинают поиск CTO для стартапа, потому что команда выглядит перегруженной. Инженеры жалуются на постоянные отвлечения. Product спрашивает, почему простые исправления занимают неделю. Support предупреждает, что следующий релиз может создать больше тикетов, чем решит. Напряжение реальное, но напряжение не говорит, кого нанимать.

Когда фаундеры проходят один некрасивый workflow от bug report до production, pattern становится очевидным. Баг быстро попадает к инженеру. За день код готов. Потом pull request лежит два-три дня в ожидании ревью. После approval передача в релиз превращается в хаос. Релиз выходит поздно и ломает что-то небольшое, но заметное.

Этот разбор меняет картину. У стартапа нет проблемы стратегии. Ему не нужен executive с громким титулом, чтобы перерисовать архитектурные схемы или ходить на звонки с инвесторами. У него проблема delivery.

Никто не отвечает за путь от готового кода до безопасного релиза. Ревью ждут, потому что senior engineer воспринимают их как побочную работу. Релизы ломаются, потому что тестирование начинается слишком поздно и никто не использует один и тот же чек-лист каждый раз. Фаундеры читают стресс как проблему лидерства, но узкое место уже: ownership delivery и дисциплина релизов.

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

Именно поэтому technical hiring for founders так часто идет не туда. Дорогая должность выглядит как действие. А разобранный workflow дает реальный ответ. Если один человек может ускорить ревью, остановить плохие релизы и вернуть команде стабильный срок выпуска, вам, возможно, нужен fractional CTO for startups, а не постоянный executive.

Быстрые проверки перед оффером

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

Потом сузьте задачу еще сильнее. Вам нужно понять точное место, где работа останавливается. "Engineering медленный" — это слишком широко. "Никто не может принимать архитектурные решения, поэтому каждая фича превращается в переделку" — уже конкретно. Сильный кандидат может починить настоящий choke point. Размытое чувство — нет.

Запишите простыми словами, за что этот человек будет отвечать. Он будет выбирать stack, утверждать технический найм, задавать правила delivery, разговаривать с клиентами о trade-offs или coachить команду, пока за вами остается финальное слово? Фаундеры часто пропускают этот шаг. А потом удивляются, почему новый лидер ждет одобрения почти на каждое решение.

Помогает короткая проверка. Назовите workflow, который каждую неделю отнимает у вас время или деньги. Отметьте точный handoff, approval или технический шаг, на котором работа стопорится. Составьте список решений, которые этот человек сможет принимать без вашего предварительного согласования. Решите, нужна ли вам part-time помощь или full-time найм. Поставьте один результат на 90-й день, например сократить время релиза с 10 дней до 2.

Теперь проверьте масштаб на вашем этапе. Небольшому стартапу с одним продуктом и несколькими инженерами часто нужен fractional CTO for startups раньше, чем full-time executive. Компании с несколькими командами, активным наймом и клиентскими дедлайнами может потребоваться человек, который будет в этом кресле каждый день. Название роли менее важно, чем часы, ownership и размер проблемы.

Еще одна простая проверка: спросите себя, "Пойму ли я к третьему месяцу, сработало это или нет?" Если ответ не складывается в один конкретный результат, остановитесь. Сначала сузьте роль, а потом делайте оффер.

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

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

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

Эта страница должна формировать саму роль. Если фичи застревают на ревью, потому что никто не может превратить идеи фаундера в четкие specs, вам, возможно, нужен technical lead, который умеет работать с продуктом. Если релизы кажутся рискованными и медленными, нужен человек с hands-on опытом в инфраструктуре и delivery. Если вы постоянно встречаете инженеров, которых не можете оценить, узкое место — technical hiring for founders, а не архитектура.

Поиск CTO для стартапа становится проще, когда роль рождается из узкого места, а не из эго, моды или investor theater. "Нам нужен CTO" — слишком размыто. "Нам нужен человек, который за 60 дней улучшит качество релизов и выстроит вменяемый engineering process" — уже достаточно конкретно, чтобы проверить.

Не переходите сразу к full hire, если проблема все еще размыта. Начните с короткого аудита или фиксированной первой миссии: разберите один сломанный workflow, назовите главное ограничение, предложите 30-дневный план и покажите, как будет измеряться успех.

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

Внешний взгляд может помочь, если команда слишком близко к хаосу. Oleg at oleg.is работает как fractional CTO и startup advisor, и именно для такой диагностики workflow этот взгляд часто особенно полезен. Иногда решение — это leadership-найм. Иногда — более четкое delivery, лучшие решения по инфраструктуре или практичное использование AI в том, как команда разрабатывает и эксплуатирует software.

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