Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - [70]

Без однопоточных лидеров, наделенных правом принимать решения, компании обращаются к другим схемам принятия решений, которые, на мой взгляд, менее эффективны. Возможно, вы слышали о модели принятия решений RAPID^© – это одна из многих систем, которые помогают организациям понять, «у кого есть D», т. е. решение. RAPID^© была создана компанией Bain как инструмент для уточнения ответственности за принятие решений, выделяющий пять ключевых ролей (рекомендация, согласование, осуществление, предоставление информации и принятие решения).

В Twilio мы пробовали использовать RAPID^© в некоторых подразделениях, но поняли, что эффективность падает, когда в модели появляется еще одна роль «без речи» – V (вето). Вы можете согласиться с процессом RAPID^© в целом, но если есть менеджер, который может наложить вето, то человек, который теоретически имеет право принимать решения, на деле лишается его. Это прямая противоположность наделению полномочиями однопоточного лидера. Вы говорите, что у него есть право принимать решения, но если вы пересматриваете решения или, что хуже, накладываете на них вето, то это право существует лишь на словах. Лидер будет бояться принимать решения и передавать большую часть дел вам. На мой взгляд, это прямой путь к уничтожению внутренней мотивации.

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

● Если вы принимаете решения, то вы полностью самостоятельны.

● Если у вашего менеджера есть решение, то вы понимаете, как оно принимается, помогаете принять его и поддерживаете.

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

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

Ловушка улучшения сотрудничества

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

Это я и называю «ловушка улучшения сотрудничества».

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

Поэтому важно формализовать отношения между командами в виде «контрактов на обслуживание». Смотрите на команды как на независимые стартапы – когда вы ведете с ними дела, их продукт четко определен, а ценообразование понятно. Представьте сайт другой команды, описывающий ее продукты, с виртуальной кнопкой «Связаться с нами» или «Начать работу», если вам нужен какой-то продукт. При взаимодействии через корпоративные границы такие формализованные контракты необходимы – продукт должен иметь описание, цена должна быть согласована, но внутри компании все по-другому. Если каждая команда предоставит другим формализованное описание «Вот что мы делаем, и вот как с нами взаимодействовать», то стоимость координации снизится. Это способ стандартизации взаимодействия, превращения его в хорошо понятный и масштабируемый процесс. Можно даже поставить цены на услуги, чтобы помочь с внутренним учетом и планированием ресурсов.

В технологических командах такими интерфейсами обычно являются API и хорошая документация. Когда команде Programmable Voice нужно куда-то позвонить, они делают запрос через API на уровень Voice Connectivity. Такой четко определенный контракт на обслуживание между командами обеспечивает стабильный, предсказуемый и задокументированный способ взаимодействия и даже предусматривает выставление счетов за предоставленные услуги. Подобная практика не ограничивается технологическими командами. В других подразделениях организации можно применять аналогичные принципы взаимодействия. Например, ваша юридическая команда тратит много времени на переговоры о контрактах с клиентами вместе с командой продаж, но есть ли у них четкий «API» для взаимодействия? Как заключается новый контракт? Как отслеживается прогресс в работе? Сколько «стоит» нанять штатного адвоката и учитывается ли это в себестоимости продаж? Представьте себе юридическую команду с платформой самообслуживания, где продажники могут взять утвержденные заготовки, не требующие участия адвоката. Это был бы отличный продукт! Многим продажникам это должно понравиться, поскольку такая платформа ускоряет цикл заключения сделок и требует меньше «сотрудничества» с юридической командой.