Engineering Manager Advent Calendar 2018を見て学んだこと・使おうと思ったこと前編
アドカレって大量にあるのでバズったり話題にあがったりしたものだけ見ていつもは終わっていたのですがせっかくなので今年は関連するものを全部見て学びになったものはまとめておいて次につなげられるようにしようかなと思いました。
以下のものを全部見ると形で。
エンジニアリングマネージャーという枠だけで50記事なんで相当やな。
一旦vol.1だけ見てまとめてみました。
最初は一気に全部見ようかと思いましたがさすがに50は多すぎた。。
プロダクトオーナー兼EMとしての資質について考えてみた。 – i35-267 – Medium
大体自然にやっている事がおおかったがVSMという手法については初めて聞いた。自分の周りでは問題となっている部分は皆すぐ言って改善していく文化なのでここらへんも自然とやっているのかもしれませんが。
駆け出しエンジニアリングマネージャーの苦しみ - Qiita
会社に会う人を採用する
これは重要だなと思います。僕もまずはマインドが合うかどうかというのを重要視しています。
Managerでありながら尖ったEngineerであるために自己組織化チームに挑む - Qiita
自己組織化するためにやるべきことが記載されていて良かったです。筆者と同じ様な立場ですができてない事も多いなと。モブプログラミング一度やってみたいんですが嫌がる人もいるかもなと思ってできていない。
アジャイルとは無縁の組織の中で、エンジニアリング・マネージャーとして取り組んでいること｜nnjyami｜note
アクノレッジメントコミュニケーションというのは初めて聞いた言葉だった。うまく言葉にはしづらいですが相手に関心を持ってコミュニケーションするという感じですかね。
エンジニアリングマネージャーになってから守っているたった3つのこと - motokieeの日記
規則正しい生活を送る。
マネージャだけじゃなく社会人としてパフォーマンスだすために正しい生活送るのは重要かなとは思います。
可視化してデバッグする
1on1でdocs共有とかは僕もやっていますがいいですね。
僕の場合も最近一つのプロダクトに関わりすぎないようにしていますがここらへんのバランスは本当に難しい。チームの状態を明確に見えるかするというのは本当に重要だなと思う。
この人はマネージャとして成果がだせなかったと書いているが自分がいる状態と別の人がマネージャをやった場合とで客観的に分析できているのでこういう見える化する能力あると思う。
マネジメントスタイルの選択基準、一貫的スタイルを持つことの困難 - valid,invalid
その時のフェーズや能力にあったマネジメントスタイルを選択する。マネジメントの押し付けはよくない。
コミュニケーション取っていると思いがちというのは自分にもあてはまったりするのでそこらへんは意識したい。そうは言ってもその人にあったコミュニケーションは取りたいところですが。
スタートアップ1人目エンジニアが、仲間を増やしEngineering Managerを志した - ユアマイスター株式会社エンジニアブログ
エンジニア一人というところからエンジニアが増える過程でのマネジメントの変化
意識しているのは無駄なことをしないということ。1on1が重要ということ
Engineering Managerをエンジニアのマネージャーとするのはやめませんか？ - Unknown Error
こらからエンジニアマネージャの定義を決める形でまとめられている。具体的にどの部分が楽しいのか記載があればよかった。一般的にはエンジニアのマネージャという方が多いようには感じますが。
コンサルティング同行で学んだ、エンジニアリングマネージャーとして新しい組織にジョインして取るべき姿勢 - ねこのひたい
記事のどの部分がコンサルティングで学んだ事かわからなかったのですが取るべき姿勢は同意です。書いてある事は普段のチーム行動で学べそうではありましたが。
-
プロダクトマネジメント
-
プロジェクトマネジメント
-
ピープルマネジメント
の技術が必要だが重要なのはエンジニアが楽しく開発できる環境を作る。だいたいの人はピープルマネジメントが主になるんじゃないかなとは思います。
人見知りマネージャが100回1on1をしてわかったこと - だいくしー(@daiksy)のはてなブログ
個人的に1on1苦手意識持った事ないんですよね。1ヶ月に1度しかしてないので話題が何かしらあるからかもしれません。
ちなみに一度1on1を頻度増やしてほしいですかとメンバーに聞いた事ありますがその時は月に1度で十分と言われました。1on1は月に1度でそれ以外は普段の業務コミュニケーションでまかなったりしています。ランチ行ったりとか。
今，個人的に重視しているエンジニアリング組織のためのセオリーをまとめる - TechとPoemeの間
Stable Teamの話が印象深かった。確かに効率はあがると思うのですがメンバーとしては飽きがきちゃうのでそこをマネジメントするのが大変だなと思ったので。弊社ではプロダクトで思考することが多いです。
Engineering Managerの難しさTOP3 – EM.PM – Medium
僕のTOP1は目標設定と評価ですかね。メンバーに対してこの話題で交渉するというのは常に慎重に望んでたりします。ここでいえば感情のマネジメントが近いですかね。
組織コンディションのスコアリングとその運用 ~wevoxを半年使ってみた~ - TOMOLOG
wevoxちょっと面白そうだなと思った。エンゲージメントを高めると事業が成長するというのはゲーム事業においてもそうかしっかりデータを取ってやってみたい。じゃないとお金を払い続けるか判断できないので。
エンジニアリングマネージャーが成人発達理論の視点で育成を考えてみた – Masahiro Taniuchi – Medium
あれ、やばい。自分の意識が低いのかオシャレな写真がところどころ挟まっているせいかあまり理解できなかった。ただ色んな視点で育成考えるって部分は重要だと思うという気づきは得られました。
良いチームとは何か、そして良いチームであり続けるために何が必要か - Qiita
重要な事繰り返しかいてあるのがいいなと。成長を常に意識しなければいけないなと。そのために振り返りは重要だなと。一応一週間に一度よかった事、改善点はあげているのでその点についてはできているなと思ったがチーム全体で同意するような形にしてもいいかもしれない。
1on1等であらかじめそういう文化を作っていくのが重要ということで交渉力みたいなものがマネージャーには必要というのがわかる。毎週技会開催されるの凄いので見習いたい。うちは大体続かないので。ちょっと気になったのがマサカリを投げ合う殺伐としたのエンジニアの一つの理想形なの？と言ったところ。あまりそう思わなかったので。あとmixiがロボット開発しているの初めて知りました。
ナイーブな問題ですが同じく引き止めは基本しない方針です。本人のためを思って退職がよくないと判断した場合は引き止めますが本人のためになるなら引き止めはしないです。あたりまえだとは思いますが。
逆に心理的安全を高める役割「煽り型リーダーシップ」について、聞いてくっしょ？ - Binary Diary
これは大分チームのメンバー構成によるなと思った。もしくはよほどうまくチームを作っていくか。少なくとも自分のチームでやるのは難しそう。リーダのキャラクターにもよりそうですし。ただこうやって新しい形のリーダシップの手法がでてくるのはいいかなと思う。
組織をデザインするという経験がないのでうまく活用はできなさそうだった。
エンジニアリングマネージャーとしてこころがけていること - Qiita
10年以上マネージャやってるということで歴戦感がありますね。
決定、決断しないというのがなかなかできないので意識したいところ。技術ではまだまだ負けないと思っているところ強い。
消極的なキャリア選択を減らすためのEngineering Manager入門｜serima｜note
Engineering Manager になったらソフトウェアエンジニアに戻るの難しいとありますが人によるのかなというイメージ。最前線でやってる人もいるし元々コード書くの好きな人が多いのでプライベートでも書いたりしてるので。
余談ですが実は僕の周りでは最近スペシャリストよりマネージャーを目指す人が増えてたりします。昨今の流行りとかもあるのかしら。
エンジニアリング組織の文化ができるまでの3年間の軌跡 - dskst's diary
なかなか0から組織作るというのはないのでここに書いてある以上に歴史あるだろうなとは思いつつ最初にやったことが全力でコミットというのがわかりやすいなと。信頼重要ですね。
なぜ、組織のつくりとソフトウェアアーキテクチャは似てしまうのか - Qiita
これを知った所で活用するのは難しいが読み物としては面白かった。ただ、面白いだけじゃなくて読んだ後に気づきが得られる方がやはりいいな。
NextAction
一気にインプットしすぎてかなり疲れました。まだvol2あるがここまで見て次何やるか。
- モブプログラミングの提案
- チームの状態の可視化(課題があればメンバー全員に見える様にしておく）
- チームとしての成長、個人として成長できているかを振り返る
- ビジョンとか思いを繰り返し(大袈裟なくらい)表現する
- 組織において仕組み化した方がいいところ等があれば務める
