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の中でも「会議を一切やらない週を作る」とか「マネージャーが定期的に長期休暇に入る」とか具体的な方法が出てきました。これは一度聴くことをオススメします。
技術で解決しない、行動で解決する
ベースラインはdoneの定義
1 on 1 5人にすると一日1人
小さくリリース、軌道修正
フィードバックの情報量は、相手が受け取れる量に絞り込む。余裕で受け取れる、ぐらいにしないとだめ。消化できる情報量は個人差、および、前提知識によって差があるので、適宜調整すること。
調整さん
最初からこれを読めばよかったのかも
途中まで読んだらログインを求められる
見たい
「ステートメントシート」には、以下の内容を記載しています。
課題: 解決すべき、明確な課題
ステートメント: 課題が解決された状態
ユースケース: 対象の機能を顧客が利用する明確なユースケース
コア機能: ステートメントを実現するために、必要な機能のリスト
諦めること: 実施しないこと、別のタスクに委譲する機能などを記載
成果について、できるだけ定量的に示せる尺度を持つべき
評価は『何をやったか』ではなくて『継続的に行動している（行動できる）ことに対して、どのような成果出したのか』を評価のポイントとしてしっかりとフィードバックを行うことが大事です。
https://gyazo.com/45cd2d261c0faa0627ebfc2a79ac9e64
マンガでやさしくわかる学習する組織
システム思考
リンク集作成用コード
i=1;copy([* [${document.title} ${location.href}]]\n + $$('.style-1covvrn table a.style-14mbwqe').map(a => ${i++ } [${a.href} ${a.textContent}]).join("\n"))