Добрый день, меня зовут Павел Поляков, я Principal Engineer в каршеринг компании SHARE NOW, в Гамбурге в ???????? Германии. А еще я автор телеграм канала Хороший разработчик знает, где рассказываю обо всем, что обычно знает хороший разработчик.

Сегодня хочу поговорить о принципах лидерства в Amazon. Что это такое и как они помогают разработчикам в Amazon делать свою работу эффективно? Это перевод оригинальной статьи.

Как разработчику применять принципы лидерства Amazon

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

16 принципов лидерства

Принципы лидерства это ДНК Amazon, они определяют как Amazon работает в целом. Можно сказать, что 16 принципов это столпы, на которых строится работа Amazon. Простой пример — представим, что идет обычная дискуссия о том, как решить какую-то проблему. Команда состоит из множества людей и у всех разная экспертиза. Конечно же, рано или поздно встретятся разногласия. Чтобы разрешить эти разногласия, сотрудники Amazon, прямо во время дискуссии, будут ссылаться на принципы лидерства. И это поможет разрешить спор. Прежде всего стоит сказать, в технологических компаниях как Amazon, люди стремятся завершить дискуссию составлением какого-то плана действий. Дискуссия может продолжаться, но люди будут фокусироваться на задачах, которые можно сделать, чтобы исследовать предмет дискуссии дополнительно или решить проблему. Такой подход базируется на принципе лидерства Действуй, который говорит что действие лучше бездействия.

На данный момент определено 16 принципов лидерства:

  • Одержимость клиентом (Customer Obsession)

  • Владей (Ownership)

  • Изобретай и упрощай (Invent and Simplify)

  • Быть правым часто (Ara Right, A Lot)

  • Учись и будь любопытным (Learn and Be Curious)

  • Нанимай и развивай лучших (Hire and Develop the Best)

  • Настаивай на высоких стандартах (Insist on the Highest Standards)

  • Мысли масштабно (Think Big)

  • Действуй (Bias for Action)

  • Бережливость (Frugality)

  • Заработай доверие (Earn Trust)

  • Погружайся глубоко (Dive Deep)

  • Имей принципы (Have Backbone)

  • Не согласись, но участвуй (Disagree and Commit)

  • Приноси результаты (Deliver Results)

  • Стремление быть лучшим работодателем в мире (Strive to be Earth’s Best Employer)

  • Успех и масштаб это большая ответственность (Success and Scale Bring Broad Responsibility)

Пару лет назад этот список состоял из 14 пунктов. Но потом Amazon добавила еще два принципа Стремление быть лучшим работодателем в мире и Успех и масштаб это большая ответственность. Актуальные принципы можно найти здесь.

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

Что разработчики делают на работе

Часто, когда люди слышат "разработка программного обеспечения", то они представляют себе программирование. Кто-то пишет код, чтобы реализовать бизнес требования. Но разработчики делают еще и кучу другой работы.

Митинги, менеджмент и операционная деятельность

  • Обсуждение продукта

  • Обсуждение технологий

  • Написание документации

  • Организация технической работы

  • Планирование технических проектов

  • Работа над метриками, создание дэшбордов

  • Исследования, чтобы понять как реализовать новую фичу

  • Участие в интервью с кандидатами

Поддержка кода

  • Работа с техническим долгом

  • Обеспечение надежности системы

  • Просмотр merge request

Тестирование

  • Написание тестов

  • Мануальное тестирование

  • Интеграционное тестирование

Безопасность

  • Тестирование с точки зрения безопасности

Написание кода

  • Реализация новых фич

  • Исправление багов

Спектр того, что делает разработчик ПО очень большой. Некоторые пункты зависят от того с чем работает ваша команда или компания. Но в целом, каждый разработчик иногда делает что-то из списка. Как же мы можем применить принципы лидерства к этим разнообразным активностям?

Как применять принципы лидерства в ежедневной работе

Создание фич или исправление багов

Обычно когда мы делаем фичи или исправляем баги, то речь в первую очередь идет о программировании. Здесь могут помочь несколько принципов лидерства.

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

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

Настаивай на высоких стандартах

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

Приноси результаты

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

Обсуждение продукта и технологий

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

Быть правым часто, Одержимость клиентом

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

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

Мысли масштабно и бережливость

Во время обдумывания новых фич или технических решений, всегда спрашивайте себя: как это будет работать через 3-5 лет? Спросите себя и запланируйте обсудить со своей командой что они думают. Очень важно получать обратную связь. Дополнительно, запишите что вы думаете, так, чтобы это осталось где-то в документации. Напишите документ с предложением продукта или фичи, в котором есть 5-летний план. Это приносит пользу и понравится всем.

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

Не согласись, но участвуй

Вы не обязаны соглашаться со всеми принятыми решениями, но если решение принято, вы должны помогать в его реализации. В будущем может быть принято другое решение.

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

Написание документации

