Технический найм после раунда: исправьте пробел в ответственности

Почему план ломается после раунда

Свежий раунд быстро меняет настроение. До того как деньги поступят на счёт, основатели спрашивают: «Какая самая маленькая команда сможет это выпустить?» После раунда вопрос часто становится другим: «Как быстро мы можем нанять людей?»

Такой сдвиг кажется нормальным. Но именно он очень часто ломает план найма.

Давление реальное. Инвесторы ждут роста. Основатели хотят динамики. Команде нужен знак, что компания выходит на новый уровень. И вот план найма превращается в список ставок: два backend-инженера, один frontend-инженер, один product manager, один дизайнер. В таблице всё выглядит аккуратно. На практике всё часто разваливается.

Проблема проста. Основатели считают людей, но не раскладывают ответственность.

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

Именно здесь найм после раунда чаще всего идёт не так. Компания предполагает, что новая команда разберётся по ходу роста. Каждый берёт себе кусок feature work, а вся грязная операционная работа остаётся в пробелах. Один инженер думает, что обратную связь из поддержки должен разбирать product. Product думает, что engineering разрулит это во время sprint planning. Основатели считают, что самый опытный разработчик удержит систему в стабильности. Никто не владеет всей картиной, поэтому все её трогают, но никто её не защищает.

Первые сигналы появляются быстро:

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

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

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

Что на самом деле значит ответственность за систему

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

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

Система может быть клиентской зоной, например billing или signup. А может быть и внутренней инфраструктурой, например deploy pipeline, задачи по синхронизации данных или alerts. Основатели часто сводят ответственность к вопросу «кто написал большую часть кода». На деле это гораздо шире.

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

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

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

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

Хорошие команды делят усилия. Зрелые команды всё равно называют владельца.

Почему headcount кажется безопаснее

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

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

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

Основатели ещё и копируют оргструктуры больших компаний. Это лёгкая ошибка. У крупной компании есть отдельные managers, frontend-команды, backend-команды, QA, platform и data. Такая структура может быть разумной при 200 инженерах. При 8 или 12 инженерах она часто создаёт пустоты вместо ясности.

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

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

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

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

Простой пример после раунда

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

Через три недели продукт всё ещё выпускается с задержками.

Проблема не в усилиях. Проблема в ответственности. Один инженер работает над billing, другой — над onboarding, третий — над reporting, четвёртый — над mobile app. Никто не владеет путём от готового кода до безопасного релиза.

Deploy jobs падают и висят, пока основатель не заметит. Alerts приходят в общий inbox, поэтому все думают, что их уже увидел кто-то другой. Доступы в production нарастали кусочками, без чётких правил. Для релиза нужно изменить базу данных, но никто не знает, кто должен это запускать, проверять и откатывать, если что-то пойдёт не так.

Команда продолжает двигать feature work, но даты релизов срываются из-за мелких и вполне избежимых причин. Сломанный тест блокирует деплой на полдня. Отсутствующий secret стопорит hotfix. Ночью срабатывает alert, и основатель подключается сам, потому что никто другой не чувствует уверенности, чтобы действовать.

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

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

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

Основатели обычно сначала нанимают ради output. Но бизнесу часто сначала нужна ответственность.

Сначала разложите ответственность, потом нанимайте

Большинство планов найма начинается с ролей. Начните с систем.

Ошибка обычно возникает здесь. Основатели пишут «2 backend-инженера» или «1 DevOps-наём» ещё до того, как выпишут, что должно работать каждый день. Такой порядок кажется нормальным, но он прячет настоящую проблему.

Составьте простой список систем, которые могут заблокировать выручку, релизы или поддержку клиентов. Для большинства команд сюда входят signup и права доступа, billing и подписочная логика, основное приложение и его API, deploy pipeline и хостинг, а также alerts и logs, на которые люди опираются во время инцидентов.

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

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

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

Простой пример: компания нанимает трёх product-инженеров, потому что roadmap переполнен. Никто не владеет deploy pipeline или production alerts. Фичи делаются, но релизы сдвигаются, баги слишком долго остаются в продакшене, а support продолжает гоняться за инженерами в Slack. Команда выглядит больше, но результат ощущается хуже.

Эта карта должна быть маленькой и скучной. Таблица подойдёт. Доска тоже подойдёт. Главное — обновлять её каждый месяц, потому что ответственность быстро меняется после новых наймов, запусков продукта и изменений архитектуры.

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

Какие роли обычно нужны первыми

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

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

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

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

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

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

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

Ошибки в первой волне найма

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

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

Старшие титулы создают похожую путаницу. Нанять VP of Engineering, principal architect или head of platform может казаться безопасным после закрытия раунда. Но титул не решает проблему нечёткой зоны ответственности. Если человек не может за одну короткую фразу ответить на вопрос «за что я отвечаю в этом квартале?», найм уже начинает расплываться.

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

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

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

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

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

Прежде чем открывать новую роль, добейтесь одного чёткого ответа: какой системой этот человек будет владеть в течение 90 дней? Если вы можете сказать только «помогать команде» или «поддерживать рост», роль всё ещё слишком расплывчата. У ответственности должен быть реальный предел, например billing flow, mobile-релизы, внутренние инструменты или путь эскалации в поддержку.

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

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

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

Перед тем как утвердить роль, запишите пять строк:

• система или workflow, которыми будет владеть этот человек
• кто закрывает это сейчас
• сколько стоит подождать 60–90 дней
• какое изменение процесса можно попробовать сначала
• кто утверждает качество, релизы и поддержку

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

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

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

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

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

Сделайте паузу, прежде чем утвердить следующую роль, и нарисуйте простую карту ответственности.

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

Вы можете обнаружить, что один инженер трогает payments, эскалации поддержки и approval на деплой, а за reliability по-прежнему никто явно не отвечает. Это в первую очередь не проблема headcount. Это проблема ответственности.

Не пытайтесь за один проход исправить весь оргчарт. Выберите одну неясную область на этой неделе. Хорошие кандидаты — ответственность за релизы, реагирование на инциденты, data pipelines, внутренние инструменты или работа на стыке engineering и operations. Если в одной из этих зон нет понятного владельца, исправьте это до того, как добавите ещё одну роль.

Когда пишете описание вакансии, делайте упор на результат, за который человек отвечает. Престиж титула — частая ловушка после раунда. «VP», «Head of» или «Principal» могут казаться безопаснее, чем прямое описание работы. Уберите язык статуса и опишите саму работу.

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

Если хотите получить второе мнение перед наймом, Oleg Sotnikov на oleg.is может посмотреть план, найти пробелы в ответственности и помочь решить, нужен ли вам full-time сотрудник, более узкая роль или вместо этого поддержка Fractional CTO. Такая проверка часто обходится дешевле одного поспешного senior-найма и гораздо легче исправляется, чем запутанный оргчарт через шесть месяцев.