Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - Джефф Лоусон
Шрифт:
Интервал:
Закладка:
Многие компании ведут разговоры о делегировании полномочий, но слишком боятся идти на риск, чтобы дать своим лидерам достаточно свободы. Топ-менеджеры слишком озабочены собственным успехом, чтобы позволить подчиненным действовать самостоятельно. Мы говорим о делегировании полномочий, но затем критикуем наши команды задним числом. Руководитель нередко задается вопросом: «Ну как я дам этим командам полномочия и позволю им действовать самостоятельно, когда на кону стоит разве что не моя жизнь? Разве я могу смириться с плохим решением, принятым моей командой? Разве у меня есть возможность отойти в сторону и позволить командам работать самостоятельно?»
Эта проблема существовала и в Twilio, когда у нас были вице-президенты по технологии и продуктам. Они либо слишком вмешивались в работу, отменяя решения команд и, по сути, лишая их самостоятельности, либо, наоборот, сидели в стороне и ничего не делали – ведь у команд есть полномочия и они могут делать все, что считают нужным. Очевидно, ни то ни другое не является идеальным.
Я инструктировал их следующим образом: «Смотрите, я генеральный директор публичной компании и поэтому отчитываюсь перед советом директоров и инвесторами». Если у нас хороший квартал, я распространяю успех на всех, а если плохой квартал, то не говорю: «Это вина директора по продукту, он принял плохое решение, вы должны разбираться с ним». Понятно, что за финансовые результаты, которые публикует компания, отвечаю я. А раз так, то в качестве способа их улучшения я ставлю во главе команд однопоточных лидеров, которые получают полномочия и обеспечивают решение проблем. Лучшее, что вы можете сделать, – научить персонал прислушиваться к клиентам и принимать правильные решения. Я уверен, что так мне удастся достичь моей цели, но на деле, конечно, я по-прежнему должен держать все под контролем.
Конечно, бывают не очень удачные решения, но нужно всегда взвешивать стоимость их отмены и потери доверия к лидерам, прежде чем давать и зеленый свет. Если это решение уничтожит компанию или нанесет долгосрочный вред клиентам, то вам следует вмешаться в процесс. Проблема в том, что лидеры часто принимают несущественные и непоследовательные решения. Это называют «строительство велосипедного навеса».
Строительство велосипедного навеса – одна из моделей поведения руководителей и менеджеров, которая раздражает команды, – это любопытный термин. Вот его происхождение. Представьте, что вы входите в правительственный комитет, отвечающий за строительство ядерного реактора. Инженеры приходят в комитет за решением о том, какой реактор строить: водо-водяной, кипящий или графитовый. Они предлагают вам экспертные заключения и рекомендации. Поскольку вы не эксперт в проектировании ядерных реакторов, то вряд ли станете углубляться в детали и, скорее всего, примете рекомендации опытных инженеров. Однако, если вас спросят, в какой цвет покрасить велосипедный навес около ядерного реактора, начнется большая дискуссия, и каждый член комитета постарается высказать собственное мнение. Иначе говоря, строительство велосипедного навеса – это склонность неспециалистов тратить много энергии на обсуждение незначительных деталей, поскольку у них нет знаний для принятия важных решений.
Тем не менее лидеры обычно стремятся передать вопрос наверх. В какой-то мере это проверка правильности решений, но в случае трудных вопросов проще попросить босса принять решение. Однако это уход от ответственности, что не очень хорошо для формирования корпоративной культуры наделенных полномочиями лидеров. Как руководитель, я больше задаю вопросы, нежели отвечаю на них. Моя цель – сделать ответственными однопоточных лидеров, но при этом помочь им найти ответы на свои собственные вопросы. Я не идеален и слишком часто иду на поводу и принимаю решение сам, но моя цель – помочь лидерам найти собственные решения.
Без однопоточных лидеров, наделенных правом принимать решения, компании обращаются к другим схемам принятия решений, которые, на мой взгляд, менее эффективны. Возможно, вы слышали о модели принятия решений RAPID© – это одна из многих систем, которые помогают организациям понять, «у кого есть D», т. е. решение. RAPID© была создана компанией Bain как инструмент для уточнения ответственности за принятие решений, выделяющий пять ключевых ролей (рекомендация, согласование, осуществление, предоставление информации и принятие решения).
В Twilio мы пробовали использовать RAPID© в некоторых подразделениях, но поняли, что эффективность падает, когда в модели появляется еще одна роль «без речи» – V (вето). Вы можете согласиться с процессом RAPID© в целом, но если есть менеджер, который может наложить вето, то человек, который теоретически имеет право принимать решения, на деле лишается его. Это прямая противоположность наделению полномочиями однопоточного лидера. Вы говорите, что у него есть право принимать решения, но если вы пересматриваете решения или, что хуже, накладываете на них вето, то это право существует лишь на словах. Лидер будет бояться принимать решения и передавать большую часть дел вам. На мой взгляд, это прямой путь к уничтожению внутренней мотивации.
Так какой же выход? Люди чувствуют себя полноценными работниками в зависимости от того, насколько они близки к лицу, принимающему решения. Из этого следует:
● Если вы принимаете решения, то вы полностью самостоятельны.
● Если у вашего менеджера есть решение, то вы понимаете, как оно принимается, помогаете принять его и поддерживаете.
● Если затрагивающее вас решение принимает тот, кого вы редко видите или даже не знаете, то вы чувствуете себя жертвой. Это делается в отношении вас, а не вместе с вами. Вы начинаете считать себя пассивной частью процесса, в отличие от уполномоченного и облеченного доверием лица.
Небольшие команды и однопоточные лидеры, руководящие ими, помогают свести к минимуму вероятность того, что люди окажутся
