Understanding the types of things that prevent programmers from completing their duties is the core of PM. That can be resources/access, requirements understanding, scheduling, productivity, etc. It's most helpful if you can achieve a deep understanding of the business objectives while understanding technical capabilities and limitations. Most programmers are required to do that anyhow, but it's especially important in PM because you'll be one of the earliest people on the tech side to influence new projects.
For example:
- If you're going to do an API integration in the coming days/weeks, make sure you provide an account with access, documentation, and consider reading the docs yourself to look for blockers. Don't focus too much on the implementation or architecture, focus on the business goals.
- If you're going to make a modification or new addition as the result of a new business requirement, make sure you are intimately familiar with the business domain and how the problem applies. It's important for the PM to understand what the business actually wants, not simply what they say they want.
- Minimize task switching by maintaining a clear strategy with the business side. When you hand off a task to a programmer the task should be in such a prepared state that nothing further can be accomplished without writing code. If business has an "emergency" that isn't, urge them to hold off until the current development task is completed.
- Build relationships. You want to be close to business and close to dev. I would often talk to developers about their day, off-work activities, family events, etc. They were more than happy to discuss their hobbies for a few minutes, I feel like it's time much better spent than group meetings and it gives them reprieve from work. Get to know them, having that connection is great for them when they can openly make requests and likewise for you. Sometimes they need vacation on short notice. Sometimes you have legitimate emergency tasks and need to ask a little extra of them. Having a real relationship to fall back upon is tremendously helpful, just be sure to reciprocate.
As a PM you can advocate for engineers and protect them from waste like excessive meetings and ensure they have everything they need to do their job. You're in a position to suggest raises, hardware upgrades, etc. Sometimes you have to fight for what they need.
You can practice many of these things before being a PM. Some of them are better left for your first opportunity managing a project. Where that line is drawn depends on the specifics of your circumstances. I was promoted to management fast after making recommendations which dramatically increased revenue, which doesn't seem like a bad way to make yourself more visible. Solve business challenges or provide new revenue streams if you're extra ambitious. If you want to manage, show initiative.
It's also worth considering you might not be happy as a PM. No longer coding, it was easy for me to feel like I never got anything done. Entering tasks/todos/bugs, talking with the business side, and writing emails doesn't feel productive after programming. Being ready for that possible eventuality is my best advice.