An engineering background can hold you back in your PM career

I am often asked whether an engineering background is necessary to be a successful PM. The short answer is “No, it is not necessary”. Some of the strongest PMs I have worked with and learned from did not have engineering backgrounds. Indeed, a technical background can even be a disadvantage in several ways that I will talk about later in this post.

Growing up, I always thought I would be a software engineer. I first learned to program computers in the BASIC programming language on a ZX Sinclair Spectrum +3. In middle school and high school, I learned C++ and assembly language because I developed a love for high performance graphics programming. For the first few years of my career, I was a software engineer working on operating systems and cloud computing platforms. I loved my job, but felt that there were many aspects of the business that I didn’t understand. I figured that business school would be a good way to expand my perspective. During bschool, I interned in strategy consulting and venture capital. Unfortunately, those career paths did not resonate with me. I wanted to be in a role in which I could drive the vision & strategy for a tech company. I realized that product management is the discipline at many technology companies that is responsible for the vision and strategy. After business school, I was lucky to get a job at Google as a PM. Given my background as a deeply technical engineer, I figured this would be an easy transition. After all, engineers do all the “real” work right?

How wrong I was! While my technical skills were certainly an asset during my first few years as a PM, they took a backseat later in my career. In some cases, my technical skills even became a hindrance to my growth. I had to consciously and intentionally work hard to break through mental blocks that were a consequence of my engineering background but were holding me back in my PM career.

Ways in which an engineering background can help

There are certainly roles and situations in which an engineering background can help a PM. Some of these are listed below.

1. Roles in very technical areas. A very small set of roles may benefit from PMs with in-depth technical expertise. My first PM gig was to build “Virtual Reality Mode” in Android N. This required me to work closely with Google’s Android team, deeply understand high performance graphics rendering, low level operating system features, and so on. I was able to hit the ground running and deliver successful outcomes, despite being an inexperienced PM because I knew the space very well. My background as a former OS engineer and a computer graphics geek since childhood made up for my lack of PM chops.
   
2. Build credibility with engineering. PMs with technical backgrounds may find it easier to rapidly build rapport and credibility with their engineering counterparts. I’ve benefited from this in a number of roles. At the same time, this can be a double edged sword as I’ll discuss below.
   
3. Engineering skillsets transfer. I’ve found that the structured and logical thinking skills of software engineering transfers well to product management (and to management consulting, as it turns out). Designing a compact data structure, writing tight performant code, or sketching out the architecture for a large software or hardware system utilizes similar cognitive skills as developing a succinct, logical, and well-structured product thesis or a MECE business strategy analysis.
   
4. Ambitious but achievable technical goals. Technical PMs can often push engineering teams just the right amount beyond what the eng team thinks is “possible”. This is because the technical PM understands the engineering stack just as well as the engineering team, but is able to “pop up the stack” and reason from first principles because they are not as close to the code. This also has a flip side discussed below.

Ways in which an engineering background can hurt

That said, I’ve also hit speed bumps and mental blocks as a result of being a technical PM. Some of these are listed below but this is by no means exhaustive.

1. The pseudo-engineer. The easiest trap to fall into is a temptation to become a “pseudo-engineer”. A technical PM working in a technical area can find it difficult to add unique and differentiated value to the team. Instead of thinking about product strategy, user needs, and use cases, you start thinking about technical features and solutions. During my early years as a PM, I was working closely and productively with an engineering manager, let’s call him “John”. In one performance review, I got feedback that I was at risk of becoming a “John Lite”. The engineering manager brings a certain set of skills to an organization. If the Product Manager is bringing a subset of those same skills, then the PM is not doing their job. The PM should complement the engineering manager, not be the “Lite” version of the engineering manager.
   
2. Self-censoring. Some technical PMs are unable to exercise #4 above, and self-censor or agree to all the constraints given by the engineering team. I’ve fallen into this trap as well. A great PM can and should push their engineering teams to achieve goals beyond what the engineers believe to be possible. This is how teams accomplish great things. However, because I have a deep understanding of operating systems and computer graphics, I’ve sometimes fallen into the same trap as my engineering teams, censored my own crazy and far out ideas, and not pushed for sufficiently ambitious goals.
   
3. PMs need to have product and strategic credibility. This is the flip side of #2 in the pros list. A great engineering leader should hold their PM accountable for thinking deeply about the strategy, user needs, and use cases, not for the PM’s technical chops. Sure, it might be fun to chat about the new features in C++20 or debate the pros and cons of microkernels, but those are not the value add of the PM.
   
4. Overly enamored by the tech. Finally, in my personal experience, PMs without technical backgrounds can be better at empathizing with the user and building creative solutions. One of the strongest PMs I have ever worked with was in the music industry prior to becoming a PM. This person repeatedly built amazing and magical consumer software products that appealed to mainstream users. Whereas I would get enamored by the tech, this person kept their eye on the value and delight they must deliver to the user.

If you’re an engineer thinking about switching into product, watch out for the traps I described above. If you’re a PM without an engineering background, remember that you have skills and mental models that may not come as naturally to your technical PM peers. Hope this helps both categories of product managers!