Первый инженер в команду: когда стоит подождать с fractional CTO

Почему этот найм так часто идет не так

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

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

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

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

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

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

Как выглядит готовность

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

Начните с ответственности. Один человек должен отвечать за ежедневные приоритеты. В молодой компании это часто основатель или fractional CTO. И тот и другой вариант подходит. Важно, чтобы у нового сотрудника не было сомнений, чей запрос победит, если двое попросили разную работу в один и тот же день.

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

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

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

Назначьте ответственных до публикации вакансии

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

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

До найма запишите по одному имени для каждой зоны решений:

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

Иногда два или три пункта принадлежат одному и тому же человеку. Это нормально. Проблема не в маленькой команде. Проблема в скрытой власти.

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

У ответственности должен быть и граница. Не говорите новому сотруднику, что он «владеет backend», если трое человек все еще правят один и тот же код, когда захотят. Дайте ему более узкую область. Это могут быть billing events, admin dashboard, CI jobs или один внутренний сервис. Понятная зона ответственности делает онбординг проще, потому что инженер понимает, где он может действовать без постоянного разрешения.

Один прямой менеджер важнее, чем многие основатели думают. Новому человеку нужен один человек для обратной связи, one-on-one и финального решения, если советы противоречат друг другу. Иногда этим менеджером становится основатель. Иногда — fractional CTO. Подходит любая схема, если команда проговаривает ее ясно и придерживается ее.

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

Напишите стандарты, которым сможет следовать новый сотрудник

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

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

Будьте конкретны с тестами. Новые сотрудники теряют время, когда не понимают, что значит «протестировано». Изменение текста в интерфейсе может потребовать быстрой ручной проверки. Изменение в auth, billing, data models или background jobs обычно должно требовать unit-тестов и короткой smoke-проверки основного пользовательского пути.

Называйте вещи одинаково каждый раз. Ветки и коммиты не обязаны быть изобретательными. Они должны быть читаемыми. Простой шаблон вроде feature/login-rate-limit или fix/invoice-rounding позже сильно облегчает просмотр работы. Сообщения коммитов должны говорить, что изменилось, а не рассказывать историю.

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

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

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

Превратите бэклог в задачи для старта

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

У каждой задачи должны быть короткие критерии приемки. Пишите просто и конкретно: «Пользователь может сбросить пароль по ссылке из письма». «Запись в логе включает request ID». «Тест покрывает случай неудачного платежа». Так исчезает обычная проблема «мне кажется, это уже готово», и у нового сотрудника появляется четкая линия финиша.

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

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

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

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

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

Как подготовиться за две недели

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

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

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

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

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

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

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

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

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

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

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

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

Поэтому команда на неделю останавливает найм.

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

К среде они договариваются о нескольких рабочих правилах. У каждой задачи должны быть короткий scope, понятное состояние готовности и один ревьюер. Маленькие pull request лучше больших. Если задача требует продуктового выбора, владелец отвечает на него до начала программирования.

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

У каждой задачи есть контекст, файлы, которые нужно посмотреть, и один ревьюер, который знает этот код.

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

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

Ошибки, которые съедают первый найм

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

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

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

Выдача человеку senior-уровня без реальной власти тоже оборачивается против команды. Компания называет роль «senior» или «lead», но человек не может сказать «нет», не может устанавливать стандарты и не может формировать бэклог. Название становится декорацией.

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

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

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

Короткая проверка перед оффером

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

Пройдитесь по короткому списку:

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

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

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

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

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

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

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

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

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

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

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