Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - Джефф Лоусон

Самостоятельность, мастерство и цель

В своей книге «Драйв: Что на самом деле нас мотивирует»[6] Дэниел Пинк утверждает, что компенсация необязательно мотивирует людей или мотивирует, но только до определенного момента. Заработная плата должна быть такой, чтобы она воспринималась сотрудниками как справедливая. (Об этом я подробнее расскажу в конце главы.) После достижения уровня справедливости сотрудники сосредоточиваются на реальных причинах работы: самостоятельности, мастерстве и цели. Я считаю, что это особенно верно для разработчиков.

Самостоятельность означает возможность работать независимо и не по указаниям, что именно делать. Мастерство означает способность со временем совершенствоваться в своем ремесле. Цель предполагает возникновение чувства, что работа, которую вы делаете, действительно имеет значение. Рассмотрим каждый элемент этой триады более внимательно, особенно с точки зрения разработчиков.

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

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

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

Один из моих любимых примеров относится к тем временам, когда я учился в средней школе. Я входил в команду школьной радиостанции WBFH, известной у нас под названием The Biff. С 360-ваттным передатчиком WBFH была самой мощной школьной радиостанцией Детройта, и мы гордились этим. У всех нас была работа как на настоящей радиостанции, и каждый должен был вести еженедельное двухчасовое радиошоу. В выпускном классе средней школы я был музыкальным директором радиостанции, и мое двухчасовое еженедельное шоу называлось «Семичасовой тюремный эксперимент». Руководитель WBFH, светловолосый и долговязый учитель Пит Бауэрс, похожий на Тома Петти[7], установил для нас только три правила: все, что мы делали, должно быть «безопасным, веселым и законным». Кроме того, мы руководили этой станцией! Например, когда мы захотели помочь продвижению нового альбома группы The Smashing Pumpkins, транслируя в прямом эфире репортаж о конкурсе по разбиванию тыкв на тротуаре перед школой, мистер Бауэрс ответил на наше предложение: «Ну, это весело и законно. Просто убедитесь, что ваши действия безопасны». Мало того, что мои воспоминания о WBFH одни из лучших за школьные годы, это была к тому же удивительная учебная среда. Бауэрс позволял нам делать ошибки (пока мы делали все безопасно, весело и законно) и учиться на них. Я использовал пример своего школьного наставника как вдохновение для осмысления создания такой рабочей среды с известными базовыми правилами, где каждый чувствует себя способным развиваться.

Также подразумевается, что нужно сократить набор правил до минимума, позволяющего создать работоспособную систему. Как руководитель, вы должны создать систему, в которой команды могут успешно сотрудничать, где таланты будут успешными, а ваши клиенты смогут доверять вам. Многое из того, о чем идет речь в этой книге, – небольшие команды, платформы, микросервисы и т. д., – является частями такой системы.

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

Когда мой друг и соучредитель компании Twilio Эван Кук работал в Цифровой службе США, самым большим их требованием была именно самостоятельность. Они не собирались сидеть в какой-то тайной комнате и выполнять приказы как сборище бездумных создателей кода. Они хотели и получили возможность создавать системы без вмешательства менеджеров по продуктам, консультантов по менеджменту и прочих специалистов, не имеющих отношения к высоким технологиям.

Они также решительно выступали за участие в принятии важных решений. Технологи Белого дома придумали концепцию, называемую техническим коэффициентом (TQ) по аналогии с IQ или EQ, чтобы объяснить руководителям различных департаментов и ведомств – будь то Пентагон, Белый дом, Администрация малого бизнеса, Министерство образования, Министерство здравоохранения и социальных служб, Администрация общих служб или Министерство внутренней безопасности – важность наличия «TQ за столом». «Мы находимся на этапе истории, когда специалисты-технологи должны участвовать в принятии почти каждого важного решения», – говорит Эван.

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

Создание системы правил также означает устранение ненужных правил. Как вы доносите до разработчиков мысль о том, что они самостоятельны? Здесь есть масса аспектов, некоторые из которых могут казаться незначительными или тривиальными, но на деле они важны. Вспоминается недавняя история из практики Twilio. У нас есть команда разработчиков-преподавателей, часто проводящая хакерские марафоны в крупных компаниях, осуществляющих цифровую трансформацию. Как-то раз они прибыли в очередную компанию для подготовки к двухдневному мероприятию и в отведенной им комнате