Interesting insight. Gives a lot to ponder indeed. Focusing on technical debt alone probably won't improve a project much. It's thus important to take a broader view for long lasting improvements.

Solving paper cuts pay off faster than you'd think.

The complexity and cost in organisations is indeed mostly about coordination. This is a difficult problem and largely unsolved in fact.

This is good advice. Going for something extremely small first is a good way to on board in a new project.

Good questions to consider to gauge how you work. Can improve the organisation if you really get to the bottom of it.

This is very true. It's not like whoever produced bad code is particularly stupid, in most cases it's the context around which breaks the people.

This is something I've definitely seen indeed. There are clearly a threshold effect in the amount of code you have to manage. Solutions working at smaller amounts don't work anymore a couple of order of magnitudes higher, and vice versa.

Or why focusing on the practices will likely lead to cargo cult and you might never reach the real benefits. Don't mimic other organisations, think about the underlying philosophy.

Indeed, I think I prefer what's proposed here rather than READMEs. Having lightweight templates and processes to collect the information you need or steer the direction puts the burden of designing those in the right place (on the manager end). You should also know when things have to be more free form.