スタッフエンジニア マネジメントを超えるリーダーシップ
第１部 スタッフとして活躍するために
第１章 全体像
- キャリアラダーは大きく2本に分岐する
- 共通：キャリア初期→中間レベル→シニア
- スタッフプラスの場合：→スタッフ→プリンシパル→ディスティングイッシュト
- マネジメントの場合：→マネージャー→シニアマネージャー→ディレクター→バイスプレジデント
- スタッフプラスエンジニアのアーキタイプ
- テックリード
- 最も一般的なアーキタイプ
- タスクの遂行においてチームを成功に導く
- チームを重視するアジャイル開発においてニーズがある
- シリアエンジニアの活動と大部分では共通している
- 大抵の企業は8人にエンジニアに対して1人のテックリードを必要とする
- アーキテクト
- エンジニアが100人を超えると必要とされる
- 特定の技術分野を成功に導く（APIデザインやストレージ戦略、クラウドインフラストラクチャなど）
- ソルバー
- 上層部の任を受けて困難な問題に取り組む
- 個人単位で動くこともよくある
- スプリント中心の会社ではあまり多くない
- 大きく成長した会社や、長期的な技術的負債を抱えた会社は例外
- 右腕
- 数百人規模の会社に現れる
- 経営責任を負わない組織リーダー
- 重要な意思決定の場に同席して大きな問題を取り除く
- 社内で火の手が上がった場所へ次々と直行して解決していく
- どんな仕事に充実感を覚えるか
- テックリードとアーキテクトは長年にわたって特定の人々と特定の問題に取り組む
- チームとの一体感や共通の目的意識が芽生えやすい
- ソルバーと右腕は週によって仕事をする相手が変わる
- 経営陣の優先事項に密接に携わる
- スタッフエンジニアの実際の仕事
- 技術的な方向性の設定
- みんなが漠然と良くしたいと思っている
- 正確な目的地のための共通理解を促し助ける役割
- メンターおよびスポンサーとしての役割
- 参考：
- エンジニアリングの展望を伝える
- 意思決定の場で適切なインプットを行う
- 探索
- ヒルクライミング法は効率が良いが、最も高い山に登れるかどうかは分からない
- 長期的に成長できるアプローチを探す
- インフラ費用を一桁減らしたり、マルチリージョン戦略を構想したり
- 接着剤になる
- 「Being Glue」
- 目に見えないタスクをこなしてチームを前進させ、成果を出荷すうｒ
- ソフトウェアを書くの？
- 時と場合による
- e.g. メンバーほどではないけど今でも頻繁にコードを書く
- e.g. データ分析においてSQLを書いたりJS/PHPで実験コードを書く
- e.g. コードとは疎遠になるが、それより重要な仕事が増えていく
- キャリア初期ほどコードを書くことは減る
- 一方で、同僚のコードを読むし、コードレビューも頻繁に行う
- 時間はかかるがやりがいはある
- キャリア初期と比べて仕事のサイクルが長くなるから
- 何も成し遂げられない日があるのは普通
- 肩書は重要？
- 年功序列という非公式制度
- 年功序列で能力を測られることが多い
- 肩書があると自分の能力を証明しやすくなる
- 部屋へのアクセス
- 上位の意思決定の場に参加しやすくなる
- 報酬
- 大抵は上位役職ほど報酬が高い
- おもしろい仕事へのアクセス
- おもしろい仕事に携わりやすくなるが、役職として求められることをするケースも多くなる
- 「より良い」よりも「異なる」仕事を
- スタッフになることで様々な利点が増えるが、楽しかった仕事ができなくなる可能性も高くなる
- スタッフになるか否かの決断も重要
- 肩書は魔法ではない
- 肩書によって解決できることはあまりない
- 肩書がblockerになっていると感じる時は、アプローチやスキル向上に目を向けた方がいい
- 女性とマイノリティは例外
第２章 スタッフとしての役割
- 重要なことに力を注ぐ
- スナッキング（つまみ食い）を避ける
- 簡単だがインパクトが弱い仕事をすることで達成感を得られて精神的にはメリットがあるが、学べることはまずない
- インパクトの強い仕事と弱い仕事の時間配分には誠実でいる必要がある
- プリーニング（おめかし）
- インパクトが弱く目立つ仕事をすること
- 企業の多くは高い視認性と強いインパクトを混同している
- 短期的なキャリアでは有効な場合があるが、長期的にはつらくなる
- ゴーストチェイシング（幽霊追い）
- 前職での経験に縛られて苦労に見合わない変革を行うこと
- 入り込む余地があり、なおかつ注目があつまる場所で働く
- たくさんの人が奮闘している場所でインパクトを残すのは難しい
- 会社にとって重要なのに、まだ活動の余地が残っている領域なら効果的に働ける
- 会社が見落としている仕事は失敗に終わることもあるが、とても困難で重要な仕事なので完全に避けるべきではない
- 成長を促す
- 採用に注力しがちだが、オンボーディングやメンタリングも同じくらい重要
- エンジニアリング戦略を立てる
- 5つのdesign docがあれば優れた戦略な下地になる
- 技術品質を管理する
- 権威と歩調を合わせる
- 上司と認識を合せる、驚かせない
- リードするには従うことも必要
- 絶対に間違えない方法を学ぶ
- 一方的に押し付けない、良い人間関係を築く
- 他人のスペース（余地）を設ける
- 会社から依存されない状態を作る
- 適切に人に任せる
- 決断も人に任せてOK
- スポンサーとして支援する
- ネットワークを築く
- 同じような仕事をする仲間を作ることが大切
- 経営幹部の前で
- 幹部は基本的に優秀だが、技術領域に対して理解と避ける時間がない場合がほとんど
- 効果的にコミュニケーションを取ろう
第３章 スタッフプラスの肩書を得る
- スタッフエンジニアの内、1/3はスタッフになるために転職が必要だった
- プロモーションパケット（昇進申請に必要な文書）
- 早い段階から作っておいて、同僚とか上司にもレビューしてもらうといい
- スタッフプロジェクト（スタッフになれるほどの重要なプロジェクト）
- 必須ではないけど経験するといい
- マネジメントに興味があるなら試してみるといい
- チームのためでなく自分だけのためならやめた方がいい
- 部屋に入り、とどまり続ける