Написание документации это недооцененный скилл разработчика. Писать тексты в целом сложно. А писать хорошую документацию еще сложнее. К счастью, есть хорошие гайды о том, как писать понятную документацию, например этот от divio: "Система документации". Но кроме структуры документации важны и другие вещи, они как раз и относятся к принципам лидерства.

Одержимость клиентом, Погружайся глубоко

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

Владей

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

Заработай доверие

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

Какие выводы можно сделать? Хороший разработчик регулярно пишет документацию. Запланируйте время раз в неделю, чтобы написать что-то для своей команды или для компании, чтобы ваши продукты были более понятны.

Планирование проектов

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

Владей

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

Действуй

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

Бережливость, Приноси результаты

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

Успех и масштаб это большая ответственность

Вы, наконец, закончили проект. Теперь пришло время измерить успешен ли он. Метрики, по которым вы будете оценивать успешность проекта, должны быть определены еще в начале.

Резюмируем

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

Принципы лидерства на Performance Review

В Amazon Performance review происходит раз в год. Большая часть этого процесса это самостоятельная оценка, оценка от ваших коллег и обратная связь от менеджера, которую вы получите. Все это основывается на принципах лидерства. У коллег есть табличка, где принципы лидерства совмещены с определенными рангами в Amazon. На основе вашей прошлой производительности, они будут отмечать ваши сильные и слабые стороны.

Этот процесс очень сложный. Представьте, что вам нужно самостоятельно оценить свои достижения за прошлый год, основываясь на принципах, о которых мы говорили в этой статье. Вам будет это сложно сделать, мне будет это сложно сделать, это в целом сложно. Потому что наш мозг не может все это держать в голове. Есть инструмент, который может вам помочь — brag document. Лично я веду список всего хорошего, что я сделал на getworkrecognized. Я ставлю тэги на свои достижения, а потом могу посмотреть на картину в целом и соотнести свои достижения с принципами лидерства. Это очень помогает мне при составлении самостоятельной оценки.

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

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

Даже если вы не работаете в Amazon вы все равно можете последовать совету и завести brag document. Люди в целом любят документы, которые подтверждают необходимость чего-то. Например, мы ранее говорили про предложения фич или продуктов. Кстати, если вы составляли такие, не забудьте указать это в своем документе.

Применение принципов лидерства помогут вам стать Хорошим разработчиком. Вы заметите это сами, ваши коллеги заметят это, ваш менеджер это заметит.

А еще...

Здесь говорю опять я, Павел. В конце еще раз приглашу вас в свой Telegram-канал. На канале Хороший разработчик знает я минимум три раза в неделю простым языком рассказываю про свой опыт, хард скиллы и софт скиллы. Я 15+ лет в IT, мне есть чем поделиться. Все это нужно разработчику, чтобы делать свою работу хорошо, работать в удовольствие, быть востребованным на рынке и получать высокую компенсацию.

А для любителей картинок и историй есть ???? Instagram.

Спасибо ????

