Когда молодой SaaS-компании нужен CTO?

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

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

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

Начните с решений, за которые кто-то должен отвечать

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

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

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

Ищите совокупность признаков, а не очередной раунд финансирования

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

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

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

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

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

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

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

Предоставьте руководителю полномочия, факты и понятный порядок работы

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

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

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

Избегайте распространённых ошибок при найме CTO

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

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

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

Пересматривайте формат технического руководства вместе с изменениями компании

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

Назначьте дату пересмотра в соответствии с задачей: часто после первых 30, 60 и 90 дней, а затем ежеквартально. Спросите, какие решения стали понятнее, как изменился риск, что команда теперь умеет делать без руководителя, где полномочия по-прежнему неясны и соответствует ли выделенное время объёму работы. Завершите явным решением: продолжить сотрудничество, изменить задачу, увеличить или уменьшить занятость, передать ответственность, начать поиск штатного руководителя или завершить работу.

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

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