I worked as a software developer at several startups before moving into PM. In general, I think having professional dev experience has made me a more efficient and effective PM, but there were some things I had to “unlearn” from my dev job in order to become a better PM. Here’s my take on the pros and cons.

The Good Parts:

• You can communicate with engineers “natively” and efficiently. It takes time, effort, and practice for engineers to effectively translate technical concepts into terms that a non-technical PM can understand. If an engineer can take communication shortcuts by explaining a technical problem in technical terms, it makes communication faster and avoids mistakes. For example, instead of writing a two-paragraph explanation of a bug, an engineer can paste a code sample into JIRA and you can usually understand the problem.
• You have more realistic expectations. If you’ve worked as an engineer, you’ll likely have better instincts and fewer illusions about which technical problems are hard and which are not. In particular, you’ll be more alert than a non-technical PM would be to problems that seem like they should be easy (e.g. improving performance/scalability, localizing software, dealing with time and time zones, ensuring security) that are often really hard problems.
• You ask better questions and have better ideas to reduce cost/risk. Because you have a better idea of how software works “under the hood”, it’s easier for you to partner with your engineering team to figure out better, cheaper, faster, and/or safer ways to solve business requirements. I’ve found that non-technical PMs often think of requirements as fixed, atomic things, whereas more technical PMs can more easily get creative about how to tweak requirements to shave time, reduce risk, etc. without hurting the business value very much.
• You respect engineers and they respect you. Too many non-technical PMs don’t have enough respect for how hard it is to write maintainable, high-performing, (mostly) bug-free code— especially if some distracting PM is always bothering them. As an ex-engineer you know instinctively how engineers want to be treated. This usually leads to solid, mutually-trusting relationships where everyone likes working together… at least most of the time!
• You’re less vulnerable to BS. With a technical background, it’s easier to spot bad technical arguments before they become bad technical decisions. For example, if a developer’s estimate comes in much cheaper than expected, I will usually follow up to make sure that the developer really understands the scope of the problem. A less-technical PM might only discover the problem at the end of the sprint!
• You write better user stories / specs / requirements. Because you understand the level of detail necessary for developers to implement a feature successfully, you can provide clearer directions for engineers, without wasting their time with irrelevant detail and without hand-waving over blocking issues that need to be resolved before implementation.
• You recognize the importance of paying down technical debt. PMs with development experience seem to be better at supporting engineering teams in work on refactoring, security, performance, and other things that salespeople and executives tend to not consider important until it’s too late.
• You can read code to understand bugs and features better. I’ve found that one of the biggest benefits to having developer experience is that I can quickly understand some product bugs or unusual product behavior by looking at the underlying code. This makes it easier to write better bug reports and minimizes the number of times I need to waste a developer’s time by asking “why does it do this?”. Some parts of the code are too complicated for me to figure out without wasting hours—and as a PM it’s not your job to spend hours looking at code!—but for basic front-end bugs the ability to understand code is a big time-saver.
• You can help. As a PM you should *NOT* be checking in production code. But you can still use your technical skills to help the team. You can find bugs and file good bug reports with clear repro steps. You can build simple working prototypes to illustrate how a new feature is expected to work, when other non-technical PMs can only build wireframes. You can test for SQL injection or other attacks that wouldn’t occur to a non-technical user. If it’s a developer-facing product, you can write sample code or documentation. And so on. Just don’t get tempted to touch the production code. That’s not your job anymore.

Some challenges: (and suggestions for how to deal with them)

• You need to care much more about the business and the customer, and much less about the technology. As a software engineer your main focus was delivering well-built code and solid technical architecture. As a PM, good code built on the right stack is an implementation detail of your new job. Your primary focus needs to be on what features you’re going to deliver, how those features are going to help your company make money, and how to ensure that those features actually get shipped. Everything else is the primary responsibility of someone else—and to be an effective PM you can’t afford to spend time thinking or caring about most of the things you did as an engineer.
• You’re not an engineer anymore. Get over it. As a PM your job is to define what features to build and how those features should behave, but NOT how those features should be implemented. This can be a difficult transition for engineers who are used to end-to-end responsibility. The more you keep your nose out of the developers’ world of code and architecture, the easier it will be for them and you. A good rule of thumb is to limit your direction to developers to things that users can see (including internal users like Ops and Support). Topics like architecture, coding standards, which libraries and components to use, etc. are not really appropriate for PMs to be deciding or even having a strong opinion about.
• Accept that your technical skills may not be relevant. Technology moves *very* fast. Your circa-2010 mastery of jQuery, Spring, and PL/SQL isn’t directly relevant to your team’s React/Node/MongoDB stack. Of course the general principles of software development don’t change, but you’ll need to accept that your tactical technical skills have a short shelf-life.
• Don’t act like a Lead Engineer. If you were a senior engineer before switching to PM, most of the engineers you’ll be working with will have less experience than you. They will make sloppy mistakes. The performance of their code will sometimes be horrible. They will have bad technical instincts. They will pick libraries or stacks that you wouldn’t have. And so on. You’ll be tempted to jump in with your technical opinions. Don’t do it! You’ll need to resist the urge to get involved with these technical decisions. Those junior engineers have a manager… and it’s not you! Talk with their manager if you have a problem with a technical decision, and let the manager sort it out. And be prepared for the answer being one you don’t like.
• Interact at a higher level with developers. Instead of weighing in on code, you’ll need to start thinking of the product as a black box. Your primary way of influencing it is via specs/user-stories before code is written, meetings/standups/chats during development, and bug reports afterwards. When you know exactly how to solve a problem, it can be frustrating not to be able to check out the code, fix the problem, and send a pull request. But then you’ll be responsible for editing unit tests, fixing more bugs that your fix creates, etc. That’s not your job anymore. Save it for the engineers. They need to learn and you need to do your real job.
• You’re (sometimes) the enemy. Remember when you were an engineer and “Marketing” said you had to do some dumb thing? Well, you’re Marketing now. Even though your technical background makes it easier to work with engineers, you’re still in a different role which requires you to care much more about the needs of customers and the business, and much less about the codebase. You’ll need to push engineers to do things that they won’t be happy about, and even though you recognize the value of paying down technical debt, sometimes you’ll need to push the team to hack together a solution so that the company can land a big deal.

In summary, having a technical background is very helpful for PMs, but it’s really important to remember that it’s a technical “background”, meaning something in the past, not your current job! Your new role is not about code and not about implementation, but is instead about defining what features to build and then ensuring that they do get built. How they get built is not your problem anymore. The more you focus on your new role and not your old one, the more successful you’ll be.