What is "Technical" in "Technical Program Manager" role?
Technical Program Manager (TPM) role is a much-coveted role in IT industry, especially in technology driven organizations. IT Giants like Microsoft, Amazon and Google have specifically designed TPM roles with strong career paths. The TPMs demonstrate good technical abilities alongside performing well in core program management areas. Strangely, there doesn't seem to be IT guidelines or even any specification given in TPM job descriptions related to what that "Technical" is expected to be.
So, let me share what I have learnt about that "T" of a TPM role. Based on my knowledge and exposure, I can outline the 4 must-have technical areas of the TPM role.
Programming
Why is this important: Take any TPM job description. It inherently (sometimes specifically) expects the TPMs to translate business requirements into engineering features. This needs foundational implementation knowledge so that the functional features are of high engineering standard and directly contribute to high code quality. Additionally, the TPMs will also be better placed to differentiate between functional and non-functional requirements; and where they occur. Even further, they will also be able to break down the features into correct unit of user stories very efficiently. This increases quality and reduces rework. Key areas are:
Database
Why is this important: The core of any enterprise solution or business application is data. Data comes in different shapes and sizes. Data needs to be well understood so that the system is correctly designed. The TPM’s ability to understand the data, look into it with a technical eye, write queries that extract data relevant enough to conduct analysis and gain proper insights, write proper data mappings, rules and policies is key to contribute to achieving robust database designs and business logic. It helps deliver high quality, stable and scalable data driven solutions. Key areas are:
Engineering Processes
Why is this important: A TPM’s strength is his/her engineering team. The TPM spends most of his/her time working with the engineering teams thru the implementation cycles – say Agile Sprints or other Release cycles. Proficiency in these areas greatly helps TPMs to lay down the right processes, identify right trainings, mitigate risks and resolve issues more effectively, guide the learning teams in the right direction and yet deliver high quality solutions as per organizational and business expectations. In addition, these areas also help the TPMs converse with the technical teams effectively at the engineering core, know where pieces of the work integrate and effectively program manage what it takes for the whole team to deliver the solutions. Key areas are:
Technology
Why is this important: Most IT solutions are technology driven. The implementation choices, the benefits and the liabilities are all there in the technology offerings. The engineering efficiency comes with the right technology choice and the success of the solution depends on the correct usage of technology. This helps the TPMs to visualize the technical end implementation, have conversations about right choice and right usage, especially during architectural and design stages. Key areas are:
Conclusion
A good TPM is the one who, while engaging with business and management teams, can have meaningful technical conversations with the engineering teams. They can also have active participations in technical discussions and decisions, better communicate to other teams the great work delivered by the engineering teams. In addition to these, it also helps TPMs to know the usage of common tools like SonarQube or frameworks like Entity Framework or collaboration tools like JIRA for higher engineering benefits.
Whatever may be the technology or organization, it is important for TPMs to have sufficient technical knowledge in the areas like the above to be able to perform better and deliver better. TPM's proficiency in these areas - that are specific to the technology being used or the organization's technology choice, will greatly enhance the chances of success of IT programs, thereby winning the trust and confidence of teams and stakeholders alike. Modern day TPM interviews also assess some of these technical areas to ensure right TPMs are hired.
Image source: https://thedigitalprojectmanager.com/
Great insights on this topic, Ravi Kiran Malladi, which I agree with what you said - that it's not always clear what "technical" entails. While I agree with most of it, I am curious about what you said about "Programming" and, to some extent, "Database". Are you suggesting that TPMs should be able to code or at least do work-breakdown structures here? I guess there is no one size fits all, but say the team consists of a tech lead, and an architect, and say also a data architect, wouldn't most of what's covered in your points 1 and 2 owned by those roles? Would love to hear your thoughts on that (may be that's a separate article in itself - the interplay of various roles!) Thank you again for writing this.