Well, I've done it. I've developed complete solutions to business problems that the company was trying to solve. I did it without waiting for permission or for my design to be approved, and I did it only after I fully researched and understood the problem space and the future goals of the company. Then I made sure the design took into account all of those future contingencies without being rigorously bound by them, i.e. flexible and not a hindrance when the business goals change in the future -- which they always do. At the most recent company I worked for (a massive corporation) the system is expected to be in production for the next 3 years at a minimum. I did the first 90% of the work in two months, then the other 90% of the work in another month or so. The fourth month was spent primarily on training, documentation, and meetings.

Competence exists. The managers are simply given the authority to squander it or to perceive it as a threat and fire them. I was lucky enough to have a manager who was receptive to me overstepping my bounds as a contractor. I made decisions (such as making Redis a core requirement of my design) before asking permission or waiting for approval. I presented a demo of an early version of it to my manager at the end of my first week, and thankfully he was both surprised and happy about it. (40x improvements to the existing infrastructure tend to elicit that reaction.) But most large corporations, and even many small ones, aren't like that at all. You'd be fired for overstepping your boundaries, whether or not you were capable of making a difference to the bottom line. It's up to the manager, and that is a wholly backwards way of running a modern software corporation.

For software companies, there has got to be a better way than the existing approach. At the very least, the concept of a "manager" should be divided into two people: a manager and a producer. The producer's role is to drive their project's goals. The manager's role is to ensure that the employees are happy and to deal with roadblocks (such as if an employee needs to purchase a third-party tool). The manager has the authority to fire people; the producer does not. The manager's goal is to look after the team, not the project. And neither of them can tell an employee what to do. The employees are given tasks to complete, not steps to complete, and then trusted to complete that task. The employee is trusted not to accept tasks which he/she feels are too ambitious for the producer's timeline. So the producer can only barter with the employees, not demand from them.

I know of a massive videogame company (not Valve) which operates that way, and it's the reason they're currently the industry leader in their genre even though they've grown exponentially as a company over the past four years, both in employee count and customer count. So it absolutely worked for them, and I'm willing to bet that it would work in a lot of software companies. I want to prove that it works.

Maybe I've been lucky, but in nearly a decade of technology work I have never been penalized for 'overstepping my bounds' by improving something important. I think improving important things is within everyone's bounds, tbh.