Технический ментор при найме фаундера: когда вмешиваться

Почему найм в стартапе превращается в хаос

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

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

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

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

Споры по офферу обычно показывают ту же проблему. Команда спорит о title, зарплате, equity и уровне, но настоящая проблема возникла намного раньше. Они так и не определили scope. Если компания с самого начала остаётся расплывчатой, кандидат и основатель могут прийти к финальному решению, имея в виду две разные работы.

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

Когда ментору стоит вмешаться в проектирование роли

Ментору стоит подключаться до публикации вакансии, если основатель не может объяснить, что именно новый человек должен делать в первые 90 дней. «Нам нужен сильный человек» — это не роль. «Нам нужен человек, который наведёт порядок в API, запустит изменения в billing и возьмёт на себя релизы» — это роль.

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

Ещё один понятный сигнал — когда команда спорит о seniority вместо результата. Если один человек хочет senior engineer, другой — tech lead, а никто не может назвать решения, за которые этот человек будет отвечать, title просто маскирует настоящую проблему. Ментор может вернуть разговор к scope: что нужно построить, что нужно исправить и какой уровень ответственности команда реально может поддержать.

Ментору также стоит вмешаться, когда одно описание вакансии пытается решить сразу три проблемы. Ранние команды часто пишут роль, которая одновременно смешивает продуктовое мышление, инфраструктурную работу и hands-on разработку фич. Обычно это значит, что компания ещё не выбрала своё первое узкое место. Нанимать одного человека на три работы кажется дешевле. Чаще это приводит к быстрому разочарованию.

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

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

Как сформировать роль до публикации вакансии

Большая часть неудачного найма начинается с вакансии, построенной на тревоге, а не на реальной бизнес-потребности. Основатель говорит, что ему нужен «senior full-stack AI engineer», но настоящий пробел часто гораздо проще: быстрее запустить onboarding, исправить проблемы с надёжностью или провести первых платящих клиентов через настройку без постоянной помощи.

Ментор должен притормозить и задать один простой вопрос: какую проблему этот человек должен решить первой?

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

Эти результаты говорят больше, чем длинный список инструментов. Они же помогают основателю понять, какого уровня найм ему действительно нужен. Компании, которой нужна стабильная поставка продукта, может хватить сильного mid-level специалиста, а не staff engineer с громким резюме.

Список навыков нужно жёстко разделить на обязательные и те, чему можно научить. Если команда может обучить фреймворку за пару недель, не превращайте это в фильтр на входе. То же самое касается названий инструментов, которые отражают только текущие привычки. Если вакансия просит Python, Go, Rust, React, Kubernetes, Terraform, пять облачных продуктов и три AI-инструмента, она звучит шумно и не очень понятно.

Ментору стоит также подтолкнуть основателя к трём решениям заранее: уровень, линия подчинения и диапазон оплаты. Эти вещи сильнее влияют на пул кандидатов, чем думают основатели. Подчинение основателю сильно отличается от подчинения engineering lead. А слишком поздно определённая вилка зарплаты зря тратит интервью и создаёт напряжение на этапе оффера.

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

Когда ментору стоит вмешаться в интервью-цикл

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

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

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

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

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

Как выстроить интервью-циклы, которые отвечают на реальные вопросы

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

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

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

Обычно этого достаточно. Больше этапов редко помогают, если суждение слабое.

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

Проверка должна соответствовать работе. Если вам нужен человек, который будет ревьюить pull request'ы, дайте небольшой review кода. Если нужен человек, который будет проектировать API, попросите набросать endpoint и объяснить компромиссы. Викторины и головоломки выглядят аккуратно, но обычно предсказывают меньше, чем реалистичная работа.

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

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

Когда ментору стоит вмешаться в споры по офферу

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

Первый тревожный сигнал — раздувание title. Если команда тратит больше времени на спор о «Head of Engineering» versus «Senior Engineer», чем на то, чем человек будет заниматься в первые 90 дней, разговор ушёл не туда. Ментор должен вернуть группу к scope, правам на решения и ожидаемому результату.

Деньги — следующий момент, где помогает внешний взгляд. Ранние команды часто знают, сколько могут платить, но не понимают, что реально можно купить на этот бюджет. Если компания может предложить $130k, а роль требует уровня staff и широкой ответственности, проблема не в кандидате. Роль слишком широка для этого бюджета. Хороший ментор говорит об этом прямо, а затем помогает сузить scope, скорректировать уровень или построить реальный план пересмотра, а не размытые обещания.

Обещания роста тоже нужно проверять на реальность. Основатели часто говорят: «Вы сможете построить команду» или «Это может вырасти в путь к CTO», потому что хотят закрыть кандидата. Ментор должен вмешаться, если компания пока не может поддержать такой путь. Пустой upside быстро создаёт раздражение.

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

На этом этапе разговор должен стать простым. Какая работа компании нужна в ближайшие 6–12 месяцев? Какой уровень компания может позволить себе сейчас? Какие риски несёт этот найм? Какие из этих рисков команда может компенсировать обучением и сопровождением? Какие обещания основатели действительно готовы зафиксировать письменно?

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

Простой пример из команды на ранней стадии

Один SaaS-основатель планировал нанять senior full-stack AI engineer в качестве первого сотрудника. Идея звучала эффективно. Один человек строит продуктовые функции, настраивает инфраструктуру, выбирает AI-инструменты и удерживает деплои в стабильном состоянии.

Ментор возразил, потому что роль смешивала две разные проблемы.

Первая проблема — поставка продукта. Основателю нужен был человек, который построит onboarding flow, свяжет его с core app и проведёт первых пользователей через настройку без трения. Вторая проблема — поддержка инфраструктуры. Стеку были нужны нормальный хостинг, мониторинг и базовые правила деплоя, но не отдельный сотрудник, который занимается только инфраструктурой.

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

Ментор также сократил интервью-цикл. Основатель придумал шесть этапов, потому что шесть этапов казались безопаснее. На деле это лишь замедлило бы поиск и отпугнуло хороших кандидатов. Цикл сократили до трёх сфокусированных разговоров: короткий созвон с основателем, чтобы проверить мотивацию и коммуникацию, технический разбор на основе реальной продуктовой работы вместо головоломок и финальная рабочая сессия по плану onboarding на следующие 90 дней.

Этот цикл ответил на важные вопросы. Сможет ли человек выпускать работу? Сможет ли он принимать компромиссы без драмы? Сможет ли использовать AI-инструменты как часть рабочего процесса, а не как магию?

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

Ошибки, из-за которых ментор становится бесполезным

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

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

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

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

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

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

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

Быстрые проверки перед открытием или закрытием поиска

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

Здесь помогает короткая проверка перед стартом.

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

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

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

Решите, кто принимает финальное решение, ещё до начала интервью. Если основатель, hiring manager и ментор думают, что у них есть право вето, процесс будет расплываться.

Сведите оффер к простым цифрам. Зарплата, equity, бонус, испытательный срок, дата выхода и условия должны помещаться на одну страницу без сюрпризов.

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

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

Если вы не можете чётко ответить на эти проверки, не идите дальше. Сначала исправьте роль, потом нанимайте.

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

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

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

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

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

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

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

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