Team Geekを読んだ

[etc] : Team Geekを読んだ

GWを利用して積読の消化をを実践中。Googleのギークたちはいかにしてチームを作るのかというサブタイトルが印象的な一冊。主にチームの文化形成やリーダー(マネージャー)としての在り方の部分を重点に自分なりに感じた言葉として纏める。

2章 素晴らしいチーム文化を作る

• チーム文化 = エンジニアリングチームが共有する経験、価値、目標。
• 優秀なエンジニアに働いてもらうためには優秀なエンジニアを採用しなければならない。優秀なエンジニアトップダウンのマネジメントではなく合意ベースのマネジメントを好み、意思決定に参加したいと思う。
• 建設的な批判はチームの発展や成長には欠かせない。
• MTGの数を減らして非同期コミュニケーションを増やすべき。
• ミッションステートメントを作成し、注力すること、やらないことを明確化し、プロダクトの方向性の合意を得る。ただしプロダクトのピボットに合わせて修正可能なものとする。
• MTGを行う際のルールを作る。
  • 絶対に必要な人だけを呼ぶ。新しいものを設計するMTGには5人以上呼んではいけない。
  • アジェンダをMTG前に配布。
  • ゴールを達成したらそこで終了。
  • MTGを順調に進める。
  • お昼、終業の前に開始時間を設定する。
• Face to FaceのMTGを過小評価してはいけない。
• 全てのコードはコードレビューされるべき。品質を保つと同時に品質への誇りを持たせる。

3章 船にはキャプテンが必要

• Googleではチームリーダーは二つの役割に分かれている。
  • TL(チームリード) : プロダクトの技術的なものに責任を持つ。
  • TLM(テクニカルリードマネージャ) : エンジニアのキャリアに責任を持つ。
• 多くのエンジニアはマネージャーになりたくないと思う。
• マネージャーになることは、自身をスケールさせたり、より多くのエンジニアと協力してより多くのコードを書くことができるし、もしくは自分がマネージャーに向いているかもしれない。
• 必要以上のマネージは行わないこと。例:マイクロマネジメントなど
• サーヴァントリーダーシップのようにエンジニアが働きやすい環境を整えるために、あらゆる障害を排除することも必要。
• 採用においては自分の言いなりになる人ではなく、自分より優秀な人を採用すべき。自分より優秀な人は自分の変わりになってくれるだろうし、新しい刺激を与えてくれるかもしれない。
• 1〜2人ほどのパフォーマンスが低い人がいるだけでチームはうまく回らなくなってしまう。そういった人をチームに残すことはその人のためにもならない。今の場所で成長させるか退席させるかを判断する。
• パフォーマンスが低い人へのコーチングは2-3ヶ月で達成する目標を定めてあげる。小さい目標から入って小さい成功体験を何個か積み重ね、次第に目標を大きくしていく。
• 採用を妥協してはいけない。イマイチな人を採用した結果、採用を妥協したことのコストより大きくなってしまう恐れがある。
• チームメンバーの幸せを追い求める。また面談では必要なものを聞く。
• チームメンバーにタスクを委譲するものと、自分で手を汚して対応する必要がある。リーダーになって間もない頃であればタスクをメンバーに渡してチームが学習する機会とする。しばらくリードした後であれば他の人がやらないような領域で自ら手を動かし尊敬を集める。
• 事を荒立たせる必要がある時もあり、その場合は直ぐに着手する。自然解決を待ってはいけない。
• 人を幸せで生産的にするのは外発的動機づけではなく、内発的動機づけであり、内発的動機づけには自律/熟達/目的の3つが必要。