Технический лидер стартапа: builder, stabilizer или scaler?

Почему стартапы часто ошибаются с этой ролью

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

Именно так команда из восьми человек получает "VP of Engineering", когда настоящая проблема гораздо проще: релизы срываются, баги не закрываются, и никто не отвечает за инциденты. Человек, который отлично умеет выстраивать уровни управления, планировать найм и проводить встречи для большой команды, может не справиться в стартапе, где каждый день нужны практические решения.

Названия должностей легко переносятся из компании в компанию. Контекст — нет. Основатели видят, что сработало в Series B или в публичной компании, и думают, что та же должность спасёт и их стартап. Обычно это не так. Builder, stabilizer и scaler решают очень разные задачи, даже если на бумаге все выглядят «сеньорными».

Несоответствие быстро становится заметным:

• Builder приходит в команду, которой на самом деле нужны спокойные, повторяемые процессы, и выпускать становится быстрее, но аварии продолжаются.
• Stabilizer приходит слишком рано, добавляет процессы, и команда начинает двигаться медленнее, ещё до того как понятна ценность продукта.
• Scaler приходит до того, как вообще есть что масштабировать, и люди тратят больше времени на отчёты о работе, чем на саму работу.

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

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

Поэтому многие команды сначала берут fractional CTO для стартапов, а уже потом решают вопрос с постоянным руководителем. Хороший консультант быстро назовёт настоящую проблему, не навязывая должность, которая подходит другому типу компании.

Как выглядит builder

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

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

Такой технический лидер стартапа не ждёт тяжёлых процессов. Он использует ровно столько структуры, чтобы команда не спотыкалась сама о себя. Обычно это простое планирование, прямые решения и много работы руками. В очень ранних командах builder часто пишет код, смотрит pull request'ы, общается с основателями и чинит production-проблемы в один и тот же день.

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

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

Скорее всего, вам нужен builder, если знакомо почти всё из этого:

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

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

Как выглядит stabilizer

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

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

Чаще всего беспорядок сильнее не в коде, а в ответственности. Stabilizer назначает владельцев сервисов, инцидентов и областей бэклога. Когда что-то падает в 2 часа ночи, команда должна понимать, кто реагирует, где лежит runbook и как закрывается проблема. Это звучит просто. Многие стартапы слишком долго живут без этого.

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

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

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

Именно поэтому такой технический лидер стартапа часто менее заметен, чем builder или scaler. Вы можете не увидеть его работу в виде одного громкого запуска. Но вы заметите, что релизы перестали падать, инциденты стали короче, а команда перестала жить в Slack.

Как выглядит scaler

Scaler — это лидер, которого нанимают тогда, когда компания уже работает, но сам способ работы перестал тянуть. У продукта есть пользователи. Выручка реальна. Команда растёт. И тут скорость начинает падать, потому что слишком многое завязано на нескольких ключевых людях.

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

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

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

Он также заранее определяет передачи ответственности, пока они не превратились в конфликт. Одна команда владеет API. Другая — приложением. Кто-то отвечает за инциденты. Кто-то — за внутренние инструменты. SLA становятся обычными и понятными обещаниями: кто первым отвечает на проблему в production и как быстро клиент должен ждать исправления.

При scaler героическая работа постепенно уходит на второй план. Поздний ночной инженер, который знает каждый сервер, каждый нестандартный кейс клиента и каждый хрупкий скрипт, — это не стратегия. Scaler превращает такие знания из головы отдельных людей в runbook'и, on-call-ротации, правила ревью и привычки релизов, которым могут следовать новые сотрудники.

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

Некоторые компании приглашают fractional CTO для стартапов именно на этот этап. Это может хорошо сработать, когда нужно выстроить планирование, ответственность и найм, не тратя шесть дорогих месяцев на пробы и ошибки.

Посмотрите на тот хаос, который у вас уже есть

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

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

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

Если продукт стабилен, а спрос растёт, смотрите на саму команду. Больше инженеров, больше встреч, больше передач задач и больше столкновений между людьми обычно означает, что нужен scaler. Такой лидер выстраивает найм, ownership, планирование и коммуникацию так, чтобы рост не превращался в путаницу.

Во всех трёх случаях есть один общий тревожный сигнал: всё по-прежнему утверждает один человек. Если основатель, lead engineer или CTO должен одобрять каждый деплой, архитектурное решение и срочный фикс, команда застряла. Работа замедляется. Люди ждут. Мелкие проблемы копятся, потому что никто больше не может двигаться без разрешения.

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

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

Как выбрать за пять шагов

Выбрать технического лидера стартапа легче, если смотреть на недавнюю боль, а не на оргструктуру, которую вы надеетесь увидеть в следующем году. Основатель может просить CTO, VP или head of engineering, хотя настоящая потребность гораздо уже.

