engineering-management - エンジニアリング管理と技術リーダーシップに関連する刺激的なリソースのコレクション

(A collection of inspiring resources related to engineering management and tech leadership)

Created at: 2016-03-17 18:29:40
Language: Shell
URL: https://github.com/charlax/engineering-management
License: MIT

目次

このリストについて

項目：

  • 🧰 : リソースのリスト
  • 📖：本
  • 🎞 : 動画/動画抽出/動画
  • 🎤 : スライド/プレゼンテーション
  • 🎧 : ポッドキャスト
  • ⭐️ : 必読

書物

他のどの分野よりも、管理は100語の記事にまとめることができるふわふわの本でいっぱいです。そうは言っても、以下にリストされている多くの優れた本があります。

船を好転させる:フォロワーをリーダーに変える実話

📖船を回す!:フォロワーをリーダーに変える実話は、私のお気に入りの管理書を引き継いでいます。

この本は、地元の決定に力を与えることの意味を本当に理解させてくれました。特に、通常の指揮系統では、チェーンを上るには情報が必要であり、下がるという決定はめちゃくちゃ非効率的であると著者が説明している方法が好きでした。

これは、マネージャーがチームメンバーが自分の決定、特に意図的な行動の概念を考え出すのを助けるための優れたツールを提供します。著者が開発した主な概念について話すプレゼンテーションもあります。

安っぽい管理本はたくさんありますが、これはその1つではありません。ナレーションも素晴らしく、説明は短く、要領を得ています。

あなたはここでビデオで短い要約を見つけることができます

「能力のないコントロールは混沌です。」

— L・デイヴィッド・マルケ、船を回せ!

