Новые принципы делового общения

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

Пример из практики: экстремальные методы

Весной 2019 года я записывал интервью для подкаста The Rich Roll Podcast. В ходе него мы обсуждали идеи, которые я изложил в этой книге. Я отметил, что техники гибкого управления, популярные у разработчиков программного обеспечения, — довольно интересный пример более вдумчивой альтернативы гиперактивному коллективному разуму. Через несколько месяцев после выхода интервью я получил письмо, по старинке отпечатанное на бумаге. Его доставили в мой кабинет в Джорджтаунском университете. Автором письма оказался Грег Вудворд, программист и руководитель, много лет проработавший в Кремниевой долине. Он писал, что только что прослушал мое интервью и особый интерес у него вызвало наше обсуждение гибких техник управления. Грег утверждал, что если я хочу в полной мере осознать, каким потенциалом обладают оптимизированные рабочие процессы, то мне необходимо узнать о проекте по внедрению программного обеспечения, которым Грег в тот момент руководил. Они внедряли методологию, «которая позволяла свести все техники гибкого управления воедино и выжать из них максимум». Этот процесс был очень метко окрещен «экстремальным программированием», и он просто потряс мое воображение.

Вудворд начал писать коды и управлять командами разработчиков в Кремниевой долине в середине 1990-х, после того как получил в Стэнфордском университете докторскую степень в области технического проектирования. Свою диссертацию он посвятил эффективному алгоритму, который позволял моделировать физическую среду, аналогичную среде космической челночной программы НАСА. Первое десятилетие работы в отделе программирования, когда сотрудники захлебывались в бесконечных графиках и изучали технические спецификации толщиной с роман, он описывает как «обескураживающее». В 2005 году Грег задумался о том, чтобы сделать работу программиста более эффективной. И получил работу в компании Pivotal Labs. В Кремниевой долине сотрудники этой организации имели репутацию чудаков, которые тем не менее были невероятно эффективными в создании программных кодов. Свои методы они называли «экстремальным программированием» (сокращенно ХР). Как объяснил мне Вудворд, эта технология беспрестанно оптимизируется. «ХР вобрало в себя лучшие практики разработки программного обеспечения, — отмечает он. — Их постоянно оттачивают и отказываются от всего, что не работает». Вудворд стал поклонником этого метода. Проработав на Pivotal семь лет, он применял приемы ХР в каждой компании, где работал после этого.

Вот некоторые (но не все) идеи, которые лежат в основе подхода ХР. Команды, работающие над крупными проектами, обычно делят на группы поменьше, как правило не более десяти человек. В век, когда удаленная работа становится все более популярной, команда разработчиков трудится в едином физическом пространстве. Предпочтение отдается личному общению, а не цифровым средствам связи. «Мы редко проверяем электронную почту в течение дня, — рассказал мне Вудворд, когда мы обсуждали команду, которой он тогда управлял. — Иногда мои сотрудники не заглядывают в свои ящики в течение нескольких дней». Если вам нужно кого-то о чем-то спросить, вы ждете, пока этот человек не сделает паузу в работе, и тогда подходите и спрашиваете. Подобные беседы, как говорит Вудворд, «в сто раз эффективнее электронных писем».