Regularly Scheduled Technical Programming

Delivering internally facing platforms can be challenging for a traditionally structured engineering team.

Any Principal Engineers involved are probably focusing more on technical details and architectural concerns, which means they might be unable to minimise the complex interplay between delivery, product capabilities and technical requirements.

The Engineering Manager may be distracted by day-to-day people management or immediate delivery concerns, leaving them unable to focus on the bigger picture of program management.

Such a team might not even have a Product Manager, leaving a meaningful gap around requirements analysis and a lack of customer perspective for whatever is being delivered.

What if you could have someone who is across all of those areas?

Someone capable of stitching all of the things together into a cohesive pattern, while also filling gaps as necessary.

That's basically what a Technical Program Manager (TPM) is.

There Was Technically An Apocalypse

Obviously a TPM isn't as good as any single expert.

Take Principal Engineers.

Such professionals have likely spent the better part of their career immersing themselves in relevant technical approaches and architectural patterns that maximise the chances of a software system being successful.

But a TPM can still help, because one of the pillars for their role is technical acumen.

They don't know as much as someone who has dedicated their career to the craft, but they know enough to understand the technical proposals being made and to contrast and compare them with the other parts of the program that they are aware of, like desired timeframes or required product capabilities.

A TPM can, and should, be able to act as a check and balance for technical specialists, taking their suggestions and recommendations and asking probing questions or making improvements as necessary for the greater good of the program of work.

In addition, a TPM should be able to drive smaller technical decisions to a conclusion entirely independently, or with minimal assistance from technical experts. This service can allow the professional engineers to focus on the most important problems, making the best use of their skills in order to ensure the program delivers what it needs to in the timeframes desired.

One thing to call out is that a principal engineer or architect might contribute to code directly, whereas a TPM probably won't. It doesn't mean that they can't, but the technical acumen pillar is mostly focused around high-level understanding and alignment as opposed to being able to rummage around inside a codebase and change it directly.

Best to leave that sort of thing up to the engineers.

Not Much In The Way Of Authority Left

Meanwhile, the Engineering Manager of a team is the recognised expert in delivery. They decide who is doing what, when it should be done and are set up to intervene if necessary when something is going off track.

Assuming they have the bandwidth to do so.

Having a TPM available can help the engineering manager make the best of what limited time they do have available, because a TPM brings execution without authority to the table.

While they might not be making execution decisions directly, they are uniquely positioned to be able to ensure that whatever decisions are being made are the best ones possible.

With the combination of skills that they have, and the balance of knowledge across the program of work, a TPM can provide detailed prioritisation guidance for what should be done and when, possibly even including specific engineer recommendations, assuming they have the context.

In addition, the TPM can also reduce the total load on the engineering manager (or managers) by facilitating planning activities consistently over time. This sort of work typically involves triaging incoming requests, aligning desired timelines with external teams and otherwise just making sure that everyone involved has a shared understanding of the various pieces of work that need to be done and when they need to be done by.

Remember though, it's the managers who know how to get the best out of their team, and they are the ultimate decision makers. Their skills and context ensure that the overarching program of work is actually delivered.

Best To Keep Those Senses Sharp

Tempering technical considerations and facilitating delivery aren't the only two things that you can expect from a TPM.

You also get product sense.

Product sense is the ability to understand what a software system needs to do by taking into account the needs and desires of whatever customer base it is aiming to support.

In a lot of internally facing engineering teams, this perspective is entirely absent, or it's treated as a second or third order priority for the available engineering managers and principal engineers.

A TPM can help fill that gap.

Now, they probably won't do it as well as someone who has dedicated their entire career to the craft (like a product manager), but they are still more than capable of talking to customers and taking their ambient thoughts and current situation and translating that information into meaningful direction.

The best part?

Because a TPM has more than a passing knowledge of the other two areas, the product ideas that they come up with are less likely to be disconnected from reality, as can sometimes be the case with a dedicated product manager.

Which avoids waste and leads to a better outcome for everyone involved.

Because There Might Be Fallout

A TPM can provide a huge amount of value to an internally focused engineering team by being a jack-of-all trades, combining the perspective of all three of the major areas (technical, delivery, product) to fill gaps and ensure that the program of work delivers the value that it needs to deliver.

I say this as a TPM, so you know, bias.

The weird thing is, I've really only been in the role for six months at most, but even in that short time I've seen a huge amount of value come from having a TPM, even one as green as me, in a space that has never had one previously.

The Engineering Managers can focus on the teams more, the Principal Engineers can spend more time doing technical things and the non-existent Product Manager is barely even missed!

In fairness, I do have a huge amount of context thanks to having lived in the space as an Engineering Manager for 3+ years, but I suspect that the extra context is offset by the complete lack of experience I have in the TPM craft.

Imagine how much of a difference a good TPM could make...