Найм CTO для сервисного бизнеса с софтверной маржой

Почему маржа проседает в сервисной работе

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

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

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

Обычно ущерб появляется из-за небольшого набора привычек:

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

В одном аккаунте это может выглядеть нестрашно. Но на двадцати аккаунтах это способно полностью съесть прибыль.

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

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

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

Что должен закрывать этот CTO

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

Сначала delivery, потом код

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

Нужны и правила, которые удерживают delivery стабильным по мере роста объёма. Хороший CTO пишет простые правила релизов, определяет, кто утверждает изменения, и следит, чтобы кто-то быстро реагировал, если сломалась поставка, интеграция или клиентский workflow. Надёжность — часть этой работы. Если команда выпускает всё быстрее, но каждую пятницу чинит предсказуемые проблемы, маржа исчезает.

Ближе к бизнес-модели

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

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

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

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

Признаки того, что человек умеет упаковывать delivery в продукт

На минуту забудьте о красивых разговорах про архитектуру. Спросите, какую хаотичную клиентскую работу кандидат превратил в повторяемое предложение. Хорошие ответы звучат конкретно: «Мы сократили онбординг с 3 недель до 4 дней, потому что использовали одну и ту же форму входа, одну и ту же настройку проекта и одни и те же проверки качества». Слабые ответы остаются абстрактными.

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

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

Ещё вы должны услышать ясное понимание delivery. Разные люди в команде должны уметь повторить его по этапам. Переиспользование должно касаться не только кода, но и промптов, чек-листов, дашбордов и шагов QA. Хорошие кандидаты отслеживают cycle time, переделки и задержки на передачах, а не только оплачиваемые часы. Они могут объяснить, почему один стандартный процесс лучше десяти разовых исправлений.

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

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

Как он должен думать об автоматизации

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

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

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

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

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

Спросите, как человек измеряет результат. «Мы сэкономили время» — слишком расплывчато. Нужно говорить о сэкономленных часах на проект, уровне ошибок, объёме переделок, cycle time и о том, как часто сотрудники обходят автоматизацию, потому что она их замедляет. Переделки особенно важны. Если инструмент экономит 20 минут, но добавляет 40 минут на исправления, он провалился.

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

Как он защищает надёжность, когда всё меняется

Именно на изменениях многие сервисные компании спотыкаются. Новые инструменты, промпты и workflow могут экономить время, но могут и тихо ломать клиентскую работу. Хороший CTO не обещает идеальную стабильность. Он объясняет, как не даёт мелким сбоям превратиться в проблемы для клиента.

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

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

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

Это легко проверить несколькими вопросами на интервью:

• «Расскажите о релизе, который создал проблемы. Что вы сделали первым делом?»
• «Что вы мониторите, когда результаты уходят клиентам?»
• «Как вы откатываете изменение промпта, модели или workflow?»
• «Кто отвечает за инцидент в 10 вечера?»

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

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

Как провести найм и найти нужного человека

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

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

Лучше всего работает простой процесс. Дайте кандидату одну реальную проблему delivery из вашего бизнеса, но с достаточной детализацией, чтобы она была конкретной. Спросите, что он измерил бы первым и что оставил бы без изменений. Попросите 90-дневный план с компромиссами, затратами и вероятными рисками. Затем проведите второе интервью, посвящённое только uptime, инструментам, обработке инцидентов и командным процессам. Когда будете проверять рекомендации, спросите, что человек реально запускал, исправлял и улучшал под давлением.

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

Именно в 90-дневном плане обычно рассыпается пустая болтовня. Хорошие кандидаты делают выбор. Они могут сказать: «Сначала я бы автоматизировал онбординг, а кастомные дашборды отложил бы, потому что текущая отчётность некрасивa, но не сломана». Это показывает здравый смысл.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Короткий чек-лист перед оффером

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

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

Спросите, какие три процесса он стандартизировал бы в первые 90 дней. Хорошие ответы звучат конкретно: входящие клиентские запросы, настройка проекта, проверки QA, отчётность или передача между продажами и delivery. Спросите, где автоматизация должна остановиться. Разумный CTO не будет пытаться автоматизировать грязные исключения клиентов, чувствительные согласования или работу, которая всё ещё меняется каждую неделю. Спросите, как он объясняет uptime не техническому владельцу бизнеса. Он должен говорить простыми словами: что ломается, как быстро команда это замечает, как быстро восстанавливается и что видят клиенты, когда что-то идёт не так.

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

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

И ещё один момент: защищает ли он надёжность, когда меняет модель? Человек, который хочет перестроить всё сразу, обычно создаёт хаос. Более сильный CTO меняет один загруженный процесс, измеряет результат и защищает те части бизнеса, которые уже работают.

Такое мышление и приводит к софтверной марже в сервисном бизнесе. И именно оно спасает от дорогого найма, который громко говорит, а потом оставляет за собой беспорядок.

Что делать дальше, если нужна внешняя CTO-помощь

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

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

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

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

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

Если вам нужна внешняя помощь, в этой сфере работает, например, Oleg Sotnikov на oleg.is. Его опыт включает software engineering, роли CTO и founder, AI-first development, инфраструктуру и контроль затрат — всё это хорошо подходит сервисным компаниям, которым нужно стандартизировать delivery, не ломая то, что уже работает.

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