Пересмотр роли технического сооснователя по мере роста компании

Когда старая договоренность перестает работать

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

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

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

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

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

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

Простой пример: два основателя много лет назад договорились, что технический сооснователь «отвечает за технику». Потом в компании появились руководители инженеров, продуктовый лидер, внешние инвесторы и корпоративные клиенты. Теперь CEO ждет предсказуемых планов, а технический основатель по-прежнему действует так, будто все решения должны оставаться неформальными. Даже при добрых намерениях это создает напряжение.

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

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

Что изменилось в компании

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

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

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

Зафиксируйте текущую работу на бумаге

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

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

Полезно посмотреть на это через короткое сравнение:

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

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

Определите, какая роль нужна сейчас

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

Выберите одну главную задачу

Сначала честно назовите настоящую работу на ближайший год.

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

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

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

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

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

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

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

Разберитесь с подчинением и решениями

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

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

• Продукт: кто решает по дорожной карте, объему и компромиссам при выпуске
• Инженерия: кто решает по архитектуре, процессу поставки и техническим стандартам
• Бюджет: кто утверждает найм, инструменты, подрядчиков и крупные расходы
• Найм: кто открывает вакансии, кто выбирает финального кандидата и кто может наложить вето

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

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

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

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

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

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

Пересмотрите ответственность, оплату и титул

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

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

Помогает простое разделение:

• Сохраняйте уже вестированную долю отдельно от новых обязанностей.
• Назначайте будущую зарплату или оплату подрядчика исходя из текущей роли.
• Любые новые доли привязывайте только к будущей работе и понятным этапам.
• Все изменения фиксируйте письменно с датой вступления в силу.

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

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

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

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

Зафиксируйте изменения письменно

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

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

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

Пошагово проведите разговор о перезапуске

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

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

Используйте простой порядок и не уходите с него:

• Соберите факты в один документ. Покажите, кто чем решает сегодня, кому кто подчиняется, где задачи пересекаются и где срываются сроки.
• Начните встречу с бизнес-проблемы. Например: релизы задерживаются, инженеры получают противоречивые указания или сооснователь по-прежнему делает то, что должно быть у менеджера.
• Задайте каждому основателю три прямых вопроса: что вы хотите сохранить, от чего хотите отказаться и что может взять на себя кто-то другой?
• Запишите новую роль до конца встречи. Сделайте ее на одной странице: зона ответственности, права на решения, подчинение, титул, оплата и любые изменения в долях, которые еще нужно проверить юридически.
• Назначьте дату пересмотра через 30–60 дней. Это даст новой схеме время показать себя и не позволит тому же спору снова вспыхнуть уже на следующей неделе.

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

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

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

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

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

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

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

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

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

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

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

Ошибки, которые снова разжигают спор

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

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

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

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

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

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

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

Быстрая проверка и следующие шаги

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

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

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

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

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

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

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

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