Временный CTO перед наймом: наведите порядок в ответственности и рисках релизов

Почему кандидаты сомневаются, когда в команде нет ясности

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

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

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

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

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

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

Сначала разберите ответственность, потом добавляйте людей

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

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

Для первого прохода стоит включить такие продуктовые области, как онбординг, биллинг, админка и отчеты. Также стоит отметить системы вроде API, базы данных, CI/CD и продакшен-алертов, а еще регулярную работу: релизы, реакцию на инциденты, продление контрактов с вендорами и решения, которые затрагивают несколько команд.

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

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

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

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

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

Снизьте риски релизов до уровня, который команда может объяснить

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

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

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

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

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

План отката должен быть коротким. Команда должна без колебаний ответить на три вопроса: кто решает делать rollback, как именно это происходит и сколько времени это занимает. «Мы просто возвращаем последнюю стабильную версию и за 10 минут проверяем вход, оформление заказа и почту» — сильный ответ. «Обычно мы это чиним прямо на ходу» — нет.

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

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

Составьте список всех внешних вендоров, от которых зависит команда

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

Временный CTO должен быстро сделать это видимым. Начните с полного пути от кода до клиента. Включите хостинг, CI/CD, аналитику, email-доставку, дизайн-файлы, сервисы поддержки, инструменты безопасности, app store, платежные системы и любого агентства или фрилансера, который участвует в релизах.

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

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

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

Точно так же проверьте условия контрактов. Даты продления важны. Минимальные сроки важны. Автопродление важно. Продуктовая команда может застрять, оплачивая инструменты, которые уже не нужны, или внезапно обнаружить, что критический сервис нельзя изменить еще три месяца.

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

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

Приведите базу в порядок в простой последовательности

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

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

Затем приведите в порядок доступы до того, как трогать документы о процессе. Общие пароли в чате, старые подрядчики с админскими правами и потерянные логины для облака, хостинга кода, CI, мониторинга, доменов или app store могут полностью остановить команду. Наведение порядка в админ-доступах — скучная работа, но она убирает много скрытых рисков релиза.

Хорошо работает простой порядок:

1. Назначьте одного владельца на каждую систему и запишите это там, где команда сможет найти.
2. Перенесите пароли в нормальное хранилище и проверьте, что текущие руководители видят все админ-панели.
3. Выпустите один маленький релиз в рабочее время и по ходу зафиксируйте каждый шаг.
4. Найдите самый шумный вендорский риск, а затем уберите его, замените или снизьте зависимость продукта от него.
5. Превратите все это в короткий бриф для кандидатов, чтобы они увидели реальное состояние команды.

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

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

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

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

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

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

Временный CTO не начал с вакансий. Сначала он сделал ответственность видимой. Для каждого сервиса появился один владелец и один резервный человек. Резервный участвовал в разборе багов и ревью релизов. Runbook’и переехали из личных заметок в общие документы, а шаги деплоя перестали жить в памяти и превратились в короткий чек-лист.

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

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

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

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

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

Обычно именно после этого найм снова начинает работать.

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

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

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

Зависимость от вендоров часто спрятана на виду. Команда может полагаться на облачные аккаунты, инструменты мониторинга, CI-сервисы, платежные системы и софт поддержки, и при этом только один человек видит полную картину. Иногда это основатель. Иногда — операционный менеджер с одним перегруженным ящиком. Новый технический лидер мгновенно видит риск: нет общего доступа, нет календаря продлений и нет записи, почему инструмент оставляют или убирают.

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

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

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

Короткая проверка перед тем, как снова открывать найм

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

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

Перед тем как снова публиковать вакансию, команда должна уметь ответить «да» на эти пункты:

• У каждой продуктовой области есть один названный владелец, даже если работа все еще частично общая.
• Два человека могут выпустить срочный патч, не дожидаясь одного труднодоступного эксперта.
• Компания контролирует все логины вендоров, биллинг, контракты и путь восстановления доступа.
• Кандидат видит простой план на первые 90 дней с целями, поддержкой и одной-двумя ранними победами.
• Менеджер по найму может простыми словами объяснить путь релиза: от изменения кода до исправления в продакшене.

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

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

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

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

Что сделать перед тем, как снова говорить с кандидатами

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

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

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

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

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

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

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

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