Skip to main content

[感想]The Staff Engineer’s Pathの1章を読んだ


The Staff Engineer’s Pathの1章を読んだ
マスタカと言えばStaff Engineer
実はSeniorより上なんだぜ・・・!
そんなわけで本書を読んだわけだ

今回は以下章の感想
1. What Would You Say You Do Here?


シニアエンジニアの次
・シニアエンジニアの次のキャリア
一つの方向性がマネージャー
もう一つが上司がいない技術リーダー。これがスタッフエンジニア

マネージャーの道も険しいがどうしたらよいかはわかる。
スタッフエンジニアは定義があまりない。
シニアよりも成長した役職を作る会社はあるが枠が少なく
スタッフエンジニアと働いたエンジニアは少ない。

・シニアエンジニアの上下で求められているもの
シニアエンジニアより下のレベルなら自立性を伸ばす
シニアエンジニアより上になるにつれて影響と責任が増える

・タイトルが必要な理由
・自分自身が進歩していることを理解する
・権限が与えられない人に権限を与えることを会社が支援する
・自分以外の人にどのレベルの人か伝えられる

 

スタッフエンジニアについて
・スタッフエンジニアのスキル

技術をベースとして以下3つが必要
・Big-picture thinking
広い視野をもって今、1年、3年と時間軸を考える
それを踏まえて良い判断をする

・Execution
プロジェクトは曖昧でめちゃくちゃだが
周囲を巻き込んで影響を与えて成功に導く。

・Leveling up
ロールモデルとしての振る舞いを周囲に見せる
そしてティーチングとメンタリングも含めて周囲のスキルを上げる

・ヒューマンスキル
上記のスキルを発揮するために以下のようなヒューマンスキルが必要
コミュニケーションとリーダーシップ
方向の曖昧さを解消する
あなたの仕事を予見できるようにする
メンターシップ、スポンサーシップ、移譲
他人が理解できるように枠組みをする
一人であったとしてもリーダーのように振る舞う

ヒューマンスキルの一部の能力が欠けると以下のようなことになる
会社や業界の行く末を把握するのうまいが、インシデントの管理に失敗して信用を失う
周囲のスキルを上げるのはうまいが、技術の方向性のコンセンサスを作るのに苦労する

・4つの役割
1つだけの場合も複数の役割取ることもある
Tech Lead:実行をガイドする
Architects:技術の方向性や特定エリアの質に責任を持つ
Solvers:一つの難しい問題に取り組む
Right hands:組織についてリーダーシップを取る

・組織での位置
directorと同格のstaff engineerもいれば
managerと同格の位置にあるstaff engineerもいる

 

他の役職との違い

・TPM(technical program manager)
TPMはデリバリーに責任を持ち、デザインやエンジニアの質にはこだわらない
スタッフエンジニアは、エンジニアの基準に責任を持つ

経験の少ないエンジニアは良いコードを見たことがない
スタッフエンジニアは良いアーキテクチャを取りこむことで
より早くより安全に作れるようにする義務がある

・TLM(tech lead manager)
チームの技術リードとチームのマネジメントのハイブリッド業務を行う
人によっては技術とマネジメント両方に時間をさけないためキャリアが前進してないと嘆く
staff engineerは技術に責任を持つのが違い

 

スタッフエンジニアの仕事の仕方

・Big-picture thinking
ローカルの最適化はシングルグループならよいが
スタッフエンジニアはもっと広い視野を持つべき

・PJでやるべきこと
PJで誰かがすべきことがあると感じるならば
誰かはあなたですよ

あなたのゴールは問題を効率的に解くこと
プログラミングがあなたが時間を使うことに最適とは限らない
デザインやリーダーシップをし、他人のプログラミングをハンドリングする方が良いときもある
問題を解くのであって、どうやってやるかではない。

・マネージャーとのかかわり方
マネージャーは情報をあなたに持ってきてコンテキストを共有するべきだろう
逆に、あなたはマネージャー達に何が重要かをあることを伝えるべきだろう

・キャリア開発
マネージャーは自分よりスキルが下の人間なのでキャリア開発には役立たたない。
自分からPJを探しキャリアを開拓する

・スコープについて
自身のスコープを無視しよう
あなたの価値の一部分は、あなたの組織上のヒエラルキーにないかもしれない

・視野が広すぎて失敗する例
問題を解くための準備ができてから動こう
インパクトが小さい:簡単なサイドプロジェクトを担当することや、ゴールがまったくないプロジェクトを担当する
ボトルネックになる:あなたなしで管理できなくて結局遅くなる
決断疲れ:全部やろうとするため
関係の喪失:チームが多すぎて全員と良い関係が作れなかった

・逆に狭すぎて失敗するの例
自身がどの場所にいるべきか明確にしよう
インパクトが小さい:スタッフエンジニアが不要なレベルの話だった
機会コスト:組織での引き合いが多いはずが1チームに配属される
他の人を見劣りさせる:staffは暇で、他人の教育機会を奪う
オーバースペック:もっと難しい問題にスタッフエンジニアを充てるべき

・問題への取り組み方
深さと幅どちらを優先するかは人による

・どのぐらいコーディングをするか
あるスタッフエンジニアはコードを読むこととレビューのみ実施し、コードは書いていない。
あるスタッフエンジニアは毎日コードを書く
あるスタッフエンジニアはコーディングする理由を探している。そして、プロジェクトが遅れない範囲で興味のあることや勉強目的でコードを書く

もし毎日コードを書いても不安なら、大きいアーキテクチャや影響力が大きい仕事を引き受けないようにしましょう。
または、その計画を立てておくことで、コーディングのタスクに飛びついて大きな問題を放置しないようにできます。

・シニアが多いPJなら
新たにスタッフエンジニアが追加されてもスピードが遅くなるだけ
別のPJを探しましょう

 

1章はスタッフエンジニアの定義と
PJへの関わり方が中心でした。

まだまだ続くよ

関連記事:

Pocket