В своей книге «Драйв: Что на самом деле нас мотивирует»[6] Дэниел Пинк утверждает, что компенсация необязательно мотивирует людей или мотивирует, но только до определенного момента. Заработная плата должна быть такой, чтобы она воспринималась сотрудниками как справедливая. (Об этом я подробнее расскажу в конце главы.) После достижения уровня справедливости сотрудники сосредоточиваются на реальных причинах работы: самостоятельности, мастерстве и цели. Я считаю, что это особенно верно для разработчиков.
Самостоятельность означает возможность работать независимо и не по указаниям, что именно делать. Мастерство означает способность со временем совершенствоваться в своем ремесле. Цель предполагает возникновение чувства, что работа, которую вы делаете, действительно имеет значение. Рассмотрим каждый элемент этой триады более внимательно, особенно с точки зрения разработчиков.
Каждый человек хочет иметь полномочия, и разработчики ничем от других не отличаются. Но еще более важно то, что как профессионалы они привносят именно тот опыт в области технологий, который ценен для компаний, однако это нередко упускается из виду. Суть самостоятельности – это чувство, что вам доверяют принимать решения. Если кто-то может просто наложить вето на любое ваше решение, то вы на самом деле несамостоятельны. Конечно, если вы занимаете высокое положение в компании, то всегда можете принимать решения. Но мудрые лидеры, которые хотят, чтобы их команды чувствовали доверие, сопротивляются искушению отменить решения своих команд и разделяют ошибки подчиненных, допущенные ими в силу самостоятельности. Я думаю именно так.
Но полная самостоятельность может оказаться контрпродуктивной в системе, где одни команды зависят от других и где трудно заставить тысячи людей поступиться своими собственными мнениями. Наделяя разработчиков полномочиями, вы доверяете им выполнение работы и даете им необходимые инструменты, но одновременно устанавливаете определенные барьеры и правила. Это более реалистично, чем полная самостоятельность, особенно в крупной организации, например, когда нужна полноценная исследовательская организация, занимающаяся такими вещами, как снижение уровня инцидентов, безопасность и стабильность.
Самостоятельность – это не разрешение разработчикам бесцельно бегать туда-сюда и делать все, что они хотят, а нечто основанное на правилах. Без ограничений люди не знают, как принимать решения, а руководители склонны постоянно пересматривать их. Создавая правила, вы даете людям свободу в пространстве между ограничениями.
Один из моих любимых примеров относится к тем временам, когда я учился в средней школе. Я входил в команду школьной радиостанции WBFH, известной у нас под названием The Biff. С 360-ваттным передатчиком WBFH была самой мощной школьной радиостанцией Детройта, и мы гордились этим. У всех нас была работа как на настоящей радиостанции, и каждый должен был вести еженедельное двухчасовое радиошоу. В выпускном классе средней школы я был музыкальным директором радиостанции, и мое двухчасовое еженедельное шоу называлось «Семичасовой тюремный эксперимент». Руководитель WBFH, светловолосый и долговязый учитель Пит Бауэрс, похожий на Тома Петти[7], установил для нас только три правила: все, что мы делали, должно быть «безопасным, веселым и законным». Кроме того, мы руководили этой станцией! Например, когда мы захотели помочь продвижению нового альбома группы The Smashing Pumpkins, транслируя в прямом эфире репортаж о конкурсе по разбиванию тыкв на тротуаре перед школой, мистер Бауэрс ответил на наше предложение: «Ну, это весело и законно. Просто убедитесь, что ваши действия безопасны». Мало того, что мои воспоминания о WBFH одни из лучших за школьные годы, это была к тому же удивительная учебная среда. Бауэрс позволял нам делать ошибки (пока мы делали все безопасно, весело и законно) и учиться на них. Я использовал пример своего школьного наставника как вдохновение для осмысления создания такой рабочей среды с известными базовыми правилами, где каждый чувствует себя способным развиваться.
Также подразумевается, что нужно сократить набор правил до минимума, позволяющего создать работоспособную систему. Как руководитель, вы должны создать систему, в которой команды могут успешно сотрудничать, где таланты будут успешными, а ваши клиенты смогут доверять вам. Многое из того, о чем идет речь в этой книге, – небольшие команды, платформы, микросервисы и т. д., – является частями такой системы.
Другой аспект самостоятельности – влиятельность, привлечение разработчиков к принятию ключевых решений, которое показывает, что вы доверяете им и цените их вклад. Именно так, на мой взгляд, вы должны поступать!
Когда мой друг и соучредитель компании Twilio Эван Кук работал в Цифровой службе США, самым большим их требованием была именно самостоятельность. Они не собирались сидеть в какой-то тайной комнате и выполнять приказы как сборище бездумных создателей кода. Они хотели и получили возможность создавать системы без вмешательства менеджеров по продуктам, консультантов по менеджменту и прочих специалистов, не имеющих отношения к высоким технологиям.
Они также решительно выступали за участие в принятии важных решений. Технологи Белого дома придумали концепцию, называемую техническим коэффициентом (TQ) по аналогии с IQ или EQ, чтобы объяснить руководителям различных департаментов и ведомств – будь то Пентагон, Белый дом, Администрация малого бизнеса, Министерство образования, Министерство здравоохранения и социальных служб, Администрация общих служб или Министерство внутренней безопасности – важность наличия «TQ за столом». «Мы находимся на этапе истории, когда специалисты-технологи должны участвовать в принятии почти каждого важного решения», – говорит Эван.
Эван и другие программисты сидели на совещаниях вместе с членами кабинета министров, секретарями департаментов и четырехзвездными генералами в парадной форме. Сначала это казалось странным, но потом все привыкли. В конце концов, как отмечает Эван, «что касается государственной политики, то механизм ее осуществления полностью опирается на технологию». Разрабатывать государственную политику без привлечения технологов – «все равно что пытаться решить юридическую проблему без участия юриста».
Создание системы правил также означает устранение ненужных правил. Как вы доносите до разработчиков мысль о том, что они самостоятельны? Здесь есть масса аспектов, некоторые из которых могут казаться незначительными или тривиальными, но на деле они важны. Вспоминается недавняя история из практики Twilio. У нас есть команда разработчиков-преподавателей, часто проводящая хакерские марафоны в крупных компаниях, осуществляющих цифровую трансформацию. Как-то раз они прибыли в очередную компанию для подготовки к двухдневному мероприятию и в отведенной им комнате отдыха, где должен был проходить хакерский марафон, обнаружили телевизор с табличкой, сообщавшей о том, что сотрудникам не разрешается переключать каналы. Это верный способ показать людям, что у них нет самостоятельности. Некоторые могут подумать: «Какая разница? Это не имеет значения». Но когда наши сотрудники вернулись с того хакерского марафона, они только и говорили об этой табличке. Для них она имела огромное значение, и все они ее заметили. «О какой самостоятельности разработчиков в создании ПО может идти речь, если им не доверяют даже переключать телеканалы?» – так выразился один из наших сотрудников.
Вот еще одна проблема, которая может показаться вам глупой и которая на самом деле ужасно раздражает разработчиков, – это одежда, точнее, дресс-код. Принуждение носить «деловой костюм» или что-то в этом роде. Как и табличка на телевизоре, это вроде мелочь, но она транслирует серьезное (и неправильное) послание: «Мы даже не доверяем вам решать, какие штаны надеть».
Дресс-код, как известно, стал огромной проблемой, когда Белый дом организовал Цифровую службу США. Моему другу Эвану и другим, кто перебрался в Вашингтон, было сказано, что женщины в Белом доме должны носить брючные костюмы, а мужчины – костюмы и галстуки. Для Кремниевой долины это просто безумие. Там никто и никогда не ходит в костюме и галстуке.
Разработчики попытались объяснить это, но им сказали, что тут не Кремниевая долина. Это был Белый дом, а в Белом доме требовались костюмы и галстуки. Большинство разработчиков согласились с этим, разве что без особой радости. Но один парень поднял шум – это был Мики Дикерсон, блестящий инженер из Google, задачей которого было восстановление сайта HealthCare.gov.
Мики оказался ужасным ворчуном и любителем вызывающих нарядов. Он заявил, что приедет в Вашингтон и исправит их сайты, но не будет носить костюм с галстуком – и вообще, это он им нужен, а не наоборот. Некоторое время Белый дом настаивал на дресс-коде, но Дикерсон упорствовал. В конце концов компромисс нашли: Мики разрешили не носить костюм, но он согласился носить рубашки с пуговицами и воротничками, хотя и мятые.
Можно подумать, что Мики был мелочным или высокомерным, но на самом деле он делал нечто важное. Так он оценивал, могут ли разработчики быть успешными в этой среде. Если у них нет даже возможности самостоятельно решать, какую одежду носить, то что говорить о влиянии на другие, гораздо более важные решения. Дело здесь было вовсе не в одежде, а в оценке границ самостоятельности.
Что произойдет, если вы не обеспечите подлинную самостоятельность? Разработчики вряд ли будут работать эффективно, а ваши шансы удержать таланты заметно сократятся. «Когда кто-то говорит “Вот три вещи, которые ты должен сделать, а остальное тебя не касается”, это демотивирует и расстраивает меня», – замечает Джаззи Чад Этцель.
По его словам, лучше всего он чувствовал себя как разработчик, когда у него была собственная компания – просто из-за полной самостоятельности. «Я был абсолютно независим и полностью контролировал продукт и направление его развития. У меня была возможность просто заниматься делом», – говорит он. Он общался с клиентами, они говорили, какие функции им нужны, а ему оставалось просто создать эти функции. По словам Чада, «именно возможность создать нечто на пустом месте заряжает его энтузиазмом и энергией».
Ему было трудно обрести самостоятельность при работе по найму. За шесть лет, с 2009 по 2015 г., Чад прошел через шесть компаний. «Я работал во многих местах. Было очень трудно найти такую компанию, которая действительно предоставляла бы самостоятельность и свободу, где я чувствовал бы, что вписываюсь в коллектив и могу полностью отдаться работе», – говорит Чад. С 2015 г. Чад работает в Apple, которая дает ему достаточно самостоятельности и свободы, чтобы чувствовать себя почти как в собственной компании.
Apple знаменита тем, что у нее нет менеджеров по продукту, которые выдают технические задания. Разработчики получают проблемы и могут решать их наилучшим, с их точки зрения, образом – в этом и заключается суть методологии «Спросите своего разработчика». В результате такого доверия к разработчикам Apple производит прекрасное ПО и пользуется невероятным успехом на рынке.
В 2016 г. Кая Томас, студентка факультета информатики Дартмутского колледжа, опубликовала проникновенное эссе, потрясшее Кремниевую долину. Кая писала о том, что огорчает чернокожих и латиноамериканских выпускников по специальности «информатика», когда они приходят на работу в индустрию высоких технологий. Она также написала о культуре, которая сложилась в некоторых технологических компаниях.
«Меня не интересуют настольный теннис, пиво и иные уловки, что используются для привлечения выпускников. Тот факт, что мне не нравятся эти вещи, не означает, что я “культурно несовместима”. Мне просто не хочется дурачиться, я хочу создавать удивительные вещи и учиться у других умных людей. Вот какую корпоративную культуру нужно искать», – написала Кая (курсив мой).
Слова, выделенные мной курсивом, – это, вероятно, лучшее из тех заявлений, которые я когда-либо читал, о том, что молодые разработчики ищут у работодателя. Эти два фактора – создавать удивительные вещи и учиться у других умных людей – и есть в основном то, что все мы ищем в работе.
Кая искала мастерство. Лучшие разработчики – молодые и не очень – всегда надеются, что их поддержат, научат и помогут вырасти. Они хотят совершенствоваться в своем деле и найти наставников, которые помогут им развиваться.
После завершения обучения Кая получила массу предложений. Она выбрала работу в компании Slack – в основном потому, что верила: она сможет учиться там. «У меня были наставники. Я работала с невероятно умными людьми из самых разных слоев общества, людьми, которые приобрели опыт в других компаниях. Я смогла многому научиться и вырасти», – говорит Кая.
Специалисты по информатике с университетским дипломом должны еще многому научиться, прежде чем они смогут создавать коммерческие программы профессионального уровня. «Штатные инженеры знакомили меня с процессом создания мобильных систем и средой для их разработки, проектированием архитектуры и принципами разработки ПО. Это было невероятно», – сообщает Кая.
Не менее важным было приобретение навыков, не связанных с программированием, – общение, деловое письмо, создание презентаций. Они могут показаться общекультурными аспектами, но это на самом деле очень важная сторона работы инженера и значимый фактор успеха в компании.
«Обычно думают, что вас нанимают в качестве инженера только для того, чтобы просто писать код, – объясняет Кая. – Но общение – это очень важный аспект работы. Как, например, донести узкотехнические идеи до людей, далеких от технологии? Вы должны знать, как выполнить анализ кода, как передавать и как получать его результаты, а также как учиться на этой информации. Вам нужны навыки делового письма, чтобы создавать технические документы. Вам нужны ораторские навыки, чтобы выступать на конференциях или просто сообщать информацию другим командам».
Каждый хочет чувствовать, что он растет не только в плане должности или зарплаты, но и в овладении выбранной профессией. Вот почему лучшие сотрудники зачастую выбирают среду, которая помогает профессиональному росту, и только потом смотрят на зарплату или льготы. Многое из того, что мы как лидеры делаем официально и неофициально, связано с созданием обучающей среды – глава 7 полностью посвящена тому, как создать такую среду.
Как и все, разработчики хотят, чтобы их работа приносила пользу. Они хотят создавать системы, которые приносят доход, или экономят деньги для компании, или позволяют повышать качество обслуживания клиентов. Они хотят открывать новые направления бизнеса. Дайте им понять, что в вашей организации разработчики считаются теми, от кого зависит будущее компании, решение проблем, влияющих на миллионы людей.
По словам Али Никнама, генерального директора компании Bunq – мобильного банка, базирующегося в Амстердаме, его стартап набирает отличных разработчиков в Нидерландах, хотя они там в огромном дефиците. Более того, он даже переманивает разработчиков из крупных технологических компаний, таких как Uber, Google и Microsoft, хотя и платит меньше, чем эти гиганты. «Специалисты соглашаются на сокращение зарплаты», – говорит он.
Как это удается? Одна из причин – миссия. «Мы меняем курс финансовой индустрии. Вы можете быть частью коллектива из 130 человек, которые приближают конец всей отрасли», – утверждает Али.
Когда компьютерщик Том Бильске переехал из своей родной Австралии в Амстердам, он ухватился за возможность присоединиться к Bunq. Как он выразился, его привлекли «интересные люди, создающие продукт, который им нравится, и решающие проблемы людей». Ему тоже захотелось принять вызов. «Когда я вышел на работу, то был ошеломлен быстротой рабочего процесса. Умопомрачительно, но мы выпускаем код каждую неделю. Мы разрабатываем функции в кратчайшие сроки. Организация процесса разработки произвела на меня большое впечатление. Разработчики здесь очень хорошие. Я работал в нескольких отличных организациях, но Bunq по сравнению с другими – это просто день и ночь». Это и есть цель, поскольку Бильске и верит и в миссию компании, и в то, что сможет повлиять на способность компании выполнить ее.
Наша задача как руководителей заключается в том, чтобы связать миссию компании с работой, которую выполняют технические команды. У каждого есть та часть работы, которая ему нравится, и та часть, которую он ненавидит, – и разработчики в этом смысле ничем не отличаются от других. Поэтому, когда разработчик занимается занудной отладкой старого кода, пишет тесты или обнаруживает, что у него отключилась программа постраничного вывода, цель становится как раз тем, что делает эти моменты терпимыми и иногда даже интересными. Осознание того, что клиенты и коллеги зависят от вас и что вы меняете направление развития своей организации и окружающих, является мощным мотиватором. На самом деле чем больше людей взаимосвязано с вами в работе, тем больше и поставленная цель. И самое удивительное в ПО – это масштаб. Написание кода, которым будут пользоваться миллионы или даже миллиарды людей, захватывает воображение. Очень немногие профессии дают то же чувство масштаба или влияния. Вот почему разработчиков так мотивирует цель.
Помните историю из главы 4, где рассказывается о том, как президент Барак Обама прилетел в Сан-Франциско на президентском вертолете, чтобы лично нанять первых нескольких разработчиков в Цифровую службу США? Это была самая потрясающая кампания по найму, о которой я когда-либо слышал: все дело было в цели. Разработчикам поручили миссию с высокими ставками и высокой отдачей. Им предложили решить проблемы, которые даже самые опытные специалисты по компьютерным технологиям в мировом масштабе сочли бы сложными.
Присутствие там Обамы было гениальным ходом. Почему Обама там вообще появился? Зачем ему понадобилось лететь в Сан-Франциско только для того, чтобы поприсутствовать в зале 10 минут? Обама знал, что его присутствие показало разработчикам, что их поддерживают на самом верху и что эта цифровая трансформация находится в числе высших приоритетов Обамы. Вот почему он оказался там.