Войти в систему
Войти с помощью соц. сетей:
Когда вы перестаете учиться, перестаете слушать, перестаете смотреть и задавать новые вопросы, вы умираете.
В большинстве компаний «обучение и развитие» — это функция отдела по работе с персоналом, подразумевающая повышение квалификации, т.е. освоение каких-то навыков в аудитории или онлайн. Все это полезно, но я говорю здесь об обучении, встроенном в саму структуру компании и ее корпоративную культуру, а не о самообразовании, которым занимаются самые амбициозные сотрудники. Это — обучение в процессе работы в экстремальной форме. Цель всегда состоит в отыскании истины. Это должна быть наша путеводная звезда, тот пункт назначения, к которому мы направляемся.
В главе 5 мы говорили об экспериментировании, которое является способом поиска бизнес-инноваций, но на самом деле — это процесс обучения. Чем быстрее вы обучаетесь, тем больше совершенствуетесь. Такой образ мышления нацелен не только на поиск того, что нужно узнать, например что нужно нашим клиентам, но и на обучение тому, как надо учиться.
Это должно быть естественным для нас, поскольку усваивается еще в школе. Когда дети дают неправильный ответ, их не выгоняют из школы — им помогают. Школа — это не столько изучение содержания учебников, сколько обучение тому, как надо учиться.
Науку о том, как учиться, осваивает каждый ребенок, начиная с детского сада. Но как только мы оканчиваем школу и начинаем работать, то, похоже, все забываем. Умение учиться теряется. Мы создаем жесткие, неумолимые корпоративные культуры, наказывающие тех, кто совершает ошибки. Такой подход мог быть хорошим в какой-нибудь давно ушедшей эпохе, хотя я сомневаюсь в этом. Но он определенно не работает в современной экономике, где компании ведут дарвиновскую борьбу за выживание в мире с постоянно меняющимися правилами. Для выживания нужно быть гибким, ловким, быстрым и способным непрерывно адаптироваться.
Чего вы действительно хотите в глубине души как лидер? Хотите ли вы, чтобы все слепо принимали то, что вы говорите, или вам нужно, чтобы каждый думал самостоятельно и предлагал лучшие решения существующих проблем? Во время дискуссии или совещания порою кажется, что руководители хотят простого выполнения их указаний, поскольку влюбиться в собственные идеи очень легко. Конечно, если вы самый высокооплачиваемый человек на совещании, то при желании все будут плясать под вашу дудку. Но в глубине души вы, наверное, сознаете, что для победы нужен лучший ответ, а не тот, который выкрикивается громче всех или принадлежит самому высокопоставленному сотруднику. Вам нужно, чтобы победили знание и истина, а не политика. Вам нужно, чтобы все постоянно учились, чтобы будущие лидеры были лучше вас и чтобы команды, ориентированные на клиентов, были самыми мудрыми. Если в глубине души вы разделяете эти убеждения, то описываемая мной открытая обучающая среда поможет вам достичь этого.
Открытой и обучающей считается такая среда, в которой организация готова принять тот факт, что у нее нет всех ответов, комфортно чувствует себя в условиях неопределенности и постоянно стремится к улучшению. Эта среда предполагает наличие гибкости и корпоративной культуры, в которой люди постоянно ищут истину.
В компаниях полно людей с собственным мнением. Человеку, которому платят больше всех, свойственно думать, что именно его мнение имеет наибольшее значение. Иногда это мнение оправданно — руководитель высокого уровня может обладать компетенцией или мудростью, которой команда может и должна учиться. Но иногда лучшие идеи возникают у совсем молодых людей, которые только что окончили школу, хорошо знают технологические тренды и тонко чувствуют новое.
Мне всегда нравилось то, что Энди Гроув, легендарный генеральный директор Intel, написал в книге «Высокоэффективный менеджмент» (High Output Management):
«После окончания технического колледжа знания выпускника остаются актуальными в течение нескольких лет. Таким образом, он является ценным приобретением для той организации, которая нанимает его. Если он хорошо проявит себя, его будут продвигать все выше и выше, и с годами его власть вырастет, но близкое знакомство с современными технологиями исчезнет. Иными словами, даже если сегодняшний заслуженный менеджер когда-то был выдающимся инженером, то сейчас его технические знания уже не те, какими были, когда он пришел в компанию. В Intel по крайней мере мы, менеджеры, с каждым днем становимся обладателями все более устаревших знаний».
Чем дальше мы, технические руководители, продвигаемся по карьерной лестнице, тем больше наши инженерные знания замещаются на управленческие. Это два ценных, но разных набора знаний, которыми мы обладаем. Чье мнение вернее — того, кто имеет больше опыта, или того, кто лучше разбирается в технологиях?
Допустим, деловые решения не должны зависеть от чьего-то мнения. У людей есть предчувствия и инстинкты, да и просто собственные теории. Но эти теории нуждаются в тестировании. Именно здесь вам нужна открытость обучению, причем быстрому обучению.
Если вдуматься, масса иерархических компаний (т.е. большинство из них) строятся на предположении, что стоящие наверху знают все ответы (хотя нам известно, что это не так) и поэтому принимают решения. Это не открытый процесс, и он вселяет страх. Люди боятся принимать решения, поскольку могут сделать что-то не так, и стагнируют как специалисты. Или руководители боятся предоставить другим возможность принимать решения, поскольку те могут ошибаться. В конце концов, судьба руководителей зависит от результатов работы, и они не хотят доверять ее другим. Это справедливо, но в результате никто не делится проблемами, а вместо этого делегирует задачи. Но, на мой взгляд, методология «Спросите своего разработчика» — это лучший способ получить то, что вам нужно, т.е. результаты, а не командование и контроль.
Открытой считается среда, в которой вы даете людям самостоятельность и делитесь проблемами. Но это не означает, что можно просто вывалить проблемы на подчиненных и смотреть, кто утонет, а кто выплывет. Как руководитель, вы по-прежнему зависите от результатов, поэтому не в ваших интересах дать кому-то утонуть. Открытая среда обеспечивает своего рода ограждения и поддержку. Вместо того чтобы бросить подчиненных на произвол судьбы, мы даем людям уроки плавания и даже дозволяем им пользоваться спасательными кругами, если они требуются.
Разница между открытой обучающей средой на работе и той, с которой мы сталкивались в начальной школе, заключается в том, что в школе учитель знает ответы, но показывает ученикам, как делать работу, чтобы прийти к ответу самостоятельно. В бизнесе, особенно когда вы работаете с передовыми технологиями, никто не ищет ответа, который уже известен кому-то. Компания и ее работники должны находить ответы на вопросы, которые раньше не задавались. Но открытая обучающая среда дает возможность найти эти ускользающие ответы.
Директор по продуктам Twilio Чи Чу предложил немало оригинальных идей с момента прихода в 2019 г. в нашу компанию. Одним из его самых важных нововведений является концепция, которую он называет «открытый анализ проектов». В соответствии с ней каждый раз, когда Чи встречается с командой для обсуждения проекта, любой желающий может наблюдать за процессом. Это может быть первая рабочая встреча, на которой инженер представляет идею нового продукта, или встреча, на которой разработчики рассказывают о достигнутом прогрессе в проекте, который осуществляется уже несколько лет.
Расписание таких встреч публикуется в общедоступном календаре, на который может подписаться любой желающий. За два дня до встречи участники должны опубликовать документ о том, что именно они будут представлять. Каждый участник обязан ознакомиться с документом до начала заседания.
Чтобы встреча не превратилась в хаос, разрешение выступать предоставляется только нескольким ключевым участникам, статус которых Чи, как истинный программист, определяет как «чтение/запись». Считается, что все остальные участники имеют статус «только для чтения» и могут просто слушать и наблюдать. Иногда участник со статусом «только для чтения» может запросить статус «чтение/запись», чтобы задать вопрос или предложить идею. Но по большей части сотрудники со статусом «только для чтения» находятся там, чтобы наблюдать за процессом обсуждения. Все эти встречи записываются, так что их можно просмотреть позже, а протоколы встреч становятся документами, на которые можно ссылаться. Политика «только для чтения» представляет собой элемент открытой обучающей среды, позволяющий всем в компании учиться у других, но при этом выполняющий функцию рабочего совещания.
Цель подобной концепции состоит в устранении одного из недостатков «правила двух пицц». Дело в том, что при большом числе маленьких команд (у нас только над продуктами трудятся 150 команд) они начинают работать в тысяче разных направлений, и отдельной команде трудно понять, чем занимаются остальные. Однако в некоторых проектах над одним кодом работает целый ряд небольших команд. Каждая команда в такой группе зависит от других команд, поэтому все они должны следить друг за другом. Открытый анализ проектов позволяет командам быстро взаимодействовать друг с другом и оставаться в курсе происходящего.
Дополнительным достоинством этой концепции является то, что открытый анализ проектов становится своего рода учебной площадкой. Сотрудники со статусом «чтение/запись» учатся, потому что их работу проверяет лично Чи, который бывает довольно въедливым. Он так много знает о программном обеспечении, что становится страшновато, особенно тем командам, которые не достигают целевых показателей, или сотрудникам, которые плохо подготовились. Эти совещания могут быть не очень приятными, однако именно это и позволяет учиться. Цель конструктивной критики не устроить разнос, а помочь сотрудникам стать лучше. В действительности это форма внимания и обучения.
Превращение подобных совещаний в открытое для всей компании мероприятие приводит к тому, что порой кого-нибудь могут публично пропесочить. В этом, конечно, мало приятного, но осознание того, что ваши результаты увидят многие, создает дополнительный стимул собраться и хорошо подготовиться. Такой процесс также показывает присутствующим сотрудникам со статусом «только для чтения», к чему готовиться, когда дело дойдет до их выступления. Конечная цель открытого анализа состоит в ускорении обучения. Урок, получаемый имеющими статус «чтение/запись», усваивается и всеми остальными.
Еще один плюс открытого анализа проектов заключается в том, что он поддерживает подотчетность. Решения принимаются открыто, на глазах у всех, а не на тайных совещаниях за закрытыми дверями, после которых другие узнают о происходящем из вторых рук, слухов и кривотолков. Каждый в компании точно знает, чего ждут от сотрудников на подобном мероприятии. Невозможно вернуться и внести изменения задним числом.
Наконец, позвольте мне признать, что организации может быть трудно принять концепцию открытого анализа проектов. В компании Twilio она стала обычной частью рабочего процесса, но это потребовало значительных усилий и широкого информирования коллектива. Если вы решите принять эту политику, знайте, что вам потребуется поддержка высшего руководства организации. Она должна быть видимой и постоянной, чтобы такая политика укоренилась.
Наш формат и стратегия открытого анализа проектов взяты из практики, которую уже давно используют в Amazon и называют «Еженедельный бизнес-обзор». Энди Джесси, возглавляющий AWS, проводил подобные обзоры уже в первые дни существования этой облачной платформы, и, на мой взгляд, именно ими объясняется большая часть нынешнего успеха компании.
Это было еженедельное совещание, на которое собирались директора всех служб. В мое время там присутствовало порядка 10 человек, сегодня их, наверное, несколько сотен. Энди просматривает показатели работы каждой команды. Наткнувшись на какой-нибудь провал, он останавливается и спрашивает руководителя, почему показатели плохие и что он делает, чтобы исправить ситуацию.
Суть этого действа в следующем. Когда у руководителя направления есть ясное объяснение проблемы и того, что предпринимается, он со всей очевидностью оказывается на коне и хорошо выглядит на фоне остальных. Но еще важнее то, что все остальные понимают, как выглядит превосходство. Показатели когда-нибудь неизбежно пойдут наперекосяк, главное, уметь выйти из положения.
Конечно, есть и прямо противоположные сценарии — моменты, когда руководитель не знает или не может объяснить, почему показатели удручающие. Это плохо. Каждый должен знать свое дело. Или, может быть, он знает, что именно идет не так, но у него нет действенного плана исправления ситуации. Это тоже плохо.
Энди не жалеет времени на то, чтобы вникнуть в ситуацию, помочь руководителям направлений — иногда, если честно, принудительно — понять, как лучше управлять бизнесом. Эти совещания — почти легендарное явление в AWS, потому что чем лучше вы подготовлены, тем лучше команды справляются с делами, а еще и потому, что это мастер-класс по искусству быть собственником. Именно такая открытая обучающая среда способствует инновациям и успеху.
Сложность состоит в создании условий, при которых обратная связь в этой открытой среде не приводит к возникновению атмосферы страха. Вот где «открытая» часть играет решающую роль. Руководитель должен исходить из того, что его команда делает все от нее зависящее, а если кто-то из ее членов не готов к этому, ему (как и всем остальным) должна быть ясна неприемлемость такого отношения. Однако руководитель не должен унижать подчиненного. Унизить — просто, но это заставит всех закрыться. Очевидно, что лучше ждать от подчиненного достижений и решительно, но доброжелательно показать ему и остальным, как справиться с проблемой.
Чи не устает подчеркивать это, повторяя: «Каждый день мы ставим себе цель — иметь меньше неудач, чем вчера». Это звучит как высказывание разочарованного руководителя, но на самом деле довольно точно передает мысль: «Мы не идеальны, но хорошо делаем свою работу, пока учимся и совершенствуемся».
Если тот же сотрудник приходит на следующей неделе с той же проблемой и тем же негодным решением, вот это уже проблема. Он не учится. У него тот же набор неудач, что и вчера. Повторная неудача, безусловно, является проблемой и требует разговора о личной результативности. Но эта часть не открытая, это уже индивидуальное дело.
Встречи с Энди Джесси, с пристрастием расспрашивающим о делах, обеспечили отличное и быстрое образование. Его подход похож на тот, что профессора в аспирантуре (особенно на юридических факультетах) используют уже более столетия. Впрочем, появился он еще в V в. до н.э. Это сократический метод, названный в честь древнегреческого философа Сократа.
При таком режиме обучения студенты приходят в аудиторию, надо думать, подготовившись к теме, а преподаватель вызывает их и устраивает быструю дискуссию. Сократический метод нацелен на выработку умения критически мыслить и с ходу приводить аргументы. Мои сокурсники называли это «прокачкой перед группой». Напряжение было очень высоким, но этот процесс помогал нам научиться задавать сложные вопросы и отвечать на них перед всей группой. Почему сократический метод не теряет актуальности вот уже 2500 лет? В фильме «В погоне за корочкой» великий актер Джон Хаусман в роли профессора Гарвардской школы права Чарльза Кингсфилда объясняет: «Мы используем здесь сократический метод. Я вызываю вас, задаю вопрос, и вы отвечаете на него. Почему я просто не читаю вам лекцию? Потому что мои вопросы приучают вас учиться самостоятельно».
Это как раз то, чего мы хотим видеть в своих компаниях. Мы хотим научить сотрудников тому, как учиться самостоятельно. В этом и заключается суть обучающей среды. Мы вырабатываем образ мышления, умение анализировать и решать проблемы. Сократический метод так же эффективен при решении деловых проблем, как и при рассмотрении сложных юридических вопросов.
Следует отметить, что программы в магистратуры славятся тем, что заставляют студентов чуть ли не плакать. В фильме «В погоне за корочкой» первокурсник, потерпевший интеллектуальный разгром от Кингсфилда на глазах у сверстников, бежит в туалет, чтобы поблевать. Я, конечно, не сторонник такого радикализма. Но тот же подход, что используется в высших учебных заведениях, вполне можно применить и для обучения руководителей в бизнесе. Он гораздо эффективнее семинаров и штудирования книг.
Мы часто говорим о том, как научиться принимать решения в контексте бизнес-планирования, но как быть, когда дела идут не так? Вы и сами это знаете — в техническом подразделении подобное может случиться, когда серверы выходят из строя и продукт страдает от этого сбоя. Но перебои не единственные виды неудач: это может быть провал интеграции после слияний и поглощений, финансовая модель, которая не принесла ожидаемых результатов, или ошибочно нанятый на работу руководитель. Существует бесчисленное множество ошибок, которые мы совершаем как индивидуумы, команды и организации. То, как руководители и компания в целом справляются с такими ситуациями, имеет большое значение для формирования отношения сотрудников к ошибкам и улучшения результатов деятельности компании или, как сказал бы Чи, «уменьшения числа неудач».
Когда дела идут наперекосяк, люди начинают либо обвинять друг друга, либо учиться. Я считаю, что неудача — это возможность глубже узнать, как работает организация и что может ее укрепить, а затем принять соответствующие меры. Мы, как и многие другие софтверные компании, делаем это с помощью ритуала, называемого «безупречное вскрытие». Его цель — докопаться до первопричины плохого результата и взяться за ее устранение всей организацией. Вот как это работает.
Возьмем самую распространенную проблему. Разработчик допускает ошибку в коде, который попадает на рабочие серверы и обрушивает сайт. Прежде всего вашим командам необходимо выявить плохой код и вернуться к более ранней версии, чтобы восстановить сервис. Очевидно, что это первоочередная задача. Но после восстановления нужно выяснить, что пошло не так и привело к заметному для клиентов сбою.
Чаще всего начинают обвинять разработчика в том, что он допустил ошибку. Это совершенно инстинктивное побуждение, но оно в реальности ничего не дает. Когда работники, даже лучшие инженеры, совершают ошибки, они, поверьте мне, и без того чувствуют себя ужасно. Обвинения лишь подчеркивают, что они — люди, и отбивают охоту к созданию программ, как минимум для вашей компании. Допущенная ими ошибка — очевидная причина падения сайта, но истоки сбоя заключаются не в ней. Подлинная проблема лежит глубже — а именно в организации работы. Поэтому вместо предъявления обвинений нужно задавать вопрос: почему, когда всем известно, что люди неизбежно совершают ошибки, «система» допустила нанесение вреда клиентам? Ответ на этот вопрос приведет вас к первопричине или — что более вероятно — к множеству первопричин.
Чтобы добраться до истины, нужно постоянно спрашивать «почему?». Обычно мы начинаем с простого: «Почему произошел сбой клиентского сервиса?» Ответ очевиден: «Инженер включил в рабочую программу ошибочный код». Теперь поинтересуйтесь: «Почему ошибочный код в рабочей программе привел к падению сайта?» Возможно потому, что ПО не обладало достаточной степенью защиты — действительно надежное ПО могло обнаружить проблему и продолжить работать, пусть и усеченным образом. А может быть, потому, что даже надежное ПО не могло выжить, и тогда возникает вопрос: «Почему ошибочный код попал в рабочую программу?» Ответ может быть следующим: «Потому что код недостаточно тестировался». Было бы легко остановиться здесь и поднять на мачте вымпел «Задача выполнена», но дело еще не доведено до конца. Почему? Да потому, что это всего лишь хорошо замаскированная версия обвинения разработчика. Если бы он или, возможно, инженер по обеспечению качества написал более полные тесты, то проблемы можно было бы избежать. Итак, вы продолжаете: «Почему код пошел в рабочую программу, если было известно об отсутствии эффективного тестирования критического фрагмента кода?»
Ну вот, теперь кое-что понятно. Первопричина редко носит технический характер — она организационная. Как наша организация допустила, чтобы этот человек смог навредить клиенту и бизнесу? Представьте себе атомную электростанцию с большой кнопкой «Расплавление активной зоны реактора», расположенной прямо посередине панели управления. Техник случайно ставит чашку чая на эту кнопку, ну а дальше понятно, что происходит. Вы обвините техника? Скорее всего, вы спросите, почему эта кнопка вообще существовала! Вот и здесь то же самое. Почему «система» позволила встроить в рабочую программу плохо протестированный код? Возможно, это произошло потому, что ваша инфраструктура тестирования настолько несовершенна, что должное тестирование очень трудоемко и инженеры регулярно обходят его в интересах прогресса. Если это так, то создание хорошей инфраструктуры облегчит корректировку ПО и позволит инженерам удовлетворять запросы клиентов, причем с помощью хорошо протестированного кода. Или, может быть, организация не вкладывала деньги в повышение квалификации инженеров? В конце концов, вы доберетесь до истинной системной первопричины и сможете решить эту проблему.
Это важно, поскольку обращение к поверхностной причине позволяет устранить лишь ее. Возможно, с помощью какой-нибудь драконовской меры и удастся удержать конкретного разработчика от повторения ошибки. Однако другие инженеры ничему не научатся. Это сродни удалению одной из сотен кнопок «Расплавление активной зоны реактора» на панели управления. У вас, скорее всего, произойдет еще одна авария. Обращение к первопричине позволяет устранить предпосылки не только прошлого, но и следующего сбоя. Повторяя этот процесс, вы системно укрепляете свою организацию.
Я привел технический пример, потому что практика безупречного вскрытия чаще встречается в технологических организациях. Однако я видел, как этот метод применяется в разных частях нашей компании, и везде он работает одинаково.
В 2010 г. стартап в составе 10 человек под названием Uber (в то время — UberCab) стал клиентом Twilio. На протяжении нескольких лет он демонстрировал стремительный рост, и к тому времени, когда мы стали публичной компанией в 2016 г., приносил более 10% нашей выручки и играл значительную роль в рекламной кампании нашего IPO. В 2016 г. Uber продолжал расти стремительными темпами и довел свои годовые расходы почти до $60 млн, что было неразумно, особенно с учетом смещения фокуса с «роста любой ценой» на снижение затрат. С точки зрения экономии мы были очевидной мишенью. В начале 2017 г. Uber заявил, что начнет сокращать свои расходы с нас. Во время телеконференции, посвященной финансовым результатам за первый квартал 2017 г., мы сообщили инвесторам, что крупнейший клиент, который стоял на первом месте в нашем проспекте эмиссии акций, решил сократить расходы на наши услуги. Это было плохо. Стоимость наших акций упала более чем на 30% за один день. Наши сотрудники были ошеломлены. Оглядываясь назад, понимаешь, что это была кратковременная неприятность, поскольку у компании были и другие клиенты. В первом квартале 2020 г. наша выручка оказалась больше на 400% с лишним при снижении концентрации крупных клиентов с 30% в 2016 г. до 14% в 2019 г. Это был явный промах для нашей новой, публичной компании, причем промах, который мы не хотели повторять.
Я попросил нашего тогдашнего финансового директора Ли Киркпатрика провести «безупречное вскрытие». Финансовая команда раньше не сталкивалась с такой задачей, поэтому мы обратились к Джейсону Худаку, нашему руководителю технической инфраструктуры (с которым вы познакомитесь в главе 11) с просьбой возглавить этот кросс-функциональный процесс. Мы начали не с вопроса «Почему у нас случился сбой в отношениях с клиентом?» — на этот раз вопрос звучал так: «Почему у нас произошла такая неприятность в отношениях с инвесторами?» Было бы легко обвинить торгового представителя, отвечающего за взаимодействие с Uber, но, как вы можете видеть, это не было первопричиной. «Наш крупнейший клиент решил сократить затраты, и мы раскрыли этот факт инвесторам». «Почему?» В конце концов все свелось к следующему. Прежде всего у нас было небольшое число клиентов, которые из-за нашей модели ценообразования, основанной на фактическом использовании продукта, стали слишком крупными и, следовательно, представляли для нас риск. Нам нужно лучше управлять «концентрацией клиентов», даже если это означает активное снижение цен. Другая первопричина заключалась в том, что у нас не было достаточного количества торговых представителей для взаимодействия со всеми клиентами. В то время у нас было всего около 15 торговых представителей с квотами по 36 000 существующих и потенциальных клиентов. Понятно, что наших торговых представителей не хватало на всех, в том числе и на крупнейшего клиента, тратившего более $60 млн в год. Итак, вторая первопричина нашей неудачи заключалась в недостаточном внимании к клиентам с нашей стороны. С той поры число наших торговых представителей выросло с 15 человек до многих сотен, а наша выручка увеличилась с $277 млн в 2016 г. до более чем $1,1 млрд в 2019 г., вклад крупнейших 10 клиентов при этом снизился вдвое.
Открытая обучающая среда, помимо прочего, позволяет готовить следующее поколение руководителей. Безусловно, существует и традиционная подготовка, предполагающая посещение семинаров или занятий. Но настоящая подготовка — это обучение в процессе работы. Вы не научитесь плавать, просматривая видео и слушая лекции. Плавать учатся, ныряя в бассейн.
В Amazon большинством инициатив руководит директор. Там есть директора, управляющие крупными направлениями, такими как розничный бизнес Amazon или AWS, которые приносят компании десятки миллиардов долларов. Эти директора мудры и опытны. Но Amazon доводит идею до крайности. Большинство компаний имеет лишь несколько директоров высшего уровня. Их подчиненные выполняют свои функциональные обязанности, а директора отвечают за финансовые результаты. В Amazon, в отличие от этого, директора управляют рабочим процессом на каждом уровне. Директора подчиняются другим директорам. Одни из них находятся на седьмом уровне шкалы оплаты труда, а другие — на третьем. В дополнение к тому, что они являются «однопоточными лидерами», которые отвечают за сроки и направления деятельности, директора получают возможности обучения по всей Amazon.
Я часто представляю себе (реального или вымышленного) человека в Amazon, который управляет магазином шин (Amazon действительно продает шины). Это молодой талантливый человек, которому доверили работу директора магазина шин. Торговля шинами — крошечная часть бизнеса Amazon, так что это должность с низким риском, на которую можно поставить молодого руководителя. Но для молодого руководителя — это шанс всей жизни. Задумайтесь, насколько вероятно, что свежеиспеченному обладателю степени MBA предложат место генерального директора в компании по торговле автомобильными запчастями Pep Boys или в другом месте? А вот Amazon идет на риск и предоставляет учебную площадку. Пусть какое-то время магазин шин будет испытывать трудности, но это хороший способ обучения. Если же неурядицы с магазином шин затянутся, то, возможно, потребуется новый руководитель. Но есть ли лучший способ обучения армии будущих руководителей, чем доверить им бразды правления частью вашего бизнеса? И все, что для этого нужно, — предоставить право управлять и принимать решения.
В компании Amazon я некоторое время был директором сервиса SQS (Simple Queueing Service), который представлял собой первый общедоступный продукт платформы AWS. До запуска этот сервис имел, естественно, нулевой доход, а после стал приносить несколько тысяч долларов в месяц. Это не так уж и много, но все же для успеха сервису требовался рулевой. Но для Amazon успех или неудача этого сервиса не имела особого значения — что такое несколько тысяч долларов для гиганта вроде Amazon? Даже если бы сервис оказался неимоверно успешным, он все равно не был бы движущей силой Amazon.
Так зачем же ставить во главе сервиса 27-летнего человека и отдавать ему бразды правления? Это была учебная площадка. Я учился быть директором и владельцем, когда на кону стояло не так уж и много. В случае успешного обучения я смог бы двигаться дальше и взяться за что-то большее. Я не уверен, но подозреваю, что сегодня в Amazon таких директоров тысячи. Это та резервная команда, которую компания обучает с тем, чтобы сделать их директорами и хозяевами следующей волны идей Amazon. На мой взгляд, это одна из основных причин постоянного успеха компании. Когда появляются новые идеи, уже есть армия бизнес-руководителей, готовых реализовать их.
В большинстве случаев сотрудники, являющиеся отличными специалистами в таких сферах, как проектирование, продажи или финансы, продвигаются по службе до тех пор, пока однажды они не становятся директорами крупного бизнес-подразделения. В такой системе предполагается, что компетентность в одной области (проектирование, продажи, финансы и т.д.) перерастает в компетентность в другой области — а именно в компетентность директора. Иногда это верно, но очень часто — нет. Есть даже термин для этого — «принцип Питера». Это идея о том, что люди растут вплоть до уровня некомпетентности. Это становится очевидно, стоит только задуматься об этом: чтобы быть владельцем бизнеса, необходим уникальный набор навыков. Владелец — это не просто великолепный специалист по продажам или блистательный инженер. Ему нужны знания и квалификация, которые приобретаются в процессе обучения.
Открытая обучающая среда является ключом как к созданию успешных продуктов в условиях неопределенности, так и к взращиванию талантливых руководителей, которые необходимы компании для успеха. Доверяя управление сотрудникам, вы превращаете их в собственников рабочих процессов.
Многие компании помогают сотрудникам учиться, организуя такие мероприятия, как короткие семинары в неформальной обстановке, выездные курсы лидерства или онлайн-тренинги. Но я считаю, что наиболее эффективно обучение в процессе работы, и руководство должно допускать людей до управления. Ищите проекты, в которых ставки невелики, где обучающийся может запороть несколько некритических позиций без особого вреда, но приобрести на этом опыт. Помните директора магазина шин в Amazon? Вряд ли можно ожидать, что обучающийся руководитель будет делать все идеально, но это нормально. Вам не нужна такая рабочая среда, где людей отстраняют или наказывают за ошибки. Подумайте о том, что такой подход покажет следующему работнику, которому вы предложите взять на себя руководство заданием. Он надолго запомнит, как обошлись с его предшественником, когда тот допустил ошибку.
Подобные назначения больше связаны с обучением, чем с получением быстрых результатов. Когда мы работаем с компаниями, которые пытаются стать создателями, мы рекомендуем им начинать с малого. Выберите скромный проект, который не является критически важным, — нечто, что было бы приятно иметь, что принесет результат и не займет много времени. Главное, выбрать такой проект, где команда может потерпеть неудачу или не достичь цели, но это не нарушит нормальную работу.
Хорошим примером служит проект в компании Target, которым занимались Джош Хойум и его команда из отдела голосовых технологий. Осенью 2018 г. в отделе кадров Target возникла проблема: оползни в Южной Калифорнии вынудили Target закрыть несколько магазинов, но у менеджеров не было подходящего способа оповещения сотрудников о том, что нужно оставаться дома. Иногда они ехали на работу, подвергая себя опасности, и обнаруживали, что магазин закрыт. Отдел кадров хотел не просто рассылать предупреждения сотрудникам, но и получать ответ от них. В чрезвычайной ситуации это позволило бы компании удостовериться в том, что сотрудники находятся в безопасности, а сотрудникам — отправить просьбу о помощи в случае необходимости. Было очень важно, чтобы сообщение доставлялось немедленно, а электронная почта не подходила для этого.
У Target имелась система оповещения, но она была не очень эффективной. Сотрудники могли узнать, открыт ли магазин, позвонив в систему голосовой почты, а затем получив через меню записанное сообщение о статусе магазина. Однако сотрудники часто не утруждали себя звонками. Отдел кадров хотел взять инициативу в свои руки и рассылать SMS с оповещениями на мобильные телефоны.
Отдел кадров нашел готовую систему и решал, что лучше всего просто купить ее. Однако это ПО было дорогим и на самом деле делало не все из того, что хотела компания. Хойум заявил отделу кадров, что его команда сама создаст приложение для экстренного оповещения.
Джош увидел в этом отличную возможность использовать проект для обучения всей команды. Проект был относительно небольшим и низкорискованным. Даже если разработчики Джоша потерпят неудачу, то у Target останется старая система как запасной вариант. И у них всегда была возможность купить готовое решение. Нужно всего несколько недель, чтобы выяснить, справятся ли с этой задачей штатные инженеры Target.
Обучающий аспект проекта заключался в том, что приложение нужно было написать на языке Python, которого не знал ни один из четырех инженеров, выделенных для осуществления проекта. На самом деле они не были разработчиками ПО. Они занимались управлением коммерческих систем компаний Cisco, Avaya и других. Такой опыт раньше был очень востребованным, но со временем становится все менее ценным.
Проект системы оповещения давал этим четырем инженерам возможность освоить новый язык, что повышало их ценность как специалистов. Хитрость заключалась в отказе от привычной последовательности: сначала изучение языка Python, а затем работа над приложением. Инженеры просто погружались в работу и начинали писать код и изучать Python по ходу дела — чистый пример подхода «обучение в процессе работы». Как рассказывает Джош, сотрудники отдела кадров скептически отнеслись к способности штатных инженеров создать подобное приложение. Да и сами инженеры были не в восторге! «Мне не сразу удалось убедить их, что это действительно то, чем мы должны заниматься, — вспоминает Джош. — Во всяком случае надо попробовать».
Невероятно, но у нас все получилось. За шесть недель эти четыре новичка-разработчика создали работающий прототип приложения. А через неделю оно было запущено в эксплуатацию в 1800 магазинах Target на всей территории Соединенных Штатов. Это маленькое приложение оказалось очень важным. Осенью 2019 г., когда в Калифорнии вспыхнули лесные пожары, оно стало настоящим спасением, поскольку позволило менеджерам магазинов поддерживать контакт с сотрудниками, оповещать их о закрытии магазинов и таким образом предотвращать небезопасные поездки. Помимо прочего, эта история оказала большое влияние на карьеру четырех упомянутых инженеров и, по словам Джоша, «убедила их в том, что они могут писать программы».
Компания Target взяла на себя большие обязательства по профессиональному обучению и повышению образовательного уровня. Каждый сотрудник ИТ-отдела посвящает 50 дней в году обучению — а это очень много! Часть знаний они получают из книг, на занятиях и семинарах, но основное — это обучение в процессе работы. Джош приобщился к созданию искусственного интеллекта, построив пару нейронных сетей, которые Target теперь использует в ряде приложений. «Возможности обучения возникают потому, что мы идем на риск, например, спрашиваем себя: “А можно ли попробовать то-то и то-то и посмотреть, что произойдет в небольшом масштабе, где не нужно ставить на кон все?”» — говорит Джош.
Мы в Twilio считаем, что инвестиции в людей дают преимущество в поиске технических талантов на высококонкурентном рынке. Например, технические курсы (буткампы) ежегодно выпускают массу перспективных разработчиков, однако многие компании не хотят вкладывать средства в их наем и продолжение обучения и, таким образом, упускают этот богатый источник талантов. Буткампы — это короткие программы, от трех месяцев до года, по обучению людей разных профессий, которые хотят стать разработчиками. На буткампы часто идут потому, что видят карьерные перспективы в сфере программирования или хотят получить работу более технического характера. В отличие от четырехлетнего бакалавриата, выпускники буткампов проходят ускоренный курс программирования и осваивают навыки, необходимые для создания сайтов и приложений. Еще одно достоинство буткампов заключается в том, что они приводят людей других профессий в технологическую индустрию.
Я преклоняюсь перед выпускниками буткампов, поскольку они выбрали невероятно трудный путь в сферу программирования — решились на смену карьеры и зачастую оставили неплохо оплачиваемую работу, чтобы переучиться и овладеть новой профессией. Когда мы смотрим на резюме, то обычно оцениваем кандидата с точки зрения положения: учился ли он в элитной школе, работал ли в престижных компаниях и т.д. Все это атрибуты положения человека, которые ничего не говорят о пройденном им пути. На мой взгляд, многое о мужестве и способностях кандидата сказало бы то, что он был, например, первым в своей семье, кто окончил колледж. Это называется «пройденное расстояние», и если смотреть, насколько далеко кандидат ушел в жизни как на показатель его потенциала, то выпускник буткампа должен занимать высокое место.
Многие компании не решаются нанимать выпускников буткампов по той причине, что у них только трех-, шести- или 12-месячный опыт программирования, но с готовностью и в большом количестве принимают 21-летних выпускников колледжа после четырех лет обучения. Некоторые все же нанимают выпускников буткампов, но бросают их сразу в пекло, полагая, что они смогут работать наравне с другими, более опытными инженерами. Понятно, что многим это не удается, и они быстро уходят из компании, что является двойной потерей. Это потеря для компании, которая не смогла использовать ценного работника, а также, что более важно, потеря для самого работника, который теряет надежду начать новую карьеру.
Поэтому наша компания запустила программу стажировки под названием «Инкубатор талантов», в рамках которой мы предлагаем шесть месяцев платного обучения для выпускников буткампов как переходный период между обучением и реальной работой. Участники в течение первых трех месяцев занимаются практическими разработками под руководством менеджера, чья задача заключается в обучении и помощи в приобретении необходимых навыков. Их допускают к внутренним проектам, что менее рискованно, чем работа с продуктами для клиентов, и к проектам для некоммерческих организаций. Для многих это первый опыт написания реального кода, и они учатся невероятно быстро, особенно с менеджером, единственной целью которого является успешный результат стажировки.
Следующие три месяца стажеры проводят в команде Twilio, занимающейся разработкой продуктов в порядке спонсорства. Они входят в команду как полноправные инженеры, однако остаются стажерами. Их менеджер знает, что они еще учатся, и помогает им добиться успеха. Менеджер заинтересован в успехе стажировки — ему выплачивается премия в размере полугодовой зарплаты за стажера. В конце стажировки менеджер может предложить стажеру штатную должность. Более 90% выпускников «инкубатора» становятся штатными разработчиками Twilio. На мой взгляд, одна из причин их успеха в том, что решаются пройти подобную программу в основном те, кто готов принимать риск и самостоятельно мыслить, а именно из таких людей и получаются великие разработчики.
Лучший показатель будущих достижений — пройденный путь. Нам нужны люди, которые хотят учиться, и выпускники буткампов, меняющие профессию в середине карьеры, демонстрируют именно такую готовность. Вот почему мы инвестируем в «Инкубатор талантов» и другие программы обучения.
Я вижу цель нашей корпоративной культуры в создании армии сильных, стремящихся найти истину и принимающих хорошие решения руководителей. Чем больше у наших команд разработчиков возможностей задавать правильные вопросы, не обращая внимания на политику и титулы, и находить лучшие ответы, тем больше у нас шансов справиться со сложными проблемами и качественно обслуживать клиентов. Рассмотрим альтернативу. Правительство исторически было оплотом крупных проектов, большой политики и главным объектом для упреков. Независимо от того, каким вы видите правительство — с минимальным вмешательством в нашу жизнь или вездесущим, вряд ли кто будет спорить с тем, что большинство правительств нельзя назвать новаторскими. Почему? Что происходит, когда у правительства что-то не получается? Вместо быстрого обучения и постепенного решения проблемы, членов правительства тащат в конгресс и засыпают вопросами в программах национального телевидения. Это просто первенство по игре на зрителя. Как, на ваш взгляд, это сказывается на моральном духе организации и ее готовности к риску? Естественно, никто не хочет, чтобы ему устраивали порку в конгрессе, поэтому он, можно не сомневаться, никогда не будет высовываться. Это приводит к тому, что члены правительства всегда принимают самые безопасные решения и стараются избежать ответственности.
Большинство руководителей хотят иметь корпоративную культуру как у Google, Apple или Facebook, а не как у федерального правительства США. Но спросите себя: когда у людей случаются ошибки, вы проводите безупречные вскрытия или вытаскиваете их на суд конгресса (т.е. высшего руководства)? Поощряете ли вы быстрое обучение, несмотря на риск ошибок? Предоставляете ли вы площадки для обмена опытом и рискуете ли предоставить молодым лидерам возможность управлять частями вашего бизнеса? Мы допускаем ошибку, «выставляя команды перед конгрессом». Человек склонен раздражаться и ковыряться в чужих промахах. Некоторые из моих ежеквартальных деловых обзоров в прошлом даже называли «Инквизицией». Но это не цель, это неудача. Моя работа как лидера состоит в том, чтобы создать среду, в которой руководители ощущают постоянное мягкое давление и поддержку стремления разобраться с проблемой.
Какая обстановка у вас? Узнать это просто: поинтересуйтесь у своих руководителей, что происходит после сбоя. Я имею в виду не «восстановление работы сайта», а последующие действия. Кого считают виновным — человека или процесс? Спросите своих руководителей: «Есть ли у вас такие части бизнеса, управление которыми можно доверить будущим директорам?» Если вы слышите возражения, спросите: «Что плохого может случиться?» Если у вас есть небольшая и проблемная часть бизнеса, вы, скорее всего, хотите от нее избавиться. А если отдать ее перспективному директору и посмотреть, что произойдет за полгода? Спросите своих технических руководителей, готовы ли они проводить открытый анализ проектов, как это делает Чи. Разве плохо расширить число участников открытого анализа, если это не наносит вреда? Попробуйте выяснить у своих команд, что их больше мотивирует — шансы на успех или избежание неудач. Эти вопросы помогут понять, ориентирована ли ваша корпоративная культура на обучение и поиск истины.
Открытая обучающая среда, о которой я говорю, нацелена на подготовку лидеров. Мы не идеальны, но постепенно приближаемся ко все более и более открытой обучающей среде. Или, как сказал бы Чи, с каждым днем у нас «все меньше неудач». На мой взгляд, все должно быть именно так.
Войти с помощью соц. сетей: