Подбор и наем разработчиков

Нет смысла нанимать умных людей и указывать им, что делать. Мы нанимаем умных людей, чтобы они указывали нам, что делать.

Стив Джобс

В предыдущих главах я говорил о том, почему компаниям так важно стать создателями программного обеспечения. Но, чтобы разрабатывать ПО, необходимы таланты. В грядущем десятилетии победителями станут компании, создающие лучшее ПО, то есть те, у кого в команде лучшие разработчики. Если вы испытываете затруднения в поиске и удержании талантливых специалистов, то эта глава поможет вам понять, как действовать, обращаясь к тому, что важно для разработчиков. Если вам постоянно не хватает технических специалистов, то, возможно, вы сможете изменить свое отношение к разработчикам и превратить свою компанию в то место, где у них есть простор для творчества. Если таланты после вас попадают в Apple, Google и Facebook, то, надо думать, ваша компания является отличным местом для профессионального роста. Мы, например, получили свою долю талантов именно из таких компаний или убедили специалистов принять наше предложение, а не предложение кого-то из числа технологических гигантов. В этой главе я поделюсь некоторыми соображениями, накопившимися за годы у меня как разработчика и работодателя, в отношении того, как привлекать, удерживать, мотивировать и оплачивать действительно талантливых специалистов.

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

Главное — нужно относиться к разработчикам просто как к людям. Они не умники не от мира сего, прячущиеся в серверной. И не нежные экзотические растения, требующие особого обхождения. Разработчики — это просто люди, полные стремлений учиться и расти, желания работать в полную силу и реализовать себя. В компаниях, где это понимают и уважают, разработчики будут активно участвовать вместе с вами в развитии компании.

Первые нанятые вами сотрудники особенно важны. Привлечение в компанию правильного лидера с самого начала может быть ключом к успеху. Хороший лидер притягивает руководителей среднего и низшего звена, которые, в свою очередь, нанимают отличных менеджеров и исполнителей. Но привлечение талантов — это только первый шаг. Удержать их нередко сложнее. Если ваша организация малоэффективна, разработчики не будут сидеть сложа руки, надеясь, что ситуация улучшится. Они просто уйдут. К сожалению, мне пришлось столкнуться с этим на собственном опыте, о чем я расскажу в главе 11.

Наймите хорошего лидера — и остальное приложится

Когда Патрик Дойл занял пост генерального директора сети пиццерий Domino’s в 2010 г., его первой целью было улучшение качества продукции — проще говоря, приготовление более качественной пиццы, а следующей — расширение технологических возможностей компании. Может показаться странным, что компания, занимающаяся товарным бизнесом, делает огромные инвестиции в технологии. Но, с точки зрения Патрика, путей дифференциации Domino’s с помощью одного лишь предложения продукции было не так уж много. Пицца — это всегда пицца. А вот возможностей дифференциации в сфере качества обслуживания клиентов с помощью технологии было намного больше.

Существующий ИТ-отдел компании должен был переориентироваться с выполнения внутренних функций на создание программного обеспечения для клиентов. Как и многие ИТ-отделы того времени, технологическая команда Domino’s была в основном сосредоточена на таких вещах, как монтаж оборудования, установка программных обновлений и исправлений и поддержание работы серверов. Но Domino’s требовалась креативная софтверная организация, которая могла бы создавать новые приложения и улучшать обслуживание пользователей. Создание такой организации Патрик начал с поиска лидера. В 2012 г. он познакомился с Кевином Васкони, опытным специалистом в области высоких технологий, который теперь признается, что поначалу его не особенно интересовала работа в сети пиццерий.

Когда Кевин пришел в Domino’s в 2012 г., его задача состояла в создании совершенно новой, высокотехнологической организации. В то время в ИТ-отделе Domino’s во всем мире работало 150 человек. Восемь лет спустя это число выросло до 650, из которых только 50 человек были выходцами из той группы, которую унаследовал Кевин. Он начал с того, что воспользовался своими профессиональными связями и создал сильный костяк коллектива. Это были не только руководители — хорошая команда технических руководителей состоит из старших архитекторов ПО, ведущих инженеров и руководителей направлений. Главное, чтобы у ваших первых сотрудников были хорошие технические навыки. Первые сотрудники также могут быть самыми трудно управляемыми, но со временем все упрощается. Совет Кевина другим — не спешите и не успокаивайтесь.

