本記事は Engineering Manager vol.2 Advent Calendar 2018 の1日目の記事になります(何故か空いていたので後追いで投稿しています)

自己紹介

@takochuu といいます。
エンジニアリングマネージャー歴は、前職を含めて約3-4年と言ったところです。
主にマネジメントしているメンバーの数は ~ 10人。評価・育成・チーム運営がお仕事です。(実装も3-4割ぐらいやっています)
主にプロジェクトマネジメントが得意ワザだと認識しています。

本記事の対象読者はエンジニアリングマネージャーになって1年ぐらいの新人マネージャーのみなさまへ僕がハマった事についてお伝えします。

TL;DR

正しいロジックで伝える事よりもコミュニケーション頻度を意識して振る舞うことで納得してもらえるようにする
組織(チーム)マネジメントの目的は事業の成長・達成に紐づけて考える

正しい結果を言おうとしてしまう罠

例えば一介のエンジニアからエンジニアリングマネージャーへ役割の変更がなされた際、多くの人たちは以下のような新しい仕事を受け取る事になります。

評価
1on1など、「話す側」から「聞く側」への変化

このようなケースにおいて、ハマっていた罠が「正しいことを話す」ということを目的にしてしまうことです。
例えばメンバーが何かに悩んでいた時に、話せる関係性であれば、悩みや問題を話してもらえます。以前の僕は、ここで正しい答えを出してあげてしまっていました。

これは良く言われる話ですが、「気付きを与える」事で納得してやってもらうのが目的であるとするとあまり相応しい行動ではありません。
頭ではわかっているがどうもモヤモヤする、というのはみなさんも経験がある話だと思います。例えば自分が1on1で話をする側だった時を思い浮かべると理解できるかと思います。

そこからの学びとして、1on1や普段のコミュニケーションでは「正しい結論」を伝えるのではなく「正しい問い」を立てる事によって、気付きを与えて成長してもらうのが今の自分なりの考え方になりました。

チーム運営・組織運営と事業運営は両輪というおはなし

僕の場合はですが、あまり経験がないEMだった時は「チームを上手くいかせる」ことに必死だったなと思い出しました。
具体的には以下のようなことです。

チームのキャパシティプランニング
心理的安全性の担保
仲の良さ、風通しの良さの担保
個人の成長の担保

確かにこれは大事なのですが、1つ重要な観点として「何のために」やっているのかということです。
ブチャラティも「任務は遂行する、部下も守る。両方やらなくっちゃあならないってのが幹部のつらいところだな」と言っていますが、当時の僕にはチームを守って、任務を遂行するという観点が抜けていました。

そうすると一見チームは仲がよいように見えますが、サイロ化ではないですが何のためにやるのかという要素が抜けてきます。抜けてくると大きな課題発見や技術的チャレンジに目を向けられないチームになってしまいます。

今のマネジメントスタイルとしては「EMとして大きな課題発見に取り組む、その課題の解決によって、チームの成長を実現する」という考え方に変わってきています。
あくまでエンジニアのマネージャーだということを考えると、課題発見とその解決アプローチに足る技術力を持っていなければいけない、というのも重要な観点です。

チームと事業、どちらかではなくどちらもやる。これがEMのつらいところだな。

おわりに

ちょっと雑になってしまいましたが、これが最近得た学びとしてあります。
ぜひEMのみなさんと意見交換などしたいな、と思っているので共感頂けたら @takochuu までmentionいただければ是非ランチでもよろしくおねがいします。

次はhidenorigotoさんのエンジニアリングマネージャーとソフトウェア設計者に共通するスキルを考えてみたです。