Оргструктура стартапа для команд до 20 человек: две понятные модели

Почему решения замедляются в маленьких командах

Команда из 8 или 12 человек должна двигаться быстро. На практике так бывает не всегда. Обычно причина проста: слишком много решений по-прежнему ложится на одного founder.

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

Команды часто усугубляют это, пытаясь обойти узкое место. Дизайнер спрашивает founder, инженер — product lead, а sales — того, кто последним что-то сказал на встрече. И каждый получает чуть разный ответ. Дело не в невнимательности. Просто структура расплывчатая, поэтому люди продолжают перепроверять, пока не услышат что-то, с чем можно работать.

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

Такой churn бьёт по маленьким командам сильнее, потому что одни и те же люди тянут несколько ролей сразу. Инженер может ещё отвечать за инфраструктуру. Founder может одновременно вести продукт. Маркетолог может помогать sales. Когда линии подчинения размыты, каждое решение втягивает в комнату двух или трёх человек там, где хватило бы одного.

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

Модель 1: структура с founder в центре

В структуре с founder в центре founders держат самые важные решения рядом с собой. Они определяют направление продукта, оценивают технические компромиссы и участвуют в найме. Большинство людей отчитываются одному founder или паре founders, даже если в ежедневной работе помогает senior engineer или designer.

Обычно схема простая: engineering, product и design отчитываются техническому founder или CEO, а sales, marketing и customer work — коммерческому founder. Founders также принимают финальное решение по новым наймам.

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

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

Стартап из семи человек может отлично работать именно так. Founder утром разговаривает с пользователями, после обеда говорит инженеру, какую фичу отложить, и успевает провести собеседование до конца дня. Ничто не застревает в очереди. Никто не думает, кто же всё-таки принимает финальное решение.

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

На бумаге это не выглядит изящно, и это нормально. Для маленькой команды, которая ещё ищет product-market fit, скорость важнее красивых линий подчинения. Когда founders остаются близко к работе, они могут удерживать движение решений, пока продукт ещё формируется.

Где структура с founder в центре ломается

Структура с founder в центре работает, когда команда совсем маленькая и продукт всё ещё меняется каждую неделю. Обычно она начинает буксовать, когда у founder становится восемь или больше direct reports. Тогда каждый вопрос попадает в один inbox, один чат или одну встречу.

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

Задержка усиливается, когда календарь founder уходит в сторону от delivery. Затянулся sales call. На две недели всё занял fundraising. Нужно внимание к нескольким hiring loops. Всё это само по себе нормально, но product decisions всё равно копятся. Senior engineer может знать лучший следующий шаг и всё равно ждать два дня одобрения.

Обычно момент, когда схема перестаёт работать, видно ещё до того, как он станет заметен на бумаге. Встреч становится больше, потому что людям нужен founder в комнате. Небольшие product calls превращаются в узкие места. Работа идёт рывками вместо ровного потока. Сильные сотрудники слишком часто спрашивают разрешения.

Самая дорогая часть — то, что происходит с ранними senior hires. Люди, которые пришли, чтобы владеть своей областью, начинают чувствовать себя курьерами. Они собирают контекст, предлагают решение, а потом всё равно ждут, пока founder примет решение. Хорошие люди долго в такой системе не держатся.

Именно здесь застревают сильные первые лиды. Head of engineering не может полностью владеть техническими решениями. Product person не может выбирать между scope и speed. Operations lead не может исправить процесс без обязательного согласования сверху.

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

Модель 2: структура с functional leads

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

Один человек отвечает за engineering, один — за product, и один — за sales или operations. Founders по-прежнему задают направление, выбирают большие ставки и решают, с какой скоростью должна расти компания. Но они больше не утверждают каждое мелкое решение.

Этот сдвиг важнее, чем сами коробочки на схеме. Если engineering lead по-прежнему должен просить founder одобрить каждый багфикс, каждый релиз или смену инструмента, команда всё так же будет ждать. То же самое относится к product и sales. Названия не помогают, если реальная власть по-прежнему застряла наверху.

Каждый lead должен управлять ежедневной работой в своей области. Engineering решает, как строится работа и когда старые системы надо приводить в порядок. Product решает, что движется первым, а что может подождать. Sales или operations отвечает за запросы клиентов, давление по срокам и внутренние процессы, не втягивая founders в каждую деталь.

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

Если клиент просит кастомную фичу, sales может проверить, реальный ли это запрос, product — оценить, подходит ли он продукту, а engineering — прикинуть объём работ в ту же неделю. Никто не ждёт два дня, пока founder ответит на обычный вопрос.

