ハンズオンマネージャーの緩やかな死
ハンズオンマネージャーの緩やかな死
source: https://newsletter.manager.dev/p/the-slow-death-of-the-hands-on-engineering
この記事ではコーディングから離れてしまったハンズオンマネージャーが、週数時間でもコードに近づけるようになる2つのアイデアを著者の経験を交えて紹介している。
エンジニアリングマネージャーには以下の２タイプがある。多くの人は1から始まり、（悲しいことに）緩やかに2のタイプに変化していくという。
-
スーパーハンズオン
毎Sprintタスクをこなし、難しいバグに取り組む。 -
フルタイムマネージャー
1日中会議をし、コーディング時間は0。
著者は2回この流れを経験している。
- マネージャーに昇進したばかりの頃
- コードの大部分に責任を持ち、Sprintに留まるのも容易
- 数年後...
- コーディングに当てられる時間は30~70%。チームの成長と共に減少していく
- さらにその後...
- 1日中の会議、新しくリーディングすることになるプロジェクト、コーディングする時間もなく、徐々にIDEを開くのを諦めていく。
- 週にコーディングに当てられるのが2時間程度になり、「2時間ではどうせゾーンに入るのもむずかしいし、ドキュメントのレビューでもしよう・・・」のマインドになる。
コーディングに戻る時
著者は以下の観点に気をつけつつ、具体的なタスクに取り組むことで、コーディングに戻ることができたという。
- クリティカルパスにあるものや、他者に依存するタスクは一切引き受けない
- 以下３つの観点でタスクを選択する
- エンジニアの役に立つもの
- これから学ぶもの
- 会社にとって有益であり、他社が真似できないもの
以降のセクションでは、特に1について具体的な実例を紹介している。
内部ドキュメント用のChatGPTを構築した同僚の話
日々著者の同僚のAviは日々誰かから4~5つの質問により作業を中断させられていた。そこで彼は全てのナレッジをドキュメントに書き起こし、さらにそのデータを全てデータベースに取り込み、ChatGPT経由で情報を引き出せるBOTを開発した。
それはチームにとって、とても有益なものになったという。
より小さいプロジェクトを選択する
他に（ハンズオンマネージャーのあなたが）できることとして以下を勧めている。
- 優先度の低いバグを解決する
- 技術的負債に対応する
- 煩わしい工程を自動化する
著者はこのうち自動化を特にお勧めしている。
実際に彼のチームが行っていた非常に時間のかかるデータ転送フローを、PythonやChatGPTを使って効率化してしまったそうだ。
こうした取り組みには2つの利益がある。
- エンジニアの生活を向上させる
- 何かしらの新しいことを学ぶことができる
最後に
著者はいかなるレベルのマネージャーも多少のコーディング時間は持つべきだと考えている。小さなタスクを選択し、自分のペースで行えば良いのだと。
感想
刺激的なタイトルだったが、マネージャーになると会議漬けになりコーディング時間がなくなってしまうのは本当にその通りだし、対策として書かれていた内容も実際に自分がやっていることと似ていて、みんなそういうものなのかと思った。
一方でコメント欄では「マネージャーなんだからコーディングなんて不要」みたいな意見で結構反論されてる。
In my opinion, the 'type 1 hands on manager' isn't a manager. That's a tech lead. Management is a role where you shouldn't be trying to be the smartest person in the room anymore.
Coding on the side and doing things here and there to help the team is great, but not if it distracts from their core responsibilities as a people leader.
それはそうなんですけど、全て理解した上でスケジュールの妥当性とか判断したいし、成果物もレビューしたいんですよね〜。
Discussion