新卒n年目でチームリーダーになり、プレイングマネージャーがしたいが、コードもかけないし評価・1on1もわからない問題
この記事を見ていて、前々から思っていることについて整理。
DMMでも他支援企業でも同じような問題として、チームリーダーになる意味をメンバーが感じられないという問題がある。
構造的には一定規模（50名前後以上）の開発組織になってくると一般的な管理監督者（例：部長）以外にもその下に階層を作ることが多い。例えば、マネージャーやグループリーダーがいて、その下に「チームリーダー」がいる。課長っぽいポジション。
ただ、このチームリーダーという役職はマネージャー的ポジションの人が忙しい問題もあって、より現場に近いメンバーの評価を任せたいがためにチームリーダーを置くことが多い。
このチームリーダーの多くは、チームのリードエンジニア的なポジション（かつ協調性がある）から来る人が多い。特に育成観点で会社へエンジニアとして新卒入社しているメンバーをチームリーダーに抜擢するケースは特にこのケースが多い。大体新卒2〜4年目のメンバーが多い。
ただ当然まだまだコードも書きたい人であり、そこにプラスして評価制度や1on1といった時間を拘束されるものがくっついてくるイメージ。
つまりソフトウェアではなくヒトに関するものが突然くっついてくる。時間も拘束される。
その人もそこまでヒトへの興味が強いわけではない場合、1on1のやり方とか評価の仕方を体系的に知らないので感覚になってしまうし、1on1で「話すことがありません」状態になる。
意味のないことに時間を取られすぎると徐々に疲弊していって「本当は何がしたかったんだろう」とキャリアについて悩み始める。また、メンバーによってはマイクロマネジメントをしすぎて疲弊するケースも多い。
急に左から右になり、フロー状態が失われる。かつ常時Slackで案件の相談といったチームへの窓口になることも多い。
さらにマネージャーや部長と違って、裁量と権限がある範囲が少ない or 定義されていないことも相まって不安定なレイヤーとなっている
こうした背景によって、かなり組織的な裁量と権限に貪欲（=組織としてどんどん役職を上げていきたい等）だったり、ヒトに興味・重要度がわかるメンバー（エンジニア歴が長いとエンジニアリングマネジメントの必要性を痛感して興味を持ち始める人は多い）
そのときに必ずと言っていいほど私が言っているのは、逆張りとしてマネジメントをしないためにマネジメントを極めようって言ってる。
マネジメントが上手い人は組織が自己組織化していくのは、1言ったら10わかるメンバーが揃っている。すると自分の時間が空くのでそこでコードを書いてもいいし別のことをしても良い。
仕事の基本は、常にスキルを上げながら今まで10かかっていたものを5にしてそこから生まれるバッファ（-5）を使って新しいものにチャレンジするという構造になる。この連続が成長感を作っていく。
あとは、組織としてはピープルマネージメント領域を体系化して伝えていくというのが大事になる。マネージャーや部長ですら1on1を感覚でやっていたり評価も評価制度に則っているだけだったりすることもあるので組織開発の領域を定義していく必要がある。
