План найма на seed-стадии, который выдержит первого senior-инженера

Почему ранние планы найма ломаются

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

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

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

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

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

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

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

Даже короткая заметка убирает массу путаницы. Запишите, кто принимает решения по приоритетам, кто утверждает технические изменения, кто отвечает за сроки поставки, кто разбирает инциденты и какие решения основатель все еще хочет проверять лично.

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

Начните с работы, которая уже на столе

Большинство команд на seed-стадии нанимают из тревоги. Бэклог выглядит хаотично, запуски сдвигаются, и основатели бросаются к титулам вроде «VP of Engineering» или «product manager». Титулы могут скрыть настоящую проблему, а проблема обычно в куче работы без понятного владельца.

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

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

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

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

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

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

Определите порядок ролей до начала поиска

Команды на seed-стадии часто нанимают под компанию, которую они воображают, а не под работу, которая лежит прямо перед ними. Так основатели оказываются сначала с дизайнером, когда продуктовая стратегия еще не ясна, или с engineering manager, когда управлять еще по сути некем.

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

Специализированные роли обычно приходят позже. Стартапу редко нужны security lead, platform engineer, data engineer и QA manager раньше, чем появится один человек, который способен принимать здравые технические решения, ревьюить работу и не дать кодовой базе расползтись. Первый senior-инженер часто закрывает именно этот разрыв. Если команда еще не готова к full-time лидеру, часть этой роли временно может взять на себя Fractional CTO.

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

Четыре вопроса сильно упрощают проверку порядка ролей:

• Какая работа опаздывает каждую неделю?
• Какие решения снова и снова возвращаются к основателю?
• Какая работа сейчас держится на одном уставшем человеке?
• Какой найм сделает следующий найм проще?

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

Перед тем как открывать поиск, запишите следующие два найма. Не следующие десять. У команд на seed-стадии все меняется слишком быстро. Если первый найм — senior-инженер, то вторым может быть инженер с продуктовым мышлением или дизайнер, в зависимости от того, где команда застрянет дальше. Это дает наставникам понятную точку для проверки: совпадает ли этот порядок с работой или только с оргструктурой в голове основателя?

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

Определите полномочия до того, как делаете оффер

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

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

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

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

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

Дайте новому senior-инженеру реальный объем полномочий с первого дня. Если он не может менять то, как команда строит, выкатывает и проверяет работу, роль senior только по названию. Хорошая проверка очень прямолинейна: может ли этот человек принять одно важное инженерное решение на этой неделе без того, чтобы дважды просить разрешение?

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

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

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

Планируйте первые передачи по шагам

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

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

Используйте график, а не расплывчатое обещание, что новый сотрудник «скоро все заберет».

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

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

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

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

Простой пример для seed-команды

Seed-компания с одним основателем, одним senior-инженером и одним гибким подрядчиком может сделать очень много, если у каждого есть своя четкая зона ответственности. Это работает, потому что опирается на реальную нагрузку, а не на фантазийную оргструктуру.

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

Практичная схема проста. Основатель отвечает за выбор продукта, звонки с клиентами и изменения приоритетов. Первый senior-инженер отвечает за стандарты поставки, технические оценки и то, как работа проходит путь от идеи до выложенного кода. Подрядчик закрывает короткую дыру, например доводку дизайна или frontend для запуска. Второй full-time сотрудник идет туда, где давление самое сильное: QA, operations или backend.

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

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

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

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

Ошибки, которые менторы должны останавливать рано

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

Классическая ошибка — нанять head of engineering до того, как им вообще кем управлять. Если в компании два основателя и подрядчик, этот человек не руководит отделом. Он либо дорогой individual contributor, либо менеджер почти без команды.

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

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

Именно здесь менторы должны говорить прямо. Остановите и проверьте план, если слышите что-то из этого:

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

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

Линии подчинения должны оставаться стабильными достаточно долго, чтобы успело сформироваться доверие. Если в одну неделю новый сотрудник отчитывается основателю, на следующей — product lead, а потом еще и советнику, он первые месяцы будет читать политику вместо того, чтобы делать работу.

Быстрые проверки перед каждым наймом

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

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

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

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

Эта проверка занимает десять минут и экономит месяцы исправлений:

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

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

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

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

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

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

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

Короткий план может охватывать четыре вещи:

• следующие две роли по порядку
• топ-5 задач, за которые отвечает каждая роль
• решения, которые остаются у основателей
• передачи на 1-й неделе, 2-й неделе и к 30-му дню

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

Внешняя проверка помогает сильнее, чем многие основатели ожидают. Ментор или Fractional CTO может заметить пересечения, нехватку полномочий или роль, которая приходит слишком рано. Если основателям нужен такой второй взгляд, Oleg Sotnikov at oleg.is делает эту работу как Fractional CTO и startup advisor. Это особенно полезно, пока команда еще достаточно маленькая, чтобы исправить путаницу в ролях за один день, до того как привычки затвердеют.

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