技術レベルのボトムラインが低く、それなりの雰囲気が組織のスタンダードになっていると、自ずとソフトウェアの品質傾向もそれなりのものになる。いくらコードレビューだとか設計レビューで誰かが警察的な予防をするにしても、人力でやっている以上そこには限界がある。誰かが部分的に品質を上げようと思っても、その他大部分は雑なわけで「別に品質に拘んなくてもよくない？」となってしまう人の気持ちはすごくよく分かる。人間誰しも、周りがやらなくて済んでいることは自分もやりたくない。
組織の中でこの振れ幅が大きくなると、不要なルールやドキュメンテーション、いろんなレベル感に配慮した一貫性のないコードやコミュニケーションが生まれてくる。いや、もちろんドキュメントやその他諸々のアグリーメントは多かれ少なかれ必要になるが、少なく回るならそれに越したことはない。早い段階でこの手の問題を予防するには、やはり一番には採用プロセスでのクオリティー担保だし、そのベースにあるのが組織のカルチャー醸成だったりするのではないかと個人的には解釈している。
個人的な体感として、そのへんの求人サイトに転がっているWeb系のシニアレベルのエンジニアの大半においては、深ぼってみると実はソフトウェア設計やコーディングのスキルはもはや評価の対象にならないもの（というか、あって当たり前）であり、どちらかというと先に書いたような組織の技術レベルのブレ幅をいかに小さくするか、複雑性に耐えられる下限値をいかに上げていくかを考えてリーダーシップをとることのほうが、公にはしないが最終的には求められがちな能力な気がしている。
とはいえ、ここまでカバー範囲が広がってくると、そもそもそれはソフトウェア・エンジニアとしての職務に含まれるのか？という気もしてくるので難しい。コードだけ書きたいという人もいるだろうし。また、こういう仕事を誰がメインでやるべきかというのもよく分かっていない。テックリード、エンジニアリングマネージャ、VPoEらへんの誰かっぽいのは分かるが、具体的な細かい技術的な話からふわっとした抽象度の高い組織の雰囲気作り的なものまで、求められるレイヤが広そうではある。