Как работают в Амазоне по словам бывшего менеджера из Амазона, которому интересно продать свои консалтинговые услуги
Это саммари, краткий обзор лежит тут.
Найм
Цель процесса: каждый новый нанятый человек должен быть в чём-то лучше уже работающих в компании. За провод человека по серии интервью есть ответственный, которого компания тренирует и которому дала ментора (менторы часто не последние люди в компании), ответственные называются bar raisers.
Их задача не закрыть вакансию, а проследить, чтобы кандидата оценили правильно. Такая система вознаграждений убирает конфликт интересов у нанимающего менеджера и не даёт срезать углы. Разумеется, это значит, что вакансии закрываются дольше.
Принцип компании — лучше не нанять, чем нанять, но не того. В этот принцип Амазон инвестирует ресурсы на создание тренингов, время своих менеджеров (менторство) и длительные простои по вакансиям. Дорого, но прибыльно в долгосрочной перспективе.
Пример — Kindle и AWS. Ключевые вакансии под новые стратегические направления стояли пустыми по полгода. Потому что было важно нанять нужных людей
How Amazon hires (не самая информативная статья, но пусть будет)
Гайд по собеседованиям в Амазон.
Орг.структура
Single threaded leadership — смысл в том, что у команды и её менеджера есть одна задача, которую они решают, доступные ресурсы и автономия в принятии решений. Вместо координации и дирижирования усилий — устранение зависимостей. Технических и организационных. Чтобы построить работу таким образом Амазон несколько лет переписывал свои технические решения на другую архитектуру (не означает, что всем срочно нужно сделать также).
Принцип компании — вместо постоянных трат на синхронизацию, лучше один раз вложиться в автономность команд. Дорого, но прибыльно в долгосрочной перспективе.
Пример — AWS. AWS родился из партнёрки для разработчиков, за которую отвечала отдельная команда, у которой были все ресурсы, возможности и ответственность, чтобы поэкспериментировать с новыми фичами.
Пример 2 — заход Амазона в цифровую дисторибуцию. Вместо того, чтобы считать цифровое направление подразделом обычного ритейла («ну продаём книжки, будем продавать ещё цифровые книжки»), выделили направление с независимыми ответственными
6-pagers
Это моя любимая штука. Вместо харизматичного тамады с кликером или душнилы, который читает по слайдам — текст. Текст, который можно читать нелинейно, возвращаться к нужным местам, помечать важные моменты, впитывать деталями и структурой.
Как и в случае с наймом, идея в реальности поддерживается солидным набором практик в виде курсов, менторства и, самое главное, — форматом митингов: первые 20 минут любой встречи все собравшиеся вместе читают документ. Как и в других случаях — это дорого, но окупает себя.
Тут можно заметить ещё одно свойство удачных решений Амазона, они часто связаны с простыми физическими логистическими ограничениями. Например, книги на старте были выбраны в том числе и из-за прямоугольной формы (легко паковать и доставлять). А формат 6-страничного документа выбран потому что 6 страниц можно прочитать за 20 минут.
Fun fact — идею подрезали из эссе Эдварда Тафти. Иронично выглядит в этом контексте.
Примеры: Prime был одним из самых мутных проектов Амазона, поначалу никто вообще не понимал какое нужно решение, поэтому первые полгода жизни проекта состояли исключительно из коммуникаций про проблемы и гипотезы. А все коммуникации были через 6-страничники. Похожая история с цифровым отделом компании. Ветвление организации означало, что менеджменту сложнее погружаться в детали и следить за всем, коммуникация такими документами сделала проблему менее острой.
Working Backwards
Перед тем, как сделать продукт предлагается написать его пресс-релиз и FAQ. Какую проблему продукт решит? Какие из фичей продадут его клиентам? Что в нём будет, чего не будет? Сколько стоит? Всё начинается с точки Б, в которой компания хочет оказаться с этим продуктом перед своими клиентами.
Такой подход означает, что стратегически важные продукты влекут за собой серьёзные траты на приобретение навыков/технологий, которых не хватает для достижения запланированного. Из всех принципов этот, пожалуй, самый дорогущий. Но он же и дал Амазону флагманские продукты Kindle и подписку Prime.
Kindle это продукт Working Backwards в чистом виде. Построена целая мини-индустрия внутри компании, чтобы клиенты получили бесшовный экспириенс покупки книг и чтения на девайсе, который «исчезает» как только ты начинаешь читать.
Инструкция по PR/FAQ от бывшего продакта в AWS и нынешнего сотрудника ML-подразделения в Apple.
Input metrics
Буквально вот это: «God, grant me the serenity to accept the things I cannot change, courage to change the things I can, and wisdom to know the difference».
Чем можно управлять: каталогом товаров, ценами, логистикой. Чем нельзя управлять: заказами, выручкой, прибылью. Вещи из второй категории важны, но напрямую управлять можно только вещами из первой. И если всё делать правильно, то вещи из второй тоже подтянутся.
Как устроена система:
- На верхушке пирамиды — некая ключевая output метрика. Например «рост»
- К этой метрике приписан некий virtuous cycle метрик, на которые можно влиять. Например: пользовательский опыт, трафик, продавцы, выбор товаров, структура цен и сами цены. Так как это цикл, то можно начать с любой точки, усилия в итоге отразятся на output метрике, что подтолкнёт следующий проход по циклу
- Input метрики в свою очередь дальше разбиваются на какие-то более детальные, соотносящиеся с конкретными активностями в компании
Дизайн метрик плюс последующая работа с ними и есть основная область инвестиций. Как и с другими принципами — он дорогой. Дизайн метрик дорогой, часто метрики проходят по несколько итераций. Сбор метрик дорогой. Поддержка всей системы дорогая. Как и в случае с другими принципами в компании есть поддерживающие его стандарты: гайдлайны для графиков, гайдлайны для митингов с обсуждением метрик.
Примеры — подписка Prime. «У нас замедлился рост, мы не можем влиять на рост напрямую, но можем влиять на цену, выбор и удобство. Давайте придумывать как.» Дальше у решения было несколько итераций. На третий раз получилось как надо.
К сожалению, нормальной статьи по Input Metrics я пока не нашёл.