Условия вестинга для технического сооснователя, которые соответствуют реальной работе

Почему копированные условия вестинга не работают

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

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

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

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

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

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

Люди копируют условия у другого стартапа, потому что это кажется простым и справедливым. Это действительно просто. Но справедливость — совсем другой вопрос. Аккуратный документ не исправит плохое соответствие между долей и усилиями.

Что на самом деле должен покрывать пакет

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

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

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

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

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

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

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

Отделите долю от роли и оплаты

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

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

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

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

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

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

Пропишите роль по этапам

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

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

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

Как выстраивать условия шаг за шагом

Начинайте со следующих 12–18 месяцев, а не с чужого шаблона. Цель — сопоставить передачу доли с той работой, которую действительно нужно сделать до того, как компания станет по-настоящему живой.

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

Хорошо работает простой процесс:

1. Посмотрите на компанию такой, какая она есть сейчас. Есть только идея или уже есть прототип, пользователи или выручка? Зафиксируйте это простыми словами, потому что стартовая точка меняет риск для обеих сторон.
2. Оцените объем работы, который нужен, чтобы дойти до следующей устойчивой точки. Обычно это запуск, первые отзывы клиентов, первый стабильный релиз и первый или второй найм. Будьте честны по срокам. Одновременно строить продукт и нанимать людей легко может удвоить нагрузку основателя.
3. Выберите период вестинга, который соответствует этому плану. Четыре года — частый вариант, но распространенность не означает правильность. Если основная ценность создается в первые 18 месяцев, четырехлетний срок все еще может подойти, но вы должны понимать почему.
4. Добавьте клифф только если оба основателя согласны с этим компромиссом. Годовой клифф защищает компанию, если кто-то уходит рано, но он же повышает личный риск для основателя, который занимается первым тяжелым этапом. Если это кажется перекошенным, сократите срок или уберите его.
5. Пропишите точки пересмотра до того, как кто-то подпишет документ. Назначьте даты, укажите, что именно вы будете проверять, и что не меняется без согласия обоих. Хорошие точки пересмотра всегда конкретны: продукт запущен, ядро системы стабильно, первые инженеры наняты, передача работает.

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

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

Когда вехи помогают, а когда вредят

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

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

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

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

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

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

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

Простой пример с двумя основателями

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

Они не копируют ровную сделку 50/50. Майя приносит идею, доступ к клиентам и первый путь к выручке. Лео сразу берет на себя риск исполнения. Их условия вестинга соответствуют этой комбинации, а не делают вид, что обе роли одинаковые.

Они договариваются о простой структуре:

• Майя получает 55% с вестингом на четыре года и годовым клиффом.
• Лео получает 35% по тому же графику за владение поставкой продукта, качеством кода, безопасностью и запуском v1.
• Лео может заработать еще 10%, если он наймет первых двух инженеров, выстроит процесс в команде и будет удерживать поставку в графике шесть месяцев подряд.

Эти дополнительные 10% — не награда просто за усилия. Это оплата за больший объем работы. Найм требует времени, здравого суждения и переделок, если первые люди не подошли. Если Лео хорошо соберет первую инженерную команду, он изменит компанию надолго.

Они также прописывают в соглашении даты пересмотра. Через 90 дней они проверяют, не изменился ли объем продукта относительно исходного плана. На запуске они смотрят, сделал ли Лео v1 и превратила ли Майя ранние разговоры с клиентами в реальные контракты. На 12-м месяце они решают, действует ли еще веха по найму и заработал ли Лео дополнительную долю.

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

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

Частые ошибки, которые рождают обиду

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

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

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

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

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

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

Быстрая проверка перед подписанием

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

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

Перед подписанием ответьте на пять простых вопросов:

• Могут ли оба основателя объяснить, кто что получает, когда это вестится, что может остановить вестинг и что произойдет, если кто-то уйдет?
• Соответствует ли вестинг той работе, которая ожидается в ближайшие 12–24 месяца, а не какому-то расплывчатому долгосрочному плану?
• Вы отдельно прописали, кто владеет кодом, кто обязан нанимать и кто обязан поставить продукт в реальные сроки?
• Вы указали, что меняется после привлечения денег, после серьезного изменения объема работ или после срыва плана?
• Каждый основатель получил отдельную консультацию до подписания, даже если финальная сделка осталась той же?

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

Жестко пропишите границы в черновике. Укажите, кто контролирует репозиторий, кто может одобрять изменения в продакшене, обязан ли технический сооснователь управлять наймом и что именно считается поставкой. Формулировка «помогать с продуктом» слишком мягкая. «Владеть архитектурой, выпустить MVP к шестому месяцу, нанять первого backend-инженера к девятому» — уже понятно.

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

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

Что делать дальше

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

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

Короткий процесс лучше длинного спора. Запишите роль, объем времени и ожидаемую работу на первые 6–12 месяцев. Привяжите передачу доли к этому реальному объему, а не к копированному графику. Добавьте условия, при которых пакет может измениться, например, срыв найма, поворот продукта или переход с полной занятости на частичную. Потом попросите обоих основателей прочитать это отдельно и сравнить, в чем они не согласны.

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

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

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

Один короткий меморандум сегодня может сэкономить месяцы потерь потом.