I've experimented with a two-crew type system before (Red Team for feature development, Blue Team for stability and bug fixes).
Rather than treating these as fixed teams, we treated them as workstreams that people rotated between every sprint (every two weeks).
It worked for about 3 months, until it didn't - by then we had grown enough to organising the teams around the business capabilities or domains instead.
Here we go again. The golden rule I've come to realise is that people don't like what they don't understand. It's made very clear this person doesn't like methodologies.
I don't get the use of midwit meme here. Either you're implying that you're preaching the the choir, in which case it's just an echo chamber, or you're calling your audience idiots. Neither outcome is great.
There's always a balance. Being overly orthodox about methodology is suboptimal, yet equally, having no guard rails when people need them is equally as bad. Going around expecting everyone to work exactly how you work is not the reality and tends to lead you down one path.
I don’t think this is exactly what it means, but I recommend if you want some quiet in a busy city, go into a library or a book store. Typically they are quiet and calm places, offering a break from the sensory overload that is a city.
Historically software engineering was part of the IT function, which historically was born out of accounting, a computer literally was someone’s job, before a machine could do it.
Today, for many businesses accounts is still the main driver behind software, and also the budget.