Technical Project Manager. Somewhere in between project manager and software developer

The PMI Talent Triangle^® defines the ideal domain skill set including project management methods, processes and tools as a Technical Project Management skillsgroup. It might seem that a technicality of a Project Manager (PM) is focused on proficiency in such methods and tools for scope, budget or risk management. However, the reality of a current IT labour market shows quite a different picture, where Technical Project Manager is often someone in between a manager and a software developer. 

---

There are noticeable changes within organizations consisting in creating more specialized technical positions (e.g. DevOps Engineer, AI/ML Engineer) as well as hybrid ones, where soft, management or leadership skills are complemented by skills related to engineering technologies and processes, which as yet were reserved only for tech experts. 

Employer expectations

An analysis of a current IT labour market within a Project Manager context shows a clear and visible trend of combining soft skills with technical ones within an ideal candidate. Among positions directly related to the project management one can find e.g. Technical Project Manager (TPM), IT Project Manager or Software Project Manager. All the above mentioned have one thing in common – connection to technology. The importance of this connection varies in different organisations and so there is no reference skills set for a Technical Project Manager. Among expected attributes technical documentation reading, hands on experience in business analysis, IT systems design, source code reading, knowledge of communication protocols and even prior experience in software development can be identified. Thus, a current TPM image is inconsistent and highly dependent on organisational context. 

Technology for dummies

Organisations adapting agile approach for IT products development as well as leveraging it for an overall management tend to bring closer tech experts (e.g. software developers) to business and end users, while at the same time tiding managers’ relations with these experts and technological issues. In case of technology experts, this might consist of attempts to include them in a process of active project scope definition. Engagement of these people can be stimulated by encouraging them to participate in face to face meetings with a business client representatives or end users. As a result, technology experts learn how to talk using business values and end-user language. Such activities, develop a better understanding and they empathise with e.g. a functionality that is being developed, supporting specific business process. How then bringing closer Project Managers to technological experts and issues can be realised in practice? When does a Project Manager become a Technical Project Manager?

Foreign language – Technical

The answers are straightforward and need to be searched in one of the key success factors of almost all IT projects – effective communication. Transparent communication in a project which goes beyond defined skills boundaries which are a result of typically established company positions division results in knowledge and competences increase for all engaged people. If we would try to divide a project team working on IT product in two groups in terms of required technology understanding level, the first one would include mainly client, users, PM and business analysts whereas the second one IT architects, developers, testers and all the other technical professions. Within each group, members use their own specific language, processes and tools. A common understanding of needs and problems between members of different groups is quite a challenge. In most of the cases, understanding a business group language is not a problem for people who are properly involved in business analysis process or everyday communication with a client representatives. However, understanding of a technical language by a PM requires some preparation, education and experience – just like learning a new foreign language. In cases where a PM does not have prior experience with a specific technology to be used in a project, initially an organic learning process based on even passive participation in technical discussions is a way to consider. 

A developer comes to a (T)PM

Let’s analyse the following situation: A software developers team wants to consult with a Project Manager a need of an IT system source code refactoring. Technology aware (Technical) Project Manager knows that refactoring is an activity which in the end increases an internal product quality and reduces future system maintenance and upgrade efforts. The same Project Manager knows also, that such an activity brings additional risks due to a lack of business value from an end user or client perspective. This is due to the fact that refactoring by definition does not provide any functional or non-functional (e.g. performance or reliability increase) increment. Therefore, a decision about a scope of refactoring activity should be an informed decision worked out by a whole team together basing on real needs. In such a situation only specific elements of an IT system to be potentially further developed could be selected at first. A TPM makes a decision by understanding objectives and consequences of code refactoring including business needs, product roadmap, costs and effort needed for such activity and risks related to a potential project delay. Conclusion: Technical Project Manager should be able to discuss with tech professionals effortlessly and make right project decisions basing on these discussions. 

Non-practising believer

Is it possible to become a Technical Project Manager without having experience related to a specific technology or software development process? The answer is strongly dependent on organisation context. Considering company environment where strategic decisions related to tech matters of a project is supported by skilled IT architects or tech leads, participation of TPM in making such decisions, requiring in-depth understanding of a technology can be limited. Although for inexperienced teams or projects where even the smallest decisions related to selection or specific use of a given technology have significant impact, TPM competences in a tech area are critical. 

I any case, a TPM should be aware of a specific technology capabilities and consequences of its usage in a project. Let’s face it, hands-on experience in technologies, processes and tools related to software products development definitely helps to: 

• communicate with tech experts (e.g. knowledge of formal and informal graphical notations for depicting technological issues)
• understand structure (What are the components of a system? What is data model behind?) and dynamics of a system (How it works from a data processing perspective?)
• manage a project scope consciously (e.g. co-creating architectural drivers, requirements management, understanding a difference between perceived and actual complexity of technological issues)
• manage quality consciously (e.g. managing a technical debt, understanding quality assurance and control processes and tools)
• determine requirements and capabilities in terms of scalability, security and reliability of a system (e.g. benefits of using virtualization, containerization or cloud infrastructure)
• optimise development processes in order to reduce waste (e.g. introducing practices and tools for automation, continuous integration and delivery)

It does not mean that it is required that a TPM must have prior experience in software coding or IT systems design. An ability to ask right tech nature questions is often enough and brings a lot of value for a project team. Questions, for which a team will most likely find answers themselves. 

Conclusions

In IT projects a traditional roles distinction between so called business and technology is no longer valid while combining soft or organisational skills with engineering ones does not surprise anybody. Commonly used agile practices (Scrum, XP, Kanban) increase a need for self-organising teams, where filling the competences gaps should be organic and stimulated by team members themselves.This also concerns Project Managers in terms of exploring technological knowledge required in projects they manage. And, above all this knowledge enables more informed, quicker and less riddled with risk decisions. Bridging the communication gap between PM and technological professionals is a key factor to be implemented first. Business aware engineers together with technology aware Project Managers seem to be a recipe for a perfect project team. But be careful… to not switch places. 

---