(翻訳) エンジニアとマネージャの振り子

"The Engineer/Manager Pendulum" というブログ記事を筆者の許可を得て翻訳してみました。

---

最近、Twitter上で何人かのキャリア相談に乗ることがあった。多くの相談はこんな調子だった。

わたしは現在シニアエンジニアで、マネージャになろうと思っている。自分は技術が大好きなのだ。でも、ときどき自分は同じ問題を繰り返し繰り返し解決しているような気がしてしまう。ほんとうに解決すべきなのはヒトの問題 (people problems) なんじゃないか? 昇進するためにはマネージャになる必要があることは知ってる。マネージャになるのは最悪じゃなきゃいいなと思っている。悪い噂ばかり聞くから。

キャリア相談に乗りながら、この記事を書きたいとずっと思うようになった。言いたいことはたくさんあるが、最初に言いたいのは 「マネージャだけがキャリアパスを前に進むことができる」という考えはクソ喰らえ ということだ。そして 「マネージャかエンジニア、どちらかの"レーン"を選び、選んだ道で成長する必要がある」という考えは捨てるべき だということだ。私はこういう「割り当て」のような考え方には全く賛同しない。

エンジニアマネージャとして最前線で活躍できるのは、実際のプロジェクトにハンズオンで注力する仕事から外れてすぐのマネージャだ(長くても2, 3年)。そして最強のICはマネージャ経験のあるIC (IC: Individual Contributor, 部下を持たないエンジニア) である。そしてテック業界の優れたリーダーは両方やる。エンジニアとマネージャー、振り子のように。

私はこのキャリアの振り子運動をすでに数回やってきた。会社で最初のインフラエンジニアとして仕事を始め、技術スタックを構築し、エンジニアチームを構築し、そのチームをマネージし、そして会社をやめて最初からはじめる。そわそわし、落ち着かない感覚になることもあったが、だんだんと自分が何をやっているかわかるような感覚を得ることがあった (それは悪いサインかもしれないけどね...)。

あなたがスタートアップやアーリーステージの会社が好きだったら、もしくはADD (注意欠陥障害) のような性質を持つ人にはこれは良いサイクルだと思う。しかし、キャリアパスとしてこのサイクルについて話す人はあまり見ない。そこで私は、素晴らしく"計画的な"人生のあり方として、この振り子のキャリアサイクルを推奨するためにこの記事を書いている。

(テック領域における) マネージャであること

マネージャに内部昇進することは、カミソリのように鋭いものづくりのスキルをすでに持っているということだ。最初は異なる職務への適応に苦しむかもしれないが、そのスキルは(マネージャとしての)信頼を与える。しかし、これは「テックリード兼マネージャ」としての一時的な栄光を得る方法に過ぎない。本質的に、これは不安定な役職の組み合わせであり、エンジニアリングスキルとある領域に特化したシャープネスは、その職を長く続けるごとに失われていく。

人はいちどに一つのスキルしか成長させることしかできない。エンジニアリングか、マネジメントか。過去の栄光にしがみつくべきではないのだ。

マネジメントはとてもタスク割り込みの多い仕事だ。そして、素晴らしいエンジニアリング (あなたがかつて学んだこと) には、そうしたタスク割り込みをブロックすることが重要になる。それらの正反対の性質を持つ仕事を同時にこなすことは難しい。いつでもタスク割り込みを受け入れ部下に対応できる状態を保つことがあなたのマネージャとしての仕事である。部下たちがエンジニアとして成長できるように、挑戦しがいのある課題から手を離すことを「選ぶ」のがあなたの仕事なのである。

(人々のための) テックリードであること

逆に、世界最強のテックリードはマネジメント経験のあるテックリードである。それは彼らが最強のプログラマであったり、問題解決に優れているからではない。「やっていく」方法を、つまり人とコミュニケーションし、マネージする方法を知っているからだ。テックリードはマネージャでもある。ただ、彼らの最優先事項は手元の課題を解決することであり、そこに働く人を気遣うことではないだけだ。

