『スタッフエンジニアの道』Tanya Reilly 著
『スタッフエンジニアへの道』を読んだ。

似たような本で『スタッフエンジニア - マネジメントを超えるリーダーシップ』と『エンジニアのためのマネジメントキャリアパス』を読んだことがあった。それぞれ、今回読んだ本でも紹介されており、この本もこれらと系統は似た本だった。

でも、それぞれで少し毛色が違う感じはある。『エンジニアのためのマネジメントキャリアパス』は副題にあるとおり、テックリードから CTO まで、職位ラダーの中で求められる・身につけるべきマネジメントスキルや経営レベルでのスキルが書いてある。
『スタッフエンジニア - マネジメントを超えるリーダーシップ』の方はより実務的な視点でスタッフエンジニアとしての職務について書かれている。本書はスタッフエンジニアについて書かれているけど、もう少し柔らかい感じ。よりエッセーに近いかなと思った(公式サイトでの分類も Essay だし)。より人間味のある視点で書かれていて、読みやすく『スタッフエンジニア - マネジメントを超えるリーダーシップ』よりは自分に合っていたかな。
シニアエンジニアとは
スタッフプラス(スタッフエンジニア以上の職位)の前に位置するシニアエンジニアについて、
「昇進するのを止め、現在の生産性、能力、アウトプットのレベルをキャリアの残りの期間継続しても後悔のないレベル」
という定義が紹介されていたけどこれはしっくりきた。正直なところ、今の自分はこの域に達している感覚はあるな。まぁ15 年近くずっとソフトウェア開発やってるしね。その間、ちゃんとしたマネジメント職につくこともなく、ひたすらコード書いてたから。別に、今の状態に満足してるわけではないが、これ以上の職位にいけなくても後悔はないのかもしれない。
スタッフエンジニアの仕事
以前のブログでも書いたけどスタッフエンジニアって、お金と人の管理はしてないんだけどやっぱりミーティングが多くなったり、いろんな人を説得・根回ししたり、組織横断の仕事は多くなるんだよね。もちろんそういう仕事を期待されてるわけだからやりたくないならなるべきではない。技術力だけでなく、信頼感やコミュニケーション力などがあるからこそ、会社はスタッフプラスの職位を与えて仕事してほしいするわけでね。
でも、やっぱ Individual Contributor の職位ラダーの上にはあるんだけどけっこう日々の仕事は変わるよねっていうのはあるよな。そこらへんは Google の morita さんも書いてたし。
そして最近も重要性の高そうな緊急プロジェクトのミーティング議事録が流れてきた。そこにはたしかにチームの Staff-plus たちが召喚され意思決定している。が、緊急度高すぎて近づきたくねー。しかも AI (action item) がひたすら stakeholder に話をして合意を得るだとか実際に実装する担当者を探すだとか、そんなのばっかり。やだよ・・・。この本にも "Present to executives" というセクションがあるけど、そんなの上司や PM に押し付けて逃げる以外にどうしろというんだ。
https://anemone.dodgson.org/2021/05/10/staff-engineer/
自分は別にコードだけ書いていたいとは思わないけど、そういうの大変だよなーと尻込みしちゃうし、そういう意味でやっぱりスタッフエンジニアになりたいかっていうと、うーん…。でも、それはそれでこの本の意図しているところというか、ミスマッチを起こさないことも目的の1つだとは書いてあった。それに「職位ラダーはいったりきたりしてもいいんだよ」とも書かれていて、もしかしたらもう少し子育てが落ち着いてきたらやる気になるかもしれないし。
ただ、スタッフプラスになろうと思わなくても、この本に書かれたことを実践するのはとてもよいことだなと思ったね。普通の雇われソフトウェアエンジニアの一人としては、こういうスキルはちゃんと持ってると強いよなーと思ったし、仕事上のツールセットとして身につけておくといいね。それに、自分の満足感として質の高い仕事はしていきたいし、「こういうところ自分直した方がいいな」と感じたところもあったから読んでよかったとは思う。
--
どうでもいいけどこの著者、今は Datadog の Principal Engineer なんだね。Datadog 毎日お世話になってます。。。
