A small retrospective of my first few months as a Technical Program Manager.

A small retrospective of my first few months as a Technical Program Manager.

A little over six months ago, at the end of 2021, I left my role leading a SaaS platform cloud operations team to join a late-stage startup as a Technical Program Manager (TPM). In many ways, I am working on similar challenges to my previous role. Still, now I get to tackle the challenges of cloud-native operations only instead of leading a team of ops engineers. I get to scale a “you build it, you run it” DevOps model, so the skills generally concentrated in a centralized operations team are integrated into every engineering team.

What is a TPM?

Technical program managers come in various forms depending on the programs they manage. I think the most comprehensive explanation of all these forms is documented well in the excellent pragmatic engineer substack.

That said, the primary function of a TPM is to bring clarity to the most complex or ambiguous challenges that organizations face as they grow.

My journey to TPM and Fullstory

I have worn many hats in my career that have spaned a diverse array of disciplines around software engineering, systems design, and SaaS cloud operations. Perhaps this role diversity led me to TPM as I think, much like the concept of an accident DBA, no one starts their career as a TPM. I reached a common career inflection point where I needed to decide between the management track and the staff/technical leadership track. This discernment process led me to learn about this unique technical program manager role. I quickly determined that this was an excellent fit for my immediate career goals. While talking to my current employer about starting a team, I found an opportunity to join an existing TPM team at a company that aligned with my personal and professional values. It was hard to decide to leave a company I had been at for eight years and had so many colleagues with that I loved collaborating every day. However, staying was the comfortable option, and I wanted growth which meant I had to push a bit past that comfort zone.

Life as a TPM

I am still in the early days of TPM life, but things move fast in our world, and I have already learned a great deal. So, I wanted to capture a few quick thoughts about what I learned.

• I was already trying to level up my written communication, but after starting my TPM role, this became critical. One of a TPMs primary job functions is to create clarity, so clear written communication is a must.
• The T in TPM is a critical differentiator from other more traditional solutions to program management. In the TPM world, we have to lead or influence others without direct authority, which requires a high degree of technical credibility to build trust with individual contributors and leaders throughout the organization. Though a TPM is not likely to be the one doing the technical work, we need to be able to participate and often shepherd technical discussions and then fully understand the technical and business requirements needed to accomplish the goals of our program.
• In my career now, I have a common need to compile and analyze data from sources that we may have never tapped into before for insights. This common task is another area where leveraging a diverse set of technical skills can add incredibly valuable. I often need to model costs, pull log data, or analyze other operational metrics to find robust quantifiable measures by which I can correlate the qualitative feedback I get on whether a program or project is on a successful trajectory.
• Finally, the expression “measure twice, cut once” has a parallel in my current work “listen first, then design.” Every organization is different; even if you had seen the problem before and successfully implemented a solution to fix it, you are likely to find that solution does not directly apply. What worked at my last company won’t work at my current one. What solution served the company well for the previous few years may no longer be able to scale to their latest organizational complexity. Not everything needs fixing, and no technical or process solution should be genuinely sacred. “Honor the skeptic.”