I think the environment you describe is somewhat old-fashioned and is not aging well. Much of the reason that software engineering gets a bad rap is because the incentives are not aligned in a way that promotes good design, implementation, and maintenance practices, leading to low-quality software. Divorcing developers from solution ownership is exactly the kind of thing which promotes complacency, malaise, and bit rot. Writing code is not, in fact the "fun part" of being a software engineer. Solving problems is the fun part, and writing the code should be mostly mechanical, except for the most junior developers who are still learning the finer points of their programming language.
I dare say that Google, Amazon, Facebook, Apple, and Netflix (the FAANG club) are based on the West Coast of the USA because this region strongly tends towards a more modern approach to software engineering, which is to drive ownership of solutions as far down the org chart as possible. Amazon, in particular, is famous for its "two-pizza teams". It might seem that it's a statement on team size, but it is not. The 2PT literally owns all the code it writes, and rarely has more than one or two senior developers. Architects do not dictate the design of new projects in detail. Rather, they coordinate design across teams, collaborating with engineers to come up with solutions created iteratively, rather than dictated in a more traditional waterfall-style approach. Or, they work on framework projects to be consumed by other teams at the teams' discretion. Junior engineers learn how to design software very quickly, because they are expected to do so, at various scales, from day 1. Which is also why they get pager duty and woken up at 3 AM if there's an outage: they own the design, they own the code, they own the bugs, they own the fix. The feedback loop is tight, and the results are indisputable.
For software which is hosted by the client rather than the provider, this feedback loop does not need to be so tight. Low-stakes software allows much greater freedom in the process to do less-efficient things. But creating solutions at the top and pushing them down the entire org chart is causing push-back for a very simple reason: it's a bad process. Your junior engineers are new and inexperienced, yes. But they also have the benefit of hindsight, of learning from instructors and an environment that has a wealth of experience that simply didn't exist when you were their age. You would do well to take their feedback to heart and push your company to adopt more modern engineering practices, starting with a more collaborative design process.
This will require quite a bit of humility from you, especially if you find out that your juniors are much smarter than you give them credit for. But an easy way to start is to just invite some of them to design brainstorming meetings. Invite them from all levels of developers. Present them the requirements you gathered, and ask: "How should we solve this?" Let them freewheel a bit, challenge them with insightful questions to show flaws in their proposed solutions, and see if you can't get them to craft the same design you would have on your own...or better yet, a superior design. Farm out parts of the specification to them, acting as the editor and reviewer, but also let them review each other.
The entire process should be very educational, and any half-competent management chain would see that you are improving the skill set of the entire team on a level that simply didn't occur before. On the other hand, by removing them from the loop, the entire middle management chain will also fight you tooth and nail, because you are eroding their clout and value add. They are the "people who take things from this desk and walk down the hall and put them on that desk." Taking away this perceived value-add will be politically threatening to them, whether it adds value to the company or not.
So, this process is political suicide if you don't already have the political capital to fend off all challengers. But if you can convince your boss that it's a good idea, and ask them to support you while you demonstrate the superior results, then it should be feasible to pull off anyway. If your boss is also politically weak, then it could simply get you run out of the company or relegated to "truck maintenance", as an old boss of mine used to call it. Just giving you fair warning that tipping the apple cart like this is not without dangers, no matter how beneficial it may be to your company's bottom line.
[EDIT]
I feel that I ended on an overly pessimistic note, so allow me to add a strategy for making this succeed, no matter how much political capital you have amassed at your company. The key, of course, is to make allies of the people who most benefit, and to include the ones who are most threatened. So explain to the more junior engineers (including the seniors who are right below you) that this experiment is a politically risky move, and that they need to voice their support for it in meetings with their managers. If you must, hold design meetings first, without consulting any other managers, so as to leverage the element of surprise. Better to ask forgiveness than permission. If you run the meetings well, it will energize the coder base and make them excited about change. This will incentivize them to go to bat for you.
You should also scout out the managers that are more forward-thinking and who might make natural allies in this process. Invite them to the design meetings too, and make it clear that it's a round table with no hierarchy, and everyone is an equally valued contributor. Ideally, the managers themselves have more engineering experience (and if they don't, because they are pure people managers selected for non-technical skills, that is a whole other ball of wax to contend with, and outside the scope of this question) and can also add valuable insights and guidance, demonstrating their technical chops and helping to firm up their technical authority.
When other architects or interested parties come to you and ask what you're doing and why you are doing it, just calmly and politely explain that you think you will get better fidelity on the results if the engineers who build the system participate in its design. It will also allow you to be more concise with the design docs and specs, saving everyone time and money and allowing you to tighten up some deadlines. And if you hold a few successful meetings, you can challenge them to go talk to the engineers themselves, get their perspective, and ask if there is any change in morale. Ideally, the results will speak for themselves, and loudly.
If you succeed in making this first step, then you can introduce modern Agile practices as mentioned in other answers, and hopefully, your management org will eventually wise up and maybe bring in a coach to help the company get up to speed on more modern practices. It doesn't matter if you follow Scrum or Kanban, Kaizen or some other system. You just need to design small, start building early, and iterate heavily. It sounds like your junior engineers will push the ball very, very hard on their own if you manage to just get it rolling. Good luck!
