The role of Technical Project Manager (TPM) within Tech Organizations — from a Former Insider
“ A successful Technical Project Manager (TPM) enjoys the art of communication, not just verbally but especially in a written form.”
Hi, my name is Nicolas. I run the Technical Department at Overproof. I invite you to share my passion for designing great software and talk about the role of senior Technical Product Management (TPM) within tech companies.
There are two types of profiles for TPMs: scrum master and tech architecture-oriented. This post is about the role and responsibilities of the latter type.
Most companies do a lousy job at Technical Product Management (TPM). I mean it! I think it’s among the most important decisions that companies make. The impacts last a long time, and they ultimately determine success or failure; and yet, for most companies, they wander into building the product, they figure it out as they go, and don’t take the time upfront to make the hard decisions, the very consequential and essential decisions, which are often made as kind of an afterthought. “I’ve used this database before, and I’m comfortable with it, so let’s just use it again. We can exchange it later.” But they never do! Or, “Let’s just start playing around with this machine learning engine or this architecture; if it’s wrong, we’ll change it later,” but they never do, and it becomes harder and harder.
“most companies wander into building the product, they figure it out as they go, and don’t take the time upfront to make the hard decisions”
Instead of doing the hard work and making the correct decisions upfront, you may need to prototype and take the time to learn and become an expert — all that is fine, but it’s worth trying to figure out what the significant consequential technical choices are and make them correctly, because the right ones can make all the difference in the world. Instead, companies follow the competitor lead and try to catch up, or they listen to the feedback from sales on the last deal they lost to a competitor and then started building that. If not this, they mock-up UIs and use cases, and they focus on the UI, and all of that comes at the expense of focusing on the core of the product.
Tech bounty
A solid Technical Project Manager (TPM) must constantly ask these fundamental questions. I call it “tech bounty.”
- What does the core of the product do?
- What are the data structures and algorithms?
- What are the technology choices in the product core that delivers the best value proposition for the customer?
It’s the fusion of two things: The understanding of the most important value or problem that the product is there to solve (which doesn’t have anything to do with how to do it) and then combining it with the critical technical choices that deliver the solution in the best possible way.
That can mean a lot of different things, but they’re all important decisions. For example: which third-party technology database to use, a pretty mundane question, right?. But we’ve got relational databases and columnar databases, key-value, in-memory, document databases, SQL databases — there are so many! Moreover, they all have their purpose right, and they’re all different tools in the tool chest. Knowing what they all are and when to use them, when it’s appropriate and how to use them, is the main role of a Technical Project Manager (TPM) among constant visibility and reporting to stakeholders. (More on this later.)
Once you pick one technology, you have to put parameters on how it’s used and to do so in the best possible ways. Those are the important technical choices, and in reality, the easy ones, because it’s just about the existing technology solution, right? However, what about picking the right data structures? And only understanding the product, understanding the core of what it does, and then seeing if your technical mind can innovate a data structure that can do better than anything else out there. And those often come conjoined with an algorithm, too, to finally fusing an algorithm with the right data structure that performs superiorly, and that’s your company’s technical advantage.
The Job
You are the Technical Project Manager (TPM): You’re innovating, you are building unique features better that are technically defensible, that can’t get copied in a week or two by somebody else, because you’ve put the thought into a superior design. It can be a ground-up sort of algorithm or chosen from existing algorithms. We have a universe of different machine learning and AI choices, but when should we use a machine learning approach or a recommendation engine or nearest neighbor or a neural network or natural language processing or whatever? Just like the database example, you’ve got all these different patterns in the world, but they are all different. When to apply them and how to apply them really matters a lot. Sometimes the Technical Project Manager (TPM) job is about identifying technology trends and figuring out how to use these trends to our advantage and what the right way to use them is. Maybe it’s something like containerization, which is a technology mega-trend right now. So where and how do we apply it? How do we choose between using ECS vs. Kubernetes? These are all things, and the landscape is always evolving and changing. Great Technical Project Managers (TPM) are experts at deconstructing what the product needs to do, and experts of all the different tools out there, including the ones that would have to be built potentially, then mark those important decisions, which is really providing technology and architecture leadership.
the Technical Project Manager (TPM) job is about identifying technology trends and figuring out how to use these trends to our advantage and what the right way to use them is”
As you can probably tell, I’m very passionate about this. I believe it has one of the most significant impacts when it comes to the success or failure of a software company, because at the heart of a software company is software. So, if your product isn’t unique and differentiated, it’s going to be really hard for your sales team to sell. If it doesn’t scale well, you’re going to have support problems. If you made the wrong decisions, it could have a cost structure, which isn’t healthy for the business in terms of not getting better as the scale increases. These all map back to the heart of the company, which is software-based solutions. It’s really that simple.
Changing Companies and Organizations from inside
Not only must a Technical Project Manager (TPM) be willing to develop the necessary skills greatly and continuously but tech companies must also provide a healthy environment to train and educate these people. Finding the right company that is willing to taking the time to build a replicable, high-quality process while developing expertise in all these areas and members to deliver high-quality decisions in a very repeatable manner is hard. If your organization doesn’t provide an environment for you to thrive, then be proactively part of that transition, or just move on. It’s just common sense.
Technical Project Manager Profile
I’ve found that good Technical Project Managers (TPM) have a couple of things in common: they all have a strong technical background, they all have had experience writing code at some point in their careers doing design, making these important choices, but frequently making these choices for other people. They’re in a lead role, making architecture work, and so they’ve learned how to deconstruct big, complicated problems into manageable components that can be independently developed and then integrated without becoming a nightmare.
Technical Project Managers (TPM) have a little bit of scar tissue to show for it. You’ve been in a role where you’ve made good decisions and bad decisions, or at least seen them play out, and you have some perspective on not only how important these decisions are — and the consequences — but some of the patterns that you want to avoid, the pitfalls that you know exist, and you will have in mind when you sit down to make design decisions on a dev factory among the team.
“I am very wary of people who have their favorite technology that’s got to be applied everywhere”
Technical Project Managers (TPM) enjoy learning new technologies. I am very wary of people who have their favorite technology that’s got to be applied everywhere, and I much prefer people who appreciate that there are all types of different tools in the world, and our job is to understand them. Our job is to evaluate them and know when to apply them, and then how to apply them, what constraints need to be put on them, and what the important decisions are when you use that tool, not just the selection of the technology itself.
I found that a successful Technical Project Manager (TPM) enjoys the art of communication, not just verbally but especially in a written form. It ultimately is how they document and pass them on within the organization to engineering and others. They enjoy organizing their thoughts and presenting them clearly and crisply. It’s analogous to writing code, because when I read their writing, it feels like I’m looking at the code when they are coding, in the sense that they make these declarative statements, the structure is very particular, the formatting is sound and the typos are addressed, and everything matters to them. They take the time to be consistent, and the naming is consistent throughout their writing; they know when to use bullet points because they want the densest way of communicating something, right? You don’t want a hundred lines when ten lines can do the job. The art of clear and concise communication is quite crucial for a Technical Project Manager (TPM).
The Pedigree
The prior roles of a Technical Project Manager (TPM) are very important. Usually they are people that used to be CTOs, technical co-founders, or lead architects — but it all comes down to people who understand technology, and whether they are passionate about making the right big-picture technology decisions and understanding the problem that is intended to be solved, and then being a leader by making those decisions in a very clear and binary way, putting them in writing so that we can all understand them, we can all be aligned to them, then finally executing the plan to build and deliver these great products.
Reporting Tooling
For the Technical Project Manager (TPM), visibility is accountability. They love essential tools like Atlassian Portfolio for sound and feasible projections. Jira, Trello, Asana — they are all part of the same family, but for you a plan must live a couple of months in the future, if not years. You must project attainable results for stakeholders’ visibility: up, down or traversal, no matter if they are Waterfall, Agile, or a combination of two. Your constant dimensions to dominate are Scope: what you want to achieve, Resources: your team velocity, and Time: product release cycles or deadlines.
Hey you! if you are reading this help me out please | Missing KPIs
How would you measure the performance of a Technical Project Manager (TPM), and what are the usual KPIs to do so?
What would you say are the KPIs or how would you measure the outcome expected as a result of the activities performed by the Technical Project Manager (TPM), and what the critical (key) indicators of progress are toward the intended result? I would love to hear your opinion, just post a comment at the end of this post, please.
Thanks, I hope you found this a useful overview of my passion for the profile of the Technical Project Managers (TPM) and the role they play.
Please leave your comments and your thoughts. Take care, and have a good day. Thanks for reading.
