В продолжение проблематики оргдизайна:

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

Логичный вывод: «Работает. Берем еще 20 человек и делаем х2».

Через полгода людей 35. Только теперь собственник согласует уже не 10 вопросов в день, а 40. Аккаунт обещает клиенту одно, креатив понял другое, проектный менеджер узнал об изменениях последним, работа возвращается на третью переделку. Выручка вроде выросла. Маржа — почему-то нет. Сюрпрайз :)

Вот примерно в этот момент обычно начинают искать «более сильных руководителей». Хотя проблема может быть вообще не в людях.

Проблема в том, что модель компании была рассчитана на 12 человек, а ее просто растянули на 35.

Так что же проверять до масштабирования?

1. Что конкретно мы хотим умножить? У Джея Гэлбрейта в Star Model есть простая логика: стратегия, структура, процессы, люди и мотивация должны соответствовать друг другу. Например, агентство решило расти за счет крупных клиентов. Тогда мало поставить план продаж х2. Крупный клиент означает более сложные проекты, больше согласований, другие требования к управлению проектами и, возможно, совсем другую экономику. Если продажи уже перестроили, а производство услуги осталось прежним — вы масштабировали только входящий поток проблем.

Маячок: понятно, откуда должен прийти рост и какие процессы должны измениться вместе с ним.

2. Прогнать один заказ через компанию "от начала до денег" McKinsey в современной модели Organize to Value предлагает смотреть не столько на квадратики оргструктуры, сколько на то, как в компании реально создается ценность. Возьмем тот же проект. Клиент согласовал концепцию → аккаунт передал ее креативу → собственник внес правки → клиент изменил задачу → производство переделало → финансы обнаружили, что дополнительную работу никто не посчитал. Проект прибыльный? В Excel — да. По факту половину маржи съели переделки. Вот где начинается оргдизайн.

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

3. Посмотреть, где в процессе собственник Есть прекрасный RAPID от Bain — инструмент распределения ролей в принятии решений. Допустим, крупный клиент просит нестандартный проект со скидкой. Продажи хотят подписать. Производство говорит: ресурсов нет. Финансы не понимают экономику. И все идут к собственнику. Он решает. НО На 12 сотрудниках — работает. На 100 — собственнику понадобится клонирование.

RAPID заставляет заранее определить, кто готовит решение, кто дает данные, кто согласует, кто исполняет и кто принимает финальное решение.

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

4. Проверить, сколько вашей компании нужно самой компании У Team Topologies есть важная идея: команда должна получать посильный объем задач и зависимостей и иметь возможность достаточно автономно доводить работу до результата. Например, продуктовая команда может состоять из прекрасных специалистов. Но если для каждого релиза ей нужны аналитик из одного отдела, дизайнер из второго, архитектор из третьего, согласование четвертого и финальное «добро» пятого — проблема не обязательно в скорости команды.

Вы так спроектировали работу.

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

И только после этого я бы спрашивал: «Сколько людей нам нужно нанять?»

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

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