I'm writing a book called The Engineering Tax, and it's about a cost most software companies pay without ever seeing it on a spreadsheet.
It's the cost of every cross-team dependency, every "quick sync" that wasn't quick, every feature that took twice as long to ship as it did six months ago for no obvious reason. After product market fit, that cost starts compounding in the architecture, in the org chart, and in the burn rate, and almost nobody has a name for it.
The book walks through the full cost, from architecture decisions that create it, to org charts that hide it, to the meeting culture that grows around it. It covers when to restructure, when to hold off, how to put a dollar number on the problem so the board will fund the cleanup, and how to actually remove things from a running system without breaking what works.
I'm not done writing it yet. But the waitlist is open, and there's a free article from the first chapter if you want to see what I mean by all this.
To find out more about the book, have a look here: https://beamersoftware.com/the-engineering-tax/