1. Посмотрите на последние 60 дней и запишите три инженерные проблемы, которые навредили сильнее всего. Используйте реальные события, а не общие жалобы: сломанный релиз, сорванное обещание клиенту, застывший найм, авария или месяц медленной доставки.
2. Разделите каждую проблему на боль создания, стабильности или роста. Боль создания означает, что команда не может достаточно быстро делать продукт. Боль стабильности означает, что продукт ломается, релизы кажутся рискованными, а инженеры тратят неделю на исправления. Боль роста означает, что команда или система не справляются с большим числом клиентов, инженеров или сложности.
3. Отметьте, что именно блокирует каждая проблема в первую очередь: продажи, доставку или удержание. Так разговор остаётся честным. Медленный прототип бьёт по продажам. Хаотичные передачи задач бьют по доставке. Повторяющиеся баги и простой — по удержанию.
4. Напишите 90-дневную карту результатов для роли. Сделайте её конкретной. «Выпустить рабочий MVP к 60-му дню» указывает на builder. «Сократить число неудачных релизов с 4 в месяц до 1» указывает на stabilizer. «Нанять 3 инженеров, чётко распределить ответственность и удержать cycle time на прежнем уровне» указывает на scaler.
5. Нанимайте под карту результатов, а не под мечту о должности. Если человек не сможет выиграть следующие 90 дней, титул уже не так важен.

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

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

Простой пример

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

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

На этом этапе многие команды делают один и тот же вывод: «Нам нужен VP of Engineering». Звучит как взрослый, правильный найм. Но часто это неверный шаг.

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

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

На практике первые 60 дней могут выглядеть очень просто:

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

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

Через полгода та же компания может выглядеть совсем иначе. Биллинг работает. Релизы перестали ломаться. Рост клиентов продолжается. Команда нанимает ещё нескольких инженеров, и теперь проблемой становится координация. Вот тогда scaler может оказаться уместным.

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

Ошибки, которые стоят времени

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

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

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

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

Несколько проверок экономят месяцы:

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

Основатели часто скрывают настоящий хаос, потому что хотят, чтобы роль звучала впечатляюще. Это оборачивается против них. Если проблема в грязном коде, слабом процессе или постоянных авралах, так и скажите. Короткий совет от опытного fractional CTO для стартапов может помочь назвать проблему до того, как вы наймёте не того человека.

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

Короткие проверки перед решением

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

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

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

Используйте этот короткий чек перед решением:

• Может ли команда описать ошибки прошлого месяца на одной странице?
• Показывает ли одна метрика главную проблему каждую неделю?
• Будет ли этот лидер отвечать за найм, delivery или и за то, и за другое?
• Готовы ли основатели отказаться от решений, связанных с этой ролью?
• Вам нужна полная занятость или сначала частичное лидерство?

Ownership — это место, где стартапы чаще всего путаются. Одни основатели говорят, что хотят CTO, но на деле им нужен человек, который починит delivery и остановит срывы сроков. Другие хотят senior engineer, чтобы он выстроил архитектуру, а потом тихо добавляют к этому найм, планирование и уборку в команде. Такая смесь быстро создаёт трение.

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

Последняя проверка — про объём роли. Полная занятость имеет смысл, когда команде нужны ежедневное направление, активный найм и постоянное давление на delivery. Частичное лидерство лучше подходит тогда, когда сначала нужны диагностика, план и несколько жёстких решений. На этой стадии fractional CTO для стартапов часто разумнее, чем поспешный найм сеньора.

Если после одной встречи эти пять ответов всё ещё расплывчаты, остановите поиск. Должность может подождать. Описание работы — нет.

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

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

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

Короткое описание должно включать четыре вещи:

• что именно ломается сегодня
• за что отвечает этот найм
• что должно улучшиться в первую очередь
• как выглядит хороший результат к 90-му дню

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

Назначьте точки проверки до выхода человека на работу. 30, 60 и 90 дней достаточно. К 30-му дню должна появиться ясная картина проблем. К 60-му — решения и план. К 90-му — заметные изменения в команде, продукте или инфраструктуре.

Если вам нужен второй взгляд до найма, fractional CTO для стартапов может уберечь от дорогой ошибки. Oleg Sotnikov занимается такой оценкой структуры команды, архитектуры продукта и инфраструктуры. Сторонний взгляд особенно полезен, когда основатели застряли между «нам нужно быстрее строить» и «нам нужно перестать всё ломать».

Используйте этот разбор, чтобы принять одно решение, а не пять. Если самая большая проблема — недоделанный продукт и слабое техническое направление, нанимайте builder. Если команда постоянно спотыкается о качество, ownership и delivery, нанимайте stabilizer. Если машина работает, но начинает буксовать из-за роста, нанимайте scaler.

Чёткая диагностика всегда лучше впечатляющей должности.