За последние годы Domino’s радикально изменила бизнес пиццерий, сформировав софтверную организацию мирового класса и предоставив разработчикам свободу в создании инновационных и даже эксцентричных программных продуктов. К ним относятся использование распознавания голоса или касание эмодзи для размещения заказа. Некоторые идеи начинаются почти с каприза. Однажды Патрик спросил разработчиков: «Мог бы я заказать пиццу, стоя на светофоре?» Это был вопрос, который возник у генерального директора по дороге домой. «Заказ на светофоре» может показаться немного странной просьбой, но на самом деле это реальный вариант использования — занятая мама или папа, которые не хотят готовить ужин, могут заказать пиццу по дороге домой. Но простой вопрос открыл дверь для многолетней истории инноваций, упрощающих размещение и отслеживание заказа. Ничего бы этого не произошло без команды, которая была ориентирована на клиента и готова к выполнению заданий.

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

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

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

Самостоятельность

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

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

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

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

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

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

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

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

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

Создание системы правил также означает устранение ненужных правил. Как вы доносите до разработчиков мысль о том, что они самостоятельны? Здесь есть масса аспектов, некоторые из которых могут казаться незначительными или тривиальными, но на деле они важны. Вспоминается недавняя история из практики Twilio. У нас есть команда разработчиков-преподавателей, часто проводящая хакерские марафоны в крупных компаниях, осуществляющих цифровую трансформацию. Как-то раз они прибыли в очередную компанию для подготовки к двухдневному мероприятию и в отведенной им комнате отдыха, где должен был проходить хакерский марафон, обнаружили телевизор с табличкой, сообщавшей о том, что сотрудникам не разрешается переключать каналы. Это верный способ показать людям, что у них нет самостоятельности. Некоторые могут подумать: «Какая разница? Это не имеет значения». Но когда наши сотрудники вернулись с того хакерского марафона, они только и говорили об этой табличке. Для них она имела огромное значение, и все они ее заметили. «О какой самостоятельности разработчиков в создании ПО может идти речь, если им не доверяют даже переключать телеканалы?» — так выразился один из наших сотрудников.

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

Дресс-код, как известно, стал огромной проблемой, когда Белый дом организовал Цифровую службу США. Моему другу Эвану и другим, кто перебрался в Вашингтон, было сказано, что женщины в Белом доме должны носить брючные костюмы, а мужчины — костюмы и галстуки. Для Кремниевой долины это просто безумие. Там никто и никогда не ходит в костюме и галстуке.

Разработчики попытались объяснить это, но им сказали, что тут не Кремниевая долина. Это был Белый дом, а в Белом доме требовались костюмы и галстуки. Большинство разработчиков согласились с этим, разве что без особой радости. Но один парень поднял шум — это был Мики Дикерсон, блестящий инженер из Google, задачей которого было восстановление сайта .

Мики оказался ужасным ворчуном и любителем вызывающих нарядов. Он заявил, что приедет в Вашингтон и исправит их сайты, но не будет носить костюм с галстуком — и вообще, это он им нужен, а не наоборот. Некоторое время Белый дом настаивал на дресс-коде, но Дикерсон упорствовал. В конце концов компромисс нашли: Мики разрешили не носить костюм, но он согласился носить рубашки с пуговицами и воротничками, хотя и мятые.

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

Что произойдет, если вы не обеспечите подлинную самостоятельность? Разработчики вряд ли будут работать эффективно, а ваши шансы удержать таланты заметно сократятся. «Когда кто-то говорит “Вот три вещи, которые ты должен сделать, а остальное тебя не касается”, это демотивирует и расстраивает меня», — замечает Джаззи Чад Этцель.

По его словам, лучше всего он чувствовал себя как разработчик, когда у него была собственная компания — просто из-за полной самостоятельности. «Я был абсолютно независим и полностью контролировал продукт и направление его развития. У меня была возможность просто заниматься делом», — говорит он. Он общался с клиентами, они говорили, какие функции им нужны, а ему оставалось просто создать эти функции. По словам Чада, «именно возможность создать нечто на пустом месте заряжает его энтузиазмом и энергией».

