Amazonのエンジニアリングマネージャーとして

私は、大手テクノロジー企業のエンジニアリング マネージャーの生活が、スタートアップでの私の経験と比べてどう違うのか、ずっと興味がありました。今週、ついにその答えを見つけようと決心し、Gilad Naor 氏にインタビューしました。

ギラッド氏はスタートアップ企業で 9 年間働き、エンジニアリング ディレクターの地位にまで上り詰めました。そして 2017 年に、妻と 3 人の子供とともに冒険の旅に出ることを決意しました。

彼らは世界を1万キロ横断してシアトルに引っ越し、彼は アマゾン2019年までそこに滞在した。

アマゾンの後、ギラッドはエンジニアリングマネージャーとして3年間勤務しました。 メタ過去2年間で数百人のマネージャーを指導してきました。最近では、新しい マネジメントデルタコミュニティ

今日彼がシェアするのは以下の内容です:

• エンジニアリングマネージャーがAmazonから学ぶべき3つのこと

• アマゾンで働いていた頃の懐かしくない思い出

• 彼が今でも最も恋しいもの

ギラッドにマイクを渡す！🎤

アマゾンでの最初の会議は困惑するものでした。

私は、約 12 人のソフトウェア開発マネージャー (SDM) と製品マネージャー (PM) がいる部屋に入りました。全員が黙って座り、目の前にあるラップトップや印刷された書類を見ていました。

アマゾンでの勤務2日目、私は予備の紙を1枚手に取って読み始めました。最初の10分間のぎこちない時間の後、全員が読み終え、会議が始まりました。

Amazon の会議はなぜいつもこのように始まるのでしょうか? これは、Amazon が問題解決に取り組む方法の具体的な例です。これは、「善意は重要ではない」というアプローチです。

有名な社内ビデオで、ジェフ・ベゾスは善意がなぜ無関係であるかについて語っています。物事がうまくいかないとき、人々が何を望んでいたかは関係ありません。重要なのは、メカニズムの問題を解決することだけです。

たとえば、忙しいマネージャーの多くは、準備資料を読まずに会議に出席します。彼らは全員、会議の前に 6 ページの資料を読むつもりでした。ただ、最新の緊急事態に気を取られてしまったのです。マネージャーを叱っても問題は解決しません。仕組みがあれば解決します。これが、Amazon のすべての会議が勉強時間から始まる理由です。会議の残りの時間は、質の高い意思決定に費やされます。

Meta は、文化的な規範を作成することで同じ問題を解決します。上級リーダーがプレゼンターの話を遮って「ここで止めてください。ここにいる全員がスライドをすでに読んでいると仮定してください。要点に入りましょう」と言うのを何度聞いたかわかりません。これは文化を第一に考えたアプローチです。一部のチームではこれがうまく機能し、他のチームではまったく機能しないのを見たことがあります。

Amazon では、このソリューションは同社の「オペレーティング システム」の一部となっている。

ヒント

物事がうまくいかないときは、5 つのなぜを問いかけて、人間が意思決定する範囲を超えるまで調査を続けます。人が新人だったり、資格が足りなかったり、調子が悪いときでも機能するメカニズムを見つけます。これが機能する解決策です。

Anton です。まったく同感です。Jira チケットが更新されないことにイライラしていたのを覚えています。何度もリクエストした後、最終的に、毎日のスタンドアップの最初の数分で更新できるようになりました。

Amazonでは、「イタチ言葉。

私は「重大な」、「低レイテンシ」、「迷惑な」などの用語の使用をやめました。代わりに、「P99 レイテンシが 12 ミリ秒から 45 ミリ秒に 375% 増加」などの具体的な指標を使用しました。これにより、事前の作業が増えましたが、想像していたものではなく、現実をありのままに議論することができました。

私は初めての 6 ページの原稿に取り組んでいましたが、大変でイライラしていました。私のマネージャーは、アマゾン人のように文章を書く方法を教えてくれるメンターを紹介してくれました。彼女は、ウイズル ワードについて、その見分け方、回避方法などをすべて教えてくれました。

しかし、今日まで私の心に残っているのは、実はマネージャーとの1対1のミーティングです。私は、曖昧な言葉はビジネス文書にだけ現れるのではないことを学びました。それは、チームメンバーにフィードバックを与える際にも現れました。私は、具体的なフィードバックを与えるために、事前準備をすることを学びました。

私は「あなたは会議であまりに率直すぎる」と言うのをやめました。代わりに、「Christopher との会議で、彼が React ベースのソリューションを提案し始めたときに、あなたは彼の話を遮りました。私たちはより多くのアプローチを確認する機会を逃しました。Christopher が他の会議に貢献しなくなったことにも気づきました。」と言いました。

このフィードバックは事実に基づいており、議論の余地はありません。相手にとっても理解しやすいものです。これは、実行可能なアドバイスへの第一歩です。

ヒント

ほとんどの人は私のことを知らないでしょうが、私は素晴らしい歌手です。実際、世界レベルです。唯一の問題は、私が歌うとき、私は世界レベルの歌手だということです 私の頭の中で実際に口を開けば、人々は逃げていく傾向にあります。

アイデアについても同様です。

