Software Engineering at Googleの5章を読んだ

<br />

5. How to Lead a Team

この章はどうやってチームを引っ張っていくかという話

・リーダーの役割は二種類ある
マネージャー：人をリードする
テックリード：技術の成果

新生のチームだと、テックリードとマネージャーを一人で兼ねる
大きいチームだと二人に分ける

・リーダーの配置方法
どこかのチームから引っ張ってくる
昇進させる

・エンジニアはリーダーになりたがらない
コードを書く時間が減るから

・マネジメントの成果
コードを書いてる時は1日の成果がわかりやすいが
マネジメントは1日の成果がわかりにくい
マネジメントはチームの進捗で成果を見ると良い

・マイクロマネジメントをしないようにするために
積極的に管理することをしない
マイクロマネジメントするとチームが死ぬよ
ただし、放置しろではないので注意

部下を信用しよう

また、ゴールを設定しその方向に部下が向いているか定期的にチェックする
これでマイクロマネジメントを防げる

・採用
自分より無能な人間を採用すると
マネージャーとしての自分の地位が確立するがアンチパターン
例えば休みが取れないw

自分より優秀な人を雇うとチームはその人がリードするかもしれないが
そうなったら自分は別のチームをリードすれば良い

・能力の低い部下
無視するとチームがバラバラになるのでダメ
そして祈っていても改善しないので手助けする
これでアップorアウトを早く判断できるようになる

期間を指定してゴールを設定して観察する。
一時的にはマイクロマネジメントになる

・部下は友達ではない
マネジメントは部下と友達になることではない。
部下をリードすることである。
部下と仕事関係なしで繋がりたい場合には、ランチを一緒に食べるのが効果的

・触媒になる
全部を正しくしたいし、全部の答えを持っていたい
だけどそんなことは無理
答えられなくても知ってる人につなげれば良い

・意思決定について
意思決定を電車に喩えて、15分ごとに電車がくるとする
毎回電車がくるたびに電車を止めていたら
あなたの時間を無駄にするだけではなくチームの生産性も下げる
本当に止めるべきものだけ止める方針にするべき

また、簡単にやり直せるものはYESと答えてよい

・1on1で聞くべきこと
何が必要か？と毎回聞く
各々メンバーが生産性と幸福で必要なことを確認するんだ

・部下の信頼を得る
マネージャーは仕事を依頼するのがメインだけれど
面倒な仕事を引き受けると信頼が得られる

・テックリードが最初に学ぶこと
自分なら20分でできることを若い人だと3hかかる。
これを自分でやらずに指導すること
良いメンターはどのぐらいの時間を自分で考えさせるか考えられる人

最近マネージメントの仕事がメインになったので
この辺痛いほどわかりますw
続くよ

<br />