Шаги выхода из операционки для сооснователя в IT-компании

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

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

1. Почему сооснователь — не просто «занятой CEO» 2. Диагностика: где именно ты застрял 3. Шаг 1. Инвентаризация роли 4. Шаг 2. Построение операционной независимости команды 5. Шаг 3. Переход от исполнителя к архитектору 6. Типичные ошибки при выходе из операционки

Третий раз за последние полгода вижу одну и ту же картину: сооснователь IT-компании, который формально не CEO, но де-факто закрывает все дыры в операционке. Иногда у него есть партнёр, который занимается бизнесом. Иногда он сам и технический директор, и последняя инстанция по продуктовым решениям. Иногда — просто человек, без которого ничего не движется.

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

Когда компания запускается, сооснователь-технарь делает единственное разумное: берёт на себя всё, что умеет лучше других. Он принимает решения быстро, потому что держит контекст в голове. Он не объясняет — он делает. Это работает на старте. Потом компания вырастает, а архитектура остаётся прежней. Только теперь вместо 3 человек — 30, и каждый из них всё равно идёт к нему.

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

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

Это и есть исходная точка. Не «как делегировать», а «что именно держит тебя внутри».

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

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

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

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

Здесь обычно возникает возражение: «У меня всё три зоны одновременно — с чего начинать?» Это обоснованное ощущение. Но оно обманчиво. Если посмотреть внимательно, одна из зон всегда держит сильнее остальных — и именно она блокирует движение в других. Начни с неё.

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

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

Сначала — диагностика. Потом — шаги.

Это не тайм-менеджмент. Это диагностический инструмент.

В течение двух рабочих недель фиксируй каждое действие, которое занимает больше 15 минут. Не планируй — фиксируй постфактум. Формат простой: что сделал, сколько времени, почему именно ты. Третий столбец — самый важный.

После двух недель у тебя будет список из 80–120 позиций. Раздели их на три категории.

Только я. Задачи, которые объективно требуют твоего участия — потому что ты носитель уникального контекста, отношений или полномочий. Таких будет меньше, чем ты думаешь. Обычно 15–20% от списка.

Мог бы другой. Задачи, которые ты делаешь сам — но мог бы не делать, если бы кто-то другой имел нужный контекст или полномочия. Это самая большая категория. Здесь живёт основной потенциал для выхода.

Вообще не нужно. Задачи, которые ты делаешь по инерции, из привычки или потому что «так исторически сложилось». Они не создают ценности ни для компании, ни для тебя. В любом списке их 10–15%.

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

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

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

Самая распространённая ошибка на этом шаге — путать «дать задачу» и «передать контекст». Это разные операции с разными результатами.

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

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

Практический инструмент — три уровня полномочий.

Уровень 1: действуй и сообщи. Человек принимает решение самостоятельно и информирует тебя постфактум. Это для задач с низким риском и высокой частотой.

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

Уровень 3: принесите мне варианты. Ты принимаешь решение сам, но на основе анализа, который сделала команда. Это для стратегических или необратимых решений.

Задача выхода из операционки — последовательно переводить задачи с уровня 3 на уровень 2, с уровня 2 на уровень 1. Не все сразу. По одной зоне за раз.

Из практики. Антон и Михаил — сооснователи B2B SaaS-компании, около 50 человек. Антон — технический, Михаил — коммерческий. Компания выросла до приличного размера, но каждое архитектурное решение по продукту проходило через Антона. Не потому что он хотел контролировать — просто никто другой не мог принять такое решение без риска сломать что-то важное.

Мы не начали с найма CTO. Мы начали с шести недель документирования: Антон фиксировал не решения, а логику решений. Почему именно такая архитектура. Какие компромиссы были приняты и почему. Какие принципы нельзя нарушать. Это не было красиво оформлено — это были заметки в Notion, голосовые сообщения, разборы конкретных кейсов.

Через шесть недель у команды появился не «директор вместо Антона», а база знаний, которая позволяла принимать 70% архитектурных решений без него. Оставшиеся 30% — те самые «только я» — он всё ещё закрывал. Но это уже была другая нагрузка.

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

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

