エンジニア組織をリードする人のことを考えた話
エンジニア組織をリードする人に、大きく3つの責務を求めたい
そんな風に考えるようになったという話をします
求める3つの責務
- テクニカルマネージメント
- ピープルマネージメント
- コミュニティマネージメント
1. テックリード
品質、生産性、技術的な承認、技術的な評価等、組織の専門性について責務を持つ人
2. エンジニアリングマネージャー
教育、採用、人事的な承認、人事的な評価等、組織の人間性について責務を持つ人
3. コミュニティマネージャー
提起、反応、支援、新陳代謝等、組織の社会性について責務を持つ人
コミュニティマネージャー？
これが今回話したいことです
エンジニア組織に1と2が重要な事は、多くの方が言葉にしてくれています
プラスで僕はエンジニアコミュニティをリードする責務が必要なのではないか？と思うようになりました
コミュニティをリードするということ
リードすると書きましたが、コミュニティマネージャーの実態は
コミュニティ内に多様なアクションが自生するためのサポートが責務と考えています
- 疑問や課題提起という種撒き
- 迅速なフィードバックという育成
- ムーブメントに実態を与えるという支援
- 風化した体験の廃止
具体的にはこのようなことを行うイメージを持っています
なぜ独立して必要？
A: あれやりたいなぁ B: いいね！やろうよ！ A: お！ありがとう、やってみようか！ B: じゃあ会場とかいるね A: あーそうね、ちょっと周りとかにも相談してみるよ ~数週間後~ C: あれやりたいなぁ B: あれ、それってAと話してなかったっけ？ A: あー、相談したんだけど具体的に動く時間とりきれてないんだよね C: あっ、そうなんだじゃあなんか進んでるんだね A&B: いや、進んでるかっていうと微妙...
コミュニティでこういう場面を結構見てきました
種撒きとフィードバックによる初期育成はできて、ムーブメントになったけど
ムーブメントに実態が与えられなかった、かつ風化してる認識ができた時に、再度進行させるかいっそ一度廃止といった次のアクションの判断もされない
結果としてCさんという新陳代謝も阻んでしまった
この体験から、コミュニティ内に多様なアクションを自生させるのは
それなりのサポートが必要で、一定の時間を使うことなんだなとイメージしました
一方専門性をリードすることも、人間性をリードすることも多くの時間がかかります
そのため、兼任だと優先度が下がりがちになる
だから独立させたい
そんな風に考えるようになりました
最後に
エンジニア組織をリードすることに、3つの責務を求めたい
それはテクニカル、ピープル、コミュニティの3つのマネージメント
特にコミュニティマネージメントという概念を独立させたい
こんなことを言葉にしました
コミュニティでは日々小さなムーブメントが起こっているはずなんです
でもそれは、大きなものになったり、組織での体験にまで到達していないことがある
これがもったいないと思っていて、何かしらそこを担いたい
ムーブメントが起こる瞬間って、とても楽しいんです
でも実態が伴わないと楽しさは持続しなくて、次のムーブメントも起こりにくい
組織に所属する上での、1つのエンゲージメントになるくらいに
ムーブメントと体験の連鎖を起こしたい
だから、コミュニティマネージメントがエンジニア組織にはあってほしい
そんなことを考えたという話でした
おしまい
