I'd argue that being accountable for technical decisions, and losing touch with the codebase and your own technical skills, is just plain dangerous.
All of the greatest managers that I've reported to were able to (1) call "bullshit" when work was subpar, and (2) drop in, right down to the codebase, when it was clear that something was at risk. This whole culture of "accepting that different people will do things in different ways, so you should let go of your will to stay close to the tech/PRs" just seems overly sensitive to the elephant in the room: manage your time better, so that you can stay technically relevant.
How are you supposed to be accountable for technical deliveries, if you've got no expertise in the field and the codebase? How can you break up your vision into a set of executable subtasks, if you have not the faintest idea where one subtask should start and the other should end? And therefore, how can you enable your team to deliver on your or the organisation's vision? How do you come up with even remotely plausible timelines? Of course you need the people-centric managerial skills too, else, nobody is going to be motivated to work under you and help you execute. But, the key is, the people under you need to respect your technical skills as well as your empathy and managerial skills.
I'm concerned that the perpetuation of this trope of "you're _encouraged_ to lose your technical acumen as an engineering manager, it's OK!" is going to result in MORE of a common failure I've observed: the non-technical pure manager. They were recognised for good people skills amidst a sea of purely introverted coders, and are now tasked with managing junior to mid-level developers. They jumped on it, because writing code was always something they struggled with, and management is "prestigious".
This is a recipe for disaster. Unrealistic promises made to stakeholders. Deadlines inevitably get pushed down to the developers. And of course, these managers will (a) NOT be capable of noticing broken windows in the codebase or delivery/CI processes, and (b) NOT be able to suggest pathways out of them. So guess what happens? Shortcuts are taken. The codebase suffers more. The shortcuts are then relied upon for critical functionality, and you can't unwind them easily. Oh joy.
So there's the "engineering manager", who maybe was good at coding at some point, but has since "needed" to lose their edge. Hopefully they have a good tech to delegate most of the major decisions to. There's the "IC", who is still busily coding...
...But there's a 3rd path here that's not often mentioned: the "scout/squad leader" team lead. It's a great blend of hands-on work, leadership and management. You're, at most, one level up from the actual developers. You're the person in the squad that runs first, not the Army General shouting orders over intercom.
You're management. You're also IC (for non-critical path items!). You'll use your experience to explore the terrain before your comrades. You'll know when you need to scaffold prototypes, and even suggest initial stubs and interfaces for your team to implement. You'll also know when this is in good hands, and can stand back. You'll be able to offer meaningful advice to unblock your team, beyond "just pair with Jill, she's done this before, I'll make sure she's free". The point is: you _can_ drop in when you need to, if "Jill" isn't free and is doing something super-important. You'll know exactly where the gaps in the team are, and therefore who to hire.
You've seen the pitfalls before. You've seen what a good engineering process looks like. You'll be able to come up with target state for technical problems, but (unlike your pure-IC friends), you'll have both the influence and the necessary skills to break that down into sub-tasks that can be _executed by a team_. You are where you are because you have (1) good technical skills, (2) good people and comms skills, and (3) at some point in your career, realised that your visions cannot be executed in a timely manner by a single individual.
Your time management needs to be bulletproof. If your schedule is fully booked with meetings, (i.e. you've got 7 hours of meetings booked in an 8 hour day), then that's on you. Personally, if I have more than a few hours of meetings booked a day, I am re-scheduling, rejecting, or suggesting alternate times. I owe it to the other members of that meeting to give it my 100%. Also, every time I make a commitment to either myself or someone else, I'm blocking out time in my diary to actually _make through on that commitment_ (whether its "Review John's latest PR" or "Pre-refine tickets for next sprint"). This (1) makes it look like my diary is fully booked (like a "good manager" is supposed to have), and (2) makes it clear if it's a realistic commitment (so I can manage expectations), and (3) makes it clear to me what will slip if I have to accept some "bullshit" meeting, so I can manage expectations accordingly.
All of this can be learnt, and it doesn't blunt your coding skills. I just don't buy this "Engineering Manager or IC - choose your adventure!" myth that our industry seems to perpetuate.