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

> -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?"

As a dev (never been a PM), the PMs who impress me are ones who ask enough questions to figure out exactly why something will take a long time to implement, and then negotiate the right surgical change in spec to significantly reduce complexity with a minimal cost in hitting requirements. The customers know their requirements, the devs know how complex they are to implement. The PM can learn both, which puts them in the position to say "What if you just did it this way? It won't hit requirement X, but it will hit requirement Y, which is much more important for this iteration."

Out of interest, why are you switching to project management if you wouldn't mind me asking?

This probably depends on your exact role, but usually there's enough technical role left for devs-come-PMs that keeping your technical skills top-notch is really important. In the end, you are the one to make a lot of decisions that have impact in the future, so better make those decisions as informed as you can. It's easy to get lost in all the new things with new role, so keeping up technology-wise will need work.

You may find yourself naturally gravitating towards thinking in terms of you doing particular tasks, and if you are still maintaining a part-time developer role on the project, the danger exists that you will make yourself a bottle-neck on tasks.

You will have to learn how to delegate. Give people the opportunity to fail. Even if someone doesn't seem like they can do a particular task, give them the chance to learn, and give them the resources to learn.

This goes into always remembering to protect the future of the project. You'll receive tons of pressure to do "quick fixes" and "just brute force it" and other bullshit management lines, a lot more than when you were just a developer. It's your job to be a shield against upper management for the sake of the project. Don't short-change the long-term viability of the project and your team for short-term gains.

Don't forget where you came from! You'll be better at your job if you understand what your subordinates have to deal with on a daily basis.