Ему было трудно обрести самостоятельность при работе по найму. За шесть лет, с 2009 по 2015 г., Чад прошел через шесть компаний. «Я работал во многих местах. Было очень трудно найти такую компанию, которая действительно предоставляла бы самостоятельность и свободу, где я чувствовал бы, что вписываюсь в коллектив и могу полностью отдаться работе», — говорит Чад. С 2015 г. Чад работает в Apple, которая дает ему достаточно самостоятельности и свободы, чтобы чувствовать себя почти как в собственной компании.

Apple знаменита тем, что у нее нет менеджеров по продукту, которые выдают технические задания. Разработчики получают проблемы и могут решать их наилучшим, с их точки зрения, образом — в этом и заключается суть методологии «Спросите своего разработчика». В результате такого доверия к разработчикам Apple производит прекрасное ПО и пользуется невероятным успехом на рынке.

Мастерство

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

«Меня не интересуют настольный теннис, пиво и иные уловки, что используются для привлечения выпускников. Тот факт, что мне не нравятся эти вещи, не означает, что я “культурно несовместима”. Мне просто не хочется дурачиться, я хочу создавать удивительные вещи и учиться у других умных людей. Вот какую корпоративную культуру нужно искать», — написала Кая (курсив мой).

Слова, выделенные мной курсивом, — это, вероятно, лучшее из тех заявлений, которые я когда-либо читал, о том, что молодые разработчики ищут у работодателя. Эти два фактора — создавать удивительные вещи и учиться у других умных людей — и есть в основном то, что все мы ищем в работе.

Кая искала мастерство. Лучшие разработчики — молодые и не очень — всегда надеются, что их поддержат, научат и помогут вырасти. Они хотят совершенствоваться в своем деле и найти наставников, которые помогут им развиваться.

После завершения обучения Кая получила массу предложений. Она выбрала работу в компании Slack — в основном потому, что верила: она сможет учиться там. «У меня были наставники. Я работала с невероятно умными людьми из самых разных слоев общества, людьми, которые приобрели опыт в других компаниях. Я смогла многому научиться и вырасти», — говорит Кая.

Специалисты по информатике с университетским дипломом должны еще многому научиться, прежде чем они смогут создавать коммерческие программы профессионального уровня. «Штатные инженеры знакомили меня с процессом создания мобильных систем и средой для их разработки, проектированием архитектуры и принципами разработки ПО. Это было невероятно», — сообщает Кая.

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

«Обычно думают, что вас нанимают в качестве инженера только для того, чтобы просто писать код, — объясняет Кая. — Но общение — это очень важный аспект работы. Как, например, донести узкотехнические идеи до людей, далеких от технологии? Вы должны знать, как выполнить анализ кода, как передавать и как получать его результаты, а также как учиться на этой информации. Вам нужны навыки делового письма, чтобы создавать технические документы. Вам нужны ораторские навыки, чтобы выступать на конференциях или просто сообщать информацию другим командам».

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

Цель

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

По словам Али Никнама, генерального директора компании Bunq — мобильного банка, базирующегося в Амстердаме, его стартап набирает отличных разработчиков в Нидерландах, хотя они там в огромном дефиците. Более того, он даже переманивает разработчиков из крупных технологических компаний, таких как Uber, Google и Microsoft, хотя и платит меньше, чем эти гиганты. «Специалисты соглашаются на сокращение зарплаты», — говорит он.

Как это удается? Одна из причин — миссия. «Мы меняем курс финансовой индустрии. Вы можете быть частью коллектива из 130 человек, которые приближают конец всей отрасли», — утверждает Али.

