エンジニアをマネジメントしてはいけない

自分が一兵卒のエンジニアのとき、自分に対してあれこれと言われていたような気がする。

『キミはこうだからできない』とか。アレは自分のキャリアや目標の達成に何一つ役に立たなかった。

1人、自分のキャリアについてマネージャから『キミには選択肢がある。(マネージャとして仕事振りを見ていると)こっちが合いそうだけどどう思う』と自分ではなく、自分のキャリアについて関心を持っていてくれて、先を示してくれた。

もう1人は、自分が選んだ先が実現できるようにマネージャとしてのコネクションを使って実現できる可能性の高い選択肢を調べ、示してくれたマネージャがいた。

どちらのマネージャも自分の『こと』について関心を持ち、考えたり、コネクションを探すなど動いてくれていた。

自分がプロマネのとき、御多分に漏れず進捗はWBSを担当するエンジニアとWBSの難易度で遅れることがある。

遅れるとき、エンジニアと話すのは遅れている『WBS』であり、気にかけているのは『WBS』がいつなら完了の状態になるか、だ。

プロマネとして関心のあることは、

  • 計画したとおりに終わるのか
  • 終わらない進捗を邪魔する障害は何か
  • それはどうやったら解消するか
  • それを踏まえて見通しはどうなるか

であるから『WBS』に対してどうこうしようとする。エンジニアと向き合うのではなく、WBSを挟んでエンジニアとどう片付けるかを向き合う。

コントロール、マネジメントするのは『WBS』でありマネージャではない。

マネージャのときは、エンジニアのMBOやOKRに対して向き合う。

エンジニアのMBOやOKRに向き合うとき、

  • エンジニアの実現したいキャリアは何か
  • それを構成するコンピテンシは何か
  • 具体的なObjectsは何か

を時間を相応に掛けて話をする。

フィードバックでも、

  • Objectsの進捗はどうか
  • 想定と違うことはあったか
  • 障害になっている原因は掴めているか
  • 障害の除去を手伝う必要はあるか

のようにObjectsを中心に起きエンジニアと向き合う。

冒頭の自分のケースでダメなほとんどのマネージャは、エンジニアに関心を持たず、コンタクトするときにだけ、エンジニア自身に対してあれこれという。

つまりこのようなダメなコンタクトするようなマネージャは、エンジニアを知ろうとしないのだ。

エンジニアのパフォーマンスの結果がマネージャとして担当する事業の成果となるにも関わらず。

エンジニアというリソース全体の2割だけに関心を持ち、その他のエンジニアは関心を割くこともないのだ。

その結果は、関心を持たないエンジニアをマネージャの意のままに動かすようにマネジメントしようとしていたのである。

でも、自分に関心を持っていないマネージャの言うことなんて耳に入るわけがない。

それは発する言葉全てがマネージャの都合でしかない。

マネージャは、

  • エンジニアに関心を持ち
  • エンジニアの実現したいことを聞き出し
  • 示唆し
  • 実現するように環境を少し整える

ことをするだけで、エンジニアの成果に繋がる。そうしたことが回り回って担当事業の成果に結びつく。

マネジメントする対象を間違えてはいけない。