Первый технический найм после запуска: разработчик, менеджер или CTO?

Почему после запуска в этом легко запутаться

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

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

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

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

Размытый startup engineering hire обычно чинит только одну часть этого хаоса. Потом основатель чувствует разочарование, даже если новый человек хороший. Проблема была не в человеке. Проблема была в размытой роли.

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

Неправильный найм может стоить шести месяцев. Понятная роль может их сэкономить.

Какая работа на самом деле занимает неделю

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда реальную проблему решает менеджер

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

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

Это проблема менеджмента, а не кодинга.

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

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

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

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

Некоторым компаниям при этом все еще не нужен full-time executive. Им нужен человек, который наведет порядок, подучит команду и вернет основателю время. Иногда это engineering manager. Иногда частичный CTO может выстроить процесс, подтянуть лида и держать команду в движении до следующей стадии роста.

Когда нужен executive, а не еще один кодер

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

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

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

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

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

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

Полноценный CTO — не единственный вариант. Частичный CTO может отлично подойти, если вам нужен senior-взгляд, а бюджета на постоянного руководителя пока нет. Такой формат часто дает достаточно опыта, чтобы выбрать стек, собрать команду, контролировать расходы на инфраструктуру и задать понятную ответственность. Oleg Sotnikov делает такую работу со стороны основателя через oleg.is, обычно для команд, которым нужна опытная техническая помощь без спешки с полноценной executive-зарплатой.

Как принять решение за пять шагов

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

Простой тест работает лучше длинного спора.

1. Запишите три проблемы, которые сегодня мешают росту, простыми словами. «Клиенты слишком долго ждут исправлений», «новые фичи каждый раз срывают сроки» или «никто не владеет техническими решениями» уже дают реальную задачу.
2. Соотнесите каждую проблему с типом работы, который для нее нужен. Баги, интеграции и выпуск фич обычно требуют разработчика. Потерянные передачи, слабое планирование и неясная ответственность указывают на менеджмент. Архитектура, план найма, контроль бюджета и техническое направление указывают на executive-работу.
3. Решите, что оставит за собой основатель. Некоторые основатели еще полгода могут сами владеть продуктом, наймом и техническим направлением. Некоторые — нет. Если основатель может направлять команду, но ему нужно больше результата, нанимайте senior-разработчика. Если основатель каждый день застревает в технических решениях, частичный CTO может быть лучшим шагом до того, как full-time executive станет оправданным.
4. Опишите первые 90 дней через простые результаты. Не пишите расплывчатые цели вроде «улучшить engineering». Пишите результаты вроде «сократить backlog багов с 40 до 15», «выпустить обновление онбординга к июню» или «настроить еженедельный процесс планирования и нанять двух разработчиков».
5. Нанимайте роль, которая закрывает самый большой разрыв, даже если титул кажется скромнее. Startup engineering hire должен убирать самый дорогой bottleneck.

Еще один быстрый пример: у стартапа уже есть платящие пользователи, один основатель и два подрядчика. Фичи постоянно срываются, потому что никто не проверяет работу, не планирует спринты и не решает, что нужно убрать из объема. Такому бизнесу сначала не нужен третий кодер. Ему нужен человек, который будет вести решения. Иногда это полноценный CTO. Иногда — помощь на part-time, пока команда не вырастет.

Обычно это самый понятный ответ на вопрос «engineering manager or senior engineer». Смотрите на узкое место, называйте работу и нанимайте под этот разрыв.

Простой пример из растущего стартапа

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

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

В этом стартапе основатель нанимает одного senior-инженера вместо engineering manager. Решение быстро окупается. Новый сотрудник исправляет баги, на которые чаще всего натыкаются клиенты, улучшает процесс релизов и выпускает две небольшие функции, которые пользователи уже просили. Нагрузка на поддержку падает. Клиенты быстрее получают ответы. У основателя освобождается время, чтобы продавать, разговаривать с пользователями и планировать следующий шаг.

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

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

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

Ошибки, которые уводят найм не туда

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

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

Проблемы создают и сами вакансии. Слишком широкий startup engineering hire часто просит одного человека одновременно писать код, руководить командой, планировать архитектуру, набирать будущих сотрудников, заниматься инфраструктурой и ходить на звонки по продажам. Большинство сильных кандидатов просто закрывают такую вакансию. Те немногие, кто остается, часто ищут больше статус, чем соответствие роли. Если вы не можете понять, нужен вам engineering manager или senior engineer, рынок не будет гадать за вас.

Титулы из крупных компаний создают свой собственный хаос. Стартапу на 10 человек не нужен тот же оргчарт, что и компании на 300 человек. Копирование «CTO» или «VP Engineering» из более крупных команд обычно скрывает более простой запрос. Иногда достаточно практического разработчика. Иногда помогает частичный CTO, который задает направление, пока команда продолжает выпускать продукт.

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

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

Если ответы расплывчаты, сначала перепишите роль, а уже потом нанимайте.

Короткий чек-лист перед оффером

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

Проверьте пять вещей:

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

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

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

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

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

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

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

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

Красивый титул часто приводит к плохому найму. Startup engineering hire должен решать тот хаос, который у вас уже есть, а не компанию, которой вы надеетесь стать через год.

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

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

Если вам нужно второе мнение перед оффером, Oleg Sotnikov на oleg.is работает со стартапами именно по таким вопросам: проектирование роли, техническое направление и поддержка частичного CTO. Такой внешний взгляд часто обходится дешевле, чем месяцы исправления ошибки.

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