Staff Engineerの本を読んだ
Staff Engineer, Leadership beyond the management trackというタイトルの本を呼んだ
何が書かれているのか
GAFAに代表される米国Tech companyではSoftware Engineerの職位として、Stuff Engineerというタイトル・ポジション・グレードがある。会社によって違いはあるものの、概ねSeniorよりも更に上のグレードのエンジニアを指す。
例えばGoogleでは下記のようなグレードがある。Google Senior Fellowが最上位となる。
Senior Software Engineer
Staff Software Engineer
Senior Staff Software Engineer
Principal Software Engineer
Distinguished Software Engineer
Google Fellow
Google Senior Fellow
https://codingrelic.geekhold.com/2018/08/google-software-engineering-levels-and.html
本書では、そのStaff Engineerについて書かれた話である。著者がインタビューしたStaff Engineerを4つのタイプに分けてまとめ、彼らのRole & Responsiblityについて紹介している。その後、Staff Engineerとして心がけるべきことや、どのようにしたらタイトルを得られるかといった内容が、紹介されている。後半には著者がインタビューしたFastly, Uber, InstagramなどのStaff Engineerの方々のエピソードがある。
読んで思ったこと
Staff EngineerはSenior Engineerの延長線にあるわけではなくて、全く別の職種であると捉えるべきだとのまとめがとても興味深い。ときには社内調整のようなものに従事したり、後進の育成に携わったり、Individucal Contoributerというよりは、Managerに近い性質を持っている。
個人的にとても感銘を受けたのは、Engineering Visionの作成についてだった。簡単に言うと、複数のDesign docから共通の要素を抜き出したものが、Engineering Strategyであり、更にその複数のEngineering Strategyから共通の要素を抜き出したものがEngineering Visionになる。組織に潜む、共通の部分を見つけ出し、そこに対するインパクトを出すことがStaff Engineerに対する期待値として、設定されているのであろう。
また、Staff Engineerになるには運と、それに向いた仕事が必要だ、と割り切っているところも清々しく読めた。私自身の経験を照らし合わせても、現実感のある意見に思える。Staff Engineerは経営陣に相当するタイトルである。そのため、単に実力・実績があればたどり着けるわけではなくて、そもそも、追加でStaff Engineerが必要とされているか、あるいは積み上げた実力実績が、会社の方向性と一致しているのかという要素も影響してくる。
SeniorなEngineerになって久しく、なにか天井感を感じているエンジニアにおすすめできる一冊である。
本のあらすじ
ここから先に本に書かれているあらすじを抜粋していく。
Staff Software Engineerとは
本書ではStaff Software Engineerが4つのパターンに分けられている
Tech Lead
Engienering Managerと連携し、チームを率いる。Product Managerとの連携を必要とし、チームのロードマップに変更を要する場合に、真っ先に相談される。
コーディングをする割合は多くないが、チームのTechnical Visionや複雑な問題に対する対応をリードする立場にある。
会社によってはTech Leadはタイトルである場合もあるし、ロールである場合もある。概ね8人のエンジニアに1人のTech Leadを必要としており、そのためStaff Engineerの中では最も典型的なパターンとなる。
Architect
技術の方向性、設計の質に責任をもつ。例えば、APIのデザインや、frontend stackの義jつ選定、ストレージに関わる技術選定、あるいはクラウドのインフラ設計などに責任をもつ。
アーキテクトには、システムのデザインにのみ責任をもち、その後は他の人に任せる、という間違った印象があるが、優れたアーキテクトの実態はそうではなく、ビジネスニーズやユーザの求めるもの、そしてそれを実現するための技術的制約を理解するために時間を費やす。
比較的大きな会社や、複雑で結合されたコードベースを持つ会社、そして技術的負債を解消する必要のある会社で必要とされる。
Solver
複雑な問題に対する解決を行う。複雑で絡み合った問題の解決を任される、信頼のおける人物である。
解決した問題の保守をチームに引き継ぐ必要がある。そのため、引き継がれたチームがやりがいの無い仕事だけを任されているといった感情を引き起こさないように、任されたチームの心情に配慮した行動が必要となる。
スクラム開発が複雑になった規模の会社で必要とされることが多い。
Right Hand
経営陣から権威を委譲され、複雑な組織を運営する。4つのパターンの中ではもっとも珍しい。
委譲された経営陣やリーダと同じミーティングに出席し、重要な問題を変わりに片づける。大抵の場合は単なる技術的な課題ではなくて、ビジネス上の課題も混じり合った課題である。
課題に入り込み、適切なチームを見つけ任せる。そして、また次の課題に取り組む。
Staff Engineerとして働く
大事なことをやる
snackingを避ける
日本語に訳すとすれば、「つまみ食い」は避けましょうといった意味になる。正常に機能している会社では、大抵の場合、手早くインパクトの出せる仕事はない。その場合、簡単なタスクだが、同時にインパクトも小さいタスクに取り組みたい気持ちになることがよくある。
そのような場合は、達成感は得られるものの、インパクトの大きな仕事はできていない。snackingに自覚的になり、陥らないようにしないといけない。
preeningを避ける
こちらも日本語に直せば、「毛づくろい」は避けましょう、といった意味になる。snackingと一緒で、難易度は低く、インパクトも低いが、効果がわかりやすいタスクでもある。現実社会の多くの場合、「インパクトの大きい仕事」と「目立つ仕事」は区別がしづらい。そのため、多くの会社で、最もSeniorなエンジニアが、インパクトが有るのか疑わしい仕事に従事しているという現象を見かけることがよくある。
Ghostを追いかけない
今の組織が抱えている課題をきちんと理解せずに、前職の成功事例などをそのまま適用しようとしてはいけない。
現実的な問題に取り組む
資金が枯渇して会社が倒産の危機にあったり、会社のサービスが極めて不安定であるような場合は、それらの解決にFocusする
Editする
多くのプロジェクトは成功にあと一歩という状態であり、Staff Engineerの助力を必要としている。
Finish Things
プロジェクトを終わらせる手助けをしよう
自分にだけできることをする
他のEngineerより、より早く、より良くできるといった仕事ではなく、自分にしか出来ない仕事をする
Engineering Strategyを書く
Design documentを5つ書く。そこに共通する課題を解決するものを書き出したものがEngineering Strategyとなる。そして、Engineering Strategyを5つ書き、そこから予測できる未来を書き出したものがEngineering Visionとなる
技術の質を管理する
ビジネス上の目的を果たしつつ技術の質を保つことが重要である。常に色々な要素とバランスを取らないといけないが、それらはしばしば対立する。会社の成熟度に応じて、取るべき行動は変わるが、以下の7つの段階に分けて考えることができる。
問題を起こしているhotspotsを見つける
解決するためのbest practiceを導入する
一番優先すべきleverage pointsを見つける
組織がどのようにソフトウェアを必要するか考え、整合性を取る
技術の質を測定する
technical quality teamを組成する
quality programを運営する
権威とアラインメントを取る
Staff Engineerは会社を運営する側にいる。Senior Engineerだったときに存在した、会社と自分の間に入って守ってくれる人は存在しない。自分で経営者とアラインメントを取る必要がある。
リードするために従う
人にフォローさせてばかりでは、影響力は維持しづらい。ときには、他の人に任せて、自分がフォローすることも必要となる
間違わないことを学ぶ
常に人の話をよく聞き、会議の空気感を読み、間違った決断を下さないようにする。相手の主張を理解するために、自分の考えを述べる前に、質問をするというプラクティスを身につけると良い。
後進のための場所を作る
頼りになるEngineerであるのは重要だが、会社をやめた途端、会社が回らなくなるという状況は作るべきではない。できるものは委譲することが重要である。成功しているStaff Engineerとは、会社が彼・彼女から多大な恩恵を受けているが、依存していないエンジニアである。
人脈をつくる
似たような仕事をしている人たちと個人的なネットワークを作ることをおすすめする。
メンターを持つことはキャリア上有益だし、イベントなどで登壇して培った人脈によって仕事の機会を得ることもある
経営陣に説明する
しばしば経営陣への説明が必要となる。構造化されたドキュメントを用意して、目的意識を持って話すことが重要である。フィードバックを集めることに集中する。異論がある際には、一度持ち帰ってデータを揃えてから行うこと。そして問題を共有する際は、解決策の提案を必ず添えること。
Staff Engineerになる
一般的な会社において、Mid LevelからSenior Engineerへの昇格は、ある程度の期間の間に達成することを期待される。一方で、Senior Engineerは必ずしもStaff Engieerに昇格することを期待されない。例えば6年間 、Senior Engineerになれないままだと、パフォーマンス上問題とみなされるかもしれないが、20年間 Senior Engineerのままだとしても問題とみなされないだろう
Staff Engineerの昇格は実力があれば必ず実現できる、といったものではない。年単位でタイミングを待つ必要があることもあるし、まったく実現できないこともある。
本書でインタビューの対象となったStaff Engineerのうち、1/3は、そのときにいた会社では実現できず、転職を行ってStaff Engineerのタイトルを獲得した。
残念な事実として、Staff Engineerへのチャンスは社内に平等に存在しない。もし、会社の経営層がProduct EngineeringよりもInfrastracture Engineeringをより技術的に複雑で難易度が高く、そしてビジネスに対してよりリバレッジが効いている仕事である、とみなせば、Infrasctracture teamのほうが昇進のチャンスが多いであろう。また、地方拠点にいるよりは、本社にいたほうがvisibilityがよく昇進しやすいだろう。
Staff Engineerはリーダ層の一部であるため、昇進にはリーダ層から自分たちの仲間だと認めてもらう必要がある。そのため、すでにリーダ層の誰かと一緒に働くチャンスがある人のほうが有利であるという事実がある
promotion packet
昇進のための推薦状であるpromotion packetを自分で書こう。昇進を果たしたい時期よりずっと前に書くのがよい。これを地図としてプランニングができる。
sponsorを探す
多くのstaff engineer候補は、実績が十分ありながらも社内の知名度と認識が十分でないために、昇進を果たせずにいる。
このような場合には、実績を関係者に認識させてくれるために、スポンサーが必要となる。
Staff Engineerへのプロモーションはteam gameである。そのため、スポンサーの助力なしで、一人で戦ってもうまく行かない。
知名度を上げる(Being visible)
Staff Engineerの昇進は、運とタイミングと仕事の組み合わせである。社内で優先度の高いプロジェクトに従事してたり、昇進を手厚く面倒見てくれるManagerと仕事してたり、Head Quaterで仕事をしてない限りは昇進は難しいだろう。
そのような状況にない場合は、社内でのvisibilityを上げる努力を行う必要がある
会社を変える
Staff Engineerへの昇進が難しい場合、そしてタイトルが重要な場合は、会社を変えることも選択肢になるだろう。
その場合、自分自身のスキルセットに一番マッチした評価をしてくれる会社を選ぶと良い。例えば、APIの設計の経験をかわれFastlyでStafff Engineerになった人もいるし、コンパイラー開発の経験を重視されてStripeでStaff Engineerになった人もいる
この記事が気に入ったらサポートをしてみませんか？