Найм CTO на частичную занятость: сначала исправьте роль, а потом публикуйте вакансию

Почему вакансия часто не видит настоящую проблему

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

Но у большинства команд нет проблемы с названием должности. У них проблема с работой.

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

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

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

Вот почему найм CTO на частичную занятость стоит начинать ещё до публикации вакансии. Короткий разбор может превратить расплывчатый поиск в понятный. Вместо «нам нужен сильный full-stack-инженер» команда может понять, что ей нужен человек, который возьмёт на себя релизы, сократит хвост багов и уберёт один очевидный узкий участок.

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

Начните с работы, а не с должности

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

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

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

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

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

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

Посмотрите на кодовую базу до того, как писать роль

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

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

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

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

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

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

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

Найдите пробелы в ответственности

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

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

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

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

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

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

Маленький стартап может сказать, что ему нужен «старший инженер с лидерскими качествами». Но если никто не отвечает за system design, качество релизов и стандарты найма, это уже ближе к роли CTO на частичную занятость, чем к очередному individual contributor. С другой стороны, если основатель по-прежнему сам отвечает за roadmap и бюджет, а нужна только более сильная роль backend-lead, называть должность CTO будет путать кандидатов с самого начала.

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

Подготовьте поиск за одну неделю

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

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

Потом превратите эти заметки в план поиска:

1. Отследите, где всё стопорится. Запишите моменты, когда работа останавливается больше чем на день: заблокированные ревью, хрупкие тесты, неясная ответственность, медленные релизы или решения только у основателя.
2. Превратите боль в результаты. Соберите scorecard с тремя-пятью результатами, которые новый сотрудник обязан дать. Хорошие примеры конкретны: уменьшить откаты релизов, взять под себя ownership API или сократить время ревью с двух дней до одного.
3. Выберите навыки из реальной работы. Если команда большую часть времени чинит приложение на TypeScript, разбирается с запросами PostgreSQL и борется со сбоями CI, это и есть обязательные навыки. Уберите всё лишнее.
4. Подстройте интервью под работу. Практический разбор бага, обсуждение кода с текущими инженерами и планировочная сессия с основателем скажут больше, чем абстрактные задачки.
5. Определите первые 90 дней. Решите, что человек должен узнать, взять под контроль и выпустить к третьему месяцу.

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

Реальный пример небольшой команды

Основатель SaaS-компании собирался нанять senior full-stack-инженера. На бумаге это звучало правильно. У продукта были платящие пользователи, небольшая команда и растущий backlog.

Проблемы проявились в еженедельной работе. Релизы съедали часы. Даже небольшие изменения превращались в ночные исправления. Все работали с production, но никто чётко не отвечал за delivery, code review или качество релизов.

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

Основатель думал, что команде не хватает скорости программирования. Аудит показал другое: команде не хватало технической ответственности. Два инженера могли делать фичи, но ни один не хотел принимать решения по архитектуре, правилам релиза или тому, как остановить повторение одних и тех же багов.

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

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

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

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

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

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

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

Переписанная вакансия скрывает настоящую работу. В ней написано «старший инженер» или «engineering manager», а команде на самом деле нужен человек, который разберётся с деплоями, примет продуктовые компромиссы и поможет одному junior-разработчику, который по пятницам релизит один.

Хорошие кандидаты замечают такой разрыв сразу. Неподходящие — подают заявку всё равно.

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

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

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

Полномочия так же важны, как и ответственность. Компания может нанять человека, чтобы он «отвечал за engineering», а потом запретить ему менять подрядчиков, задавать стандарты программирования или говорить «нет» случайным запросам на новые фичи. Такая схема выжигает людей, потому что они несут вину без права исправить причину.

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

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

Быстрые проверки перед публикацией

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

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

Перед публикацией проверьте несколько базовых вещей:

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

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

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

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

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

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

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

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

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

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