世界を動かす技術を、日本語で。

エンジニアリングマネージャーにならないでください

概要

  • エンジニアリングマネージャー(EM)昇進の是非についての議論
  • 現在のキャリアパスや組織構造の変化
  • EMとIC(Individual Contributor)の報酬比較
  • 技術進化とマネージャーの役割変化
  • 最終的なキャリア選択は個人の価値観次第

エンジニアリングマネージャー昇進の是非

  • 友人が Engineering Manager (EM)への昇進を打診され、辞退を検討
  • 以前は「絶対にチャレンジすべき」と勧めていたが、今回は デメリット も考慮
  • EM経験は貴重だが、 管理職 キャリアを目指さない場合は慎重な判断が必要
  • AIコーディングツール の進化で、エンジニアの働き方自体が大きく変化
  • EMになると 実験や技術習得 の時間が減少し、技術的な成長機会が限定

組織構造とキャリアパスの変化

  • 企業の フラット化 が進み、EM以上のポジション(Senior EM, Director, VP)が減少
  • Amazonなど大手で IC-to-manager比率 が上昇、管理職枠の競争激化
  • EMからの昇進は「より多くのエンジニア管理」が条件だが、ポスト不足
  • IC(個人貢献者) としての卓越した技術力は、より高い評価と報酬に直結

報酬と市場価値の比較

  • EM昇進による報酬アップは限定的で、 Staff Engineer などIC職の方が高待遇例も多い
  • スタートアップなどでは Senior/Staff Engineer のオファーがEMより 20~30%高い ケース
  • 業界全体で、 優秀なIC の需要は今後も高まる見込み

マネージャーの役割と将来性

  • 経験豊富なEM で技術に手を動かし続ける人材は今後も価値あり
  • 技術トレンド追従は難しいが、 マネジメントスキル は引き続き重要
  • 何よりも「 自分が楽しめるか」がキャリア選択の最重要ポイント

キャリア選択のアドバイス

  • 現時点では ICトラック をおすすめ
  • 数年後、状況が落ち着いてからEM昇進を検討するのが賢明
  • ただし、「 本当にやりたい」という直感があれば、挑戦も選択肢
  • James Stanier の「ラダーが消えたときに何をすべきか」記事も参考推奨

関連リソース紹介

  • Gergely Orosz の「Even fewer middle managers and more flexible teams?」など業界分析
  • Gregor Hohpe の「Being an architect isn’t the sum of skills. It’s the product」
  • Sahar Carmel の「The Product Velocity Paradox」など、現代の組織課題に関する記事

Hackerたちの意見

タイトル(特に「テック」関連)がほとんど無意味だと感じるのは、私だけじゃないよね?「シニア」、「リード」、「プリンシパル」、「スタッフ」といった役職の定義は、組織によって全然違うから、重複が多すぎるんだよね。私自身もそういった役職に呼ばれたことがあるけど、正直なところ違いが分からない。場合によっては、「シニアバックエンド開発者」としての責任の方が「スタッフエンジニア」よりもずっと重かったりするし。最近、CTOやエンジニアリングマネージャー、テックリードなどの役職でいくつか面接を受けたけど、重複が多すぎて、ほとんど同じに見えるよ。6人から1万人以上の企業で働いたことがあるから、いろんな役職を見てきた。

タイトルは全然意味がないよ、あなたの言う通り。でもほとんどの組織では、ICトラックとマネージャートラックの分かれ目があるから、OPの主張は議論の余地があるけど、全く馬鹿げているわけではないよ。

特定の会社内では、これらの役割はしっかり定義されていると思う。大手テック企業では、プリンシパルエンジニアはシニアよりもずっと高いレベルで意思決定に影響を与えるし、シニアは自分のチームの外ではあまり目立たないからね。そしてエンジニアリングマネージャーは、チームをサポートしたり評価したり、代表したり、目標の調整を手伝ったりする役割だよ。

あなたの役職名は、あなたがプロとして誰であるかを示す重要な部分を含んでいるよ。価値は、単一の組織内よりも、組織間でずっと大きい。もし長い間同じ場所にいるつもりなら、あまり重要じゃないかも。実際に物事がどう動いているかを理解するチャンスがあるからね。知っている人にシニアアーキテクトがいて、会社ではみんな彼をそう呼んでいるけど、実際の役職名は「プロジェクトテクニカルリード」みたいな感じなんだ。20年や30年そこにいて、深呼吸のメティスを追い求めるつもりなら、役職名はあまり重要じゃないよね。私は同じキャリアの見通しを持っていないから、役職名は私にとって重要なんだ。私はそれについて積極的に交渉しているよ。私の役職は「シニアDevSecOpsエンジニア」。略語に対する批判はさておき、これは私が得意なこと、まあまあできること、他の人に頼んだ方がコストパフォーマンスが良いことをすぐに理解できるように示しているんだ。脆弱性管理やCI/CDパイプラインのセキュリティにはかなり自信があるけど、スパム対策のロジスティック分類器の重みを最適化するのは得意じゃないかも。などなど。

ICのタイトルが重要な理由は2つあるよ:報酬とパフォーマンスレビュー。大きな会社では、スタッフとシニアのRSUの量がかなり違うこともあるしね。スタートアップだと、株式が無価値で給料もあまり変わらないから、あんまり関係ないけど。パフォーマンスレビューでは、タイトルが評価基準を決めるけど、実際にはマネージャーがカーブを合わせてから基準に戻ってくることが多い。だから、3か4に決めて、弱い部分を選んで評価を下げるんだよね。現実的には、同じ仕事をしても、交渉や経験、前職によって、低いレベルで働いているのに給料が少ないこともある。VPやディレクター、Cレベルに入ると、組織ごとに独自の階層があるけど、責任のレベルが上がるにつれて結果に対する責任も増える。政治的な側面もあるけど、大きな組織間では大体同じようなものだよ。