Комментарии (25)


  1. amarao
    11.01.2022 16:39
    +22

    Быть разработчиком в Amazon это ежедневное испытание на прочность

    Спасибо, анти-репутация компании подросла. Я предпочитаю комфортные условия работы, а не "испытание на прочность каждый день".

    /тред, /статья.


    1. PavloPoliakov Автор
      11.01.2022 16:43
      -1

      Ну тут каждый выбирает свое, с одной стороны испытание, с другой большее количество денег. Трейдофф.


      1. dopusteam
        11.01.2022 17:03
        +3

        Не всегда деньги и испытания корректируют


      1. amarao
        11.01.2022 17:28
        +12

        Не такие у них уж и большие зарплаты. Они хотят платить по рынку, а выжимать программистов, как будто они биороботы на складах Амаз... wait, oh shi...


        1. korobkov-k
          11.01.2022 19:03
          +3

          Тоже вспомнил про "биороботов" со складов (несчастных рабочих, вкалывающих сверхурочно на утомительной работе потому что кто-то захотел черную пятницу)
          И когда читаешь принцип "Стремление быть лучшим работодателем в мире (Strive to be Earth’s Best Employer)" то это прям настолько весело что не могу.. Я еще подумал что ок, как и везде айтишники в шоколаде и работают в отдельной от остального персонала среде, но не тут то было и сам же автор это подствердил, а затем и коментарии.


          1. Ommonick
            12.01.2022 14:28

            Starve to be Earth’s Best Employer*


    1. vadlit
      11.01.2022 16:44
      +13

      В оригинале предсказуемо используется слово challenged. В английском языке оно имеет несколько иную коннотацию, чем в русском, гораздо более позитивную. Что-то типа "вызов", "интересная задача", а не тупо как у нас "проверка на прочность" и т.п.

      Например challenging work обычно используются в хорошем смысле, а не в том, что каждый день будешь упахиваться


      1. PavloPoliakov Автор
        11.01.2022 16:50
        +4

        Да, вы правы. Но судя по тому что я знаю, от друзей которые работают в Amazon, проверка на прочность тоже подходит :)


    1. Stas911
      11.01.2022 22:39

      Амазон - огромный и у всех разные понятия об "испытании на прочность" (для кого-то это работать больше пары часов в день), тч я бы не стал так категорично утверждать.


      1. amarao
        12.01.2022 13:51
        +2

        Может быть. Но, в целом, оно звучит не очень привлекательно. С учётом, что на складах обстановка нечеловеческая, я по-человечески понимаю желание менеджеров сделать так же бесчеловечески эффективно и в других отделах.


    1. idelgujin
      12.01.2022 07:10

      У меня Амазон сейчас ассоциируется с фильмом "Земля кочевников". Конечно, это кино, но где-то я слышал о нечеловеческих условиях работы за копейки в компании Безоса


  1. laatoo
    11.01.2022 17:00
    +11

    Успешный успех, лидерское лидерство, продуктивная продуктивность, инфоцыганская инфоцыганскость, N вещей чтобы стать *кем угодно*, заголовки в побудительном наклонении…
    *Зевок*


  1. sets
    11.01.2022 17:03
    +1

    Нанимай чтобы увольнять — это какой из принципов лидерства?


    1. DarthVictor
      11.01.2022 18:37
      +14

      Это — принцип курятника. "Клюй ближнего, сри на нижнего".


  1. Maxmyd
    11.01.2022 18:20
    +4

    Во время обдумывания новых фич или технических решений, всегда спрашивайте себя: как это будет работать через 3-5 лет

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


    1. korobkov-k
      11.01.2022 19:05
      +2

      Вот-вот, а потом ПМы из таких корпораций очень завидут шустрым стартапам которые пилят 3 фичи, пока корпораты заседают на митингах по 6 часов в день и что-то там планируют :)


      1. Xop
        11.01.2022 19:48

        К сожалению по 6 часов митингов в день бывает и в стартапах


    1. PavloPoliakov Автор
      11.01.2022 23:52

      Я согласен. И одновременно согласен что представить хоть какой-то логичный план на 5 лет покажет что вы подумали о будущем. А это с какой-то вероятностью значит, что во время когда все изменится, вы опять сможете подумать о будущем.


  1. FlyingDutchman2
    11.01.2022 22:26
    +1

    Прочитал про Безоса:

    https://www.businessinsider.in/jeff-bezos-once-said-that-in-job-interviews-he-told-candidates-there-are-3-ways-to-work-and-at-amazon-you-have-to-do-all-3/articleshow/65343632.cms

    "When I interview people I tell them, 'You can work long, hard, or smart, but at Amazon.com you can't choose two out of three," Bezos wrote in the 1997 letter.

    Я уж лучше в обычной компании поработаю.


  1. leventov
    11.01.2022 23:39
    +4

    Разработчику не надо бездумно брать и применять любой принцип Амазона. Эти принципы работают в связке и тогда, когда все люди в компании (более-менее) работают по этим принципам, и процессы выстроены вокруг этих принципов.

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

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

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

    Вот хороший пост на эту тему: https://copyconstruct.medium.com/know-how-your-org-works-or-how-to-become-a-more-effective-engineer-1a3287d1f58d


  1. n2dt4qd2wg9b
    11.01.2022 23:53

    Перфоманс ревью у них называется OLR - Org Level Review и происходит два раза в год


    1. PavloPoliakov Автор
      11.01.2022 23:54

      В гугле пишут, что Organization and Leadership Review.


      1. n2dt4qd2wg9b
        12.01.2022 06:40
        +1

        Да, там собираются менеджмент и объявляют сколько процентов работников нужно выбросить на улицу. Так называемая URA-квота, в прошлом году была 10% в этом году - 6%. Потом идет жестокий stack ranking и через несколько месяцев необходимое количество людей оказывается на улице. Даже когда у тебя все в команде супер-пупер, ты каждый год должен выбросить на улицу. По-этому некоторые менеджеры специально нанимают сакральных жертв :)


  1. romangoward
    12.01.2022 03:05
    +7

    Один никогда не работал в Амазоне, но имеет мнение, второй не может в русский, но переводит с английского. ¯\_(ツ)_/¯


  1. Polaris99
    12.01.2022 15:54
    +2

    Быть разработчиком в Amazon это ежедневное испытание на прочность. Ожидается, что вы добиваетесь результатов и применяете принципы лидерства во время работы.

    Довольно несложный проект нашей фирмы с Амазоном благодаря этим принципам лидерства уже года 3 длится, все эти лидеры постоянно меняются, никто не в курсе того, что наделали предыдущие лидеры, все имеют свою точку зрения и готовы ее яро отстаивать, пока не уйдут на другой проект/другую фирму, ну и количество митингов и документов зашкаливает. Результата, правда, нет пока, но мы же можем подождать, верно? У других фирм длительность проекта с нашей стороны - около года и меньше. Знаете, я лучше как-то без амазоновских принципов, оно быстрее и проще получается.