- 7年間フロントエンド開発者として働いた後、チームリードと専任のエンジニアリングマネージャーになり、プロダクトやチームへの影響力は大きくなった一方で、仕事の性質は大きく変わった
- マネージャーは、テスト作成、プロセス改善、チームの雰囲気調整のように、ICだった頃には変えにくかった問題に、公式・非公式の権限で介入できる
- 長期的なキャリアでは、一般的なエンジニア職位より報酬が高く、staff+ ICより機会が広く、他の技術領域・プロジェクト管理・プロダクト管理・起業へ移りやすい転用可能なスキルを得られる
- 一方で、評価、無理な締め切り、組織の方針といった企業的な手続きを執行しなければならず、対立・心理的不安・常時待機のプレッシャーも直接背負うことになる
- マネジメント業務は結果が1か月以内に現れにくく、チーム分割や採用のように正しい変化であっても短期的には状況を悪化させることがあり、長いフィードバックループに耐える必要がある
エンジニアからマネージャーへ転換した過程
- 約2年前にチームリードへ移り、チーム拡大の後に専任のエンジニアリングマネージャーになった
- その前は7年間フロントエンド開発者として働いており、当初は上級個人貢献者（IC）キャリアトラックを選んでいたが、管理職へ転換した
- 転換の過程はでこぼこしていたが面白く、現在の仕事には好きな点も嫌いな点もある
マネージャー役割で好きな点
-
プロダクトとチームを変える権限
- マネージャーになると、プロダクトとチーム全体の状態を改善する権限が生まれる
- ICのときは、早朝のスタンドアップ、低いコード品質、理解しにくい新機能のような問題を変えにくいことがある
- EMは公式・非公式の権限を通じて、チームと自分自身がより良い形で働けるよう調整できる
- 同じ「テストを書くべきだ」という言葉でも、ICが言う場合とEMが言う場合では重みが異なり、EMの言葉は実際のテスト作成につながりうる
-
より広いキャリア機会
- エンジニアリングマネージャーは、一般的なエンジニアのトラックより広いキャリア機会を提供する
- EMは通常、junior、middle、seniorのような基本的なチーム単位のエンジニア職位より高い報酬を受ける
- staff、principalのようなより上位のIC職位にも、EM以上の報酬帯は存在する
- ただし、staff+ ICの仕事は、より難しい技術課題を抱える大規模テック企業に集中する一方、ほぼすべての企業のソフトウェアチームにはリーダーシップポジションがある
- 管理職のキャリアラダーはICよりさらに上まで続いている
- CTOになる可能性が低いとしても、マネジメント経験のない純粋なICにはない選択肢が開かれる
- EM需要はstaff+エンジニア需要より安定しており、キャリア後半でもより多くの機会を提供する
-
他領域へ移りやすいスキル
- マネジメントスキルは、特定のICエンジニアリング職より幅広く活用できる
- React経験のあるフロントエンドエンジニアは、他のフロントエンドフレームワークへ移るか、多少の職位低下を受け入れてバックエンド・モバイル職へ転換できる
- エンジニアリングマネージャー経験があれば、モバイル開発者チーム、インフラチーム、MLエンジニアチームのように焦点の異なるチームも任されやすい
- 新しいチームの大きな技術的難しさを理解するには時間が必要だが、多くの企業はこうした転換を受け入れられる
- EMを続けたくないなら、プロジェクト管理やプロダクト管理の役割へ移るのにも良い立場にある
- 技術市場全体が低迷していても、多くのマネジメントスキルは他業界でも通用する
- 人とビジネスの意思決定に関わる経験は、起業前の訓練としても有用である
-
知識が古くなりにくい
- 最新のフロントエンドフレームワークやツールを追い続けることに疲れを感じるなら、マネジメント役割は負担を軽くしてくれるかもしれない
- 「新しい」agile、kanban、scrumの方法論は20〜30年前からある概念であり、デモ・デイリー・1:1のような基本的な会議タイプも長い時間をかけて発展してきた
- マネジメントの核心にはチームワークと人間同士の相互作用があり、これは人類の初期から大きく変わっていない
- 技術変化を引き続き見ていく必要はあるが、急いで深く掘り下げる場面は相対的に少ない
-
慣れた技術課題の外にある新しい挑戦
- 特定の技術領域で4〜5年働くと、たいていの実務上の問題は十分に解決できるようになる
- 熟練したエンジニアがより大きな挑戦を探す方法には限界がある
- 新しいフロントエンドフレームワークのようにスタックを少し変える方法は、長く興味を保ちにくい
- フロントエンドからバックエンドへ移るような、より大きな転換は数年分の面白さを与えるかもしれないが、偶然に左右されたり報酬に影響したりすることがある
- 新しいライブラリで全部を書き直したり、将来のために9000 RPSを処理しようとしたりする形で問題を作り出すと、面白くてもチームやビジネスには害になることが多い
- 熟練エンジニアにとって、管理職への転換は報酬を下げずに最も多くの新しい学びを与えてくれる
マネージャー役割で嫌いな点
-
企業的な手続きを執行しなければならない
- エンジニアだった頃は、個人評価、無意味な締め切り、会社が強制するプロセス・技術スタック制限のような企業的なBSが嫌いだった
- マネージャーになると、そうした慣行を信じているかどうかに関係なく、それを執行する側になる
- 評価調整のある組織では、チームリーダーは6か月ごとに、十分に頑張っていない人を1人指名しなければならない
- 犠牲になるチームメンバーを出さないと、その後の過程で誰かが無作為に選ばれる可能性があり、手続きをなくすのは難しい
- 手続きによっては交渉したり迂回したりでき、たとえば「期待未満の成果」をラウンドロビン方式で割り当てることも可能だ
- チームの立場から見ると、マネージャーは時に企業モンスターのように見えることがある
- 解雇、閉鎖、組織改編のようなさらに難しい状況はまだ経験していない
-
人間関係の緊張を扱わなければならない
- エンジニアリングマネージャーになった出発点は、何かをうまく作る能力であり、技術的意思決定の支援、キャリア助言、プロセス調整、自動化構築を想定していた
- 実際の仕事の大きな部分は、人々の社会的緊張や心理的不安をデバッグすることだ
- 例:
- ジュニアエンジニアが機能プレビューをデプロイしようとして、いくつかのテストをコメントアウトした
- QA担当者は、チームがQAの役割と価値を尊重していないと感じ、大きく怒った
- マネージャーは信頼を回復しなければならない
- 別の例:
- プロジェクトマネージャーが滑った冗談を言い、デザイナーが傷ついて泣いてしまった
- マネージャーはPMに謝罪させなければならない
- 心理学者ではなく、人を特別うまく扱えるわけでもないため、この部分は難しく、慣れるまでは耐えながら進む感覚に近い
-
オフラインになりにくい仕事の構造
- エンジニアの生活は比較的余裕があることもある
- 急ぎのことがなければ、半日外に出てプロジェクトの未来を考えることもできるし、いくつかの会議を急に欠席しても大きな問題にならないこともある
- EMが数時間席を外すと、メッセンジャーには問題がたまる
- インターンが
npm install のやり方を忘れて作業できない
- シニアマネージャーが潜在的な機能について話したがっている
- リリースが崩れる
- 自分が進行したり調整したりする会議は、事前準備なしで飛ばすのが難しい
- チームが成熟し、プロセスが良くなれば改善する可能性はあるが、一般的にマネージャーはオフィスアワーをより強く実感する
- ワークライフバランスは自分の業務遂行能力に直接依存するようになる
-
フィードバックループが長く非線形
- ほとんどのエンジニアリング作業は、結果が比較的早く見える
- 新機能は数週間から数か月で結果が出て、バグを直せば翌日にユーザー反応を見られる
- リファクタリングは数時間で複雑さの低下を確認できる
- マネージャーの行動が1か月以内に目に見える結果を出すことは非常にまれだ
- チームが大きくなりすぎて分割するには、複数の段階を踏まなければならない
- 新チームに適切なエンジニア構成を決める
- 関係者と変化に対する感情について話す
- 新しい定例会議を設ける
- プロセスとコミュニケーションを設定する
- Jira関連の作業を処理する
- 場合によっては、サブプロダクトのコードベースを分離する
- こうしたことを1週間で終えられると思うなら間違いだ
- 正しい変化であっても、良くなる前に悪化することがある
- 人手不足で採用を決めても、短期的には面接に多くの時間がかかり、新メンバーもすぐには戦力化せずオンボーディングの時間が必要になる
- マネジメントの変化は、素早い問題解決というより大規模リファクタリングに近く、即時の改善が見えないためもどかしいことがある
転換を考えるエンジニアへ
- ICエンジニアから管理職へ移ることは、明るい面と暗い面の両方を持つジェットコースターのような経験だ
- 利点は、プロダクトとチームにより広い影響を与えられ、長期的なキャリアトラックとして機会と柔軟性が大きく、技術分野に退屈を感じたときに新しい挑戦を与えてくれる点にある
- 欠点は、企業方針の執行、社会的緊張と心理的不安への対応、オフラインになりにくい仕事の構造、非常に遅れてやってくる満足感と長いフィードバックループである
- 挑戦と責任を楽しめて機会があるなら、試してみる価値はある
- 管理職は誰にでも合うわけではないが、技術の幅を広げ、エンジニアリング業務を新しい角度から見る経験になりうる
- 完全に合わないとしても、コーディングに戻る時間は十分にある
1件のコメント
Hacker News の意見
FAANG での2回を含めてマネージャーを4回やったことがあるが、原文には同意できない点が多い
マネージャーのラダーが実際に上位というわけでもなく、ほとんどのエンジニアリングマネージャーは L6／スタッフエンジニア相当に集中している。シニアマネージャー以上への昇進は状況に大きく左右され、まれである一方、エンジニアトラックの同僚たちは準備ができれば、星回りが合うまで待たずに昇進する
純粋なエンジニアリングマネージャーとして働いていて解雇された人たちは、まだ仕事を探していて、諦める寸前のケースが多いが、IC に戻っても構わない人たちは就職に大きな問題はない。会社ごとの管理文化は非常に異なり、そのまま移転しにくい。この業界で最も移転性の高い技術は Linux の内部構造だと思う
5年の経験があれば大半の問題を解けるという考えもおかしい。18年働いていても、いまだに知らないことやもっと良くなるべき点は多く、40年の経験を持つ優れたエンジニアたちも学び続けている
マネージャーの一番良い点は、未来について考える時間を多く使い、C レベルと話す「その部屋」に入れる可能性が高まることだ。同時に、意思決定がどのように作られるのかをあまりにもよく見てしまうので、最悪でもある
原文が嫌っていた点には同意するが、時間が経てば良くなる。ただし新任マネージャーなら、まだ最も嫌になる点、つまり多くの会社の上級管理層が高校の派閥のように振る舞い、VP、C レベル、ときにはディレクターの問題行動が、一般社員なら解雇されるレベルでも容認される環境を経験していないかもしれない
ほとんどのソフトウェアエンジニアはシニアで頭打ちになり、特に Google ではなおさらなので、L6 に集まること自体が相対的に特権的だ。L6 昇進は極めて珍しいわけではないが、過半数が得るものでもなく、L7 以上は難しい。同僚の大半が自然にそこまで行くと感じるなら、昇進できずに去った人たちを除外しているか、自分より低いレベルの人たちと親しくなる機会が少なかったのかもしれない
エンジニアリングマネージャーの道が、かつて人々が考えていたほど多くの扉を開くわけではないことには同意するが、昇進機会が IC より狭いようには見えない
0から1を作る仕事は、エンジニアリング管理とはほとんど関係がない。素早くコードを書き、潜在顧客と気軽に話せる能力が最も重要で、どちらもエンジニアリングマネージャーの役割と直接は関係しない。管理する人を採用することになる保証もない
管理職は構造的にエンジニアリング職よりはるかに少なく、リードエンジニアと一次マネージャーの境界は双方向にかなり曖昧なので、実際の競争プールがそれほど小さくなるわけでもない
移転可能というのは、大手テックのバブルの外でも役に立つ技術という意味だ。待遇が良くて外に出たくないかもしれないが、コンピューターをピコピコさせる仕事以外にもできることがあると知っておくのは良いことだ
たとえば「もっとテストすべきだ」という話を、IC よりエンジニアリングマネージャーが言ったときのほうが真剣に受け止められる、という考えがそうだった
実際、私もスタッフ級に昇進したばかりの IC だったころ、信頼度が足りないと感じ、肩書きの後ろに隠れれば助けになると思って管理職へ移ろうとした面がある。実際にはその必要はなく、今は別の会社の IC として、自分の考えやフィードバックが組織レベルでも同僚にも真剣に受け止められている
半期ごとに強制的に順位付けして低パフォーマーを選ばなければならない制度は壊れたやり方だ。多くの場所のパフォーマンス管理にはそうした悲しい現実があるが、マネージャーなら必ずそうしなければならないという普遍的な真実ではない。実際のパフォーマンス問題についての難しい会話は統計的に避けられないが、「今期はチームメンバー全員があなたより良かった」とか「誰かを選ばなければならないので今回はあなたになった」といった会話をしなくて済む会社もある
私は問題解決と全体像を見ることが好きで、解決策を見つけて障害を取り除くのが好きです。いちばん合っていた役割は「アーキテクト」でしたが、肩書きとしては消えつつあるようです。それでも、その仕事が必要だという事実は変わりません。
チームリード/マネージャー、Scrum Master、プロダクトマネージャーの役割も経験しましたが、良いマネージャーに必要なスキルはエンジニアとは大きく異なります。核心は神経症傾向が極めて低いこと、つまり長期間のストレス下でも良い判断を下し、落ち着いた合理的な外見を保てる能力です。
下位の管理職の90%にはこうした特性がなく、ストレスを受けるとチームと会社を壊してしまいます。マネージャーになりたいなら、長く続くストレスに自分がどう反応するのかを率直に評価すべきです。周囲の人に怒りをぶつけるのか、隠れたり固まったりして意思決定できなくなるのか、他人のせいにして自分の評判を守ろうとするのか。こうした一見退屈に見える要素こそが、有能なマネージャーとそれ以外を分ける本当の違いです。
たいていは、誰もが避ける問題を持ち出し、人々が自分の判断について集団で不満を吐き出すのを受け止め、相手が disengage して突き放してきても関わり続ける、といった楽しくない仕事を含みます。
私にとってマネジメントは、持っているスプーンをすべて要求したうえで、さらに要求してくる仕事のように感じました。ただしこれはマネジメントの本質というより、私との適性の問題に近いと思います。インターネットの診断基準では私は神経症傾向が中程度ですが、「十分に良い」で止めるのが苦手で、マネジメントによって広がった責任範囲が感情面でスケーラビリティの問題を生むと感じます。
クランチやバーンアウトを解決する鍵は、労働者の生活全体、つまり健康、家賃、公立大学の学資ローン返済などが、ひとつの仕事を維持できるかどうかだけに左右されないような規制環境を作ることなのかもしれません。
ICなら新しい技術やドメインを学びながらキャリアを伸ばせますが、マネージャーは次第に、成熟度、視点、感情的な回復力といった個人的成長にキャリア開発がかかってくるようになります。シニアリティとマインドフルネス瞑想のようなものへの関心が一緒に高まる理由も、これなのかもしれません。
HNは嫌がるでしょうが、独身の私でも、親のほうがより良いマネージャーになるのではないかと気になります。大局的には重要でないことに視点を失ってストレスを感じる可能性が低いからかもしれません。不思議なことに、感情的に一歩引いたときにマネジメントをいちばんうまくできるようです。
分かってみると、私は気質的にかなり敏感で、管理職に根本的に向いていないのではないかと個人的に心配しています。「操縦するのではなく動機づけるのだ」といった、ときに偽善的な性格もつらいです。ただ組織の中を渡り歩き、問題を直し、プロセスを単純化し、業務システムを組み直す仕事をしたいだけです。
ソフトウェアエンジニアになって12年目ですが、マネージャーになりたい気持ちはまったくありません。ただ何かを作りたいのであって、管理したいわけではありません。
マネージャーたちと近い距離で働き、どんな仕事なのかは見ていますが、まったく魅力的には感じません。シニアエンジニアとして私の発言にも影響力があることは多いですが、マネージャーに伴う莫大な責任はないので、それで満足しています。人生でストレスをこれ以上増やしたくありません。
おそらく今後30年のキャリアも、今と同じ立場のままだと思います。
数年前の私も似たような状況でした。上司は私を気に入っており、人脈も多かったので、すべての情報を共有し、意思決定の場に座らせ、方向性について意見を求め、必要なら自分や他のマネージャーの代わりに発言しても、裏で支えると言ってくれていました。
今はまったく新しい管理構造が入り、非常にトップダウンで、プライドが高く、フィードバックを受け入れようとしません。声を上げる下位マネージャーやエンジニアは次々に押しのけられ、私が持っていた自律性と発言権はほとんど消えました。
エンジニアリング上の判断だと思っていたものまで、多くを奪われました。私が作るサービスに X が必要だったので自動化された解決策を作り、うまく動いていたのですが、数カ月後に X には別の計画があると言われ、私が間違っていたことにされ、完全に自動化された解決策を削除して別チームの手動の企業プロセスに置き換えるよう指示されました。その作業は頻繁に抜け落ち、私のサービスの安定性を下げています。
こういう人たちと戦わなければならないマネージャーでなくてよかったです。もしそうだったら、今ごろ職を失い、彼らの友人に置き換えられていた可能性が高いでしょう。ただし、シニアエンジニアの影響力は、同じ会社・同じチームの中でも長期的には大きく変わり得ます。
管理責任がない、またはごく少ない、より上位の技術職もあります。シニアプリンシパルエンジニア、アーキテクトなどがあり、会社があなたをどれだけ価値ある存在と見るかに左右されます。
私が見た最も良い例は、博士号と数十年の経験を持つエンジニアが研究/アーキテクチャのグルとして働き、チームや直属の部下を持たず、Matlabを多用し、数百人規模の会社で「VP of technology」だったケースです。
難しいのは学習そのものや人だけでなく、その周辺状況です。マネジメントの視点を持つと、何をなぜ作っているのか、なぜ仕事が非効率で壊れて見えるのかを理解するのに非常に役立ちます。解決策や、きちんと伝わっていない文脈についての洞察も得られます。
私は現在シニア開発者で、スタートアップのチームリードポジションの面接を受けている。自分では技術力は高いと思っているが、日々いちばんもどかしいのはチームワークに関する問題だ。
信頼の不足、互いに話したがらないチームメンバー、低水準の仕事をしても見過ごされる他のシニア、明確なチームの目的とプロダクトビジョンの欠如、共通のエンジニアリングプラクティスへの合意不足などだ。ピープルマネージャーになれば、良くも悪くもこうした問題が自分の影響を及ぼし、責任を負うべき範囲に入ってくる。
ただ、実際にチームリードになってみると、思ったより影響力を行使できる範囲はずっと小さかった。自分の上司も含め、何でも自分で直接回したがる人が多く、私には判子を押すことだけを期待している。
むしろ、チームの人たちが口にするのを恐れていることを代わりに持ち出さなければならず、さらに厄介になった。たとえば「ストーリーを準備完了にするにはAPIが定義されていなければならない」という話だ。何をテストすべきかも分からないのに、QAが自動化テストをどうやって並行して作れるのか。
Scrum Master、プロダクトオーナー、マネージャー、アーキテクトたちは、その日その日に自分に都合のいいことを自明の真実のように言い、翌日にはなぜテストが遅れたのかと不満を言う。
結局、今の状態の責任が誰にあるのかという政治の話になり、そういう方針や戦略を選んだ人たちは人脈があり、責任転嫁もうまい。
以前、当時の上司が別部署の人に仕事を頼む電話をうまく終えたあと、そのオフィスに立っていたことがある。
上司は机から私を見上げ、少し笑って戸惑ったような調子で「肩書きが『Specialist』から『Manager』に変わったからといって、私がより美人になったわけじゃないけど、物事を進めるうえでは確かに役に立つね」と言った。肩書きの力が実際に機能する瞬間だった。
マネージャーは実際の不利益をちらつかせない限り、ただ無視されがちで、そういうカードは温存すべきものだ。
数年前、小さなスタートアップのCTOとしてエンジニアリングマネージャーを始め、生活は大きく変わった。原文で好きだ、嫌いだと言われているすべての面に同じ感情を覚える。
追加の助言は、本当に瞑想をすることだ。人に害を及ぼしうる重要で影響力のある決定を下す前に、脳が停止するくらい十分に静かに座っている必要がある。
最初はある種の親子の天才関係になる。人々を受け入れ、その人たちのやり方を理解しなければならない。統制を多く置けば置くほど、実際の統制力は減っていく。不要な官僚主義を迂回し、反発しようとするだろうし、正直、自分でもそうする。
2つ目の助言は、常に明日去る人のように振る舞うことだ。そうすればチームと同僚が準備でき、自分のライフスタイルも良くなる。
本当に速く成長するし、自分がいなくても組織が回ると確認できるのは妙に安心する。同時に、自分がいないときのほうがより速く成長しているようにも見えて、自分が何か間違っているサインなのかと思うこともある。
ある日は、職場で学んだスキルで家族をマネジメントしているように感じる。
私のバックグラウンドは逆だ。私は平凡なソフトウェアエンジニアだが、人を扱う能力はかなり高いほうだ。
何に時間がかかるのか、システムのどの部分がより重要なのかが分かる程度の経験はある。本当に耳を傾け、多くの信頼と権限を与えているシニアエンジニアが何人かいる。
設計判断は私ではなく彼らが行い、私は意見を添える。失敗すれば責任を負って学び、成功すればチームに功績を帰す。控えめに言っても、マネージャーの役割は何より人に関する仕事だと思う。
コーダー/ICの役割からマネジメントトラックへ移りたい理由は1つだけだ。転職するたびに毎回必要になるホワイトボード面接のせいだ。
ほとんど苦痛なほど一から準備し直さなければならず、そういうプロセスのない役割もあるにはあるが、非常にまれだ。その準備を考えると、「ああ、頼むからまたか？」と思って、そのまま同じ職場にとどまることが多い。
悪いエンジニアリングマネージャーは、悪いICよりもはるかに大きな被害を与えうる。この話は十分頻繁には取り上げられていないと思う。
長いキャリアの中で、素晴らしいマネージャーは1人、まともなマネージャーは数人、ひどいマネージャーは大勢見てきた。ひどいマネージャーは仕事をはるかに難しくし、ときには完全に悲惨なものにする。
悪いエンジニアリングマネージャーとジュニアICの組み合わせは、特に良くないことがある。年齢を重ねるにつれて、悪いマネージャーとも働きながら状況をより良い方向に動かせること、あるいは望みがないと感じたら去れることが分かってきた。
最近マネジメント責任が増えているので知りたい。
かつて博士号持ちのICたちで構成されたチームを率いたことがある。彼らに仕事を見つけてやり、夢想家たちを食い止め、幸せな状態に保たなければならなかった。
冗談ではなく、一度に6時間ずつ個別に話し、キャリアカウンセラー兼慰め役を務めることもあった。そんなことが自分の仕事になるとは思っていなかった。
チームメンバーの1人が、別々の10億ドル規模の契約2件を獲得するのに貢献したので、私の時間は報われたことになる。