Technical Program/Project Manager is a relatively new job title compared to the more ubiquitous management titles that we see in the tech world: Project Manager, Product Manager, and Program Manager. The titles can be interchangeable depending on how your company defines the role, so this article will generally apply to many [Fill in the Blank] Managers who work on software projects and aren’t exclusively business focused, and for ease of discussion, I’ll refer to all of the above as T/PMs.
One question that I’m often asked by people who are thinking of becoming a T/PM is: “How technical do I need to be?” This is usually from more business-oriented folks who are thinking about taking the TPM route, and sometimes (but less often) from developers who are looking to move into management-oriented roles.
The short answer would be: just technical enough to get the job done.
The longer answer is that there are different areas of knowledge you’ll need. This will probably be the most controversial stance I take here, but it is my personal opinion that it helps a ton to have cut your teeth working as a professional developer for 1–2 years before considering transitioning to the T/PM role. Does this mean it’s impossible to become a T/PM without professional development experience? Not at all. If you’ve programmed in your spare time, done college projects, or have a degree in a technical field you have a good amount of preparation. I also know that there are excellent T/PMs out there with no programming experience! I have just personally found that it makes the job much easier (then again, I don’t know how hard the job is without a development background). Regardless, you’ll likely need some hands-on experience with:
Have you designed and implemented APIs (Application Program Interfaces) before? Can you read an API spec comfortably? APIs are the primary way that two disparate pieces of code or functions communicate with each other. Understanding how APIs work and when they are used is vital to being a T/PM since so much of the job is teasing out dependencies that your project will have on other systems.
Technical specifications are T/PM bread and butter. At a high level, they describe and define the behavior of systems. In application, they will tell you information such as how your data needs to be structured to be consumed by a system, or what functions you need to implement if you choose to use a given interface. They will help you understand how to use a new framework. You will write them to help create new software and to help others use your software. Sometimes you will write specs to sell someone else on something that you want to build. Get comfortable reading and writing in this area.
Building software requires hardware, so understanding basic client-server architecture, deployment, the OSI stack, and hardware constraints is incredibly helpful. Plus it’s possible that you will be responsible for provisioning resources for your team.
As a T/PM, fluency in data, how it is structured, how it is stored, how it is extracted, and how it is used is important. From the technical side, you’ll likely have to help define data models, and from the business perspective, you’ll define success and/or operational metrics — it will be up to you to monitor, report, and respond to changes in the data.
This is not exactly technical, but since it’s a keystone T/PM skill, I feel that it should be called out. Being the intermediary between business and development is one of the core features of the T/PM role: That means having equal fluency when talking to Product, Marketing, Finance as you do when talking to Engineering or Operations so that you can help each domain understand the other.