Ask HN: Switching from developer to project manager. What to keep in mind?

I've never made that switch so I can't give advice on how to PM effectively (that probably is also very team- and project-dependent). But I imagine it might be a challenge to completely leave the engineer mindset behind. So I'd be careful to avoid talking with engineers as if you're still one of them, e.g. discussing technical challenges in depth, suggesting solutions, reviewing code. Stay focused on your new role as PM to avoid any confusion and keep the team humming along. Good luck!

I did the switch. The hard part is leaving your previous shoes behind. While not mandatory you have to choose how to partition your time and set your priorities straight.

Chances are if getting promoted you are good at it, whatever that is, probably better than most your manages. Find someone that thinks in your same patterns and delegate as much technical issues to his guidance, so you will have no surprise if you need to turn your back at the technical aspects while solving budgeting/timing/serivces issues.

Be prepared to say no to improvements, that's a hard thing to do for programmers turned managers. If you have a chance, get a 10% contingency on tasks so you can gift good devs with time to branch out their ideas.

Be sure to rotate menial tasks to prevent burnout, it's easy to pin them always to the less skilled but that does nobody any favor.

Depending on your org structure it may be impossible to be autonomous on budget/spending/allocation, use that to negotiate timing. "I need x to finish in this timeline or need the timeline shifted by y" works most of the time if you're not happy with a given objective, especially if x is controlled from above.

The answer depends a lot on the industry/ product. But in general:

- Communicate, communicate, communicate. Give status updates. Ask for status updates. Get information from customers to your development team. Give updates from your dev. team to your customer.

-Be the voice of the customer. Know if it's more important to be really good or just get the dang thing finished. Let the development team know "we need to cut corners on this one because that's what the customer wants" if that's what needs to happen (of course, don't compromise safety).

-Take care of external roadblocks. Get API info, product specs, pricing, timelines, deadlines, etc... and find a way to effectively give it to the development team.

-Assume your dev team knows best how to build, test, and ship the product, but ask them questions to find out why. Don't be authoritative, but rather put on the attitude of a student. E.g. "I hear you saying we won't be able to ship next week. Why is that? What caused that? Is there anything I could for our next project that would help prevent this from happening?"

-Do project retrospectives.

-Learn the art of minimizing meeting length but maximizing their effectiveness. Communicate, communicate, communicate.

You have to delegate planning/architecture/development always. You can't afford to take deep dives into specific things anymore because you will be in charge of many more disparate tasks.

Every once in a while you can participate in some technical discussions but ultimately now you are responsible for them happening, not necessarily happening with you.

Don't forget where you came from : you're there to help grease the path forward, not to be a new cog for higher management. I've witness the change multiple time, and it lead to very bad pm... and don't forget that you will fail sometimes one or the other parties involved - some dev will be disgruntled, management will be behind you with misunderstanding of the situation. Last thing : learn to communicate, you're more than probably moved because of that !