Engineering Manager Advent Calendar
hitode909.iconプロダクトオーナーの資質がわかった。EMを兼ねていることで、という特徴は？
hitode909.icon開発プロセスを作れるあたり？
超ざっくり言うと「エンジニアの組織づくり」が仕事でしょうか。
hitode909.icon人を動かす、が紹介されてた。これはエンジニアリングにかぎらないマネージャ向けに思う
hitode909.icon人を動かす、はとりあえず買った
能力を開発する: マネージャはチームメンバが目標を達成するための能力開発を支援しなければならない。困難な課題に取り組む機会を提供することが，社員の能力レベルの向上に役立つ。
どんどん、空中に浮いているタスクを取っていってもらいます。
hitode909.icon自己組織化されたチームの振る舞いとしてはこうなりそう
「褒めるのが苦手だな」という課題を持っていましたが、そんな時に読んだ本が褒めることも大切だけど、アクノレッジメントすることが重要だと教えてくれて、自分自身がコミュニケーションへ感じていたプレッシャーが和らぎました。
hitode909.icon買った(446円)
hitode909.icon言葉遣いに気をつけている
先日、コーチングの手法に習い、自己採点型の振り返りをしたところ、思いの外、建設的な意見が多く出てきて、手応えを感じました。
組織やPJのデバッグを意識してやるようにしています
課題が出てきたときにログを取ったりすることで可視化して何が原因なのかをデバッグして解決していく
hitode909.icon1on1シートでTODOをメモしてアサインしたりは今もやってる
という(たとえ大雑把であっても)はじめの一歩としてのメンバーそれぞれの工数計測が必要だった。ひいてはこの計測結果がプロダクト維持に必要なリソースということになる。
hitode909.icon計測した工数を見えるようにする必要がありそう。マネージャなら当然見れるということなのかも
タスク成熟度という概念
hitode909.iconこれも読んだ。ジュニアは採用しない、成熟した最強の人材を採用してるのを覚えてる
総じて無邪気に、興味をもって話を聞く
謙虚なコンサルティング ― クライアントにとって「本当の支援」とは何か
hitode909.iconとりあえず買った
マネジメントを学ぶ習慣のないエンジニアではエンジニアリング + マネジメント (エンジニアが足しているだけ) になっていて、それはエンジニアの力の最大化にはならないと思っています。
いい話
組織づくりを考える上で知っておく必要のある概念たち
用語集っぽい
怪しさもある
第二部「ＥＱリーダーへの道」では、個人のＥＱを高め、「ＥＱ型リーダー」になる方法を具体的に伝授。第三部「ＥＱの高い組織を築く」では、さらに一歩進んで、組織や集団全体のＥＱを高めていくための手法件をさぐります。欧米有名企業の実例を豊富に盛り込んだ、実践的かつ画期的なリーダーシップ論です。
wevoxのデータの使い方。チームのどこかで見れるとよさそう
メンバーからのアンケートを元にスコアを算出する。
過去スコアやベンチマーク比較を元に、マネージャー/リーダー層で議論を行う。
議論を元に、解決すべき課題に対するアクションを決め、実行する。
という、流れで約半年ほど運用を続けています。
常に今を疑う
「普通は」「常識的に」「当たり前に」という言葉を絶対に使わない
ムーンショットな目標を掲げる
「出来ない言い訳」よりも「どうすれば出来るか」を真っ先に考える
あえて曖昧にする勇気を持つ
ジョブディスクリプションだけに囚われない
外部の人を積極的に活用する
人の入れ替えだけでなく、ハンガーフライト等の交流で常に新しい風を入れていく
目先のことにとにかく熱中する
やることとやらないことを明確にする
素早く実行し、小さな失敗を繰り返す
短いサイクルでスプリントを回す
マサカリを投げ合う殺伐とした現場もエンジニアの一つの理想形かとは思いますが、私は肯定と相手への興味がベースになっている文化を広めていきたいと思っています。
ポエミーな感じになってしまい恐縮ですが、褒める組織が増えることを願っています。
A「たぶんこうすれば出来ると思うんだけどー・・・」
K「え？やるっしょ？」
hitode909.icon関係性によっては発言しづらい関係にもなりそう
指示しない、提案・アドバイスする。
決断・決定しない、チームに任せる。チームの決断・決定は無条件に支持し責任をとる。
hitode909.icon良い
そのためには役割はできるだけシンプルにしてある程度抽象的な役割にしておき、実際の責務をだれにどう割り振るかはそのチームごとに決定するほうがよいと考えています。
その決定事項をjob descriptionとしてチームで共有するといったことなども有用だと思います。
hitode909.iconjob descriptionは対外向けに求人のときに使うイメージだったけどチーム内の共有にも使える
hitode909.icon曖昧なまま一旦置いておくのはメンバーシップ型雇用を感じる
私のこういう「こころがけ」がどれだけ奏功しているかは検証できていませんが、今のところチームは、私が年寄りゆえに研修や啓蒙などの業務に引っ張って行かれてなんだかんだで1週間くらいオフィスに顔を出せなくても何の問題もなく(?)回っているし、親子に近いくらい年齢の離れたメンバー同士が相互に教え・教えられしているし、いい感じに回っていると思います。
hitode909.iconうまくいってるかどうかを見る指針は難しそう
入社後半年ほどはサーバサイドエンジニアとして、他のメンバにたくさんの教えを請いながら機能開発や改修を行っていたのですが、やはりエンジニアの採用がうまくいかない問題は、徐々に大きな組織課題として浮き彫りになってきました。
そこで、サーバサイドエンジニアとしての役割はいったん脇に置いて、業務時間のすべてを採用活動に注ぎ込むことにしました。
思えばこのあたりから「足りないピースを埋めに行く」行動を自然としており、あえて言い換えるなら Engineering Manager 業に片足を突っ込み始めていたのだと思います。
hitode909.icon良い
たとえば「明日から Engineering Manager」と言われたとしたら、まず絶対にやるべきなのは「Engineering Manager は何をする役割なのか」という認識をすり合わせることです。
hitode909.icon期待はアウトプットしておくと目線が揃いやすそう
権力、依存
1on1や普段のコミュニケーションでは「正しい結論」を伝えるのではなく「正しい問い」を立てる事によって、気付きを与えて成長してもらうのが今の自分なりの考え方になりました。
この10の行動規範からも分かるように、マネージャーの仕事の対象は、主としてメンバー、つまり人です。
本当に寝てる
教職についている学生時代の先輩に「学校教育大変じゃないですか」と聞いたときに返ってきた「(生徒は)話し足りてないね。話を聞くだけで8割解決するよ」という言葉を思い出します。
仕事をする中で議論したあと、なんとなく合意を形成されてそうな時があります。そういうときこそ「では○○ということですすめていきましょう」と結論を言うようにしています。
いい話
信頼を示すために実施したことは２つ。
具体的に信頼していることを相手に伝える
メンバーの仕事に極力口を出さない
EMFMの中でも「会議を一切やらない週を作る」とか「マネージャーが定期的に長期休暇に入る」とか具体的な方法が出てきました。これは一度聴くことをオススメします。
リンク集作成用コード
i=1;copy([* [${document.title} ${location.href}]]\n + $$('.style-1covvrn table a.style-14mbwqe').map(a => ${i++ } [${a.href} ${a.textContent}]).join("\n"))