Your focus on "process" is missing the deeper truth: companies don't slow down because some busybody managers put in processes, it's because as organizations (a

Your focus on "process" is missing the deeper truth: companies don't slow down because some busybody managers put in processes, it's because as organizations (and codebases) grow, they become more complex and more difficult to change. It's not a question of preventing formal processes, doing that indiscriminately is a recipe for disaster; every engineer will do things their own way, and once the head count exceeds the ability for everyone to talk to each other daily, there will be an explosion in complexity and duplicated effort. Rather, you need to put in the right processes, maintain them just as you would code, and kill them when they no longer serve the company. Where "process" goes wrong is when it's used as a hammer to address issues that would be better served by team structure, common tooling or architecture. For instance, if you have a quality issue, adding more code reviews will generally cost a lot more, and do a worse job than making the responsible team wear the pager for their own code. The real secret sauce to staying agile as a company grows is small, cross-functional teams. This is where SOA (microservices for the kiddies) really pays for its overhead—by decoupling human teams and giving them agency. This won't make a big company as agile as a startup, because that's literally impossible, but Amazon and Facebook have shown how much more agile it can make you than any prior megacorp.