This is a question that comes up a lot more frequently than I would have expected. To be completely honest, there isn’t a good yes/no answer to it – which is possibly why it keeps being asked. In this article I’ll cover the answers that I have received when I have asked this question in the past, and tell you what I think the answer should be based on my experience so far.
What others say…
“It’s really not technical” was one of the statements I heard from a user experience program manager a few years ago. She had had a number of technical roles in her career; so if anyone would know she would, right? Unfortunately it’s not that easy. For her particular brand of program management she was most likely exactly right though. Her team worked on evaluating user experience designs, gathering feedback on them, and tracking feature work around the user journey in the product. Much of the program manager’s time was spent thinking about how users would interact with the product; not how it worked internally.
With that in mind though how “technical” a role is strongly depends on how technical the person doing that role is. For somebody with an SEO or user experience background the same program management role would have most likely seemed very technical.
“It’s incredibly technical” was what one of the user experience PM’s colleagues told me earlier that day. At the time he worked as the program manager for SRE (site reliability engineering) for their service. Site Reliability Engineering is a discipline that incorporates aspects of software engineering and applies them to infrastructure and operations problems.
In this case it concerned the smooth running of the service that both PMs were working on. For his particular role that meant regularly using internal software, database, and reporting tools to measure the reliability of internal and customer facing services. It also involved writing scripts and tools to pull the right information to assess the health of the service and to prototype new ideas for reliability software in code.
With all of that in mind he was most likely also completely right about his assessment. His day to day activities would be seen as ‘technical’ by many in the industry.
What I think…
As you can see from the above examples, there is a wide range both in the definition of what ‘technical’ means in our discipline and industry, and in the extend of how ‘technical’ each PM role is. As with most things you’ll find that the ‘average’ – if such a person exists – PM will be somewhere in between with how technical they need to be to be successful.
The last part of that sentence is what’s important here though. As a PM you do not necessarily need to be very technical, but you absolutely need to be as technical as required to do the job.
The definition of ‘the job’ will change depending on the specific PM role at hand, but you will absolutely be expected (and even required) to grow into the technical requirements of your role. Failing to do this impedes your ability to take decisive action when it is required. It also reduces your ability to understand and communicate as well as connect different stakeholders, which will be another large roadblock.
I hope this helps to answer the above question and expands on the ‘it depends’ answer that I usually give. 🙂