「プログラマー」、「ソフトウェアデベロッパー」、「ソフトウェアエンジニア」なども同じだよ。実際には違いがあるって主張する人がいるけど、俺は全部やってきたけど、違いなんてなかった。

他の人も言っているように、レベルやタイトルは一般的に報酬やパフォーマンスレビューのためのものだよ。各社には独自の階層があるけど、一般的には次のように進む: - L1: 学部卒のインターン - L2: 大学院卒のインターン - L3: ジュニア - L4: 中堅 - L5: シニア - L6: スタッフ - L7: シニアスタッフ - L8: プリンシパル - L9: ディスティングイッシュド - L10: フェロー 各社には独自の数字や名前があるけど、だいたいこんな感じで進んでいく。階層が上がるにつれて影響力や範囲も広がる。L5やシニアは通常「終端」の役割と見なされる。つまり、すべてのエンジニアはこの役割に到達できるべきだってこと。頭打ちの人はL5に到達できないと管理されることになる。スタッフ以上は通常「特別」な役割で、イニシアチブを推進することが期待されていて、単にコードを書く以上の何かを持っていることを意味する。プロダクトやビジネスに影響を与えることができる。ディスティングイッシュドやフェローは非常に稀。大手FAANG企業では、こういったエンジニアはほんの数人しかいない。業界全体に影響を与えるようなことを成し遂げたことを意味するんだ。例えば、map-reduceやDynamoDB、Kubernetesを発明したような。

愚痴:しばらくシステムエンジニアをやってたけど、純粋なソフトウェアエンジニアではなかった。実際のエンジニアで、ナットやボルト、空気圧、アンプ、ボルトなんかを扱ってた。多くの会社でそのタイトルが使われていて、職務内容はかなり多岐にわたっていたけど、タイトルはかなり厳格だった。でも、テクノロジー業界が「システムエンジニア」というタイトルを使いたいと思ったんだ。理由は悪くなかったと思うけど、自分の役割に合った仕事を探すのがほぼ不可能になった。UnixだのWindowsだの。確かに、仕事でUnixシステムも使ってたけど、機械システムを制御するための小さなサーバーだったし、何億ものリクエストを処理するような巨大なラックではなかった。それに、ソフトウェア系のシステムエンジニアとしてキーワードに引っかかって、仕事のスパムも来るようになった。いつもエントリーレベルの役割ばかり。うんざり!なぜソフトウェアがUnixサーバーエンジニアやPython統合エンジニアみたいな、もう少し具体的なタイトルを使わなかったのか?俺の専門分野を侵食しないでほしかった。まあ、愚痴はこれでおしまい。

本当に組織による。 これが全てだね。タイトルは組織内で一貫して順序付けされるべきだけど、他の組織からは持ち運べない。これは、キャリアの初めにいる人たちに何度も説明しなければならなかった教訓だよ。数十万ドルをテーブルに置いておくことになるかもしれないオファーを選ぶ際に、他の会社がシニアエンジニアのタイトルをくれるからそれが重要だと思っている人からアドバイスを求められたこともある。採用の際、タイトルは基本的に無視される。MicrosoftやGoogleのようにレベルシステムが公に知られている会社から来た人でない限り。俺は「プリンシパルスタッフエンジニア」や「CTO」と名乗る人たちをたくさん面接したけど、平均的な会社ではシニアエンジニアとしてもぎりぎりの人たちだった。俺たちのチームの誰よりも経験が豊富で知識が少ない「シニアソフトウェアエンジニア」も面接したことがある(それはかなり言ってることだ!)。採用マネージャーはこれを知っているけど、たくさんの採用をしたり、いろんな会社で働いたことがないと分からないことだよ。

うちの組織では、タイトルを上げない限りインフレ率以上の昇給はないよ。長年働いているのに、達成可能なタイトルのレベルが少ないから、給料のゲートキーピングの一環かもしれないね。

幅広いばらつきがあるけど、過去10年間で「タイトルインフレ」がかなりあったと思う。これは、株式パッケージをこれ以上引き伸ばしたくない人たちにインセンティブを与えるためだと思う。

この分析には、業界や企業を考慮していない大きなギャップがあるね。エンジニアリングマネージャーは非常に一般的な役職だから、スタートアップ、大手テック、小規模テック、エンタープライズ、契約会社など、いろんなところに当てはまる。スタッフエンジニアはエンタープライズや契約会社ではあまり見かけなくて、そこでよく見るのはSWE 1/2/3 -> テックリード -> アーキテクトだね。ほとんどのテック企業は、SWE 1/2/3 -> スタッフエンジニア -> プリンシパルの流れが多いと思う。もう一つのポイントは、エンジニアリングマネージャーは終着点のポジションで、20年間マネージャーをやっていてもディレクターやエグゼクティブには昇進しない人も知っている。これは競争が激しくて、数学的に見てもほとんどの人は上に行けないんだよね。これもシニア -> スタッフやプリンシパルにも当てはまるけど。だけどエンジニアリングマネージャーのポジションは、エンジニアよりもボーナスやインセンティブの面で上昇の可能性が高いことが多い。結局、これはキャリアの変更でもあるから、それが一番考慮すべき要素だよ。

Hacker Newsで議論の続きを見る