Повысить инженера или нанять fractional CTO для команды

Какую проблему вы пытаетесь решить

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

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

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

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

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

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

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

Что меняется, когда сильный инженер становится CTO

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

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

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

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

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

Меняется и работа с конфликтами. Продукт хочет скорость. Инженеры хотят времени. Sales хочет обещаний. Support хочет меньше пожаров. CTO должен выслушать всех, принять решение и объяснить его так, чтобы не затянуть компанию в бесконечные споры.

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

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

Сначала проверьте decision load

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

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

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

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

Особенно быстро проблему раскрывают изменения roadmap, production-инциденты и решения по подрядчикам. Если roadmap меняется каждую неделю, потому что sales, product и engineering тянут в разные стороны, кому-то нужно владеть компромиссами. Если инциденты затягиваются, потому что инженеры ждут подтверждения, кому-то нужна понятная власть принимать решение. Если выбор подрядчиков тянется месяцами, значит, никто не отвечает за стоимость, риск и сроки.

Самая полезная находка часто оказывается неловкой: набор решений, за которые никто явно не отвечает. Этот пробел может быть между engineering и product, между infrastructure и security или между основателем и командой. Повышенный инженер может вырасти в этот участок. А может, компании нужен fractional CTO, который уже работал с наймом, архитектурой, операциями и коммуникацией с основателем.

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

Смотрите не только на код, но и на пробелы в найме

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

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

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

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

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

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

Честно оцените зависимость от основателя

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

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

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

Также смотрите, кто объясняет компромиссы за пределами инженерной команды. Когда клиент спрашивает: «Сможете ли вы выпустить это к следующей неделе, если мы уберём X?», кто отвечает уверенно? Когда инвестор спрашивает, почему roadmap сдвинулся, кто связывает воедино продукт, найм и поставку простым языком? Сильные инженеры часто хорошо понимают техническую часть, но они могут пока не хотеть вести такие разговоры.

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

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

Если ваша реальная цель — быстро снизить эту зависимость, fractional CTO может решить задачу лучше, чем внутреннее повышение.

Используйте простой процесс принятия решения

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

Помогает простая схема оценки:

1. Составьте список того, что компания должна выпустить, исправить, нанять и стабилизировать в течение следующего года. Включите сроки по продукту, рост команды, изменения в архитектуре, крупные запросы клиентов и проблемные зоны вроде безопасности, надёжности или скорости поставки.
2. Оцените внутреннего кандидата по работе с людьми, планированию и здравому суждению. Используйте простую шкалу от 1 до 5. Навык программирования важен, но он не должен определять всё решение.
3. Запишите пробелы, которые нельзя оставлять ещё на год. Будьте прямыми. Возможно, никто не умеет хорошо нанимать senior-инженеров. Возможно, никто не владеет компромиссами в архитектуре. Возможно, основатель всё ещё принимает каждое сложное техническое решение.
4. Сравнивайте реальные варианты, а не идеальные. Смотрите на полноценный наём executive и fractional CTO рядом. Сравните стоимость, время входа, объём ответственности и то, сколько времени основателя каждый вариант действительно освободит.
5. Назначьте дату пересмотра до того, как примете решение. Девяносто дней подойдут для пробного повышения. Шесть месяцев — для внешней поддержки или более крупного изменения структуры.

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

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

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

Простой пример стартапа

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

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

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

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

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

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

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

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

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

Ещё одна ошибка — оставлять тот же объём кодинга после смены должности. Сильный инженер может целый день писать код или хорошо вести команду. Делать и то и другое долго обычно не получается. Встречи множатся. Найм занимает время. Компромиссы по продукту накапливаются. Инциденты всё равно случаются. Вскоре новый CTO работает по ночам, чтобы не отстать, а у команды всё ещё нет ясного направления.

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

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

Простой пример показывает, как это ломается. Основатель повышает своего лучшего backend-инженера после тяжёлого релизного цикла. Через три месяца этот человек по-прежнему владеет самыми сложными сервисами, по-прежнему проверяет половину pull request'ов и теперь ещё отвечает за найм и планирование. Ничего не получает должного внимания. Основатель решает, что «повышение не сработало», хотя настоящая проблема была в дизайне роли.

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

Быстрая проверка перед тем, как решать

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

Короткая интуитивная проверка помогает:

• Снизит ли это решение количество согласований с основателем в течение 90 дней?
• Умеет ли этот человек хорошо нанимать, развивать других и принимать трудные решения, когда кто-то работает слабее нормы?
• Нужна ли вам помощь на короткий период или постоянный executive?
• Если что-то пойдёт не так, может ли компания позволить себе задержку и расходы?
• Пока кто-то входит в leadership, кто будет каждую неделю держать поставку под контролем?

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

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

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

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

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

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

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

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

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

Fractional CTO имеет смысл, когда команде не хватает executive-опыта, основатель по-прежнему тянет на себе слишком много продуктовых и delivery-рисков, или найм буксует уже несколько месяцев. Постоянный executive имеет смысл, когда роль уже широкая, долгосрочная и чётко определённая.

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