В первый же день он узнал, что должен руководить группой из 10 техников. Они по восемь часов в день следили за работой технических систем агентства. Иногда что-то выходило из строя, и один из техников чинил поломку. Работа была рутинная и, в принципе, скучная.

Предшественник Джона перед уходом пожелал ему удачи и открыл некоторые секреты. Оказывается, иногда техники симулируют болезнь. Они работают строго с 9 до 17, тогда как остальные по необходимости задерживаются допоздна. С обязанностями еле-еле справляются. Во многом они напоминают машинисток из страховой компании Travelers.

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

Сперва Джон покончил с восьмичасовыми сменами. Эта работа, «схожая с функциями няньки», по его словам, «была скучной и не позволяла развиваться». Смены также подразумевали, что после восьми часов работы техники могли позволить себе расслабиться. Вместо этого Джон установил для них две ежедневные четырехчасовые смены. Он хотел, чтобы в перерывах техники выполняли дополнительную работу. Руководитель группы давал им различные задания – от починки подслушивающих устройств до создания инструментов, улучшающих сотрудничество с другими службами. Такой подход позволил техникам заняться их любимым делом: совершенствовать компьютеры, экспериментировать и решать другие проблемы. Впервые они получили в свое распоряжение игровую площадку.

Раньше эти сотрудники не чувствовали, что могут как-то участвовать в работе: если портилось одно устройство, просто использовалось другое.

Джон хотел, чтобы у них сформировалась собственная цель, чтобы они генерировали идеи по улучшению работы и анализировали ее результаты. Он переместил их из темной комнаты в оперативный зал, где отслеживались реальные угрозы безопасности США, раздавались звонки с запросами срочной информации и принимались решения. Джон брал техников на встречи с заказчиком – другим агентством в сфере безопасности, для которого они собирали информацию. Он просил заказчика оценивать полезность и ценность выданной информации. В конце концов, еженедельно рассылал по организации (включая руководителей) электронные сообщения с описанием результатов, которых удалось добиться группе технической поддержки.

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

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

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

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

В 1999 году компания Salesforce.com создала частный портал, оказывающий услуги по программному обеспечению{256}. Быстрота и гибкость были их главными преимуществами. Salesforce.com обновляла продукт четыре раза в год, тогда как другие компании – только единожды{257}. В результате компания росла очень быстро.

Работа Salesforce.com строилась по принципу конвейера. Одна группа сотрудников встречалась с клиентами, выясняя их потребности. Другая создавала перспективные проекты конкретного программного обеспечения. Третья группа писала программы, четвертая их проверяла, а пятая производила итоговый продукт. Но координация между группами и отделами сильно хромала. Изменения, часто вносившиеся в последнюю минуту, приводили к настоящей катастрофе.

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

Salesforce.com попыталась запретить изменения конечного продукта еще на стадии производства, чтобы не допускать переделок в последний момент. От каждого служащего и группы требовали четко спланированной работы и ее результатов на полгода вперед. Но ничего не помогало. Индустрия программного обеспечения развивалась гораздо быстрее, чем изготавливались заказанные проекты, и никто не мог представить, с какими вызовами придется столкнуться при производстве очередного продукта. Стратегии, отрицающие адаптивные подходы во имя тактических, обрекают себя на неудачу. В IT-сфере волатильность особенно остра.

И тогда Грин решился на очень смелый шаг. Вместе с коллегой Крисом Фраем он обратился к Паркеру Харрису, соучредителю Salesforce.com, и предложил реорганизовать каждое рабочее место в соответствии с принципом гибкости.

Принцип гибкости был разработан в 2001 году на встрече 17 программистов и инженеров в области программного обеспечения. Специалистов волновала заметная утрата адаптивного подхода в их профессиональной среде. Производство подменило здравые суждения в ущерб работе. Эти программисты составили и разместили в интернете «Манифест гибкости»: его символом стал рисунок, на котором компьютерщики окружили ослепительно белую классную доску{258}. Картинка напоминала известное изображение отцов-основателей Декларации независимости США, которое можно увидеть в американских учебниках истории. В манифесте провозглашался революционный подход: с момента его принятия программисты должны работать только в составе команд. Конечный продукт – программы и приложения – должны делать «имеющие глубокую мотивацию индивидуумы. Им нужно всего лишь создать необходимые условия и оказать поддержку. И еще – им нужно верить. Верить в то, что они качественно выполнят свою работу»{259}. Таким образом они переформатировали собственное дело, максимально повышая абсолютную мотивацию и адаптивную эффективность.