詳細の確認および参加申し込みは以下のページからお願いします。早速定員になってしまったようなのですが増枠も検討中です。
(追記) 40名に増枠しました。
動機
いちエンジニアリングマネージャとして、エンジニアリングマネージャ・エンジニアリングマネジメントに興味・関心・知見・意見・失敗談・一家言ある方々と話してみたい。
"エンジニアリングマネージャ"の曖昧性
イベント概要欄に書いたとおり、（少なくとも自分が観測しているWebサービス業界隈では）エンジニアリングマネージャ職について統一された定義・見解を見ることはほとんどありません。
エンジニアリングマネージャというポジションは組織が成熟する過程において戦略的または偶発的に発生しており、会社や人それぞれによって思い描く姿やその実態・運用が異なるようです。*1
また、スタートアップ初期においては必要性が認識されることはあまりなく、CTOがその役割を兼ねていることも多いようです。*2
「いわゆるマネージャやテックリードとは何が違うのか？」という問を見るにつけて、プロダクトマネージャという役割が流行り始めた当初の「プロジェクトマネージャと何が違うのか？」と言われていたことを思い出します。
しかしプロダクトマネージャ職は今でこそ product manager conference や product manager meetup が開催されるほどにその専門性と職務内容の認知が高まり、組織ごとの知見や工夫・失敗談を交換する機会も多いものの、エンジニアリングマネージャは未だそれには及ばないと考えています。
そうした機会は少ないながらも、このポジションに就いている方はそれなりにいるようなので、各々の創意工夫や悩み、ドラマがあるのでしょう… 僕はそんな方々のうまくいった成功談、また、それ以上に失敗談も聞いてみたいのです。
…という思いを込めた tweet。
Engineering Manager Meetup 存在しないならやってみようかな
— 広島の粗大ゴミ (@ohbarye) 2018年7月20日
話すテーマについて
Connpass ページに書いたとおりオープンスペース形式でやりたいと考えています。LTやプレゼンの準備は不要です。その代わり「何を話してみたいか」のタネが大事です。
興味が沸くように、あるいはイメージが湧くように、Connpass に書いたテーマのいくつかについて一言ずつ触れてみたいと思います。
「自分はこんなことを話してみたいな」ということを書きます。（議論の方向性を決定づけないように自分の意見は控えめで）
エンジニアリングマネージャの仕事内容
少なくともコードを全く書かないポジションではなさそうだと思うものの、どのぐらい書いている、あるいは書くことが期待されているのか。オレは毎日書いている…お前らはどうだ…???
エンジニアの上司はコードを書ける人間であるべきか？という問をよく見るが、個人的にはどちらの視点から見るかによって意見が変わりうる。
例えば自らの立場がメンバーだとしたら「マネージャはコードを書けなくても良い」と答える。コードを書けなくても頭の切れるマネージャのもとで働いたときの経験からそう思っている。エンジニアリングや目標設定に関するフィードバックは同僚から貰うこともできる。
だが、もし立場がマネージャであるときは、コードを書ける人間であるよう自分が自分に要請する。前述した自分の元上司ほど頭が切れるわけではないので、メンバーのエンジニアの抱える問題や挑戦をより深く理解するためには一定のエンジニアリングスキルは間違いなくあったほうがよい。
ちなみに『Work Rules!』によると
グーグルの採用の信条は、エンジニアリング部門のマネジャーは最低でも自分のチームのメンバー並みの技術力を備えていなければならないというものだった
エンジニアリングマネージャの仕事、キャリアパス、求められるスキル
この辺は先述の、エンジニアリングマネージャ何する人かという問いの答え次第でもある。
また、エンジニアリングマネージャを続けた先に何があるのか？VP of Engineering なのか CTO なのか分からないが、それがオレたちの望んだ未来なのか...???
テックリードなど他職種との違い
エンジニアリングマネージャからピープルマネジメント除いたらテックリードになる、みたいな会社もあるようです
エンジニアリング組織論
はい
エンジニアリング組織論への招待 ?不確実性に向き合う思考と組織のリファクタリング
- 作者: 広木大地
- 出版社/メーカー: 技術評論社
- 発売日: 2018/02/22
- メディア: Kindle版
- この商品を含むブログを見る
本の感想を語り合う場所であっても良さそう
給与
エンジニアリングマネージャの給与の話だけでなく、マネジメントするメンバーの給与に関して裁量があるのか、どのように決定しているのか。そのあたりが気になります。
また、各社エンジニアリングマネージャの給与をそれ以外のメンバーに比べて高く設定しているのだろうか？
個人的には"マネージャ"と付く名前の役職にならないと給与が頭打ちになるような会社は嫌だという思いがあります。
自分が新卒入社したSIerで、エンジニアリングスキルを伸ばすよりもプロジェクトマネジメントスキルを伸ばした方が評価されるような状況にて悩んだ経験から強くそう思っています。
ちなみに U.S. 全体で$108,849 per yearが推定平均給与 by Indeed (8/13時点)
https://www.indeed.com/jobs?q=Engineering+Manager&l=United+States
Indeed Japan だと給与どころか募集があまり多くなく、推定平均給与の記載もない
https://jp.indeed.com/%E6%B1%82%E4%BA%BA?q=Engineering+Manager&l=Japan
エンジニア採用
会社によっては採用もやるようだ。
自分も採用活動に関わっているが、エンジニアリングマネージャだからやっているとか、エンジニアリングマネージャだから採用権限があるわけではない。
そういえば、マネージャに採用権限を与えるのはアンチパターンだと『Work Rules!』にはある。
採用に関する権限をマネジャーに手放してもらう必要がある。前もって言っておかねばならないが、グーグルが新たに雇うマネジャーはこれを嫌う！ マネジャーは自分のチームを選抜したがるものだ。ところが、意欲に満ちたマネジャーでさえ、人材発掘の作業が長引くと採用基準をゆるめてしまう。
マネジャーに採用決定を任せると、チームのメンバーに対して彼らの権力が大きくなりすぎてしまう
評価、育成、1-on-1
1-on-1 のやり方や研修関連の情報はそれなりに見かけるし、参考になる書籍もある。
評価は結構ナイーブな話題なのでオンラインで公開するのが難しい側面も含んでいると思う。
ネガティブフィードバックをどうするか。パフォーマンスの低い社員の扱い。解雇の権限（日本だとまず無さそうではあるが…）
また、エンジニアリングマネージャにメンバーの給与を決定する裁量があるのかどうか。
許可より謝罪 権限とか承認とか
功利主義的に考えたとき承認制は本当に効用が費用を上回るのか？
意味ある承認、会社や法的に義務付けられた承認があるのも勿論知っていますが、世の中の89%ぐらいの承認って無意味ではないのだろうか。残り11%で失敗したときのリスクがでかすぎるというなら払うべきコストだと思うが…。承認業務が比較的少ない現状でもそんなことを考えている。
またまた『Work Rules!』を持ち出すと「マネージャは部下に権限を与えまくって、不安になるぐらいでちょうどいい」という話が良かった。
人々がマイクロマネジメントに走るのは、組織のパフォーマンスに関する不安を緩和するためだ。つまり、他人の行動を絶えず監督し管理していると気が楽になるのだ──これは、本質的には彼らの自信のなさを表しているにすぎない。そうすることで、マイクロマネジャーは自分が管理をしている（役立っている）という幻想に浸れる。もうひとつの動機は、スタッフの能力に対する信頼の欠如だ。マイクロマネジャーは仲間が『やります』と言っても、彼らが職務を見事にやり遂げる、あるいは責任を果たすとは考えないのだ
書き始めたら一言触れる程度では終わらなかったうえにあまり unobtrusive にもならなかったので、わりと話したいことがある気がしています。
ということで改めて応募お待ちしています。
Slack group も用意しました。“コミュニティのSlack廃れがち“問題はあると思うので何か面白いアイデアが欲しいところ
参考
ちょうど読んでいる最中なので引用元が Work Rules! ばかりになってしまった
- 作者: ラズロ・ボック
- 出版社/メーカー: 東洋経済新報社
- 発売日: 2015/07/30
- メディア: Kindle版
- この商品を含むブログ (2件) を見る
