There is significant ambiguity in how the terms “project manager”, “program manager”, “technical project manager”, “technical delivery lead” are being used today – they imply certain nuanced expectations about the role and the skill set of the individual filling that role, but those nuances are not necessarily uniformly understood. For the purposes of this post, we’ll keep it simple and we’ll narrow the scope of the conversation to focus on those individuals that have the overall responsibility of leading project-based efforts for delivering technology solutions. We’ll consider them to be “Technical Project Managers,” and for shortness – refer to them here as “PMs”
Caveat: I wrote this for the PMs because that’s where my professional roots and heart are. However, if you replace “PM” with “Scrum Master”, “Product Owner”, “Agile Coach”, “IT Exec” (been there, done it all) – the thoughts and assertions below remain valid for the most part.
The industry has general expectations for what non-technical skills the Technical PMs should have. The Project Management Institute and the highly ubiquitous PMP certification have helped tremendously towards setting those standards and expectations. However, there is lots of fuzziness and a wide gray area about the expectations for the technical skills of the PMs. PMI being industry-agnostic does not go into the subject matter expertise of a field (IT in our case). Furthermore, “technical knowledge” means different things to different people – a data center migration project requires considerably different technical knowledge and background than a software development project. Even in the software development space, an ERP upgrade project is quite different from a mobile development project.
Would a PM experienced in delivering projects involving technology A, be (un)able to perform just as well on projects with technology B? Prior experience with B is an obvious plus, but what’s the minimum sufficient critical mass of technical knowledge and experience to ensure successful performance?
These questions have obvious implications for hiring decisions. However, more subtly - they also impact retention, professional development, and training plan development decisions. For example, if a systems integrator is wrapping up a SharePoint project and the only upcoming project with a PM vacancy is for Java modernization. Can the same PM be rolled over? And what training would the PM need beforehand? Conversely, what percentage of training budgets and hours for PMs should go into technical vs non-technical (soft-skills, Agile, PMI-related) training? Should we expect PMs to obtain or retain their technical certifications? Should we set performance evaluation goals around technical knowledge/skills metrics?
Below are some thoughts and suggestions, based on my 20+ years of experience as a PM myself, and as someone hiring and managing PMs.
The guard rails (and to slightly paraphrase Marilyn Monroe):
On the right: Being technical is not the most important skill in a PM... As much as I am an advocate for strong technical literacy among PMs, I must stress upfront that strong technical expertise is NOT the most important skill in a PM and should not be a key decision factor for hiring and retention decisions. Communication, organization, and people skills are by far more important and provide a stronger correlation to future success. Conversely, the most technically strong team members are likely not the best PMs for the job. It does take a certain level of detachment from the minute implementation details for a PM to keep an eye on the big picture and manage the project as a whole.
On the left: … but it is sure nice to have it. PMs managing technical projects must have some technical aptitude and curiosity. I was recently in a conversation with a senior PM who was only 1 month into a new project. He could readily describe to me the business domain supported by his system and some process issues the team was experiencing, but he could not answer what platform his application was written on. This is just not acceptable. PMs must understand the technical domain of their projects to a reasonable level of detail so that they can connect better with the team, be able to identify technical issues and risks and be able to provide effective translation between the non-technical stakeholders and the technical team. It is the job of the Solutions Architect to provide technical guidance and make technical decisions, but the PM should have the literacy and experience to understand those decisions, assess their impact on the overall project performance, and be able to frame and ask further clarifying questions.
So, if at a minimum, the PMs must be at least somewhat technical, but are not to be expected to be the most technical people on the project – what is the “just right” level of “being technical” for a technical PM?
Well, there is no binary answer, but the below graphic provides visualization for that sweet spot of where PMs are the most effective (all other non-technical qualifications being equal).
(Note that the “Success” dimension is not metered – the technicality expertise is one of few dimensions and skills of a PM and it does not unilaterally determine the probability of success.)
“Technical Expertise” Scale Legend:
No project management experience, no prior technical education or experience
No project management experience, some technical education or experience working on a technical project as a business SME or analyst
Some project management experience, no prior technical education or experience
Prior project management experience, managing a project with an IT component
Experience managing technical projects in a different technical domain (e.g. “Infrastructure” vs “software development”)
Experience managing projects in related technical domain, but considerably different technologies (e.g. ServiceNow implementation vs iOS mobile development)
Experience managing projects with different, but related technologies (e.g. .Net vs Java platform),
Experience managing the same technology, but a different type of project (O&M vs green-field modernization)
Experience with the same technology and same type of project
Strong technical expertise with the main technology
Still has the hands-on skills and jumps in from time to time to help the team
I wouldn’t paint a complete picture if I don’t mention another important dimension of the PM skillset – the business domain they have experience supporting. Financial systems and projects tend to have certain commonalities, which are quite different from e-commerce applications, which in turn are quite different from Health IT projects, even if the base technologies are all the same. Knowing the business domain is important for reasons analogous to knowing the technical domain – better control over the project and better cohesion with stakeholders.
My personal trifecta for evaluating PMs is:
Mastery in Project Management – all the soft and PMBOK-related skills
Technical experience (see the 10-point scale above)
Business domain experience
As a rule of thumb – pick any 2 and be lenient on gaps in the third. Don’t chase unicorns, because even if you catch one – no one likes working with unicorns!
In conclusion:
If your PM is the most technically smart person in the room – they are in the wrong room or you’ve got the wrong PM.
If your PM can’t have a lively technical debate with your Architect - you’ve got the wrong PM.
Bella Trenkova