それでも、テックリードにはマネージャーとしてのスキルセットは必要である。どうやってチームを作り士気を高めていくか、どうやって物事の優先順位をつけ、デスマーチ化したプロジェクトを再始動していくか。テックリードはビジネス的な目標と技術的な奥表を結びつけ、大きな目標を分解する必要もある。テックリードは他のエンジニアの能力を最大限に伸ばし、意義のある課題を繰り出すこと、彼らを潰してしまうことなく、彼らの守備範囲を徐々に広げていくこともできる。それを20人の他のエンジニアにやってみよう。それは立派なマネジメントの仕事になる - ただ、「Xを達成する」という視点を「Xをする人々のケアをする」の代わりに持っているだけだ。

そのようなテックリードは、ふつう何かを作るよりも長い時間ミーティングに出席している。そのことに文句を言っているかもしれないが、実際にそうしている。なぜならコードを書くことは最も良い時間の使い方ではないからだ。技術的なことは彼らの仕事の簡単な部分で、エンジニアの群れを先導することのほうが難しいパートなのだ (Tech is the easy part, herding humans is the harder part)。

この両方のスキルセットを持ったシニアエンジニアは、組織をイチから作ることができる。もしくは会社をイチから作ることすらできる。彼らは何でもできる。そして彼らは希少である。そして彼らのほとんどは、少なくない時間をマネジメントに費やしているのだ。

エンジニアとマネージャの振り子

マネージャとICの間を行ったり来たりすることで身につく幅広さと深さについては、いくら書いても足りない。ICであることは、会社の仕組み (how a company works) について少ない情報からリバースエンジニアするようなものだ。ひとつのリーフノード (leaf node) の視点からだと、たくさんのことがバカバカしく、要領を得ず、非効率に感じる。

マネージャになると、どう会社が回っているのかを理解できる。他の人がどう仕事しているのかを理解できる。居心地の悪い面談のやり方を学ぶ。苛立った、あなたのことが嫌いなエンジニアたちに、必要な仕事をこなしてもらうやりかたを覚える。コンフリクト (利害の対立や衝突) を解決する方法を学ぶ - そう、コンフリクトを解消する方法を学ぶのだ! (正確には、あなたはコンフリクトを切望するようになる - 単純なコンフリクトが解消できるならば、それはたいてい最善の選択肢であるからだ)。疲れ切って家に帰っても、あなたは「自分が自分自身でやり遂げたこと」をひとつも挙げることができないかもしれない。それでもあなたは仕事をしているのだ。

あなたはバグを直したり課題を解決したときに出るドーパミンを恋しく感じる。切実にそれを感じるだろう。

マネジメントについてもう一つ。マネージャ自身やその周りの人がいかに悲惨な状況であったとしても、マネージャを辞めてICに戻ることを非常に難しくしているひとつの「神話」がある。それは「マネージャになることは昇進であること」だ。

マネジメントは昇進ではない

真剣に、この神話にはクソを食らわせたい。この神話はじわじわと感染症のように広がり、たくさんの人をマネージャにしてしまった。いかに彼らがマネジメントを嫌っていて、さらに彼らの会社にメンタリングのできるシニアエンジニアが欠乏していてもだ。

マネジメントは昇進ではない。マネジメントは職業の変更 (a change of profession = 社内転職) だ。マネジメントを始めてしばらくは、自分のマネジメントは下手くそだと感じるだろう。もし下手くそだと感じていなければ、あなたは自分の仕事をしていない。

あなたのエゴイズムのためにマネジメントをすることは、本当はコードを書いているか他に楽しいことを探すべき哀れな人に他のエンジニアを管理させる、最悪のやり方だ。世の中に、いやいやマネージャをやっている人にマネージされるほど最低のことはない。頼むから、IT業界の人々が燃え尽き症候群に至ってしまう理由の一つにならないでほしい。

マネジメントは昇進ではない。マネージャをやめてもなにかの権威や地位を失うことはない。マネージャになるのが幸せであり、周りの人もそれで幸せである限りにおいて、マネジメントを続けてほしい。そうでなくなったらマネージャを辞めて、また何かを作る仕事に戻ればいい。またマネジメントがしたくてうずうずするの待とう。

そしてまた、同じことを繰り返していこう!

charity.wtf

twitter.com