Когда компьютерщик Том Бильске переехал из своей родной Австралии в Амстердам, он ухватился за возможность присоединиться к Bunq. Как он выразился, его привлекли «интересные люди, создающие продукт, который им нравится, и решающие проблемы людей». Ему тоже захотелось принять вызов. «Когда я вышел на работу, то был ошеломлен быстротой рабочего процесса. Умопомрачительно, но мы выпускаем код каждую неделю. Мы разрабатываем функции в кратчайшие сроки. Организация процесса разработки произвела на меня большое впечатление. Разработчики здесь очень хорошие. Я работал в нескольких отличных организациях, но Bunq по сравнению с другими — это просто день и ночь». Это и есть цель, поскольку Бильске и верит и в миссию компании, и в то, что сможет повлиять на способность компании выполнить ее.

Наша задача как руководителей заключается в том, чтобы связать миссию компании с работой, которую выполняют технические команды. У каждого есть та часть работы, которая ему нравится, и та часть, которую он ненавидит, — и разработчики в этом смысле ничем не отличаются от других. Поэтому, когда разработчик занимается занудной отладкой старого кода, пишет тесты или обнаруживает, что у него отключилась программа постраничного вывода, цель становится как раз тем, что делает эти моменты терпимыми и иногда даже интересными. Осознание того, что клиенты и коллеги зависят от вас и что вы меняете направление развития своей организации и окружающих, является мощным мотиватором. На самом деле чем больше людей взаимосвязано с вами в работе, тем больше и поставленная цель. И самое удивительное в ПО — это масштаб. Написание кода, которым будут пользоваться миллионы или даже миллиарды людей, захватывает воображение. Очень немногие профессии дают то же чувство масштаба или влияния. Вот почему разработчиков так мотивирует цель.

Помните историю из главы 4, где рассказывается о том, как президент Барак Обама прилетел в Сан-Франциско на президентском вертолете, чтобы лично нанять первых нескольких разработчиков в Цифровую службу США? Это была самая потрясающая кампания по найму, о которой я когда-либо слышал: все дело было в цели. Разработчикам поручили миссию с высокими ставками и высокой отдачей. Им предложили решить проблемы, которые даже самые опытные специалисты по компьютерным технологиям в мировом масштабе сочли бы сложными.

Присутствие там Обамы было гениальным ходом. Почему Обама там вообще появился? Зачем ему понадобилось лететь в Сан-Франциско только для того, чтобы поприсутствовать в зале 10 минут? Обама знал, что его присутствие показало разработчикам, что их поддерживают на самом верху и что эта цифровая трансформация находится в числе высших приоритетов Обамы. Вот почему он оказался там.

Наем на работу

Могу себе представить, что именно вы говорите: «Это все очень хорошо, но что, если вы набираете сотрудников не для Цифровой службы США и не можете использовать Барака Обаму в качестве последнего аргумента? Что, если вы нанимаете компьютерщиков не в сверхсекретные и изменяющие мир новые подразделения Amazon? Как сделать так, чтобы работа в нашей компании была притягательной? Как убедить выпускника факультета информатики поступить на работу именно в нашу компанию, а не в Google или в соседний крутой стартап?»

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

Когда Джефф Иммельт решил преобразовать компанию General Electric с ее 330 000 сотрудниками, он задавал бесконечные вопросы экспертам по высоким технологиям, поскольку действительно хотел понять, что к чему. Он не боялся признаться, что чего-то не понимает, и, как говорится, всегда давал специалистам слово. Это был жест, показывавший, что цифровая трансформация не просто модные словечки.

Инженерам иногда нужно помочь увидеть, что нетехнологические компании полны важных, запутанных и сложных технологических проблем, над которыми интересно работать. «Я знаю, что в каждой крупной компании есть масса очень интересных проблем», — говорит Вернер Фогельс. Вернер тратит много времени на разъезды по миру и встречи с представителями компаний, которые пользуются AWS. Это практически все интересные стартапы в мире, а также тысячи крупных компаний из нетехнологических отраслей. Традиционные компании широко пользуются интернетом вещей и другими новыми технологиями. «Масштабы их деятельности огромны, и у них есть очень интересные, очень содержательные проблемы, требующие решения», — замечает Фогельс.

