スタッフエンジニアが「解くべき問題」を見つける方法：受動的に耳を傾け、問題を蓄積し、共通の形を見抜く

著者は次のように述べています。

> 注意点：私の経験は主に大企業でのインフラや開発者ツールの仕事に基づいており、エンジニアがロードマップに影響を与えるボトムアップの裁量を多く持つチームで働いてきました。よりトップダウンな環境では、このように働く余地が単純に少ないかもしれません。

テック業界全体の傾向として、エンジニアのボトムアップの裁量が減り、トップダウンで管理される環境が増えているのではないかと思います。エンジニアが裁量を持つテック主導から、プロダクトマネジメント主導へと変わったテック企業（または平均的なエンジニアの経験）がどれだけあるのか、知りたいところです。証拠はありませんが、私の推測では、エンジニアの裁量は年々減少していると思います。テックの文化が（私の意見では）テック重視からビジネス、経営、プロダクト重視へとシフトし、エンジニアはビジネス、経営、プロダクトの目標を達成するための駒に過ぎなくなっているからです。

すべて仮説であり、逸話的なデータに過ぎません。

面白いことに、そんな問題を抱える人もいるんですね。私はキャリアのほとんどをスタートアップで過ごしてきましたが、一貫して感じるのは、解決すべき問題の数は、起きている時間で合理的に達成できる量をはるかに超えているということです。

ですから、私は解決すべき問題を探すのではなく、どの問題が最も緊急か、あるいはどの解決策が複数の問題を同時に解決できるかを評価しようとしています。すべてのチームと顧客を満足させ、生産性を保つために、そういった優先順位付けを正しく行うことを学ぶことが、私がキャリアで非常に誇りに思っていることです。

これはすべて非常に良いアドバイスですが、エッセイの冒頭で質問している人には、おそらくスタッフエンジニアになるべきではないと警告したいです。その肩書きが単に昇進の階段の一段で、責任に差がない会社（そういう会社はたくさんあります）にいるのでない限りは。

私が一緒に働いたスタッフ以上のエンジニアで成功した人は、昇進はたいてい形式的なもので、すでに明らかにその仕事をしていた人たちでした。私が見てきた「無能のレベルまで昇進した」人たちは、肩書きや給与アップを目指して、そこに到達するために「ゲームをしよう」としている人たちでした。

人の問題を解決する動機が、昇進を得ることではなく、問題を解決することが好きだからであるなら、それはあなたに合った仕事ではないでしょう。

私たちの最もシニアなスタッフエンジニアやアーキテクトが、実際に役立つことに取り組んでくれたらいいのにと思います。彼らは、現在のプラットフォームや今後の方向性とは何の関係もない新しいテクノロジーで遊ぶのが大好きです。時には、前のアーキテクトが始めたものを、彼らもまた別の仕事に移る前に直そうとすることもあります。

テックのほぼすべてが肥大化しており、大規模なレイオフがあってもほとんどの企業はびくともしないと思います（ただし、人々の生活に有害なので、そうするのは残酷に思えますが）。チームあたりの人数が減れば、コンテキストスイッチが減り、開発者はより多くのことを所有します。彼らは仕事を探す必要はなく、目の前に仕事があるでしょう。私が働いてきた大企業の多くで、仕事が足りない人が多すぎるのを見てきました。彼らは結局、会議やその他の無駄なこと（ドキュメント作成など）を作って時間を埋めています。マネージャーやディレクターは大きくて肥大化したチームを望んでいるようで、ヘッドカウントが多ければ多いほど、プロモーションを要求し推し進めることができます。

シニアスタッフの黄昏時に難しいと感じるのは、深い技術的知識があると、短期的な問題を、単なるリクエストとして、迅速かつ効果的に解決できることです。

著者は、他のチームの不満を理解するために時間を費やすべきだと述べていますが、それは多くの時間を費やし、私は話してばかりでコードをプッシュしたり機能を出荷したりしない人になりたくありません。他の人がどう経験したか聞いてみたいです。

私はしばらくスタッフレベルで働きましたが、鍵はマネージャーを管理するディレクターに報告することだと思います。そうするたびにうまくいき、プロジェクトは定義しやすく、人々は説得しやすかったです。他のICを管理する数人のマネージャーと同じレベルで働いたこともありますが、それは決してうまくいきませんでした。他のICはタスクで競争しようとし、人々はあなたにニーズを持ってきません。異なるプロジェクトについて知るのはしばしば遅すぎます。他のチームは縄張り意識が強く、あなたの介入を本当に望んでいません。