雑記帳

情報を自分の言葉で蓄積しておく場所

マネージャの継承をするときに考えること

EM Engineering Manager Advent Calendar Engineering Manager

これはEngineering Manager Advent Calendar 2023 13日目の記事です。

エンジニアリングを軸としながら、現職で所謂マネージャという役割を正式に担い始めてから約2年、自分が持っていた職責を他のメンバーに渡して次のステップに挑戦したり、他のマネージャが職責を継承していくサポートをしてきました。

その中で心がけたこと、今振り返ってこうすればよかったなと思うことがいくつかあるので、この期に棚卸ししようと思いました。

マネージャの継承についての文章って意外と少ないと思うので、誰かの役に少しでも立てば嬉しいです。

"成果"に対する向き合い方が変わることを伝える。客観的に見た成果をより細かくフィードバックし続ける

個人的にマネージャという職責を担って大きく変わる(変えざるを得ない)のは成果に対する向き合い方だと考えています。
これまでマネージャを経験したことのある方であれば、これまで以上にアピールできる成果が減ったなあ・・・とか、成果が出るまでかなり時間がかかるのでしんどいなあ・・・という気持ちの壁に何度もぶつかったことでしょう。

脅すわけではないのですが、事前にこの事実を知っておいてもらうことでマネージャという仕事と向き合う覚悟を持ってもらい、いざその事実に直面したときに周りを頼り、長期的な時間軸の視座を持ってチームで成果を挙げられるよう準備を一緒に整えます。

とはいえ、「成果がでるまで時間がかかるから頑張れ!」だけだと誰でもしんどいので、北極星に向かって着実に歩みを進められている実感を持てるようにする必要があります。
職責を新たに継承したマネージャが主導する様々な取り組みが、目指す北極星に対してどの程度妥当であるか、課題がある場合どのように軌道修正すべきかを、役割を継承した初期は特に気を配ってコミュニケーションを取ります。

マネージャとしてやってきたこと、その背景、見えていた課題を伝える。

継承をする上では未来の話だけでなく足元の"今"の話もとても重要です。

ジョインして日の浅いメンバーだったり、それなりに歴があるメンバーだったとしても昔のことは意外と覚えてなかったりするでしょう。 (自分もよく忘れる)

任せるチームがそのタイミングでどういった状況か(プロジェクト、メンバーの状況、チーム外との関係値 etc...)や、それまでの取り組み(メンバーとのコミュニケーション、スクラムイベント、職能やチーム間の関係値づくり etc...)がどのようなきっかけで何を考えてやり始めたのかという経緯、各取り組みなどが抱える課題を伝えて、新任のマネージャが現状と理想をつなぐための目標や取り組みを考えられるようにサポートをします。

組織として何を目指し、何をマネジメントしてほしいか伝える

新たな役割にチャレンジし、さらに大きな事業成果を挙げ続けてもらうためには、いかに全社の目標やスタンスと地続きに本人が目標を立て実現していってもらうかがとても重要です。
新任のマネージャが自ら自チームの北極星を打ち立てメンバーと一緒に推進できるようにするために、継承元のマネージャはより視座を上げて北極星を打ち立てる必要があります。

ただ目標を立てそれに従ってもらうのではなく、目標を自分で立てメンバーを巻き込みながら推進できるようになってもらうことで、組織をよりスケールしやすくすることが出来ます。

また、EMといってもその範囲は非常に広く、マネジメントの領域によってはコンテキストスイッチが発生したり、得意不得意によるパフォーマンスのばらつきがうまれ、かなり苦戦することでしょう。

課題解決のスコープをうまく絞り、切り替えながらマネージャとして仕事をしていくには、それなりの経験とスキルが必要です。
組織状況によって特に注力すべきマネジメント領域も異なるため、最初から全領域を任せるのではなく、最初は2人3脚でマネジメントのカバー範囲を調整し、着実に成果を挙げてもらいながら見る領域も増やしてもらうことで、継承する/される側のリスクを減らしながらパニックゾーンに入ってしまうことなく新たなチャレンジを後押しすることが出来ます。

マネージャはうまく行ったときも行かないときも、チームや組織などに与える影響が大きいため、任せる側としてもどうしても慎重になってしまうと思います。
組織のスケールのためにメンバーにチャレンジのきっかけをたくさん作っていくためには、当たり前ですがこういった丁寧なサポートが必要だなあとこれまでの経験を踏まえて痛感しています。

同じことはしなくてよい、ということを伝える

役割を継承するということは、なんらかの形でチームや組織の状況が変わったということだと思います。
状況が変わったということはこれまでやっていたことや職能の定義、メンバーの期待値なども改めて見直す必要があるかもしれません。

しかし、新たな役割を担うということはとても大きなプレッシャーとなるため、コンフォートゾーンを抜け出せず表面的にこれまで通りの取り組みを行ってしまい、役割を継承したにも関わらず改善が促進されない、組織がスケールしない、といった状況に陥る可能性があります。
役割の継承は、それまでの様々な取り組み、定義を棚卸しして仕切り直すよい機会なので、上で書いたような現状の共有を通じて課題の共通認識を育み、場合によっては今ある仕組みや定義、期待を"一緒に"ドラスティックに変えてしまうのも手です。

いまでこそ色々な事例が世に出るようになってきましたが、自分が所属する組織においてマネージャという職責をどう定義するかは最後は自分たちで考え定義し、状況に応じてアップデートしていかなくてはなりません。
ここで書いたようなサポートを通じて、自らを取り巻く仕組みや期待だけでなく、自らの職責自体も一緒に定義し直していこう!というメッセージングをしていきたいという想いもあります。

同じチャレンジをする仲間を作る

少し自分の話をすると、2年ほど前にEngineering Program Managerという役割を任され、そのタイミングで本格的にマネージャの門をたたきました。 EPM(Technical Program Managerと呼ぶ会社もある)という職責はそもそも世の中にケースが少なく自ら役割を定義していく必要があり、更には同タイミングで採用も担いはじめました。

新たなチャレンジをするのはとても勇気がいることです。マネージャともなるとメンバーのパフォーマンスに影響を与えたり、採用においてはお給料などにも影響を与えうる役割となります。
しかし、自分の場合はありがたいことに同タイミングで他に2人がEPMの役割を担い、計3人で日々の開発をリードしつつ自身の役割の定義や採用の試行錯誤をするようになりました。

正直同じタイミングでチャレンジする仲間がいなかったら、ここまで色々な言語化やそももそもマネージャとしてのチャレンジは心が折れていたと思います。一緒にEPMをやってくれた仲間には本当に感謝しています。

そういった経験も踏まえ、大きなチャレンジをしてもらうときに同じレイヤーで一緒に試行錯誤できる仲間もできるだけ作れるようにし、コンフォートゾーンから抜け出しやすくすることを心がけています。

最後に

EMは定義が広いです。広いということはそれだけ課題解決の選択肢が与えられているとも言えると思います。
役割を任せる際には自ら羅針盤を作り、オーナーシップを持ち自らの役割を自分で定義し続け、自分が率いるチームがどの島に向かうべきかを選べるようになって行ってもらいたいと思っています。

そのために、役割を任せる側の人間としてはこれまで自分自身がどういう海路や島々を辿ってきたか伝えて歴史から学んでもらい、はじめは一緒に舵を取っていく必要があると思います。

自分がそうしてもらったように、他のメンバーに対しても同じように、それ以上にサポートをしていろんなチャレンジをしてもらえるようになり、それがもっと広がってより多くのメンバーが自分で自分の仕事を作っていろんなチャレンジができるようになっていってもらいたいなと思っています。