Putting the Techno in TPM

I've been a Technical Program Manager in Atlassian for almost a year now, which is a weird sentence to write because it feels like only yesterday that I was considering switching roles.

But it definitely wasn't.

A year is enough time for me to form all sorts of dangerous opinions and the obvious next step after I form an opinion about something is to shout it into the void that is the internet.

So here we go.

You Better Wake Up

You should be technical if you want to be a Technical Program Manager.

I mean, it's right there in the name, so hopefully this doesn't come as a surprise.

Specifically, you want to have enough technical context around any of the software systems that are involved in the programs of work you're responsible for delivering. You need to understand how those systems operate, how they connect together and how they need to change in order to move forward.

You don't need to have the most technical context (that's a job for the engineers), but you do need to have some.

Speaking of engineers, basically every single one I know is really good at technically designing a thing to meet a set of requirements, assuming there is appropriate clarity around what the requirements are.

They tend to be less good at taking those resulting designs and turning them into a delivery plan though, which is where they need guidance from someone else.

Someone like a TPM.

If you, as a TPM, don't have enough of an understanding of the technical things in play, you're not going to be in a good place to help your engineers actually deliver on their designs in a reasonable timeframe.

So get cracking.

This World Is Just Sugar-Coated Topping

For starters, just talk to your engineers.

I don't mean that you should spend a bunch of time interrogating every single engineer in your area, but you should definitely carve out dedicated time to catchup with some of them. I'm talking architects, principal engineers and possibly even the senior engineers who tend to lead the larger pieces of work.

Ask them what they are working on, how they are thinking of doing it, what they are thinking about in general and then actually listen to what they have to say, adding in probing questions to make sure that you understand sufficiently.

Don't just do it once. Do it all the time. If you make time to talk to the technical people, the context will naturally flow from that.

The second thing you can do is participate in architectural sparring.

When I say architectural sparring, I mean group sessions where engineers get together and discuss a specific topic, poking and prodding it, coming up with and then discarding solutions and just generally throwing ideas back and forth.

Make sure you are an active participate though. Offer your own thoughts and opinions, because even if they are wrong or misguided, you'll learn something.

Hell, if you're particularly motivated, propose technical topics of your own for the sparring sessions. There is no better way to make sure something gets explored than to put it in front of a group of engineers and watch them tear it apart.

The third and last thing you can do to improve your technical context is to actively review technical proposals.

When systems are being changed for some reason it's generally a good idea to write up a proposal for why the change is necessary and how it is going to be structured. Obviously, this isn't really worthwhile for small changes at the team level, but anything above that should be interesting to you in your position as a TPM.

Again, this is more a case of actually reviewing rather than just reading, though if you only have time to read the proposals that's better than nothing.

Ask clarifying questions, suggest improvements, poke holes and do it all in a structured and easy to understand way. If you do that, you're not only growing your own knowledge and context, there's a chance you might actually improve the proposal itself.

Win-win.

There Is Another World Beneath It

In the struggle to develop your technical understanding, there are some things you should avoid though. Not everything will give you the same bang for your buck, and you've got a lot of other stuff to worry about.

For example, you shouldn't be reading code.

That's not to say that you shouldn't be reading any code, but you definitely shouldn't be doing a lot of it.

Yes, you need to know the general shape of things, how everything slots together, how it all works in concert to deliver outcomes and any relevant limitations that could impact capabilities, but anything more granular than that is wasted effort.

There is a huge amount of complexity in any software system, lurking under a relatively complex surface, and if you start spending time trying to understand it all, you're going to be far less effective at your actual job.

If you want to do that sort of thing, just go be an engineer.

Speaking of being less effective at your actual job, the other thing to be careful of is that you don't overinvest in building technical context.

You need to strike a good balance between all three of the pillars in order to be an effective TPM and if you spend too much time doing all the technical stuff, you're going to be much weaker at product sense and execution without authority.

Sometimes you might need to rebalance how much effort you're putting into a specific pillar based on the situation, but make sure you're doing that from the perspective of trying to achieve the best overall outcome.

If you have a weak technical team then you might need to be the technical expert, but if you're just playing around in the technical space because it makes you feel good, ignoring the other things that you should be doing, you're in for a bad time.

And It's Dark and Gritty

Ensuring that you have an appropriate amount of technical context is a critical part of being an effective TPM, though as with all things, how technically competent you need to be will vary from situation to situation.

Still, even if you have incredible capable and reliable engineers to work with, being able to understand what they are talking about and relate to them as professionals will go a long way to helping you to achieve your own goals.

That's true regardless of whether your goal is to successfully deliver some new piece of platform functionality to support brand new customer features or if it's something much simpler, like summoning a blood god through an ancient ritual involving the essence of the Daywalker so that you can subjugate the entire human race and treat them as nothing more than cattle.

In both cases you should watch out for people trying to stake you through the heart though.