Эффективность фракционного CTO: сигналы основателя, которые важны

Почему внешняя работа CTO буксует

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

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

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

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

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

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

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

Какие сигналы ускоряют работу

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

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

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

С цифрами нужна та же честность. Основатели иногда откладывают показ выручки, burn, runway или затрат на команду, потому что хотят сначала «причесать» картину. Обычно это оборачивается против них. Внешний CTO может принимать лучшие решения с грубой правдой, чем с красивой историей, которая скрывает давление.

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

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

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

Дайте доступ в первый день

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

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

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

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

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

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

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

Выведите честные цифры на стол

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

Начните с runway в месяцах. «Нам хватит примерно на 7 месяцев» гораздо полезнее, чем «пока все нормально». Внешнее техническое руководство принимает лучшие решения, когда понимает, может ли компания исправлять все постепенно, нанять одного человека или ей нужно жестко сокращать уже на этой неделе.

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

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

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

Даже грубого среза достаточно, чтобы начать принимать хорошие решения:

• Runway: 8 месяцев
• Фонд оплаты труда: 58 тыс. долларов в месяц
• Подрядчики: 14 тыс. долларов в месяц
• Инструменты и инфраструктура: 9 тыс. долларов в месяц
• Конверсия от регистрации к оплате: 3,4%
• Месячный отток: оценочно 6%
• Среднее время выпуска функции: 12 дней

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

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

Назначьте одного человека для решений

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

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

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

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

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

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

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

Как должен пройти первый месяц

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ошибки, которые сжигают первый месяц

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

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

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

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

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

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

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

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

Короткая проверка перед стартом

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

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

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

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

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

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

Что делать после проверок

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

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

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

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

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

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

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