Когда компания быстро растёт, она испытывает стресс
Когда компания растёт быстро, она подвергается стрессу. Чем быстрее рост, тем больше стресса.
Структура может улучшить ситуацию, но только если она правильно разработана для роста. Хорошая структура обеспечивает каркас, который позволяет вашей организации расти. Плохая структура может усугубить положение.
Структурные решения имеют решающее значение для бизнеса. Они могут сделать компанию или разрушить её. Если успех вашей компании зависит от эффективного роста, вам нужно правильно всё организовать.
Определите структуру вашей организации
Существует множество способов организации разработки продукта. Два подхода, которые стоит рассмотреть:
Модель триады.
Каждая функция (инженерия, продукт и дизайн) имеет свою структуру отчётности и организацию. Они работают вместе как равные.
Модель генерального менеджера. Каждая организация возглавляется генеральным менеджером (GM), который отвечает за все функции в своей организации. Это также известно как модель «Единый владелец».
Обе модели одинаково хорошо подходят для масштабирования вашей организации. Однако если вы не определите свою структуру, это может помешать вашему росту. Я часто вижу компании, где различные функции противоречат друг другу. Когда у вас нет согласованного способа взаимодействия друг с другом, вы добавляете трения в свой рост.
Поскольку модель триады более распространена, остальная часть этого поста отражает советы по масштабированию в рамках модели триады. Компромиссы для модели генерального менеджера описаны в моём посте-ретроспективе о внедрении модели единого владельца Amazon.
Организуйте кросс-функционально в рамках инженерии, внедрите продукт и дизайн
Инженерам свойственно организовывать свою работу по функциональному принципу. Например, команды Frontend и Backend. Это может показаться естественным, потому что именно так инженеры часто думают о своей работе. И инженеры склонны выстраивать свою идентичность вокруг своих ролей как Frontend Engineers или Backend Engineers. Поэтому они ожидают наличия Frontend команд и Backend команд.
Хотя можно заставить это работать, у такого подхода много недостатков:
- Увеличение зависимостей между командами, что приводит к плохому исполнению.
- Увеличение сложности вашей организации (которая усугубляется по мере роста).
- Увеличение потребности в коммуникации.
Каждая команда должна стремиться быть в состоянии приносить бизнес-ценность без привлечения других команд. Поэтому по умолчанию вы должны организовывать команды кросс-функционально и организовывать их по функциональному принципу только тогда, когда это не работает.
Это подтверждается в книге Team Topologies — определяющей книге по организационному дизайну в инженерных командах. Если вы сомневаетесь в моей рекомендации, прочитайте эту книгу.
В большинстве случаев вы должны делать вид, что дизайн и продукт являются частью команды. Внедрите дизайнера и менеджера по продукту в каждую команду. Для глубокого погружения в то, как добиться успеха с внедрением, см. моё руководство для счастливого внедрения.
Бывают случаи, когда внедрение не имеет смысла. В этом случае список способов координации групп людей можно увидеть в моём списке моделей координации.
Иногда может помочь, если дизайн подчиняется продукту
Что касается структуры отчётности, я часто рекомендую, чтобы дизайн подчинялся продукту. Это трюк, которому я научился у лидера дизайна. Они использовали этот подход, чтобы помочь дизайну быть более эффективным. Отчитываясь перед продуктом, он заставил команду продукта проделать работу, чтобы согласовать себя с дизайном.
Помимо этого, руководство триады может отчитываться перед генеральным директором, директором по продукту (CPO) или вице-президентом/руководителем отдела разработки продукта.
Постоянно совершенствуйте процесс адаптации и определяйте роли
В условиях экстремального роста плохой процесс адаптации может привести к организационному сбою. Если вы удвоитесь в размере за шесть месяцев, а на адаптацию уйдёт шесть месяцев, вы потеряете позиции. В конечном итоге у вас будет уменьшающийся процент организации, которая прошла адаптацию с течением времени.
Это одна из причин, по которой умные лидеры инвестируют в эффективную адаптацию и проводят структурную работу, чтобы упростить адаптацию.
Одним из примеров структурной работы, которая помогает в адаптации, является определение ролей. Определите, какой тип менеджера по инженерии у вас есть (ожидания компаний значительно различаются). Кто занимается техническим руководством? Кто занимается управлением проектами?
Определение этих вещей важно, потому что вам нужно нанимать людей с такими навыками, и вам нужно, чтобы все понимали, как они вписываются в быстрорастущую организацию, которую вы строите. Вы можете использовать это упражнение для определения границ между ролями.
Этот тип структуры абсолютно необходим. Я работал в компании, где руководство было недовольно тем, как управлялись проекты. Они поняли, что возложили ответственность на менеджеров по инженерии, но не использовали это в качестве критерия при найме. В результате у них была целая команда менеджеров по инженерии, которые плохо управляли проектами! Это стало проблемой, на устранение которой ушли годы, и это тормозило рост компании. Это заметно повлияло на траекторию развития компании.
При определении ролей я рекомендую записывать их в хорошо подобранном месте, обычно в вики. Выберите кого-нибудь, кто будет следить за тем, чтобы вики поддерживалась с течением времени. И сделайте так, чтобы вики была каноническим источником истины — это неправда, пока это не написано в вики. Вы хотите, чтобы люди могли обращаться к вики, чтобы узнать, как всё работает в компании, а этого не произойдёт, если это не будет надёжный источник информации.
Вы должны сообщить, что всё, что написано, является гибким и может быть изменено со временем. Если эти письменные роли станут неизменными, это помешает организационной гибкости и изменениям. Это проблематично в быстрорастущей компании.
Создавайте сильные группы местного руководства
Одной из наиболее распространённых причин неудач в быстрорастущих организациях является плохая структура местного руководства. На самом деле, я бы сказал, что это одна из проблем, которые я вижу наиболее часто.
Симптомы плохой структуры местного руководства:
- Инженерия, продукт и дизайн не согласованы. Вы слышите разные истории из каждой области, и у каждой свои противоречивые приоритеты. Вы видите разную коммуникацию, исходящую из каждой функции.
- Несколько артефактов, представляющих одно и то же от команды. Например, у менеджера по продукту есть одна версия дорожной карты, а у менеджера по инженерии — другая.
Это более крупная организационная неудача. Лидеры часто ожидают, что местные лидеры сами разберутся, как работать вместе. Вместо этого они должны разработать стандартный подход для местных групп руководства, а затем позволить местной команде настроить его под свои нужды.
Создавайте сильную централизованную координацию
Идеальная организация имеет фрактальное лидерство:
- Децентрализованное принятие решений в местных командах.
- И централизованное установление целей, контекстуализация и координация.
Кто-то должен уделять значительную часть своего времени установлению контекста для компании. В зависимости от размера вашей компании это может быть сделано:
- Генеральным директором.
- Вице-президентом или руководителем отдела.
- Советом вице-президентов по продукту, инженерии, дизайну.
- Человеком, который фокусируется на бизнес-стратегии.
Самое главное, чтобы у людей был правильный контекст для принятия обоснованных местных решений. И чтобы кто-то в бизнесе проделал тяжёлую стратегическую работу, чтобы у вашей компании был план, который обеспечит успех компании.
Когда компания быстро растёт, отсутствие этих вещей приводит к хаосу. Мой главный совет — записать стратегию и рассказывать о ней, пока люди не перестанут жаловаться на недостаток контекста. Это может быть работой на полный рабочий день или работой нескольких человек.
Определите взаимодействие между местными и центральными группами
Когда у вас есть децентрализованные лидеры, активно работающие в своих областях, и централизованные лидеры, сосредоточенные на целях и стратегии, вы неизбежно придёте к конфликту. В идеале у вас должно быть хорошее общение между этими группами и их влияние друг на друга.
Один из способов добиться этого — определить взаимодействие между местными и центральными группами. Обычно я видел, что их называют бизнес-обзорами.
Когда я работал в Gremlin, мы скопировали подход Amazon и провели такие встречи:
- «Еженедельное бизнес-обозрение» с местным руководством. Мы рассмотрели состояние нашей части продукта, узнали, что мы узнали о наших клиентах, как работают недавние функции. И обсудили риски, возможности и так далее.
- «Ежемесячное бизнес-обозрение». Эта встреча имела во многом ту же структуру, что и еженедельная бизнес-встреча, но была свёрнута за месяц информации. И она включала в себя следующий уровень руководства. Это была возможность для нас выявить проблемы и риски. И это была возможность для нас повлиять на стратегию более высокого уровня. Например, мы предлагали новые подходы к продукту, которые считали ценными.
Формат этих встреч должен быть адаптирован к вашим местным потребностям, но кто-то должен обращать внимание на то, насколько хорошо местное руководство работает с централизованным руководством.
Нанимайте менеджеров по найму заранее
Чем быстрее вы растете, тем раньше вам следует нанимать менеджеров по найму. Это распределяет работу по найму более широко. Это лучше масштабируется. И это имеет смысл — чем больше вы нанимаете, тем больше времени это потребует у менеджеров по найму.
Вам нужно будет стандартизировать ваши методы найма, чтобы облегчить участие менеджеров по найму.
Определите свою стратегию реорганизации заранее
Распространённым источником проблем в организациях, которые быстро растут, являются реорганизации. Если у вас нет чётко определённой стратегии того, как будут работать реорганизации, каждая организация будет проводить их независимо. Обычно это означает, что они будут происходить независимо друг от друга. Инженерия проведёт реорганизацию. Затем через несколько месяцев продукт проведёт реорганизацию. Они могут делать это с разными философиями. Это будет хаотичным беспорядком.
У вас должен быть общий для продукта взгляд на то, как определяются команды, как продукт согласован с этими командами и как дизайн работает с этими командами. Очень часто инженерам хочется организовать работу вокруг технологий, продукту — вокруг сегментов клиентов, а дизайну — вокруг функций дизайна: UX и исследований, например.
Это больная точка для модели триады. Запишите, как это должно работать. Признаюсь, я никогда не видел, чтобы это делалось раньше. Но это то, что может уменьшить столько организационной боли. И чем быстрее вы будете расти, тем более ценным это может быть.
Поддерживайте своих лидеров
Вам нужно много лидерской структуры, чтобы ориентироваться в быстрорастущей среде. В идеале у вас есть лидеры, которые постоянно улучшают организацию и устраняют все неизбежные проблемы, которые возникают по мере того, как компания увеличивается в размерах.
Это происходит только в том случае, если вы инвестируете в рост своих лидеров. Они должны расти так же быстро, как и компания. Я рекомендую следующие практики:
- Используйте 1-1 для обучения менеджеров. Они дают возможность выявить навыки, которые нужны менеджеру, и целенаправленно обучать его этим навыкам.
- Используйте пропуск уровней для наблюдения. Пропуск уровня 1-1 — это хороший инструмент, позволяющий отобрать образцы из всей вашей организации и выяснить, где могут быть проблемы. Вы можете обнаружить команды, которым нужна помощь, или менеджеров, которые неэффективны. Они также помогают сохранить коммуникацию — если вы встречаетесь с людьми в вашей организации каждые три-шесть месяцев, они с большей вероятностью сообщат вам о проблемах.
- Создайте группы поддержки управления. Вы можете организовать группы менеджеров в небольшие группы поддержки. Пусть каждый расскажет о том, что для него сложно. В идеале они могут стать учебными встречами, где люди могут быть уязвимы друг с другом в отношении своих проблем. И они могут учиться друг у друга и становиться более эффективными лидерами.
Джейд Рубик — бывший вице-президент по инженерии в New Relic и вице-президент по продукту и инженерии в Gremlin. Сейчас он консультирует стартапы по масштабированию их организаций по разработке продуктов. Джейд пишет о разработке продуктов в своём блоге и имеет бесплатный (или платный) курс по лидерству в инженерии (и разработке продуктов).