1) Why are you wrangling with project management systems? The amount of time you spend with that should be minimal, otherwise it's hurting you. Are you trying to update all the features to the next sprint or something? That's a waste of time, don't do it.
Large companies often require multiple levels of approvals, often from teams in multiple time zones, before you can even get on with the business of coding. A couple years back I had a project where getting the approval took 6 weeks, and the code took one day (yes, I left that company not long after).
2) If you need to 'translate user requirements from PMs' on a regular basis, it sounds like you are micro-managing a part of the process. If that's the case, then you can gain efficiencies by teaching your developers to do that. Push as many responsibilities down to the developers as you can, and watch how much more focused, effective, and efficient they become
Indeed. But junior developers, almost by definition, aren't good at this. Most large software actually corps have this firmly in their interview process: give the candidate ambiguous requirements, and see whether he asks clarifying questions or just jumps in and codes some arbitrary take on the problem. It's a good way to assess the senior-ness of a candidate.
Practically, "how big of a design/project can you own" is the best measure of a developer. A senior dev drags projects across the finish line despite all the obstacles created by the company being stupid. A junior dev can follow clear requirements, but gets stuck and needs help at every ambiguity (or worse, doesn't get stuck and just solves some arbitrary problem).
And I'm certainly not a manager. Tried that once - my ability to anticipate people problems before they happened were sorely lacking. But managers should be focused on the people first, and the technology only enough to tell when a developer is BSing (or just wrong) about the difficulty of some task. Making decisions about how to staff competing projects so that the best work gets done, morale stays high, and devs grow their skill set - that's hard work. Preventing personality clashes, recruiting, firing people who aren't making the cut, that's all hard work. That why there are senior devs - to provide technical leadership so that the managers can get on with the people leadership.