«Роль архитектора» — это не метафора про стратегическое мышление. В IT-контексте это конкретный набор действий, которые отличаются от операционных.

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

Как выглядит переход на практике? Три маркера.

Маркер 1: твоё расписание изменилось. Не «стало меньше встреч», а изменилась структура. Раньше — реакция на входящие. Теперь — проактивные блоки на стратегические задачи. Если расписание по-прежнему формируется входящими — ты ещё не вышел.

Маркер 2: команда принимает решения, о которых ты узнаёшь постфактум. И это не вызывает у тебя тревоги. Тревога — это сигнал, что передача контекста не завершена или полномочия не подтверждены.

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

Теперь — про то, как не скатиться обратно. Это случается почти всегда, и обычно — через 2–3 месяца после того, как кажется, что всё получилось. Механизм простой: возникает кризис, ты «временно» возвращаешься в операционку, чтобы его разрулить. Потом ещё один кризис. Потом ещё. Через полгода ты снова внутри.

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

Подробнее о метриках, которые показывают реальный прогресс выхода — в материале «Метрики контроля при выходе из операционки».

Ошибка первая: нанять директора и уйти.

Это самый распространённый сценарий — и самый дорогой. Сооснователь находит сильного операционного директора, передаёт ему формальные полномочия и пытается выйти. Через 3–6 месяцев директор либо уходит, либо компания начинает буксовать.

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

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

Ошибка вторая: делегировать задачи, не передав полномочия.

Это тонкая ловушка. Ты передаёшь задачу, но оставляешь за собой право отменить решение. Формально — делегирование. По факту — иллюзия. Команда быстро понимает, что реальные полномочия остались у тебя, и перестаёт принимать самостоятельные решения. Зачем рисковать, если всё равно придёт и переделает?

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

Ошибка третья: выйти слишком быстро.

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

Медленный выход — 6–12 месяцев последовательной передачи контекста и полномочий — почти всегда надёжнее быстрого. Не потому что нужно тянуть. А потому что система должна успеть перестроиться под новую архитектуру.

Подробный разбор ошибок с примерами — в материале «Ошибки при выходе из операционки: топ-5 от советника».

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

Это переговорная задача, а не управленческая. Партнёр, скорее всего, либо не видит проблемы (потому что система работает), либо боится, что выход одного изменит баланс в паре. Разговор должен начинаться не с «я хочу меньше работать», а с «вот что происходит с компанией, пока я в операционке, и вот что станет возможным, если я выйду». Разные рамки — разный разговор.

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

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

И тот вопрос, который я обещал в начале. Я спрашиваю каждого сооснователя: «Если ты уедешь на месяц без связи — что произойдёт с компанией?» Большинство отвечают: «Всё сломается». Некоторые говорят: «Ничего страшного». Готов к выходу тот, кто отвечает: «Не знаю — и это меня беспокоит». Потому что именно это незнание — сигнал, что система уже начала работать без тебя, но ты ещё не убедился в этом достаточно.

Если ты сооснователь IT-компании и узнал себя в этом тексте — скорее всего, вопрос не в том, как делегировать. Вопрос в том, что именно держит тебя внутри.

Работаю с фаундерами и сооснователями IT-компаний с выручкой от 80 миллионов рублей. Не с теми, кто хочет «разобраться в себе» — с теми, у кого есть конкретная операционная задача и понимание, что решать её нужно системно.

Беру не более 3 новых клиентов в месяц.

Напиши на hi@vvetrov.com: кто ты, что за компания, в чём застрял. Коротко — достаточно трёх предложений.

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

P.S. Если не подхожу — скажу честно и объясню, к кому имеет смысл идти.

Также — в моём Telegram разбираю похожие ситуации без воды: конкретные кейсы, инструменты, наблюдения из практики. Ссылка: t.me/vvetrov.

Июнь 2026. Автор — Виталий Ветров, эксперт по выходу из операционки.