Эта модель хорошо подходит командам, которые планируют по неделям и делают достаточно повторяющейся работы, чтобы видеть закономерности. Она особенно полезна, когда у компании есть регулярные sales calls, предсказуемый product cycle и стабильный поток инженерных задач. Подходит она и тогда, когда на один пробел привлекают внешнего лидера, например Fractional CTO, который берёт на себя engineering, пока команда не готова к full-time lead.

Выбор здесь простой. Founders отдают часть контроля, а команда получает скорость.

Где структура с functional leads ломается

Схема с functional leads может выглядеть аккуратно на бумаге. Проблемы начинаются, когда команда ещё слишком мала, чтобы у каждого lead каждую неделю было достаточно настоящей управленческой работы.

Если один lead управляет только двумя людьми, роль может добавить ещё один слой, но почти ничего не прояснить. Вопросы идут вверх к lead, потом обратно к founder, а потом снова вниз. Команда из 12 человек начинает работать как команда из 50: решения принимаются медленнее, ожидания больше.

Это ломается и тогда, когда founders и leads тянут в разные стороны. Founder хочет выпустить сырую фичу за пять дней, потому что клиент ждёт. Engineering lead хочет сначала переписать часть системы. Marketing lead хочет более аккуратный план запуска. Каждый из этих goals по отдельности логичен, но маленькой команде редко хватает запаса, чтобы гнаться за всеми сразу.

Functional charts могут ещё и разрезать одну и ту же customer problem на аккуратные внутренние блоки. Sales думает о закрытии сделки. Product — о scope. Engineering — о качестве и скорости. Support — о тикетах. Но клиент видит один продукт, а не четыре функции. Когда каждый lead защищает свой участок, команда может пропустить настоящую проблему: signup слишком сложный, настройка занимает слишком много времени или один баг мешает продлениям.

Один слабый lead может навредить сильнее, чем ждут founders. В структуре с founder в центре слабый manager обычно влияет на несколько решений. В структуре с functional leads этот человек может замедлить целую функцию. Слабый engineering lead создаёт переделку для каждого разработчика. Слабый product lead наполняет roadmap недоделанной работой. И тогда founder тратит ещё больше времени на исправление решений, чем раньше.

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

Некоторые команды избегают этого, откладывая полноценные lead-roles до тех пор, пока нагрузка не станет реальной. Другие берут part-time leader для одной функции, а остальную команду оставляют более плоской. Часто это работает лучше, чем выдавать титулы до того, как у компании появится достаточный масштаб.

Как выбрать между двумя вариантами

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

Начните с простого упражнения. Выпишите решения, которые команда принимает за обычную неделю. Делайте это конкретно: изменения scope в продукте, исправления в production, обещания клиентам, найм, расходы на поставщиков и сроки релизов. Если какое-то решение возникает часто, а люди всё ещё спрашивают: «Кто это утверждает?», значит, схема уже сама вам что-то показывает.

Затем отметьте одного человека, который даёт финальный ответ по каждому решению. Одного человека, а не группу. Команды замедляются, когда три человека думают, что у них есть право вето. Если founders принимают большинство финальных решений, и команда при этом всё ещё двигается быстро, структура с founder в центре, возможно, пока подходит. Если решения уже принимаются внутри product, engineering, sales или operations, схема с functional leads обычно лучше.

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

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

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

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

Простой пример на 12 человек

Представьте стартап из 12 человек: два founders, шесть engineers, один designer, один product manager, один marketer и один customer success hire. Люди одинаковые в обеих версиях. Меняется только то, кто может сказать yes, кто может сам принимать мелкие решения и кто становится узким местом.

Модель с founder в центре

В первой модели founder CTO ведёт большую часть product и tech calls. Engineers идут к этому founder за компромиссами, архитектурными решениями и сроками релиза. Designer и product manager тоже втягивают этого founder в ежедневные решения, потому что design, scope и engineering тесно связаны.

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

Но напряжённый релизный месяц показывает слабое место. Customer success приносит три срочные проблемы от пользователей. Marketerу нужна точная дата запуска для кампании. Двум engineers нужен ответ по рискованному изменению backend. Designer хочет решение по срочному исправлению onboarding.

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

Модель с functional leads

Во второй модели engineering lead ведёт ежедневные engineering calls, а product manager — ежедневные product calls. Founder CTO по-прежнему отвечает за более крупные технические ставки, найм и долгосрочное направление, но больше не утверждает каждый мелкий шаг.

