Построение топ-команды: полный гайд для фаундера

1. Почему фаундеры собирают команды неправильно 2. Фреймворк CORE — базовая логика 3. C — Context: зачем команда существует 4. O — Ownership: кто за что отвечает по-настоящему 5. R — Rhythm: как команда принимает решения 6. E — Exit: когда и как расставаться 7. Как применять CORE пошагово 8. Интеграция с другими инструментами

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

В этом гайде — фреймворк CORE: четыре уровня, на которых фаундер либо собирает команду, либо коллекционирует людей. Context, Ownership, Rhythm, Exit. Каждый уровень — отдельный тип управленческого решения. Пропустишь один — остальные не держат.

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

Четвёртый раз за этот квартал вижу одну и ту же картину: фаундер с командой из пяти–восьми директоров, у каждого — своя версия того, куда идёт компания. Не потому что директора плохие. Потому что фаундер никогда не создавал архитектуру — он создавал должности.

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

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

Третья — откладывают «до масштаба». Логика такая: сейчас нас мало, структура не нужна, разберёмся по ходу. Масштаб наступает — и оказывается, что разбираться по ходу при выручке 300 миллионов стоит значительно дороже, чем при 80.

Прежде чем читать дальше — остановись на секунду. Вспомни последнее совещание с директорами. Сколько из них могли бы принять решение без тебя? Не «могли бы технически» — а реально приняли бы, не оглядываясь?

Если ответ неудобный — это нормально. Это отправная точка, не приговор.

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

Есть один способ выйти из этого круга. Не через делегирование — это слово уже затёрто до дыр. Через архитектуру.

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

C — Context. Зачем эта команда существует? Что изменится, если она проиграет?

O — Ownership. Кто за что отвечает по-настоящему — не по должностной инструкции, а в момент, когда что-то идёт не так?

R — Rhythm. Как команда принимает решения? Какие решения принимаются коллегиально, какие — единолично, какие — вообще не должны доходить до фаундера?

E — Exit. Когда и как человек покидает роль? Это плановый элемент системы или всегда кризис?

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

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

Если хочешь пройти диагностику своей команды по CORE — есть формат стратегического спринта на 90 минут. Разбираем все четыре уровня применительно к твоей конкретной ситуации. Пишу на hi@vvetrov.com.

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

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

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

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

Кейс. Андрей — фаундер производственного бизнеса, 12 лет в рынке, выручка около 300 миллионов. Пришёл с вопросом, который я слышу часто: «Почему директора не берут инициативу?» Мы разбирали это несколько сессий. Оказалось — он никогда не объяснял им, что будет, если компания проиграет конкурентам из Китая, которые зашли в его сегмент два года назад. Директора знали про конкурентов. Но не знали, насколько это серьёзно с точки зрения фаундера. Они думали — он справится. Он думал — они понимают масштаб угрозы.

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

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

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

Ответственность и исполнение — не одно и то же. Исполнитель делает работу. Владелец несёт последствия. В большинстве компаний с выручкой до 500 миллионов скрытым владельцем всего является фаундер — даже если в оргструктуре написано иначе.

Это не потому что директора слабые. Это потому что фаундер никогда не передавал владение — он передавал задачи. Разница принципиальная. Задача — это «сделай X к пятнице». Владение — это «ты отвечаешь за то, что в этой зоне всё работает, и я узнаю об этом последним, а не первым».

Простой тест: когда что-то идёт не так в зоне директора — кто первым об этом думает? Если фаундер — владение не передано.

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

1. Кто принимает финальное решение, если мнения расходятся? 2. Кто первым узнаёт, что что-то пошло не так? 3. Кто объясняет мне результат — не процесс, а результат?

Если на все три вопроса ответ «фаундер» — это не команда директоров. Это команда исполнителей с директорскими зарплатами.

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

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

Ритм — это не частота встреч. Это не «еженедельный стендап» и не «ежемесячный стратегический комитет». Ритм — это договорённость о том, какие решения принимаются как и кем.

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

Я разделяю решения на три типа.

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

Тип Б — тактические. Принимаются директором, но с уведомлением фаундера до исполнения. Не для согласования — для информирования. Фаундер может задать вопрос, но не имеет права вето, если директор объяснил логику.

Тип В — стратегические. Принимаются совместно. Фаундер — участник, а не арбитр.

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