Вопрос в том, как сделать так, чтобы инженеры увидели эти проблемы и загорелись желанием решить их. И снова все сводится к представлению миссии и ее значимости. Вот почему в каждом шпионском фильме есть сцена, где героя вызывают на встречу и рассказывают о следующем задании. Задание там — это не что-то обыденное вроде «Вы должны приходить ежедневно в течение следующих 30 лет, сидеть за столом и заниматься рутиной, которая совершенно не интересна вам. А если это не удастся, то ничего страшного не случится». Нет, все формулируется не так! У плохих парней есть ядерная бомба! Часы уже тикают! Если вам не удастся остановить их, мир будет уничтожен! Писатели называют это «путь героя». Он начинается, когда главные действующие лица получают «призыв к действию» и берутся за опасное дело, требующее использования всех их способностей и преодоления препятствий.

Чтобы быть хорошим рекрутером, вам нужно представить свою версию пути героя. Что мы здесь делаем? С какими вызовами мы сталкиваемся? Почему важна наша работа? Почему она для вас интересна? Что поставлено на карту? Почему вы будете с удовольствием ходить на работу? «Вы должны рассказать им историю о том, как работает ваша команда, — говорит Джош Хойум, бывший директор по голосовым технологиям компании Target в Миннеаполисе, а впоследствии — директор по проектированию сетей в компании Liberty Mutual. — Я думаю, что многое из происходящего сейчас, особенно в технологическом пространстве, зависит от веры в босса. Поэтому рассказывайте о том, что вы собираетесь делать, о своем видении перспектив компании — вот ключ к найму людей. Это должно убеждать. Многие на самом деле не думали о Target как о технологической компании. Но за последний год я нанял трех человек, и у пары из них были довольно хорошие возможности пойти работать куда-то еще. Это умение показать, как вы хотите изменить положение дел и какое место отводите новым специалистам в технологической организации».

По словам Джоша, ему тоже приходилось терять специалистов. Три разработчика, проходивших стажировку в Target, после окончания университета ушли в Facebook, Google и Zynga. Но, как утверждает Джош, даже кандидатов, получивших предложения от технологических компаний высшего уровня, можно удержать. Есть своя прелесть в том, чтобы быть большой рыбой в маленьком пруду, а не идти в гигантскую технологическую компанию, где работают тысячи подобных тебе. «Это звучит так: “Если вы придете в Target, то у вас будет возможность учиться, расти и принимать технические решения. Я не собираюсь указывать вам, что это должны быть за решения. Я надеюсь, что это вы будете решать”. И на многих молодых инженеров такой призыв действует», — заключает Джош.

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

В Twilio есть немало разработчиков, которые получали предложения от Google и Facebook. Мы привлекли их своим подходом к работе в небольших командах, в котором есть все: и самостоятельность, и мастерство, и цель, — я расскажу подробнее об этом в главе 8. Когда есть выбор, кем стать — еще одним винтиком машины или ключевым членом небольшой, но важной команды, — многих разработчиков привлекает второе.

Вознаграждение за труд

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

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

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

Управление по целям — еще один метод распределения премий в привязке к целям, которые ставятся на индивидуальном или командном уровне. На бумаге это выглядит лучше, поскольку вы четко формулируете, что нужно сделать команде, а затем членам команды или конкретным исполнителям платят больше, если работа выполнена. Вместе с тем я не раз видел, как компании бьются и не могут никак решить, какими же должны быть эти цели! Иногда на их определение уходит столько времени, что к моменту принятия они теряют смысл. Как результат, сотрудники сосредоточены на достижении целей, а не на том, что следует делать. Также перед вами встает проблема: как бы не сделать цели слишком высокими, что превратило бы премию в нечто недоступное, или слишком легкими, что привело бы к получению премии всеми. В любом случае такие рычаги лишний раз подчеркивают несправедливость вознаграждения. По мнению Дэниела Пинка, лучшими следует считать те системы оплаты труда, при которых сотрудники воспринимают вознаграждение как справедливое и могут думать не о зарплате, а о своей работе.

