Did this myself. Remember: You know too much. Make this an advantage, but don't become a part-time dev manager.<p>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.<p>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.<p>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.<p>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.<p>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).<p>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.