Кейс. Михаил — фаундер IT-сервиса, шесть лет в рынке, выручка около 120 миллионов. Применил CORE частично: внедрил классификацию решений, провёл с командой разговор о ритме. Первые два месяца — заметное улучшение. Через четыре месяца ритм сломался. Директора принимали решения в правильном формате, но в разных системах координат: у каждого был свой ответ на вопрос «куда мы идём». Уровень Context был пропущен.

Пришлось откатиться. Это ограничение фреймворка, о котором важно говорить честно: CORE работает только последовательно. Начать с R, пропустив C, — значит построить механизм без цели.

Ритм также включает один элемент, который фаундеры почти всегда игнорируют: ритм разногласий. Как команда обсуждает то, с чем не согласна? Если ответ «никак» или «через фаундера» — это не команда, это совет директоров без права голоса.

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

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

Три сигнала, что человек вырос из роли — не стал хуже, именно вырос:

Первый. Его решения стали предсказуемыми до степени, когда его присутствие на совещании ничего не меняет.

Второй. Он перестал задавать неудобные вопросы. Не потому что всё хорошо — а потому что устал или перестал верить, что это что-то изменит.

Третий. Новые люди в команде — те, кого нанимали последние полгода — не идут к нему за советом. Они идут к фаундеру или к другим директорам.

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

Один коллега, партнёр по M&A-сделкам с которым мы работали над несколькими транзакциями, говорил мне: покупатели бизнеса первым делом смотрят не на P&L. Они смотрят на то, кто принимает решения в отсутствие фаундера — и что происходит, когда ключевой директор уходит. Если бизнес при этом останавливается — его стоимость падает вне зависимости от финансовых показателей.

Exit — это не конец. Это часть архитектуры.

Фреймворк не внедряется за одну сессию. Реалистичный горизонт — три–четыре месяца при условии, что фаундер готов к неудобным разговорам.

Шаг 1. Диагностика текущей команды — четыре вопроса.

Задай их себе письменно, без команды:

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

Если хотя бы на два вопроса ответ «нет» или «не уверен» — начинай с C.

Шаг 2. Последовательность внедрения.

C → O → R → E. Только так. Не параллельно, не с того уровня, который кажется проще.

C занимает обычно один–два разговора с командой плюс время на то, чтобы формулировки устоялись. O — это серия индивидуальных разговоров с каждым директором, от двух недель до месяца. R — командная договорённость, которую нужно зафиксировать письменно и проверить через 30 дней. E — это не разговор, это политика, которую нужно встроить в найм и в ежегодные ревью.

Шаг 3. Ограничения и противопоказания.

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

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

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

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

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

С диагностики уровня C. Попроси каждого директора письменно ответить на вопрос: «Что изменится для компании, если мы проиграем конкурентам через три года?» Сравни ответы. Если разброс большой — начинай с контекста, даже если кажется, что это «мягкая» работа. Без общего понимания угрозы остальные уровни не держат.

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

При условии, что фаундер готов к неудобным разговорам и не откатывается при первом сопротивлении — три–четыре месяца до устойчивого состояния. Первый месяц — работа с контекстом. Второй — с владением. Третий — с ритмом. Exit встраивается в процессы постепенно. Быстрее не бывает — если бывает, значит что-то пропущено.

В начале я написал, что большинство фаундеров строят топ-команду задом наперёд. Теперь ты видишь, в чём именно: они начинают с людей, а не с архитектуры. Нанимают сильных — и удивляются, что сильные не складываются в систему.

CORE — это не гарантия. Это структура, которая делает ошибки видимыми раньше, чем они становятся дорогими.

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

Не «справятся ли люди технически». А что реально произойдёт. Где возникнут дыры. Какие решения зависнут. Кто начнёт тянуть одеяло.

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

Это решаемо. Но только если называть вещи своими именами.

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

Это не подойдёт, если ты только формируешь команду с нуля, если выручка ниже 80 миллионов или если ты ищешь HR-консультанта для подбора. Это подойдёт, если у тебя есть команда, которая работает, но не как система — и ты понимаешь, что дальше так не масштабируется.

Беру не более четырёх advisory-клиентов одновременно.

Напиши на hi@vvetrov.com: кто ты, размер бизнеса, в чём конкретно вопрос с командой. Отвечаю лично.

P.S. Если задача не моя — скажу честно и порекомендую, к кому идти.

Май 2026. Автор — Виталий Ветров, стратегический советник для предпринимателей.