Работа в Amazon преподала мне несколько ценных жизненных уроков, один из которых связан с сочетанием трех принципов лидерства — (1) ответственности, (2) предвзятости к действию (3) «изобретай и упрощай». Вот краткое изложение того, что каждый из них значит для меня:

Владение

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

Предвзятость к действию

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

Изобретайте и упрощайте

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

Что означает объединение всех трех?

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

У вас есть примеры из жизни, подтверждающие это?

Позвольте мне дать вам три. Первый — об инженере из моей команды в Amazon. Он был немного помешан на языках программирования, и ему нужно было попробовать каждый язык программирования, до которого он мог дотянуться. В этом случае он хотел построить и показать команде что-то на Kotlin, чтобы продемонстрировать, насколько легко работать с языком поверх чистой Java и адаптировать его к нашей существующей производственной системе. Поэтому было решено создать приложение, которое могло бы выполнять A/B-тестирование между двумя моделями ранжирования, контроль — это текущая модель, а лечение — новая модель. И его программное обеспечение запускало множество смоделированных запросов на разные продукты через две модели и распечатывало те запросы, результаты которых были разными. Тогда никто не знал, что это мгновенно станет хитом для научной команды, поскольку им нужен был инструмент для анализа радиуса взрыва их изменений, то есть, сколько продуктов будет затронуто, если они запустят свою новую модель в производство. У научной группы теперь был инструмент для имитации изменений модели и прогнозирования того, стоило ли вносить изменения в первую очередь. Инструмент изменит способ создания моделей в ближайшие дни, просто запуская симуляции, а затем помещая их в реальный мир и проводя реальный эксперимент A/B. Его процесс даже принес ему патент США и кучу научных публикаций для научной группы. Все это началось, потому что мой товарищ по команде решил прогуляться один и исследовать свое любопытство.

Далее один из моих экземпляров. Поэтому команда Science работала над новой моделью ранжирования, которая будет в большей степени основываться на данных, чем существующая модель, которая в большей степени основывалась на логике. И команде инженеров было поручено создать платформу, которая позволит научной команде запустить несколько итераций новой модели в производство, запустить ее через различные эксперименты A/B с использованием живого трафика и, наконец, запустить ее для всего трафика. Это была цель уровня вице-президента, которую нужно было запустить к определенной дате, и в ней участвовало несколько команд, поскольку это полностью изменило бы работу со страницей Продукты (или Подробности) на Amazon.com, сайте США, а затем вскоре последуют и другие регионы. . По мере приближения даты запуска Продукт уже понял, что Платформа никуда не денется, чтобы начать первый эксперимент. Тем не менее, они предполагали, что наш существующий процесс запуска моделей в производство и проведения эксперимента будет работать, а тем временем мы будем продолжать работать над платформой и использовать ее для следующей итерации. К сожалению, это оказалось неверным, так как существующее решение было несовместимо с новой моделью и ее конвейером и загнало всю команду в угол. Я помню, как мы были в комнате для совещаний с несколькими ключевыми заинтересованными сторонами, когда объясняли, почему нынешняя система не будет работать, и нам, возможно, придется сообщить руководству, что мы опаздываем. Внезапно я понял, что мы можем перепрофилировать некоторые из нашей системы управления конфигурацией и ее рабочие процессы, которые будут соответствовать этой платформе после ее создания, и использовать ее сейчас для запуска модели и начала эксперимента. Когда это услышали остальные старшие руководители, было видно, что они не были убеждены и решили составить условный план действий, т. е. сказать руководству, что мы все равно опоздаем. Один из продакт-менеджеров даже предупредил меня, что мне придется взять на себя полную ответственность за этот релиз, если я все еще настаиваю на запуске в текущую временную шкалу. Что-то во мне подсказывало, что все будет хорошо, и я прошел через это. В конце концов, настал день, когда военная комната была заполнена старшими руководителями, и даже наш директор решил присоединиться к нам в этот важный момент. И мы запустились с оглушительным успехом. Мы видели, как система управления конфигурацией добросовестно проверяет, анализирует и запускает модель в производство. Просто так все могли видеть изменения на странице Товары (Детали). После этого дня моя команда, команды партнеров и наше руководство слепо доверились системе управления конфигурацией.

Наконец, я расскажу о случае, когда я не решался прыгнуть и потерял возможность построить что-то великое. Это было, когда команда работала с другой командой над передачей данных о важных функциях из их системы в наш механизм ранжирования. Интеграция в масштабе оказалась слишком дорогостоящей, поэтому нам нужен был способ проведения экспериментов A/B, где мы могли бы генерировать как функциональные метрики, так и технические метрики, такие как время процессора, которые влияли на стоимость. Ранее я руководил командой, которая создала возможность экспериментов A/B для логических изменений, которая теперь использовалась для создания функциональных показателей. Тем не менее, не было возможности связать процессорное время с запросами, относящимися к контрольной и экспериментальной группам, что помогло бы нам сгенерировать техническую метрику. Раньше я думал об этом, но ничего существенного не делал. Но с этим новым проектом нам нужно было решение как можно скорее. Именно тогда один из инженеров из другой команды предложил дизайн и выглядел очень взволнованным, чтобы решить эту проблему. Хотя дизайн был хорошим, я немного скептически отнесся к тому, как мало времени у нас было на это, и к мысли о том, что мне придется поддерживать это с моей командой, если оно будет построено. Скептицизм подобен смеху; это очень заразительно, и вся группа начала сомневаться в этой идее и отказалась от нее. В конце концов, для получения этих цифр был использован специальный процесс, и эта функция никогда не была встроена в платформу.

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

Последние мысли…

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