Staff plus engineerの役割は、チームが何を必要としているか、また特定のエンジニアが何を得意としているかによって大きく異なります。 私の経験では、スタッフ・プラス・エンジニアの責任は時間とともに変化しますが、通常は、会社にとって戦略的価値のあるプロジェクトや取り組みに従事し、技術設計を推進し、チームをレベルアップさせることに重点を置いています。 – Diana Pojar

パーティーで親戚に追い詰められ、ソフトウェアエンジニアが実際に何をしているのか説明を求められたことがある人なら誰でも、その仕事を説明することが難しいことを知っています。 しかし、同僚が身を乗り出してきて、「スタッフ エンジニアの仕事は何ですか」と尋ねると、多くの人は頭が真っ白になってしまうのです。 しかし、それは誤解を招く答えです。 彼らは同じ仕事をしていますが、以前は仕事の中心であったのに対し、補助的な仕事となり、新しい優先順位を持つようになりました。 技術的な方向性の設定と編集、スポンサーシップとメンターシップの提供、組織の意思決定へのエンジニアリングの文脈の注入、探索、そして Tanya Reilly が「糊付け」と呼ぶものなど、アーキタイプによって毎日のスケジュールは多少異なりますが、すべてのアーキタイプで共通の基盤があります。 私たちは皆、自分のコードを現在よりも優れたアーキテクチャにしたい、または何らかの方法で改善したいと思うことに同意すると思います。 しかし、多くの場合、人々はより良いものを求めるという漠然とした感覚を持ちながら、それが何であるかについて明確な考えを持っていないことに気づきました。 私は、グループ内で、自分たちがどこに到達しようとしているのか（実際には、そこに到達できなくてもかまわないのですが）についての共通認識を持ち、そこに到達するための一般的なゲームプランを考える手助けをするのが好きなのです。 – ジョイ・エバート

人気児童文学の中でロラックスが木のことを代弁しているように、スタッフエンジニアは会社の技術のことを代弁しているのです。 テクノロジーはそれ自体で語ることはできないので、その代表として効果的な支持者を必要とします。 技術の進歩に成功する人は、現実的で計画的であり、個々の決断を決定的な危機としてとらえるよりも、長期的な進歩の傾向に焦点を合わせています。

スタッフプラス エンジニアの中には、API 設計のような特定の分野をリードするために明示的に雇われる人もいれば、広い分野にわたってアプローチを編集し調整することになる場合もあります。 すべての役割に共通するのは、技術的な方向性を決めるという現実は、周囲の組織の真のニーズを理解し解決することのほうがはるかに多く、自分自身が学ぶことに興奮するような技術やアプローチを優先させることははるかに少ないということです。 しかし、上級職では、まずビジネスと組織に対して責任があり、自分自身はその次です。

Mentorship and sponsorship

現在の私の役割では、私がスポンサーした人が作品を出荷したという発表を送ったり、エンジニアリング チームの重要トピックに関するモデルの形成や転換に私が貢献したとわかると元気を感じます。 テクノロジーを構築し、サポートするという大変な仕事を日々こなしているのは、私ではなくこれらのチームなのです。 私は、彼らの進歩、そしてより重要なのは、その進歩の方向性、彼らの仕事と会社の目標との整合性に基づいて、私の影響力を測定しています。 – ミシェル・ブ

英雄的リーダーシップの一般的なビジョンは、その決定が会社の将来を変えるような、非常に生産的な個人を中心に据えたものです。 そのような物語のほとんどは、広報チームによって意図的にデザインされたもので、良いストーリーを作るためのものです。 会社の長期的な軌道を変えるには、個人の英雄的な行動よりも、周囲のエンジニアを成長させることの方がはるかに効果的です。 周囲の人を成長させる最善の方法は、メンターシップとスポンサーシップの積極的な実践を生み出すことです。

多くのキャリア ラダーには、スタッフ職への昇進の資格を得るために、メンターシップに関する義務的なチェックボックスが設けられており、メンターシップはその役割の重要な部分を担っています。 自分の経験やアドバイスを共有し、相手の状況を理解するために継続的な関係を築くことは、インパクトのある仕事です。 上級職では、メンターシップは入社のハードルに過ぎません。最も効果的なスタッフエンジニアは、適度なメンターシップとかなり多くのスポンサーシップを組み合わせ、自分の親指を直接スケールに乗せて、周囲の人の昇進と支援を手助けしています。 まだ読んでいなければ、Lara Hogan がスポンサーシップとメンターシップの違いについて、「スポンサーシップとはどのようなものか」（What does sponsorship look like?

Providing engineering perspective

I have a seat at the table that occur at higher level engineering discussions above a individual project and teams.このようなレベルの議論に参加することができます。 定期的に開催されるスタッフ・エンジニアリング・ミーティングでは、技術的なものから非技術的なものまで、チーム横断的に問題を議論しています。 – Dan Na

