引用文献

コードの質の計測

ディスティングイッシュト・エンジニアという表現がわからなかったが、ディスティングイッシュトが「抜群の」とかなので立場上の「凄腕エンジニア」という感じで捉えれば良さそう

「セーフティネットの向こう側」の節で書いてあるが、スタッフエンジニアはそれまでのマネージャーが引いたレールから外れて、自分で思考し動かなければならなくなる

リーダーシップとマネジメントの違いは、マネジメントはただの職能でリーダーシップはどの職能でも発揮できるアプローチ

SCQAフォーマット：
Situation（状況）/Complex（複雑化）/Question（疑問）/Answer（回答）で、「現状はこうである→現状がなぜ問題か→問題は一体なにか→最善の答えはこうである」といった論法。コンテキストを最初に合わせるのが良いね。

エンジニア ↔ マネージャーのキャリア論について書かれたブログ、あとで読む：https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/

プロモーションパケット：
自分の能力や功績を会社にアピールするために書く文書らしい。日本にはそういった文化はないけど振り返りにはいいかもね。

インポスター症候群：
Googleのソフトウェアエンジニアリングにも出てきてた

スタッフプラスエンジニアになるという段階の前にスタッフプロダクト（キャリアに影響を及ぼすような重要プロダクト）に携わる必要性があるのではないか？と本書では書かれているのだが、果たしてそうなのだろうか？

Mailchimpの方のインタビューでは一応関わったが、そこまで重要度の高いポジションにいない時に関わっただけ、とあった。
ただし、その携わった経験などは得難いものであるので、そういった意味で前哨戦として関わるのは良いのかもしれない。（自分の力が通用するものなのかどうか？などの見極めとしても

キャリアに影響するかどうかはさておき、社内での信頼の構築といった点では大きな影響を及ぼしそうだなと感じた

Stripeの方は必ずしも必要ではないし、自分はスタッフプロジェクトに近しいプロジェクトで成果を上げることができなかった。
但し、それでも重要な人物であるというアピールはできる。

Mailchimpの方の参考になった資料２つ。これはどちらもアーキテクチャ周りのお話。

Slackの方のインタビューでのスタッフエンジニアの成り方として役立ったアドバイスが非常に正攻法だった。

これらを全て上手くやり切るには運もあるよね、という点も含めて至極真っ当なお話。

"信頼"についてはFastlyの方も言及していた。上の立場になればなるほど、重要な指標ということが分かる。

Squarespace社の方のインタビューの中で「エンジニアリングの成果に貢献（または邪魔）するものなら、技術戦略だろうが文化だろうが何でも引き受けるのが、スタッフプラスエンジニアのおもな責任だと思います。」がかなり責務の説明としてしっくりした。

「組織としてのスケーリングとは地上戦であり、１回限りの空爆ではないのです。多くの時間と忍耐が必要ですが、あなた自身のゴールに到達するためには、目指すゴールとそこへ至る方法の点で、会社全体と歩調を合わせる必要があります。」

ほとんどの人のインタビューに共通することだが、スタッフプラスエンジニアになって「コーディングの時間が減り、コミュニケーションの時間が増えている」という点が面白い。
個人でコーディングをして組織を変えることは出来ないが、他の人と協調して組織を変えることは出来るということの証左である。