That's great advice. An experience with a director overruling his engineering staff is one reason I no longer work for him.
As a leader, your most valuable asset is context: big-picture strategy, business priorities, and the like. If you're in an interaction where you find you're not utilizing that asset, you probably should back off and let your reports do their jobs (unless you're mediating a dispute, but even there you should help people work together better—not just pick a side).
What you should be doing is focusing on making sure the decision making process is working well and that you are all learning from issues. If you have an idea you think is better, by all means hand that off to the team. But you have to let them decide against it (so long as they can articulate why). Absent strong empirical evidence that the path is wrong, you go with their choice and discuss how to validate it.
In all cases except team incompetence you are better off this way in the long run. And if the team is incompetent, you have bigger problems.
This tendency is very common, and it results in the Peter principle: https://en.wikipedia.org/wiki/Peter_principle
This is impacting the team b/c he takes away lower level decision making responsibility, while not spending the time he needs to spend planning out and setting top level vision.
1) Ask him for his deliverables to you frequently. If he's a program manager, presumably part of his job is to fill you in on context and the goings on outside of your group. Ask him for those regularly. Ask him to present the planning and top level vision.
2) Be direct and tell him what you just wrote -- that you expect him to delegate and trust and not dictate now that he's been promoted.
Every manager has different ways to lead, every person has different behaviors that make them more or less likely to follow someone who is leading. The whole team needs to work out the right dynamic and be truthful with each other and managers need to be truthful with their employees as well as with themselves.
It may turn out like it often does, great developers who understand the product and project inside out don't automatically make them great managers
You likely also got very good at your job just by doing it A LOT. Give that person the benefit of the doubt and some time to grow into the role. Just like you will have to for your new role.
Related, if you can see a better way to do it, strongly consider keeping your mouth shut if that way is only 5% better. If you improve the project by a few percent and sap your report's motivation and confidence by 50%, you're probably not making things better for your company. Save your insights for times where you think your way is 50+% better.
In short, if you are overwhelmed, make sure you're doing your executive job. If you're not, consider still spending more time on reading and thinking rather than defaulting to pitching in on a project deliverable if it isn't written in English prose (feel free to work on a project high level summary, objectives, and key results document).