Вряд ли кто захочет, чтобы сотрудники думали только о премии — они должны думать о клиентах. От них требуется творческая энергия. Дэниел Пинк ссылается на исследование, в котором людей просили выполнить простую задачу, требующую творческого мышления. Им вручали коробку с канцелярскими кнопками и несколькими случайными предметами и предлагали прикрепить свечу к стене. Задание давали двум группам — одну просто просили решить проблему, а другой говорили, что за решение проблемы они получат финансовое вознаграждение, скажем $20. Понятно, что лучший способ решения проблемы требует творческого подхода. Большинство пытается прикрепить свечу кнопками, но из этого ничего не выходит. Однако некоторые замечают, что из коробки можно сделать отличную подставку, которую можно кнопками прикрепить к стене. И что же? Команда без финансовой мотивации решала эту творческую головоломку в среднем на три с половиной минуты быстрее, чем команда с финансовой мотивацией.

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

Мы платим сотрудникам больше, чем большинство аналогичных компаний, по твердой тарифной ставке, которая не зависит от причуд руководства или плохо поставленных целей. Мы также выделяем сотрудникам несколько большую долю акций, чтобы компенсировать отсутствие премий, и таким образом концентрируем их внимание на долгосрочных, а не краткосрочных целях. Я всегда считал, что людям нужно хорошо платить, чтобы они чувствовали справедливость вознаграждения, но не следует заблуждаться и считать, что оплата труда — это великий мотиватор, особенно в творческой работе. (Я понимаю, что в сфере продаж все обстоит по-другому. Там комиссионные — это часть игры.)

Вместе с тем Али Никнам, основатель и генеральный директор Bunq, считает, что более низкая оплата труда, чем во флагманских компаниях, помогает привлекать таланты. «В Bunq работают не ради денег. Там работают потому, что действительно верят в наше дело. Мы платим среднюю в отрасли зарплату и открыто говорим об этом. Не высокую и не низкую, а среднюю. Традиционные банки платят больше, поскольку, если честно, никто не хочет там работать, — говорит Али. — Полагаю, что для меня и для Bunq важно иметь тех, кто работает здесь не только из-за денег, но и по другим причинам, — просто лучших».

Точно так же я отношусь и к льготам. Конечно, мы предлагаем конкурентоспособное медицинское страхование, включая стоматологию и офтальмологию, пенсионные взносы и другие привилегии нашим сотрудникам, и у нас имеется несколько вариантов перекуса в офисе. Но мы не перебарщиваем с такими льготами, как трехколесные велосипеды, парикмахерские услуги или дюжина сортов разливного пива. Хотя это и привлекательно для потенциальных сотрудников, я вижу здесь риск соблазнения их неправильными стимулами. Я бы предпочел, чтобы к команде Twilio присоединялись те, кто любит свою работу, радуется общению с коллегами и хочет обслуживать наших клиентов, — это устойчивые мотиваторы. Однажды я побывал в компании из Кремниевой долины, где было 12 местных сортов разливного пива. Это здорово. Но что произойдет, если компания по соседству предложит 13 сортов разливного пива? Все эти формы непрямой оплаты, по моему мнению, в лучшем случае излишни и просто отвлекают от внутренних факторов мотивации — самостоятельности, мастерства и цели.

Лучший способ узнать, почему ваша компания привлекает или не привлекает таланты, — это… спросить своих разработчиков. Серьезно. Спросите своих специалистов, что работает в компании, а что нет. Спросите разработчиков, что им нравится в компании и что они терпеть не могут. Часто ли они задумываются о поиске нового места работы и что чувствуют, когда думают об этом? Что их заставило в прошлый раз отказать рекрутеру? Когда вы проводите собеседование с потенциальными работниками, спросите, чего они хотят достичь и чему научиться на своем месте работы. Поинтересуйтесь, хотят ли они стать собственниками — и пообещайте помочь в этом. Когда разработчики уходят из вашей компании, что они говорят о своих мотивах? Не превращайте разговор при увольнении в простой опрос, не принимайте расплывчатые, ничего не значащие ответы вроде «лучшая возможность». Конечно, если бы это была худшая возможность, они бы ею не воспользовались! Выясните, почему они видят в другой компании лучшую возможность. Это что-то простое вроде размера оклада? Неэффективный менеджер? Или нечто более связанное с культурой: позволяет ли наша компания разработчикам блистать и расти? Возможность вносить вклад, совершенствоваться в мастерстве, расширять самостоятельность и достигать цели часто лежит в основе причины ухода.

Отправить