エグゼクティブとちゃんと話そう
以前から、自分の同僚やチームメンバー、上司と話すのと、会社のエグゼクティブ（役員）と話すのは違うな、と感じています。チームメンバーとかと話したり議論したりするのは普通に行えるのですが、エグゼクティブと話すときには少し勝手が違い、それを意識しないといけないように思います。
今回は、自分の過去のミスを元に抑えたいポイントを書きたい思います。
計画なし、自信なし
エグゼクティブと会話する中で、スケジュールの遅れ、障害、バグ等の悪いニュースを伝えないといけないことも当然あります。
自分も以前、プロジェクトの遅れていることについて伝えた際に、当然CEOから「で、どうするの？」と聞かれました。自分が答えたのは…
正直分かりませんが、とりあえず頑張ります。
というものでした。まあ、ダメな答えですね😅
どんな事業でもそうですが、何が起こるかわからないものですし、エグゼグティブもそんなことは理解しています（自分たちも、それに対応できていない時があるのも理解してますし）。そのため、彼らとしては「ちゃんと対応できているか、してくれるか？」ということです。もし、自分が答えを持っていなくても、自信を持って「対応します」と答えてほしいと思っています。反対に、それができない状況で助けが必要な場合もそれを伝えてほしいと思っています。
いつも聞いている Developing Leadershipポッドキャスト第10話 の
Engineering Leaders are always in "de-risking" mode, so they will often present complex plans with many variables and outcomes to the exec room - this usually doesn't transmit a lot of confidence to the CEO. Ideally, one should figure out a way to communicate an "I've got this!" message while showcasing competence in doing so.エンジニアリーダーは常に「リスクを減らす」モードにあり、そのため、経営層に対して変数が多く、結果のパターンも多いような複雑な計画をを提示することが多いです。これではCEOは安心できません。理想的には、「大丈夫です」という言葉を伝えつつ、それを実現するコンピテンシーを見せられなければいけません。（著者の意訳です）
是非ポッドキャストのエピソードも聞いてみてください。
表面上の争いをしてしまう
エグゼグティブが放つ言葉を字面通り取ってしまって、本質（エグゼグティブが本当は言いたかったこと）を見ずに表面的な議論になってしまうことがあります。エンジニアマネジメントに関するブログが有名なWill Larsonさんのブログの内容がまさにこういう話をしていました。
The most frequent issue I see is when a literal communicator insists on engaging in the details with a less literal executive. I call the remedy, “extracting the kernel.”...I recommend that teams receiving executive feedback try to “extract the kernel.” When you get a question from an executive, focus on understanding the insight or perspective within the question.
よく見られるのは、詳細を把握している人（エグゼグティブでない人）が、そこまで詳細を把握していないエグゼグティブと細かい議論をしてしまうことです。解決方法としては「核を抽出する」ことです。（中略）エグゼグティブから何かフィードバックがあったチームは、「核を抽出」してみてください。エグゼグティブからの質問があったら、その質問に込められたり隠れている本質に注目してください。（著者の意訳です）
上記のブログの中で「ChatGPTを使ってみたら？」みたいな話が出てくるのですが、自分のときもほとんど同じことが起きていました（もちろんChatGPTでない技術の話ですが）。エグゼグティブがはなった技術がいかに自分たちが利用しているものより劣るかなどを細かく説明してしまい、エグゼグティブの方も混乱していたと思います。今思うと、その方は別の技術を推したかったのではなく、今のシステムの安定性は大丈夫なのか、という問いを投げかけていたのだと思います。自分も、その点（まさに「核」の部分）に注目して、今のシステムの安定性が問題ないことや、もし高める場合にはどういう手段があるのか、その費用対効果などを説明するべきだったと思います。
実際に日々の作業を行っていると、細かい部分や表面的な部分で議論をしてしまいがちな点に気をつける必要があります。
ただエンジニアのタスクをスライドに載せるだけ
自分が経営会議などにも参加していた頃の話ですが、毎週エンジニアのタスクについて進捗のスライドを用意していました。同じ会議にプロダクトやデザインのマネジメントをしているメンバーも出席していたので、戦略的な内容や機能の見た目や説明などはそのお二人に任せていました。当然ながら、自分のスライドは、残ったサーバなどのインフラの話や、ライブラリやフレームワークのアップグレードの話など、かなり技術的なものの話が多かったと思います。当然ながら、エグゼグティブの方々にはあまり内容が伝わっていませんでした。伝わっていないだけなら良いのですが、もし、その中で少しでも「懸念」や「心配」な要素が出てくると、先程の話にあるような「表面的」で「重要性の低い」議論に陥ってしまったりしていました。
自分が説明するべきは、エンジニアのタスクであっても、その背景・理由、そして、それがどうビジネスに貢献するのか、影響するのかを説明するべきだったと思います。
Miri Curiel さんによるこちらのエントリー がとても参考になります。
As the VP of Engineering, you share the responsibility of creating real value for customers. Make sure the tasks align with the overall business goals and actually deliver value.お客様のために価値を生むことはVPoEの責任です。タスクがビジネスの目標と一致していること、そして、実際に価値を生む必要があります。（著者の意訳です）
真っ当なエンジニアであれば、自分がやっていることはすべてビジネスへの貢献があるはずですし、もし、エグゼグティブと意見が食い違うことがあれば、それは優先順位や時間軸の違いの可能性が高く、そのすり合わせをするために議論することは、とても大切なことだと思います。
ビジョンがない
自分は正直昔からちゃんと「計画」とか「ビジョン」を持つのをやってきていませんでした。
理由は、周りにそういうのを得意としているメンバーがいたのもあるのですが、状況が刻一刻と変わるようなスタートアップでは計画を立てても、あまり意味がないと考えていたためです。そのため、経営会議のような場では、せいぜい3ヶ月ぐらい先のプロジェクトの進捗程度しか話していませんでした。そのため、エグゼグティブの方からすれば、先が見えない不安が大きかったと思います。
エンジニアは仕事柄、普段から細かい部分に目を向けているおり、必然的に「現実主義」なところがあると思っています。そのため、時間軸の長い計画やビジョンという「不確定要素」の大きいものに対しては保守的になりがちだと感じており、自分も類に違わずという感じでした。
今思うと、自分は、なるべく考え抜いて現実味があるような「ビジョン」や「計画」を立てて、示すべきだったのだろうと思います。少し上の方で書いたようにエグゼグティブも計画は状況によって変わる可能性があるので、完璧にうまくいくとは限らないことも理解しています。それよりも、エンジニア組織が行っていること、行うことが事業の目指すところと一致していることや、その状況を知りたく、うまく行っていない場合はいち早く聞いて、サポートしたいと思っています。
とりあえず話してみよう
長々と書いてしまいましたが、エグゼグティブとのコミュニケーションで悩んだ場合は話見るのが良いと思います。何を聞きたいのか直接聞くのもありだと思いますし、僕がこのブログで書いたものを試して見るのでも良いと思います。
とりあえず、話してみましょう。
この記事が気に入ったらサポートをしてみませんか？