The Role of a Technical Project Manager – Explained

by Sreejith Partha

The shift towards agile, lean development environments has made communication all the more important. Although missteps can be rectified faster today, they are still a drain on resources. Not only do they delay the product releases, but they also cause friction between developers and product managers – creating a highly unhealthy work environment that is counter-productive.

Technical Project ManagementTechnical Project Managers handle management of software development projects. They specialize in bridging the gap between the technical (e.g. developers, cloud engineers, QA and systems engineers) and non-technical teams (e.g. product managers and stakeholders )

Our very own Technical Project Manager, Anand Suresh, has agreed to give us an insider’s look into this fascinating and inevitable position in software development.

Let’s start with a simple one – Who exactly is a Technical Project Manager?

Anand: A Technical Project Manager (TPM) is, simply put, a technically-adept Project Manager. Although this is almost certainly an oversimplification, it does indicate the responsibilities that a Technical Project Manager is expected to shoulder.

TPMs should know technical concepts well enough to be able to deep dive into the technology, code and other factors, and understand the implementation. At the same time, they should also be well-versed with client-side matters such as product requirements, budget constraints, time management, and so on.


Download a PDF version of this Checklist. Access it offline anytime. Bring it to team or client meetings.

So, what is the role of a Technical Project Manager within a company or a team?

Anand:Technical Project Managers act as a bridge between non-technical and technical folks on any given software development project.

Technical Project Management TeamIn my case, I interact with the product team of clients. These are Product Managers / Product Architects – professionals who are not too well-versed with the technical aspects of a project. They often come up with new ideas/features for their products and provide us detailed requirements such as design, specifications, budgets, and so on.

For example, consider a new feature release by Google on their Android platform. The product manager will let me know that they want this feature integrated into their product and specify the timeline/budget.

It is then upon me to break down all the data/requirements/specifications I get from the Product Managers into development tasks for our team, estimate them, conduct Agile processes and manage milestones. I also interact with the third-party vendors of our clients whose technologies need to be integrated into our clients’ software.

Would you say this will remain an essential role with the industry moving towards lean development?

Anand: Absolutely! Without a Technical Project Manager, Product and Project Managers find themselves dealing with developers directly. A developer won’t always get a good handle on what the product team wants. There are many intricate details within each feature request that are often overlooked.

Similarly, the product team may not fully understand the limitations of development. The product leads/managers frequently come up with new and flashy technologies that are new and trending. Of course, it is a part of their job to keep improving their product. But many a times, they do not realize the effort, skills, and time required to get these new features out into the market. This leads to under-estimation of effort and over-burdening of the developers.

Both the above scenarios will lead to a lot of back and forth communication, significantly delaying the development process. On the other hand, a TPM could come in and expedite this process by giving both parties the information they need to continue with development and keep expectations reasonable.

Do they replace/absorb any traditional roles within companies?

Anand: Based on my experience, they would complement a traditional project manager. Technical Project Managers are essentially managers responsible for managing technical tasks and being accountable for developers working under them.

I can say that I do manage some of the Quality Assurance tasks, Cloud Engineering procedures and release management services as well. For example, in some projects, I take care of packaging the application and delivering these to the clients. In other applications, I do learn and understand the automation, but play minimal role in the actual processes while monitoring how they work.

I would also say that a TPM replaces a Scrum Master to a certain degree too. A Scrum Master is considered the foremost facilitator for an Agile Development team. As part of my responsibility, I also conduct scrum calls and organize weekly sync meetings with clients. Both of which, are supposed to be handled by a Scrum Master.

Technical Project Management ManagerWhat should be a Technical Project Manager’s background? Ideally.

Anand: Well, they most definitely need a technical background. We need to be able to understand various development practices, coding procedures, different technologies, and so on, at a much deeper level than most.

Keeping all this in mind, I’d say a senior developer with a few years of experience is the ideal candidate to transition into the role of a Technical Project Manager. Especially one who is prepared to take on more responsibility. And of course, interacting with the stakeholders in a non-technical language is a skill that developers have to learn over time to assume this responsibility.

Does this role require any specific inherent abilities? Or can a good TPM be trained?

Anand: I don’t think you need any specific inherent abilities to become a good Technical Project Manager. Good TPMs can be trained and usually become more adept at their work as they gain more experience. Very similar to so many other job roles out there.

Do you recall any personal experience that underlines the importance of a Technical Project Manager in your firm?

Anand: Yes, I can think of many such instances. But if I was to choose one, it’d be a project where we had to integrate a third-party SDK into a mobile application that is used by millions of users.

The requirement was to integrate an ads SDK from a vendor into our client’s app. We estimated the task and assigned it to our developers. The task was completed and I sent out a build to the client to validate (these tickets need to be validated by the vendor also).

The client then passed it on to the SDK vendor for validation. However, they got back to us saying that the integration is wrong and they didn’t see the right implementation happening in their findings. This sparked off a long chain of emails between the vendor, the client, and us.

I had a conversation with our developers about the issue and confirmed that they had followed all the steps outlined in the official documentation. I conveyed this to the vendor and they tested it again to no avail. We ended up with the same reply from them – “the integration is wrong”. The email chain became longer and longer and all parties found themselves severely hamstrung.

At this point, I decided to go through the integration myself. As I was going through the debug logs, I noticed a peculiar error. A bit of further investigation brought me to the root of this issue quickly. For the SDK to work with our advertisement SDK, we needed to incorporate an additional adapter that would connect with our ads. However, this wasn’t mentioned anywhere in the documentation provided by the vendor.

The vendor confirmed my findings soon after and updated their documentation. The adapter was implemented, tested, and pushed live almost immediately after.

This simple oversight threatened to derail the project and release milestone. Without someone to communicate with both the technical and non-technical sides of a team, vendor and client, it would have remained as a predicament for much longer.

What about emerging technologies and new features? How do you keep yourself constantly updated?

Anand: Humbly speaking, continuous learning comes as a core perk to this title. This is mainly because we work with many innovative clients who ask to push boundaries, and we are able to help other clients in transforming digitally with our continuous learning. However, there are a few different ways by which I keep myself up-to-date with emerging technologies explicitly.

First, I make sure to follow all major tech events such as Google I/O, Apple WWDC, AWS, etc. I watch the keynotes and make notes about the key features they discuss. A few hours are then spent on the internet – researching and understanding these features.

Another way I go about it is by having conversations with developers. I have noticed that I can learn a lot for every developer that I manage. For example, they could be using different methods of accomplishing the same task. And some of these, I would never have even considered or heard before they tell me. So, continuously learning from peers and developers is definitely one of the most important ways to stay on top of technology.

Lastly, I learn from experience. While checking up or completing a task myself. I make sure that I search for different, better ways of accomplishing it all the time.

These things ensure that newer technologies or features never slip past me unnoticed.

Keeping up with technology doesn’t sound easy.

Anand: It’s not easy, yes. But then, in my line of work, it is necessary. This field is right within my comfort zone so I am more than happy to offer any insight I can, especially to those curious about it.


Leave a Reply

Your email address will not be published. Required fields are marked *

Development partner
7 steps to choosing the right development partner
Continuous Delivery
Different Stages of a Continuous Delivery Pipeline

Stay Tuned.

There is new content added every week about the latest technology trends etc