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

Did this myself. Remember: You know too much. Make this an advantage, but don't become a part-time dev manager.

You know the nitty-gritty and every detail of how a piece of software is made. Use this to your advantage to make developers you work with feel safe. You've been in their shoes before, you aren't going to change requirements last minute. You aren't going to come to them with an incomplete spec and demand unrealistic outcomes. When your bosses are setting the stage for disaster, you're going to fix it at their level before your dev team even hears about it.

However, don't fall into the trap of discrediting what the developers you work with are saying or doing, because you have the experience or know more than them. Be humble, and believe in your team. Gain their trust, and make sure they know they can come to you with their problems, mistakes, and questions early. They'll warn you when something is going wrong before anyone else even notices it (instead of keeping quiet and going along with a bad idea). They'll tell you the real reasons why they're pushing back, while they give other PMs excuses they think are more likely to get them what they need to succeed.

Your primary job is no longer product or productivity or even shipping. Your job is to get the best work out of the people you work with (even the people you work for, not just those you manage). Most of the time, the problems you fix are communication problems. Most of the time, everyone means well but doesn't realize when and how they're shooting themselves in the foot.

Momentum is everything. Don't let anyone place anything above your team's momentum. Become a firewall between criticism and productivity. Internalize critical feedback, but be careful about when and how you bring it to your developers. Sure, there may be rough edges on your product, but every time you tell your guys they're screwing up, you're sacrificing project momentum. Finish a rough draft of your product, celebrate the victory you've earned (now it's 80% complete), and motivate everyone to polish off the rough edges after thanking them for their hard work.

It's your job to celebrate every minor victory and be “that guy” (or gal) that emails the entire company to show off something a member of your team did. Not to make yourself look good, but to motivate that person to give a damn the next time doing the right thing means working hard (when nobody is going to notice).

Also, don't write any code and don't do code reviews. Keep your skills sharp by building MVPs, doing technical research, exploring APIs while the spec is being written, etc. Don't step on your team's toes by micromanaging & nitpicking with their code.

It might be that you're better at the management side of things. But don't be tempted just by "grass is greener" thinking: Try to imagine that every job could be hard, that you jump in, discover you don't know what you're doing and you're under a lot of pressure to find a solution, to take action and write documents and schedule meetings and send emails. Will you be motivated to struggle and prevail? More motivated than your worst days in previous jobs? If your response to that is "bring it on," then the shift will be good.

I'm conflicted, because both of these statements are true.

People are going to come to you with unrealistic requirements. This can't be a discussion- you have to say “No, there's no way my team can pull that off, we need to fix this”, and you have to have the relationship and credibility for them to believe you, trust you, and know they can work with you to come up with a solution. That's ambiguously like being a peer that also has the authority or respect to have the final say.

At the same time, you'll find out that every new project starts with the same response from your best developers: “No, I don't think we can do that”. 99% of the time, there's some ambiguous requirement making them apprehensive at a totally reasonable request. You have to have the relationship to firmly say “I'm willing to put in the hard work to figure this out with you”. You should have the credibility that they will have some kind of faith that you can better scope requirements in a way that alleviates their concerns.

Don't forget that any position that deals directly with clients also takes the brunt of their wrath if they're unhappy. As a non-dev in a SaaS company, I was the primary point of contact for a number of clients and if anything went wrong, I was the first person to hear about it. Clients are not usually pleasant when something is broken or if their project is running late.

My advice is to not underestimate the toll that can take on you. Trying to convey the importance of a specific item for a client to a developer is difficult, too, particularly if the dev is already pretty busy.

I think you have correctly identified a class of decisions in which PM's should have the final say:

ie. "What should the team be working on now"

But equally there are a class of decisions in which developers ought to have the final say:

"how should we implement this" and sometimes "which technology should we use"

I think peer is about right. With an important caveat, that PMs are often ALSO people managers. But that role is separate.