Why Hire Technical Program Managers
Before answering the when to hire, focus first on the why.
Howdy Tribe -
Working at an early stage startup as a Technical Program Manager is an almost impossible opportunity. This space, for non-code delivering roles, is oddly reserved solely for Product Managers. This experience is fermenting so many new thoughts to old questions and a few to which I want to give some water and sunshine to see what answer grows.
Happy Reading!
Aadil
Why Hire Technical Program Managers (TPM)?
My last piece “What is Technical Program Management” raised a few questions from readers about when the right time is to hire a TPM. Before addressing the when, it is important to understand the why.
I have had the luxury of working in large organizations where the need for TPMs is already established. The game underway was to hire the best talent and as much as we needed. Thus, the unadulterated form of “Why hire TPMs” never presented itself; it was always forgone conclusion that we needed more TPMs, most often because there was too much work for one person or the present team roster. That is not a compelling enough “Why” to address but a reality of a large organization.
Having now spent time as a TPM/EPM (Engineering Program Manager, its often interchangeable or the same as TPM depending on organization), I have now had the privilege to be placed in a position to ask the proper “why” including pointing the inquiry at myself and my current role.
Why you should hire TPMs, especially at early stage startups, is all about creating or improving engineering discipline.
For me engineering discipline is not productivity, nor is it simply building schedules.
Engineering discipline is the process of how engineering teams do work. This encompasses a whole bunch of different areas and topics ranging from tactical to strategic:
How do we decide what to build?
How do we release software or product at a certain pre-determined point?
What is success? What is feature complete?
Do we have a unified decision of what done is?
Do we work in 2 week, 6 week or 8 week sprints?
Are we really doing sprints, this early?
Do we all agree what the story points stand for?
How do we document architectural decisions?
Is Jira the right tool for us?
If we are using Asana or Jira, how do we setup the tool? Components?
Should we do multi project or single project Jira setup?
Is this the right time to do a team all hands?
How often should we have planning activities?
Do engineers understand what a program increment is?
Who is responsible for building unit tests?
Are we making critical decisions at the right time?
How do we scale our reporting on work in progress vs work done?
How do we align hand-offs between engineering and design?
What is our development lifecycle? Forget SLDC, are work hand offs between teams well understood?
How often will we ship software post 1.0 launch?
Do we have the ability to project how much our headcount growth should be to support future plan?
How do we know we have signed up for too much?
Are we scaling the organization at the right pace?
Is our current organization structure productive or hindering progress?
This is neither an exhaustive or precise list of questions pertaining to engineering discipline but some of these are large enough that they can occupy multiple hours to days to weeks of conversation at any scale and size of an organization.
Yes, you can argue that these are all questions that you can and have to address without needing to hire a TPM especially at an early stage startup. However, keep in mind, this is mental space and cycles an engineering leader or individual contributor will have to surrender or spend focus on which can be better spent on thinking more about the architecture of how the backend systems will work and scale to support product and customer growth.
You can also argue that these are problems that aren’t a huge concern for a young startup. Sure, but keep in mind that engineering discipline is like a muscle; the longer you wait to figure out how to train this muscle, the harder it will be to roll back the neglect and even harder to stay on the plan or implement one.
When you believe that the organization is better served to hire someone to either partner with an engineering leader or execute independently, you have answered the question - why hire a TPM.
Next step - when is the right time…
P.S. - if you are hiring TPM to build schedules,
Was this essay helpful? Relevant? Help me to improve!
Omg hahahaha how did I miss. Yeah that train of thought is lost. 😂