В тот же напряжённый релизный месяц customer success сначала отправляет пользовательские проблемы product manager. Product manager решает, какие проблемы обязательно идут в релиз, а какие могут подождать неделю. Engineering lead разбивает работу на части, защищает release branch и принимает обычные технические решения вместе с командой.

Marketer получает даты от product manager, а не гоняется за founder. Designer работает с product manager по scope и с engineering lead по реализуемости. Founder CTO подключается только к тем немногим решениям, которые действительно меняют план.

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

Ошибки, которые создают лишние задержки

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

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

Другая ошибка — слишком рано делать лучшего builder'а менеджером. Отличные исполнители часто быстро двигаются, потому что остаются близко к работе. Management — это другая работа. В ней нужны найм, обратная связь, планирование и умение говорить нет. Если человек по-прежнему тянет важную delivery work, страдают обе роли. Команда ждёт ответов, а новый manager застревает в встречах, которых на самом деле не хотел.

Частая смена линии отчётности тоже добавляет задержки. На одной неделе design отчитывается product. На следующей — founder. Потом engineering забирает design на один sprint. Люди перестают доверять схеме, потому что ожидают, что она скоро снова изменится. И каждое решение становится тяжелее, чем должно быть.

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

Команда из 12 человек чувствует это очень быстро. Если для одной фичи нужно, чтобы founder, product lead и tech lead все сказали yes, дата релиза начинает зависеть от календарей, а не от усилий.

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

Быстрая проверка вашей текущей схемы

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

Спросите пятерых людей, кто отвечает за roadmap, найм, incident response и pricing. Если ответы расходятся, значит, там, где важно, структура размыта.

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

Посчитайте direct reports у каждого manager. Если один человек не может встречаться с каждым хотя бы раз в неделю, люди начинают слишком долго ждать ответов.

Понаблюдайте за одним повторяющимся решением, например скидкой для клиента или датой релиза. Если оно всё время прыгает между product, tech и sales, линии подчинения слабые.

Маленькие признаки появляются раньше больших проблем. Разработчик идёт к product за решением по приоритету, product отправляет его к founder, а founder спрашивает sales за контекст. Такой круг может съесть два дня. Найм часто ломается так же. Один человек думает, что роль ведёт engineering, другой — что founder, и вакансия так и лежит нетронутой.

Incident response — ещё одна хорошая проверка. Во время outage люди должны знать, кто принимает решение, кто обновляет клиентов и кто решает, делать ли rollback. Если команда спорит о том, кто за что отвечает, прямо в середине проблемы, схема уже стоит вам времени.

Ещё один сигнал не менее важен: как часто одна и та же тема возвращается после того, как её вроде бы уже решили. Если pricing, scope или ownership каждую неделю открываются заново, значит, владелец на самом деле не определён.

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

Не тратьте месяц на обсуждение идеальной оргструктуры. Выберите одну модель и протестируйте её в течение одного planning cycle. Для большинства команд до 20 человек это две недели или один месяц. Этого достаточно, чтобы почувствовать трение, но не так долго, чтобы менять курс с драмой.

Запишите простыми словами, кто что решает. Без театра с job title. Запись вроде «Maya решает backend architecture» или «Dan approves pricing changes» работает лучше, чем расплывчатая коробочка на схеме. Поделитесь этой заметкой со всей командой, а не только с managers.

Короткого плана теста достаточно. Выберите схему, которую будете использовать в следующем cycle, и назначьте дату пересмотра. Назначьте одного владельца для product calls, одного для technical calls и одного для people calls, если это разные люди. Уберите встречи, которые существуют только потому, что никто не знает, кто может принять решение. Оставьте те, что снимают блокеры, помогают взвесить компромиссы или координируют работу между функциями.

Потом смотрите, где решения всё ещё тормозят. Если engineers продолжают ждать одобрения founder, вашей команде может понадобиться более чёткая technical ownership. Если product и engineering снова и снова открывают один и тот же спор, линии отчётности могут выглядеть аккуратно на бумаге, но не работать в реальной ежедневной работе.

Небольшой пример помогает. Если команда из 12 человек каждый день тратит по 30 минут на повторное обсуждение одного и того же решения между product и engineering, это примерно 10 часов в неделю, потерянных всей группой. Один более чёткий owner решения быстро возвращает это время.

Если после одного цикла беспорядок не уходит, может помочь внешний operator. Oleg Sotnikov at oleg.is работает со стартапами как Fractional CTO и advisor, помогая founders разобраться с технической ответственностью, архитектурными решениями и структурой команды, не превращая проблему маленькой компании в процесс большого бизнеса. Правильная схема — это та, которой команда действительно может пользоваться в понедельник утром.