その他のジェネラリストの本

  • 📖利点、拡張版:組織の健全性がビジネスの他のすべてに勝る理由、パトリックM.レンシオーニ。
    • 人々がメッセージを受け入れる唯一の方法は、一定期間にわたって、さまざまな状況で、できればさまざまな人々からメッセージを聞くことです。だからこそ、優れたリーダーは、自分たちを何よりも最高責任者と見なしています。
    • カスケードコミュニケーションを行うための最良の方法は、対面とライブです。リーダーに会い、彼または彼女の声のトーンを聞くことは、質問できることと同様に、従業員にとって重要です。
    • しかし、繰り返しになりますが、ほとんどの組織は、洗練や知性よりも規律、粘り強さ、フォロースルーを必要とする基本的なことを行っていないため、不健全です。
  • 📖人間の管理:ソフトウェアエンジニアリングマネージャーの痛烈でユーモラスな話:「マイケル・ロップがApple、Pinterest、Palantir、Netscape、Symantec、Slack、Borlandでのマネージャーとしての多様で時には奇妙な経験から抽出した深刻な教訓を含む陽気な話を読んでください。物語の多くは、ロップの長年人気のあるブログ、Rands in Reposeに原始的な形で最初に登場しました。」
  • 📖Oren Ellenbogen、Leading Snowflakes: エンジニアリングマネージャーハンドブック:メーカーモードからマネージャーモードに移行するための本当に素晴らしいコンテンツと具体的なアイデア、管理上の決定をコードレビューし、品質や可視性を失うことなくタスクを委任します。
  • 📖アダム・グラント、ギブアンドテイク:他の人を助けることが私たちの成功を促進する理由:「この宝石は読むのが楽しいです、そしてそれは貪欲が成功への道であるという神話を打ち砕きます。」、ロバート・サットン。
  • 📖ケン・ブランチャード、イエスのようにリードする:史上最高のリーダーシップロールモデルからの教訓。
  • 📖アンドリューS.グローブ、高出力管理。インテルのCEO、アンディ・グローブによる画期的な本。1-1、OKRなどの管理ベストプラクティスの多くを紹介しました。
    • 管理レバレッジは、チームのアウトプットを増やすためにマネージャーが行うことの影響を測定します。
    • 消防署の計画方法を計画する必要があります。次の火災がどこにあるかを予測することはできないため、予期せぬ事態や通常のイベントに対応できるエネルギッシュで効率的なチームを形成する必要があります。
    • あなたの一日のすべての時間は、あなたが責任を負っている人々のアウトプットまたはアウトプットの価値を増やすことに費やされるべきです。
    • 私たちが常に注意すべき一般的なルールは、可能な限り価値の低い段階で生産プロセスの問題を検出して修正することです。
    • 真に効果的な指標は、単に関係する活動ではなく、作業単位の出力をカバーします。明らかに、あなたはセールスマンが行う呼び出し(活動)ではなく、彼が得る注文(出力)によってセールスマンを測定します。
    • マネージャーのアウトプット=彼の組織のアウトプット+彼の影響下にある近隣組織のアウトプット。
    • リーグの順位は、個人ではなくチームごとに維持されます。ビジネス、つまり商業のビジネスだけでなく、教育のビジネス、政府のビジネス、医療のビジネスは、チームの活動です。そして、常に、勝つにはチームが必要です。
    • あなたの意思決定は、最終的にあなたがあなたのビジネスが直面している事実と問題をどれだけよく理解しているかにかかっています。これが、情報収集がマネージャーの生活において非常に重要である理由です。
    • 決定の欠如は否定的な決定と同じです。青信号は赤信号ではなく、組織全体の作業が停止する可能性があります。
    • フォロースルーなしの委任は退位です。
    • どんな決定も解決され、最も低い有能なレベルで達成されます。その理由は、これが状況に最も近く、それについて最もよく知っている人々によって作られる場所だからです。
    • 自信は主に、間違ったビジネス上の決定を下したり、不適切な行動をとったり、却下されたりして亡くなった人は誰もいないという直感レベルの認識から生まれます。
    • MBO(目標管理)システムを成功させるには、次の2つの質問に答えるだけで済みます。 1.どこに行きたいですか?(答えは目的を提供します。2.そこにたどり着くかどうかを確認するために、どのように自分のペースで進めますか?(答えは私たちにマイルストーン、または主要な結果を与えます)。
    • MBOシステムが卓越したものを提供する必要があることの1つは、焦点です。これは、目標の数を少なくした場合にのみ発生します。実際には、これはまれであり、ここでは、他の場所と同様に、私たちは「いいえ」と言うことができないこと、この場合はあまりにも多くの目的を犠牲にします。私たちは、すべてに集中しようとすると、何も焦点を合わせないことを認識し、その認識に基づいて行動しなければなりません。いくつかの非常に適切に選択された目標は、私たちが「はい」と言うものと「いいえ」と言うものについて明確なメッセージを伝えます—これは、MBOシステムが機能するために必要なものです。
    • アルフレッド・スローンは、ゼネラルモーターズでの数十年の経験を要約して、「優れた管理は中央集権化と地方分権化の和解にかかっている」と述べました。または、応答性とレバレッジの最適な組み合わせを得るためのバランスをとる行為について言うかもしれません。
    • 私はグローブの法則を提案したいと思います:共通のビジネス目的を持つすべての大規模な組織は、ハイブリッドな組織形態になります。
    • 人が自分の仕事をしていないとき、それには2つの理由しかありません。その人はそれをすることができないか、それをしないでしょう。彼は能力がないか、やる気がありません。
    • その変数は、部下のタスク関連成熟度(TRM)であり、部下の達成志向と責任を取る準備の程度、および教育、トレーニング、および経験の組み合わせです。
    • TRMが低い場合、最も効果的なアプローチは、上司が部下に何をいつ、どのように行う必要があるかを伝える、非常に正確で詳細な指示を提供するアプローチ、つまり高度に構造化されたアプローチです。部下のTRMが成長するにつれて、最も効果的なスタイルは、構造化されたものから、コミュニケーション、感情的なサポート、励ましに与えられたものへと移行します。
    • 部下を教える責任は彼の上司によって引き受けられなければならず、彼の組織の顧客によって支払われてはなりません。
    • 常に、可能性ではなくパフォーマンスを評価するように強制する必要があります。
    • マネージャーは一般的に、部下の個々のパフォーマンスのレベルを上げるために、モチベーションを高めること、各人が自分の仕事をうまくやりたいという願望を高めること、そして個々の能力を高めることの2つの方法があり、そこでトレーニングの出番です。
  • 📖パトリック・レンシオーニ、チームの5つの機能不全:リーダーシップの寓話。
  • 📖仕事のルール!:あなたの生き方とリードを変えるGoogleの内部からの洞察、ラズロ・ボック。グーグルのプロセスに関する非常に興味深い説明。時々少し長い。
  • 📖マネージャーの道、カミーユ・フルニエ。現実的なアドバイスがたくさんある非常に実用的な本。

以下に引用されている他のいくつかのより具体的な本があります。

本の読書リスト

エンジニアリング管理とは何ですか?

一般的なリソースを次に示します。

一般的な経営資源

タル・ベレズニツキーのエンジニア管理のための素晴らしい定義:

やる気のある人を雇う。それらを信頼してください。すべてに高い基準を設定します。模範を示す。彼らの邪魔にならないようにして、彼らをその日のヒーローにしましょう。それです。

記事

  • ソフトウェア開発で展開する静かな危機
  • ウォーレン・バフェットが「制度的義務」、または機関が悪いマネージャーの不合理な決定をどのように増幅するか(抵抗しない)を説明する最初の25年間の間違い。
  • RethinkDBの共同創設者からの44のエンジニアリング管理の教訓。非常に高レベルで、かなり良い要約です。
  • イムグルで学んだ21の管理上のこと
  • ランドテスト、休息中のランド。管理のためのジョエルテストに相当します。
    • 1:1はありますか?
    • チームミーティングはありますか?
    • ステータスレポートはありますか?
    • 上司にノーと言うことができますか?
    • 会社の戦略を見知らぬ人に説明できますか?
    • 事業の現状について教えてください。
    • 担当の男/ギャルは定期的にみんなの前に立ち、彼/彼女が何を考えているかを教えてくれますか?あなたはそれを買っていますか?
    • 次に何をしたいか知っていますか?あなたの上司はいますか?
    • 戦略的になる時間はありますか?
    • あなたは積極的にグレープバインを殺していますか?
  • あなたが素晴らしいマネージャーを持っているという兆候は何ですか?:ハッカーニュースに関する素晴らしい議論
    • 優れたマネージャーはチームに奉仕しています。
    • あなたは本当に素晴らしいマネージャーに気づいていません。
    • コンテキストを可能な限り高レベルかつ完全に伝えます。
  • ユーザーの管理
    • マネージャーとして、すべてはあなたのせいです
    • プロセスを管理します。あなたは人々を導きます
    • プロセスは明示的にされた期待です
    • 透明性による信頼
    • 自律性と放棄を混同しないでください
    • ドライブバイ管理を避ける
    • 明示的>暗黙的
    • 数か月ごとに会社をリファクタリングすることを期待する
    • 混沌は、それを作成する人々によってあまり感じられません
    • あなたから報告するマネージャーにもっと期待する

ツール

エンジニアリング管理のトピック

これは、エンジニアリング管理に関連する刺激的な記事のリストです。それらは通常、刺激的で具体的なアイデアが満載の短く簡潔な記事です。彼らは私自身の経営慣行を形作っており、彼らがあなたにも刺激を与えることを願っています。

私は必ずしもここにリストされているすべてに同意するわけではありません。実際、それらの記事のいくつかは正反対の意見を持っていることがわかります。これらの示唆に富むリソースは、マネージャーの旅に役立つと信じています。

1-1

アンチパターン

  • 管理の7つの致命的な病気、デミング博士。素晴らしいビデオも。私は必ずしもすべてに同意するわけではありませんが、デミングは依然として偉大な経営思想家の一人です。

バイアス

認知バイアスは採用だけに当てはまるわけではありません...パフォーマンスレビュー、1対1、チームミーティング、さらには同僚との小さな話に影響を与える可能性があります。

ブレーンストーミング

  • 新しい、より良いアイデアを引き起こす極端な質問、スマートベア
    • 次のプロンプトは、小さな思考からあなたを揺さぶる
    • 価格を10倍に引き上げることを余儀なくされた場合、それを正当化するために何をしなければなりませんか?
    • すべての顧客が姿を消し、成長とブランドをゼロから獲得しなければならない場合、私たちは何をしますか?
    • 何らかの形で技術サポートを提供することが許可されなかった場合、何を変更する必要がありますか?
    • 私たちの最大の競争相手が私たちが持っているすべての機能をコピーした場合、どうすればまだ勝つことができますか?
    • 完成した(少なくともMVP)新機能をわずか2週間で出荷することを余儀なくされた場合、一部の顧客を喜ばせ、驚かせるでしょう。
    • まったく異なる方法で顧客に請求することを余儀なくされた場合はどうなりますか?
    • 同期会議はもうありませんか?
    • 二度とお客様と話すことができない場合、何を構築するかをどのように理解しますか?
    • あなたがどれほど不採算であるかが問題ではなかったらどうしますか?
    • 会社全体を殺す可能性のある外部性は何ですか?

危険な男はただ一つの考えを持っている人です、なぜならそれから彼はそれのために戦って死ぬからです。本当の科学のやり方は、あなたがたくさんのアイデアを思い付くことです、そしてそれらのほとんどは間違っているでしょう。

— フランシス・クリック

キャリアの成長と仕事のはしご

ジョブラダー/キャリア開発マトリックスの厳選された例:

リストのリスト:

概念：

変更管理

コードレビュー

コードレビューに関する私のプロのプログラミングセクションを参照してください

通信

紛争解決

CTO(最高技術責任者)

  • CTOの7つの役割
    • エグゼクティブ
    • 代表
    • ユーザー マネージャー (時々)
    • ハンズオン開発者(時々)
    • セキュリティとITを所有
    • 店員
    • 必要なことは何でもします

データ編成

  • 中途半端なスタートアップでデータチームを構築する:短編小説
  • ウィッシュで分析チームを構築する(4部構成の記事シリーズ)
    • データパイプラインの再構築
    • データ ウェアハウスの構築
    • ビジネス インテリジェンス ツールの展開
    • データ エンジニアリングでは、アナリストが独自のパイプラインを作成できるシステムを構築する必要があります。
    • 強力な面接官は、候補者からの合図に反応する柔軟な質問を持っている必要があります。
  • エンジニアはETLを書くべきではありません:高機能データサイエンス部門を構築するためのガイド
    • あなたはおそらくビッグデータを持っていません
    • データ パイプラインや ETL の作成と保守を楽しんでいる人はいません。業界究極のホットポテトです。
    • データサイエンティストにETLのエンドツーエンドの所有権を与える
    • エンジニアは、データサイエンティストが創造的な方法で組み立てて新しいデータサイエンスを作成する新しいレゴブロックを設計します。
    • プラットフォームエンジニアがデータサイエンスチームの先を行くことは絶対に不可欠です
    • エンジニアは、自分たちを「トニー・スタークの仕立て屋」と見なし、データサイエンティストが拡張性のない、または信頼性の低いソリューションを生み出す落とし穴に陥るのを防ぐ鎧を構築する必要があります。
    • 速度と自律性のために技術的効率を犠牲にしても大丈夫です

決定

使用を避けるべき引数-それは論理的な誤謬です 「それはいつもこのように行われてきたからです。」 「以前に試してみましたが、うまくいかなかったからです。」 「X社がこれを使っているから」 「{重要な人}がそう言ったからです。」

代わりに、トレードオフ、制約、機会の理由。

- ゲルゲリー・オロシュ

代表

  • 手放すことによって導く直感に反する芸術
  • マイクロマネジメントに対して:「地面に種を植えた後、毎週それを掘り起こしてそれがどのように機能しているかを確認することはありません」、3MのR&D責任者であるWilliam Coyne。

70/10/80委任の原則:「成功率70%であなたがしていることを実行できる人を見つけてください。彼らに余分な10%を教えて、80%で大丈夫です。」

配達

ダイバーシティとインクルージョン

PwCによるいくつかの素晴らしいビデオ:

チームをトレーニングする方法:

トレーニングの例:

採用の多様性

従業員ハンドブック

エスカレーション

フィンオプス(コスト)

初めてのマネージャー

仕事の最初の日

  • ウィル・ラーソン、CTOまたはVPエンジニアリングとしての最初の90日間。
    • 永続的な改善は、改善の一時的な外観を作成する戦術的なアクションを実行するのではなく、変更を作成するシステムを作成することに依存します。
    • 何かが本当に間違っていて、すぐに注意が必要かどうかを判断します。
    • シャドウ顧客会議、パートナー会議、またはユーザーテスト。
    • ビジネス分析とそのクエリ方法を見つけます。
    • 既存のインタビュー、オンボーディング、クロージングコールをシャドウイングします。
    • エンジニアリングブランドの取り組みを開始します。
    • 些細な変更を構築してデプロイします。

フィードバックとパフォーマンス

  • 📖過激な率直さ—良い上司になるための驚くべき秘密
  • 📖Amazon.com:賭け金が高いときに話すための重要な会話ツールケリー・パターソン著。
    • ですから、私たちが本当に望む結果を達成するための最初のステップは、他人が私たちを苦しめるすべての源であると信じるという問題を解決することです。「敗者を直せば、すべてが良くなる」という私たちの独断的な信念が、対話と進歩につながる可能性のある行動をとることを妨げています。だからこそ、対話が得意な人がこの論理を好転させる傾向があるのは当然のことです。彼らは、「私たち」に取り組む最良の方法は「私」から始めることだと信じています。
    • 尊敬は空気のようなものです。それが存在する限り、誰もそれについて考えません。しかし、あなたがそれを取り除けば、それは人々が考えることができるすべてです。
    • 「1本の鈍い鉛筆は6つの鋭い心の価値があります。」あなたのハードワークを記憶に任せないでください。重要な会話を完了するために努力した場合でも、思い出を信頼することによって作成したすべての意味を無駄にしないでください。結論、決定、および割り当ての詳細を書き留めます。
  • 人々を解雇する:Githubから解雇された経験についてのZach Holmanの話は、めったに話されないプロセスへのいくつかの素晴らしい洞察を提供します。
  • 発砲するのに早すぎることは決してありません、アンドリーセン・ホロウィッツ。
  • 批判的なフィードバックを与えるための入門書
  • フィードバックは双方向に行われます:ツール:Googleのマネージャーフィードバックアンケートをお試しください
  • 負帰還アンチパターン
  • パフォーマンスレビューは時間の無駄です:正式なパフォーマンスレビューに対する良い逆張りのテイク
  • オープンフィードバックサークル(OFC)、パドミニピャパリによる素晴らしいアイデア。
    • 月に一度会って、テーブルを囲んで、他のチームメイトの前でお互いにフィードバックを共有しました。この集まりは、フィードバック交換を私たちが恐れていた半年ごとの活動から、私たちが楽しみにしている毎月の儀式へと導きました。
    • 脆弱性は信頼を育む
  • サイモン・シネック:指標よりも目的を優先すべき
    • ターゲットは素晴らしいです。しかし、目標をどのように達成するかも重要です。2か月後に目標を達成するチームは、士気と品質を犠牲にして目標を達成したチームよりも多くの報酬を受け取る必要があります。
    • SEALはパフォーマンスと信頼性を測定します。彼らは、高パフォーマンスの低信頼の人よりも、中程度のパフォーマンスの高い信頼の人をチームに迎えたいと思っています。
    • Simon のチームは、チームのピア レビューを実行します。1人が上位3つの弱点を共有し、チームはコメントできますが、感謝の気持ちを伝えることしかできず、その後、彼らは自分の強みについても同じことをします。

雇用

全般

  • 📖最高の知識労働者、技術者、オタクを雇う:技術者を雇う秘訣と科学、ジョアンナ・ロスマン。ソリューション指向の本。
    • 面接チームをトレーニングして、限定的なコンセンサスアプローチを採用に適用します。グループが限られたコンセンサスを使用する場合、誰もが決定に同意するわけではありませんが、各人は、特定の候補者の適格性に十分に満足して、彼または彼女を採用する決定を妨げないようにする必要があります。
    • 拒否権者が組織に留めたくない人である場合はどうなりますか?」これに対する答えは簡単です:面接プロセスでは、あなたが尊敬し、評価する仕事の従業員だけを巻き込みます。従業員が技術職で成功していない場合は、その従業員を面接チームの一員にしないでください。
    • チームのメンバーは、外部の候補者にインタビューするのと同じ方法で内部候補者に面接するようにしてください。
    • より多くの人を雇っている理由を知ってください。問題を定義して、採用戦略を定義します。
    • 採用マネージャーが候補者を採用しない主な理由は、その人が文化にうまく適合しないという直感を持っていることです。しかし、「直感」は誰かを雇わない正当な理由ではないので、文化に合った違いを明確にするように自分自身を訓練してください。
    • 私は個人的に、技術職に誰かを雇っているとき、認定はあまり意味がないと考えています。テストされる知識は機能スキルブックの知識であるため、認定を維持するためにその人が何をしなければならないか、および環境に対するその認定の価値を理解していることを確認してください。
    • 多くの場合、社内の採用担当者は、機能スキルや製品ドメインの経験ではなく、ツールやテクノロジーの専門知識や高度な学位を求めています。
    • メモを取る必要があると感じた場合は、コンピューターではなく紙にメモを取ります。その理由は、コンピューターを使用するときは、画面の後ろに座らなければならず、それがあなたと候補者の間に障壁を作るからです。
    • 無条件の昇進を約束することは、リスクが高いだけではありません。それは愚かです。社内の状況は変わる可能性があります。従業員は期待に応えられない可能性があります。経済は停滞するかもしれません。
  • eシェアーズからのオファーレターの良い例。
  • 私たちは他のみんなと同じように、ジェフ・アトウッドを雇います。
  • ⭐️採用方法:採用に関する最高の記事の1つ。
  • ⭐️採用投稿:トーマス・プタチェクによる採用についてのもう一つの本当に素晴らしい投稿。
  • これが、優れた開発者を雇うことは決してない理由です
    • 多くの面接テクニックは、せいぜい実際の仕事の生活とは無関係なスキルをテストします。
    • あなたは今仕事をするのに十分なことを知っている誰かを望んでいます。
    • または、仕事をすばやく学ぶことができるほど賢くてやる気のある人。
    • あなたは彼らがしていることで良くなり続ける誰かを望んでいます。
    • 面接は、戦闘的な尋問ではなく、共同の会話である必要があります。
    • また、一緒に仕事をするのを楽しむ人が必要です。
    • 「一緒に働くことを楽しむ」と「一緒に過ごすことを楽しむ」を分けることが重要です。
    • 嫌いな人がどんなに優れていても雇わないでください。
    • チームが多様でない場合、チームは必要以上に悪化します。
    • 採用には非常に長い時間がかかり、本当に、本当に難しいことを受け入れてください。
  • あなたがこれまでに行う最も確実な採用決定は、インターンプログラムを確立することです。
  • エンジニアリング管理 - 採用は、採用が最優先事項であるべき理由を説明します。
  • 私たちが最高のものだけを雇うとき、私たちは最もトレンディな人だけを雇うことを意味します
  • 採用方法、パティ・マッコード(Netflixで人事機能を構築)。
  • シニアエンジニアの採用に問題がありますか?それはおそらくあなたです。
  • 私はエンジニアであり、リクルーターでした。採用は壊れています。
  • 🎧理想的なチームプレーヤーを獲得する方法

採用:多様性と偏見

チェックアウト採用における多様性

採用:面接

エンジニアリングマネージャーの採用に関する詳細:

採用:面接の質問

採用:求人情報

採用:プロセス

採用:ソーシング

採用:持ち帰り演習

採用:引用符

「タフな雇用」ができれば、「簡単に管理」できます。

Sue Tetzlaff、 従業員エクスペリエンス:ピークパフォーマンスへの絶頂ガイド

人材の採用と育成ほど重要なことは何もないと確信しています。結局のところ、戦略ではなく人に賭けます。

ローレンス・ボシディ、GE

私は私より明るい人を雇い、それから私は彼らの邪魔をしません。

リー・アイアコッカ、フォード

あなたは世界で最も素晴らしい場所を夢見て、創造し、設計し、そして構築することができます...しかし、それは人々が夢を実現することを必要とします。

ウォルトディズニー

キャラクターを雇う。スキルを訓練します。

ペーター・シュッツ, ポルシェ

テクノロジーでは、それは人々についてです。最高の人材を獲得し、維持し、創造的な環境を育み、革新する方法を見つけるのを支援します。

マリッサ・メイヤー

間違った人を雇うよりも、50人に面接して誰も雇わないほうがいいです。

ジェフ・ベゾス

才能はゲームに勝ちますが、チームワークと知性はチャンピオンシップに勝ちます。

マイケル・ジョーダン、アメリカの元プロバスケットボール選手

多くの場合、管理上の問題に対する最善の解決策は適切な人です。

エドウィン・ブーズ

誰かがかつて、雇う人を探すとき、誠実さ、知性、エネルギーという3つの資質を探すと言いました。そして、あなたが最初のものを持っていない場合、他の2つはあなたを殺します。あなたはそれについて考えます。本当です。あなたが[誠実さ]のない人を雇うなら、あなたは本当に彼らが愚かで怠惰であることを望んでいます。

ウォーレンバフェット

手を雇うことはできません。男全体がいつもそれと一緒に来ます。

ピーター・ドラッカー

仕事をするために専門家を雇うのは費用がかかると思うなら、あなたがアマチュアを雇うまで待ってください。

レッドアデア

インシデントの防止と対応 (オンコール、停止)

学習、振り返り、事後分析

インシデント対応に関する私のプロフェッショナルプログラミングセクションを参照してください

引用符：

  • 「卓越性はファンダメンタルズの習得によって達成されます」、NFL史上最高のコーチの一人と見なされているヴィンスロンバルディ。

経営スタイル

  • 人道的開発:「私たちは人間と協力して、人間の利益のためにソフトウェアを開発する人間です。」
  • リーダーシップは復活しています:リーダーが使用人でもヒーローでもなく、ホストであるモデルを提案する興味深い記事。
  • 経営理念
  • シリコンバレーのトップテクノロジー企業からの12の「マネージャーREADME」
  • 🎞リーダーシップに関するあなたの哲学は何ですか?ネルソン・マンデラ(モーガン・フリーマンが演じる)とフランソワ・ピーナール(マット・デイモン)の間の美しいシーケンス。
  • ソフトウェア開発にサーバントリーダーが必要な理由
  • アンドリーセン・ホロウィッツ、平時CEO/戦時中CEO
    • 平時のCEOは、適切なプロトコルが勝利につながることを知っています。戦時中のCEOは勝つためにプロトコルに違反します。
  • ツイッターの多くのディーホック、ザックカンターからの抜粋。
    • マネージャーとしてのあなたの最初の責任はあなた自身を管理することです:あなたの誠実さ、性格、倫理、知識、知恵、気質、言葉と行動。
    • 第二の責任は、私たちに対する権威を持つ人々を管理することです。
    • 3番目の責任は、仲間を管理することです:彼らの尊敬と自信がなければ、何も達成できません。
    • 第四の責任は、私たちが権威を持っている人々を管理することです。
    • 上司、同僚、規制当局などを管理することはできません。しかし、あなたはそれらを理解し、彼らをやる気にさせ、彼らに影響を与え、彼らを許すことができます。
    • 「驚くべき成長と恵みがしばしば訪れるのは失敗からです。それは、それを認識し、認め、そこから学び、それを乗り越え、そして再び試みることができる場合にのみです。真のリーダーシップは、人間の完全性をはるかに超えた基準を前提としており、喜びと満足は目的の実現ではなく、目的の追求にあるため、それはまったく問題ありません。」
  • スタッフプラスエンジニアの管理
  • 誰もがリーダーであるエンジニアリングチーム、ゲルゲリー・オロシュ。
    • 1 つのプロジェクト、1 つのエンジニアリング リード
    • メンタリング、そして最初の数人のリーダーのコーチング
    • 毎週の書面による更新による透明性と説明責任

引用する：

  • 「船を建造したいのなら、木材を集めるために人々を太鼓で叩いたり、仕事や仕事を割り当てたりするのではなく、果てしない海の広大さに憧れるように教えてください。」
  • 「経営陣は物事を正しく行っています。リーダーシップは正しいことをしている」、ピーター・ドラッカー

Meetings

Mentoring

Mindset and attitude

  • Taking Ownership Is The Most Effective Way to Get What You Want
  • Shreyas Doshi on Twitter: "Good managers, what they do, how they think & act
    • Good managers are skilled at asking questions that give their team members a new perspective on the problem and reach the right solution on their own.
    • Good managers address context first, then content.
    • Good managers know that, above all else, they are agents of their company. Their default mode is to make and facilitate company-optimal choices.
    • Good managers know that fixing broader company culture is an important part of their role as a designated leader within the company.
    • Good managers understand that the long game is all about people.
    • Good managers don’t have just one go-to management style nor do they have a notion of “THE ideal employee”.
    • Good managers can discern good intent from bad.

Warren Buffet, "It's only when the tide goes out that you learn who's been swimming naked."

Motivation

Quotes:

  • "The best time to plant a tree was twenty years ago. The second best time is now", Chinese proverb.
  • "A ship in harbor is safe, but that is not what ships are made for.", John A Shedd.

Onboarding new team members

Organization structure

See also Data organization

  • Martin Casado, Hire a VP of Engineering on the Andreessen Horowitz blog
    • The most important function of a VP of engineering is to build out the engineering team and set a startup’s engineering culture.
    • Competent engineering management should therefore be able to push the team towards more practical, incremental designs that can garner useful external feedback quickly — without compromising the long-term generality of the system. The VP’s role here is not producing the architecture, but ensuring that incremental release is a real requirement in the design process.
    • Strong engineering management tends to give their teams enough ownership and latitude that they are happy and fulfilled in driving the product forward.
  • AVC, VP Engineering Vs CTO
  • Mark Suster, Want to Know the Difference Between a CTO and a VP Engineering?
  • 🎤 CTO vs VP Engineering Balancing Innovation, Bryan Cantrill, Jason Hoffman
  • Spotify’s Failed #SquadGoals
    • Engineering managers in this model had little responsibility beyond the career development of the people they managed.
    • There was no single person accountable for the engineering team’s delivery or who could negotiate prioritization of work at an equivalent level of responsibility.
    • Autonomy requires alignment. Company priorities must be defined by leadership. Autonomy does not mean teams get to do whatever they want.
    • Business units, departments, teams, and managers more effectively communicate organization structure roles and responsibilities than Spotify’s synonyms and are not attached to a way of working that failed their creator.
  • Independence,autonomy,too many small teams
    • Every autonomous team is expected to generate direct business value all by itself, without a lot of overlap with other teams.
    • The team should be able to meets its goals independently (i.e. without reliance on or interference from other teams).
    • Coordination, also known as alignment, communication, shared roadmap, Gantt chart and many other positive sounding names, is the arch-enemy of the autonomous team.
  • 🎞 Monoliths vs Microservices is Missing the Point—Start with Team Cognitive Load by the authors of team topologies.
  • Organizing software teams (Team Topologies Book Summary)
    • There should be no shared ownership of components, libraries, or code.
    • If you have microservices but are still waiting to do end-to-end testing of a combination of services, you have a distributed monolith (a distributed monolith is when all changes in a service require updates to other services).
    • Use software boundaries defined by business-domain bounded contexts
    • Teams composed of only people with single functional expertise should be avoided at all costs.
    • Four fundamental team topologies: stream-aligned, enabling, complicated subsystem, platform.
  • Structure Eats Strategy
    • BAPO: the B (business) should define the A (architecture) which is the starting point for the P (process), on which the O (organization) is based.
    • Most companies are not BAPO but instead they are OPAB: the existing organization is used as a basis for the definition of convenience-driven processes, which in turn leads to an accidental architecture.

Production and productivity

  • The Toyota Way, Wikipedia
    • Base your management decisions on a long-term philosophy, even at the expense of short-term financial goals.
    • Create a continuous process flow to bring problems to the surface.
    • Use "pull" systems to avoid overproduction.
    • Level out the workload
    • Build a culture of stopping to fix problems, to get quality right the first time
    • Standardized tasks and processes are the foundation for continuous improvement and employee empowerment.
    • Use visual control so no problems are hidden.
    • Use only reliable, thoroughly tested technology that serves your people and processes.
    • Grow leaders who thoroughly understand the work, live the philosophy, and teach it to others.
    • Develop exceptional people and teams who follow your company's philosophy.
    • Respect your extended network of partners and suppliers by challenging them and helping them improve.
    • Go and see for yourself to thoroughly understand the situation
    • Make decisions slowly by consensus, thoroughly considering all options; implement decisions rapidly
    • Become a learning organization through relentless reflection (hansei) and continuous improvement (kaizen)

Personal productivity

In terms of software, I can't recommend Things enough (Mac and iOS only). It is a delightful piece of software that gets out of the way and lets you focus on your tasks.

Planning (roadmap, goal setting, KPI, OKR, etc.)

  • Top 10 Reasons for Slow Velocity
  • The Heilmeier Catechism: a crafted a set of questions to help DARPA officials think through and evaluate proposed research programs.
  • The Fundamentals of Roadmapping
    • With constant innovation, new market entrants and potential black swans like a global pandemic, the best a leader can do is set a 12–18 month strategic plan that is directionally aligned with the company’s true north. That plan should be broken down by quarter with the assumption that the degree of confidence in achieving goals within each quarter will decline over time.
    • Expect each team across the organization to cascade their operational roadmaps from these strategic foci. Operational roadmaps should identify key initiatives and milestones.
  • How to measure and improve success in your engineering team
  • “Stories” Don’t Tell a Story: Good Sprint Planning Uses Milestones
    • Manage Through Milestones
  • Rituals for hypergrowth: An inside look at how YouTube scaled
    • Planning cadence: 6-month strategic planning and 6-week sprints
    • Strategic planning had two key outputs: (a) a list of Big Rocks and (b) the matrix of project allocations
    • Our process was designed to avoid the “just in time” ad-hoc meetings
    • Many of our meetings included a long “bullpen” period (i.e. unstructured multithreaded discussion time)
    • Replace read-outs / meetings with broadcast emails
    • Pre-reads (”Come prepared and expect others to be prepared”)
  • Dear PMs, It's Time to Rethink Agile at Enterprise Startups
  • When Everything is Important But Nothing is Getting Done
    • Step 0: Create Consensus That There is a Problem
    • Step 1: Create a Unified View of All Existing Work
    • Step 2: Create and Implement Criteria for Comparing Projects
    • Step 3: Sequence The Projects & Commit to that Sequence
    • Step 4: Getting Work Started
    • Step 5: Identify and Fix Your Organizational Constraints
    • Step 6: Create A Clear Finish Line (Definition of Done)
    • Step 7: Keep It Going
  • The practical application of "Rocks, Pebbles, Sand", A Smart Bear
    • If you schedule little things first, you run out of time for the big things.
    • Rocks maximize Impact
    • Rocks: Beware: “Maximizing impact” is harder than you think
    • Execs decide, but ideally PMs are in command
    • Sand maximizes Throughput
    • Beware: Administrative overhead destroys throughput
    • Sand: Prioritize with intuition and desire, not math and metrics
    • Self-managed teams schedule their own Sand
    • Pebbles maximize ROI
    • Beware the surprisingly high impact of estimation error on ROI

Truth emerges more readily from error than from confusion. Francis Bacon

Goals

  • With Goals, FAST Beats SMART: goals should be embedded in frequent discussions; ambitious in scope; measured by specific metrics and milestones; and transparent for everyone in the organization to see.

A goal without a plan is just a wish. Antoine de Saint-Exupéry

OKRs

Presentations, design and public speaking

Some great examples of presentations:

Prioritization

See also the Prioritization section on my entrepreneurship-resources list

  • How To Do Less
    • Ordering a todo list vs. only doing the top item in the list
    • Two meta-priorities: (1) keep the lights on, and make keeping them on cheaper, (2) cut the entire roadmap down to one thing at a time
    • How to handle disappointment
    • Say no, early and often
    • How to say no
    • How to correct distractions
    • Maintaining flexibility: default to iterate, but be willing to invest
  • Prioritization is a Political Problem as Much as an Analytical Problem
    • Does not work: Asking exec teams to collectively prioritize long lists of things
    • Does not work: Lectures about algorithms, development processes, and staffing shortages
    • Does not work: Expecting spreadsheets to prioritize for us
    • Helpful: Set an explicit top-down allocation of effort across a few broad categories
    • Helpful: Push every exec-level stakeholder to provide a very short, fully ordered list of their group's needs
    • Helpful: Briefly recap top 3-4 products or projects every week
    • Helpful: Use Now/Next/Never to frame upcoming choices
    • Helpful: Define in advance what kinds of work can be realistically outsourced, and actively recruit external partners

Problem solving

See my professional-programming section about problem solving

Processes for engineering

@samkottler: No amount of process will ensure the right work is getting done.

Product management

Project management

The ultimate inspiration is the deadline. — Nolan Bushnell

Estimating work (project management)

Release management

Remote teams

Team vision

"Starting with the why" is one of The 7 Habits of Highly Effective People's best chapters.

Technical strategy

  • Joel Spolsky, Things You Should Never Do, Part I: Joel explains why (according to him) you should never rewrite a codebase.
  • 🎤 Choose Boring Technology, Dan McKinley.
  • Stevey's Google Platforms Rant: how Amazon became a platform.
  • Letter to Shareholders, Jeff Bezos: “Day 2 is stasis. Followed by irrelevance. Followed by excruciating, painful decline. Followed by death. And that is why it is always Day 1.” So much is packed in this letter. Day 1 is about true customer obsession, resisting proxies, embracing external trends, high-velocity decision making.
  • 5 Red Flags Signaling Your Rebuild Will Fail
  • Polyglot programming in startup environments
    • Never introduce a new programming language in an existing code-base because of personal preference. Building software is a team effort. Globalize your code languages. Team cohesion is what matters the most.
    • You must have production experience in the programming language you want to replace or complement with another one
    • A decision to introduce a new programming language must be based on non-functional requirements, measurements or other relevant arguments, and not personal opinions.
    • Always think about the team and company, and especially about hiring and expanding the team.
    • A programming language is just a tool to deliver software. Don’t be in a tight relationship with your screwdriver.
  • Tech Migrations, the Spotify Way
    • Ruthlessly prioritize
    • Product-ify migrations: accountability, test first, train, lead with value, KYC, gamify
    • Automate, automate, and move up the stack!
  • hwayne/awesome-cold-showers: for when people get too hyped up about things
  • IT Software Engineering Principles

Team culture

Those are considered classics:

culturecodes is a repository of culture deck from companies (including the ones above).

Engineering values:

  • Engineering Values. A letter to the Medium Engineering…
    • Professional & personal growth is more important than team stability
    • Everyone is a mentor; human connection is the path to bringing out the best in people
    • Excellent teams require diversity & inclusiveness
    • Good leaders are active and supportive
    • Good engineers are rigorous and resolute
    • Pursuit of greatness is a virtue
  • Engineering Values at Lullabot
    • People matter more
    • Cultivate inclusivity
    • Learn and share
    • Excellence balances perfect and done
    • Code for the future
    • Work joy into work
  • Figma's engineering values
    • Communicate early and often
    • Lift your team
    • Craftsmanship
    • Prioritize impact
  • HubSpot’s Engineering Values
    • Customers Come First
    • Complacency Equals Failure
    • Think Like an Owner
    • Move Quickly & Iterate
    • Small Teams Win
    • Keep It Simple
    • Embrace Organizational Change
    • Scale Each Other
  • Our engineering values at Wise
    • Ship often. Learn. Iterate. Have impact.
    • Be replaceable — single ownership is no ownership.
    • Move fast, but build for tomorrow.
    • Strong opinions, weakly held, openly shared.
    • Raise the bar — for yourself and your team.

Scaling an organization

Security

Soft skills, Emotional Quotient (EQ)

Strategy

Shameless plug here, two presentations I contributed to:

  • 🎤 Amazon: the hidden empire
  • 🎤 Apple: 8 easy steps to beat Microsoft
  • Michael Porter's generic strategies (Wikipedia)
  • Steve Jobs explaining why you should start from the customers, and go backward (video 🎞). He makes the point that stopping the OpenDoc project was the right thing to do because it was a technology without any customer.
  • Can Do Vs Must Do , AVC. "Doing a startup is like playing a video game. Each level requires you to master one thing and once you do that, you level up and then there is a new thing to master."
  • "Waterline principle" from Bill Gore: "Think of being on a ship, and imagine that any decision gone bad will blow a hole in the side of the ship. If you blow a hole above the waterline (where the ship won’t take on water and possibly sink), you can patch the hole, learn from the experience, and sail on. But if you blow a hole below the waterline, you can find yourself facing gushers of water pouring in, pulling you toward the ocean floor. And if it’s a big enough hole, you might go down really fast, just like some of the financial firm catastrophes of 2008. To be clear, great enterprises do make big bets, but they avoid big bets that could blow holes below the waterline.", How We Might Fall.
  • Write five, then synthesize: good engineering strategy is boring, Will Larson.

Team dynamics

  • Shields Down, Rands in Repose
    • Boredom in its many forms is a major contributor to resignations, but the truth is the list of contributing factors to shield weakening is immense.
    • Every moment as a leader is an opportunity to either strengthen or weaken shields.

Training

  • Great developers are raised, not hired
    • Take some money, energy, time that you spend on recruiting and invest it in teaching your best developers mentoring skills.
    • Adjust your interview process and give a chance to candidates that are not good enough yet, but are eager to learn and have a growth mindset.
    • Relax “hard requirements” in your job ads to avoid filtering out impostors.
  • “Sharing Interesting Stuff”: A simple yet powerful management tool
    • Your direct report sends you something they consider worth sharing with you (can be a blog post, book chapter, video, podcast…) and a few related questions they have in mind a few days before you meet together.
    • On the D day, you share your opinion about it and try to answer the questions that go with it.
    • You switch roles for the next session.
  • Introduce Team G Morning Learning Sessions to Coach the Growth Mindset
    • Meet every morning for 30 minutes. Spend 20 minutes studying and 10 minutes sharing what you have learned.
  • Your Startup’s Management Training Probably Sucks — Here’s How to Make it Better, First Round Review
    • People often think they don’t like management training. But what they’re really saying is “I don’t like shitty management training.”
    • Mistake: only training new managers
    • Snacks are good for the kitchen. They’re less useful for leadership lessons.
    • 4 topics every manager training should include:
      • Goal setting
      • Talent management
      • Org planning
      • Leadership & culture development

Work ethics & work/life balance

Workshop facilitation

Writing

➡️ See also my professional-programming list

Other sources

Other lists

Movies

TV Shows

Netflix's Chef's table profiles a couple world-renown chef. The kitchen world bears a lot of similarities with management. In the season two, I especially recommend episode 1 and 3:

  • Alex Atala's story shows that you need to constantly reinvent and disrupt yourself.
  • ドミニク・クレンは、最初のキッチン体験で自分の仕事の所有権を与えられた方法を説明します(基本的に料理名と材料のリストだけが与えられ、キッチントレーニングなしでレシピを発明することが期待されていました)。彼女はそれを自分のキッチンで再現しました。

オフィスは、機能不全のオフィスの偉大な風刺です。

最新情報の入手: ブログやニュースレター

ここに私がフォローしているいくつかのブログとニュースレターがあります。

ニュースレター

  • ソフトウェアリードウィークリー(オーレンエレンボーゲン):優れた管理記事の短いキュレーション。また、いくつかのビデオ、およびそれほど深刻ではない、面白い素材を含めます。このリポジトリにあるリンクの多くは、Orenの毎週の電子メールに表示されていました。
  • HBRの今日の管理のヒント
  • テックピープルリーダーシップ(ジョーダン):テクノロジー業界のリーダーのためのリンク、メモ、意見。
  • CTO Insights(Tosho Trajanov):ソフトウェアエンジニアリングとテクニカルリーダーシップに関する毎週の読み物。

ブログ

  • ハッカーニュース:テクノロジーで何が起こっているかに遅れないようにしたい場合は必須です。時々いくつかの良い管理記事もあります。それはかなり大きな時間のシンクになる可能性があるので、私は代わりにトップ記事のキュレーションを購読します(RSSフィードはこちら)。

ポッドキャスト

  • ボブ・サットンとの摩擦。このポッドキャストには2017年以降の新しいエピソードはありませんが、いくつかの本当に素晴らしいコンテンツがあります。素晴らしい会話。たくさんの物語。
    • 一部の組織設計。部分療法。組織心理学者でスタンフォード大学のボブ・サットン教授は、従業員を苛立たせ、チームを疲労させ、組織を挫折させ、失敗させる現象である摩擦に取り組むために戻ってきました。

About

Author：charlax

Watch
Star
Fork