私たちは、技術、ビジネス、または管理の分野について明確かつ正確に理解していると考えています。他の人とコミュニケーションをとるという行為は、私たちの理解のギャップを広げます。考えを書き留め、曖昧な言葉を避けることで、私たちはより優れた思考者になるよう強いられます。これはメカニズムです。

Amazon は、あなたがどのように働くかを気にしません。あなたが達成すべき明確な目標があり、それだけです。

スタートアップ企業のマネージャーとして、私はスクラムやカンバンなどのアジャイル手法の学習に多くの時間を費やしました。私は、自分のチームが業界のベストプラクティスを活用した標準プロセスを使用することを望んでいました。

大手テック企業で働いていたとき、 全くそんなことない! 標準化されたプロセスはありません。各チームは自己組織化し、特定のプロジェクトごとにどのように作業するかを選択します。

チームの自律性はさらに進みます:

• テクノロジースタック—マイクロサービスはあなたが所有し、それを構築する方法を選択します。

• 2ピザチーム—チームは独立しています。1 つのチームには、バックエンド、フロントエンド、デザイン、UX、製品管理などが含まれます。

• ソフトウェア開発ライフサイクル (SDLC) —毎日のスタンドアップ? チームが望むなら、もちろんです。スクラム? カンバン? 他の方法? これも、チームが選ぶ方法です。

• 製品対エンジニアリングなしPM がシニア SDM に直接報告するのは一般的であり、その逆も同様です。

• リーダーは、自分の役割に関係なく、製品に関するすべての責任を負います。また、リーダーシップにより、ビジネス目標の達成に対する責任を負います。技術マネージャーであることは言い訳にはなりません。

別の例として：

新しいアイデア（大きなことを考えましょう！）を思いついたら、それを現実のものにするのがあなたの仕事です。それがビジネス上の意味があることを上級管理職に納得させるのはあなたの責任です。

経営陣がプロジェクトを承認した場合、資金（「人員」）が支給される可能性があります。その後、採用はあなたの責任となります。職務内容の説明の作成から候補者の発掘、そして候補者の参加の説得まで、ファネル全体にわたって取り組むのがあなたの仕事です。

ヒント

所有権の原則は開発者にも適用されます。

人々に自主性を与えてください。開発者に完全な機能を所有させてください。開発者をサポートし、自由の限界を与え、責任を持たせてください。

すべての人をリーダーとして扱えば、ほとんどの人がリーダーであることがわかるでしょう。

アマゾンの新CEOアンディ・ジャシーは、2つの新しい リーダーシップの原則 2021年に就任した際に、彼は（LP）に新たな理念を掲げました。その1つは、「地球上で最も優れた雇用主となるよう努める」というものです。この理念は、結果重視の姿勢に対して、人材第一主義のバランスをとるものです。

2017 年当時、マネージャーが従業員やマネージャーを扱う方法には大きなばらつきがありました。私は世界でも有数の優秀なマネージャーと働いたことがあります。また、仕事の背後にいる人々を見ない、結果に執着するマネージャーとも数人一緒に働いたことがあります。たった 1 つの悪い経験で、その日全体が嫌な気分になってしまいます。

当時、私たちは家族の健康に深刻な問題を抱えていました。そのため、悪いやり取りの影響が拡大しました。どの会社にも良い人と悪い人はいますが、当時は Amazon 全体として、ここで最低限の基準を設けることを優先していないように感じました。

アンディ・ジャシー氏の在任期間中の個人的な経験はないが、Amazon はこの方向で変化を起こしているように思える。

Amazon のプリンシパル (POA) の講演。

ほぼ毎週、Amazon で最も上級の個人貢献者の 1 人が技術講演を行いました。レベル 7 以上のエンジニアが、世界クラスの問題をどのように解決したかを詳しく説明しました。

これらの講演は洗練されていました。各プレゼンターは複数のコーチと協力し、プレゼンテーションを洗練させ、磨き上げました。私はいくつかの講演に直接出席し、他の講演をライブで視聴し、録画もいくつか視聴しました。

POA の講演ほど多くのことを教えてくれた技術講演は、それ以前にもその後にもありませんでした。S3 の規模の分散システムだけが直面する困難な課題について学んだことを覚えています。あるいは、まったく新しいデータベースをゼロから作成する方法と理由について。これらすべてを、これらの問題を解決した人々から直接学びました。

ここに記事があります POA の話についても話す IC7+ の Amazon 担当者によるものです。

アントンです。時間を割いてストーリーを共有してくれたギラッドに心から感謝します。

他の企業内でエンジニアリング管理がどのように機能しているかを聞くという新しい形式は興味深いと思いました – 少なくとも私にとってはそうです 🙂

それについてどう思うか、また私に聞いてほしい質問があれば教えてください。

昨年

、50 冊以上の本を取り上げました。そのうち 3 冊は Amazon に関する本です。

1. で スタートアップのベストストーリー7選 私はカバーした あらゆるものを扱う店、 これは、オンライン書店がどのようにして 1 兆ドル規模の企業になったのかという起源の物語です。

2. で これがAmazonが無敵である理由、オレルはカバー の ベゾスからの手紙、 ベゾスがいかにして重大な決断を下したか（そして、他の時にはいかにしてひどく失敗したか）について語っています。

3. で あなたは間違った方向に考えています、

   そして 覆われた 逆算して、 ここでは、6 ページのレポートと PRFAQ 方式の起源について読むことができます。