A major part of the art of the handwavey term "good" management at the technical-line-level-and-middle-management stage is exactly in that area of "selling the rest of the business on why this will take longer than it sounds" and "protecting the team's time to work on what the team needs to work on to continue to be able to deliver stuff fast."
Good management means the team can keep working fast. Bad management means that three-to-five years later, someone has to come in and really put their foot down and say "if you want simple features to stop taking six months we have to take the time now." But to be able to sell that message outside the tech team at that point, you sorta have to be an external "fixer" - IME, it's hard to sell your own ability to clean up the mess if you're seen as part of who created it, sadly.
Figuring out the difference between a place with good management and bad management if you're interviewing there can be tricky - but if they don't have tests, etc, and also can't tell you their plan to add them / why they're adding them now, that's probably a bad sign. Or ask them what they've shipped recently and how long it took - maybe easier to look for the symptoms than for specific process failings, since those could be wildly varied.
EDIT: I love working in flat structures where the total relevant number of people to what I'm working on is under 15. Either a small startup or a truly independent sub-unit. But there are few worse environments than a flat structure where 30+ people feel like they should have a say in a given feature.
Then they are useless. Send us the boss directly, will save a layer of communication.
Problem is the boss wants a unique interlocutor, and one who says yes. Then if he is friendly enough, engineers will prefer to do a shitty job (rush "features" and even more bugs) rather than inconvenience their manager who already committed on behalf of the whole team.
Or they just want to cut out unnecessary layers. You don't really want an extra level between the group demanding the features and the group implementing them.
Feedback about technical feasibility, time to implement et cetera really needs to go directly to the group demanding the feature, and their responses need to come directly back to the group implementing it. A competent middle man can help those two groups interact, but generally adding an extra middle layer reduces everybody's ability to function well.
