私がチームと最もよく交わす議論は、組織の大きさについてです。より正確には「我々には来年、2 倍 / 3 倍 / 4 倍のエンジニアリングチームが必要になり、今、その経験を持つリーダーを雇わねばならない」というような議論になるのです。そしてその議論をうまく進めるためには、組織の規模に関する理論が必要です。
チームを成長(grow)させるためにはチームを大きく(grow)しないこと、これは明らかです。チームを大きくすることはむしろ、他の差し迫った問題を解決するためのツールです。実際には、多様な課題に直面している何百人ものエンジアリングリーダーや CEO との会話において、「我々には十分なエンジニアがいない（適切なエンジニアがいない）」という結論には、全世界的なカバレッジがあります。そして私の記録によると、ほとんどのチームは採用に十分な時間を使わず(原題 "FAQs from Coaching Technical Leadership")この頭数のパーセンテージ（または乗数）としてのチーム成長モデルは致命的な欠陥をはらんでいます。
雇用はしばしば、プロダクトを構築・運用するときに発生する、いくつかの高ぶる緊張の解決策として提案されます。十分ではない？もっと人を雇います。バグが多い？バグ回収のために人を雇います。安定性に問題が？シニア/インフラ/SRE/バックエンドの人を雇います。技術的負債が重要な仕事を遅らせる？コアチームが負債を返しているあいだの開発をするために、新しいチームを雇います。成長の鈍化？成長のためのチームを雇います。各々が優先順序に妥協しなくて良いのが、このモデルの素晴らしい点です。欠点は、機能しないことです。