効果的な組織は、日常的な意思決定を合理化します。 この良い例が、潜在的な企業顧客との契約を検討するプロセスです。 初期の段階では、製品チームやエンジニアリング チームがサポートしにくい契約が結ばれることがあります。 このようなことが数回起こると、プロセスにはより多くの利害関係者がレビューのステップに参加するようになり、最終的には、適切な人が適切な時間に適切な場所にいるようになります。 組織再編の場合、結果を変えるような貴重な意見が得られないまま行われることがよくあります。 同様に、エグゼクティブやアーリーステージ企業のスタッフプラス・エンジニアのように、毎年1人ずつ採用するような頻繁でない職務の面接では、候補者の重要な側面が評価されないことがよくあります。 会社によっては、ロードマップの計画などもこのカテゴリに入ります。

スタッフプラス エンジニアは、この種の決定が行われている部屋に不意に引き込まれることがよくある人たちです。 これにより、結果を変えることができるうちに、エンジニアリングのコンテキストや視点を意思決定に反映させる機会が与えられます。 重要な決定事項に対するこうした短い時間の意見は、過度に影響を与えることはなく、エンジニアの視点に耳を傾けることができるようになります。 7349>

探求

インキュベーター内での私の現在の役割では、一日中プロトタイプを作成していますが、以前の技術リーダーの役割では、さまざまなことを行っていました。 – Ritu Vincent

ヒルクライムはすべての問題を解決できるわけではありませんが、非常に効果的なので、多くの企業が他のアプローチをとるのに苦労しています。 これは、企業向け案件のサポートに苦労している消費者向け企業であったり、小規模な競合他社のリリース ケイデンスに対抗するのに苦労している成熟した企業であったりします。 また、現在のビジネスが非常に貴重であるため、貴重なビジネスの成長率が下降線をたどっているにもかかわらず、新規ビジネスを優先することが難しいという場合さえあります。

長期的には、企業は探索することを学ぶか衰退するかのいずれかですが、これは無視できる挑戦ではありません。 これは無視できない課題です。ヒルクライムをマスターしたチームに探索的な仕事をさせるだけでは確実ではないので、多くの企業は別のアプローチをとっています。 多くの企業では、幅広いスキルを持つ信頼できる人材を数人見つけ、リソースを割り当て、数カ月後に彼らが何を発見したかを確認するのです。

これは必ずしもビジネス上の問題ではなく、会社のシステムが対応できないような、曖昧で重要な問題である場合もあります。 それは、インフラストラクチャのコストを一桁減らすことかもしれません。 3年かかる多地域戦略を6ヶ月で実現することかもしれません。 プライマリー・データベースのディスク容量が残り3ヶ月しかなく、より大きなサイズにアップグレードできないことに突然気づくかもしれません（私の経験では、急成長する新興企業で驚くほど頻繁に起こる問題です）。

これは、企業が行う仕事の中で最もやりがいがあり、最もリスクの高い仕事です。 それは、正しい仕事を特定し、出荷するために必要なことを行うことです。

But Will Still Write Software? 「まだソフトウェアを書く時間があるのですか？ しかし、私の技術戦略 (およびその他のマクロレベルの意思決定) がチームの他のメンバーの現場での経験に基づくものであることを確実にするために、「手でキーボードを打つ」作業を継続することが重要だったのです。「

Katie Sylor-Miller は、「私はフロントエンドアーキテクトですが、最近主に書いているのは SQL です。 パフォーマンス指標を見て、改善すべき点はどこか、パフォーマンスとビジネス指標を改善するために修正すべき最もインパクトのある問題は何かを考えています。 あちこちで JS や PHP を少し書きますが、ほとんどはチームのブロックを解除したり、パフォーマンスに関連する小さな実験を実行したりするためです」

Silvia Botros は、「私はもうビジネスのためにコーディングをすることはありません。 最後に端末を立ち上げたのは、自分のドット ファイルをリファクタリングするためだったと思います。 これは、私の上司であるチーフアーキテクトが意図的に決めたことです。 彼は、四半期ごとに、私たちが生産に入るコードに貢献していないことを確認してきます」

Joy Ebertz は、「上級者になればなるほど、あなたの仕事はコードに関するものではなくなります」と語りました。 確かに、ピープル・マネージャーと違って、あなたはまだ非常に技術的な側面を持っていますし、プリンシパルであっても、少なくともいくつかのコーディングをする可能性があります。 しかし、上に行けば行くほど、あなたの仕事は、あなたの周りの人々(そしてより広範に)を指導し成長させること、会社の公共技術ブランドを構築することを通じてチームを作ること、改善または修正できる大きな技術トレンドに気づくこと、あなたのチームまたは会社の技術ビジョンを定めるのを助けること、技術負債プロジェクトのための資金調達を提唱することになります」

ほとんどの人がある程度書き、誰も書かないが、キャリア初期の頃ほどは書かない。

Slow but rewarding

Staff-plusの仕事に共通するテーマは、タイムフレームが長くなることです。 キャリアの初期には、ソフトウェア開発の迅速なフィードバックサイクル (書く、テストする、出荷する、繰り返す) に執着しがちですが、このレベルで行う仕事のほとんどは、このフィードバックループに代わって、数週間、数か月、数年かかるものです。