BA 27A/52: Working with Difficult Engineering Managers
Q: Does a TPM have an opinion? Or maybe from another angle: what does a TPM need the T for? Sometimes I feel like I overstep because I can be very opinionated. I tend to believe that my opinions are rather questions to spark a discussion. But I wonder if it is the task of a TPM to really give input on the how (and if so: how does that work with an EM)
You will meet two different types of Engineering Managers in your career as a TPM:
Person A: Only sees you as an admin, traffic controller, accountant whose only purpose is keeping the documentation, dates, and project plan in order, hosting meetings, writing meeting minutes and that’s about it. You are not important beyond those functions especially in matters or discussions of technical nature.
Person B: Sees you as a part of the engineering team, a partner, collaborator, whose input is as valuable as the next engineer on the team. They value the experience you bring and the ability to find things they may overlook. Yes, you still hold meetings and write meeting minutes but they expect you participate in meetings as any engineer might.
I have been fortunate enough to have encountered both Person A and B in my career.
When you encounter Person A, it is a jarring experience. It creates doubt and imposter syndrome quickly creeps in.
The Technical in the Technical Program Manager is a muscle. If you don’t train that muscle by tackling ever more complex projects, it becomes out of shape. Rust appears and you lose your edge and do fall into the trap or profile the Person A expects of TPMs.
I wish ever Engineering Manager (EM) is Person B. Alas, reality is different. Very different. We don’t always get to pick our EMs.
There are reasons why Person A behaves the way they do:
They worked with a TPM who actually did exactly the bare minimum project management.
They worked with a TPM who wasn’t worried about the details, but were zealous about making sure every task was broken down by half day story points scrum agile etc.
They worked with a TPM who wasn’t able to represent the team in cross-functional meetings effectively.
They worked with a TPM whose only response to engineers who missed a deadline was “what is the new eta”, nothing more nothing less.
They didn’t understand what the actual role of the TPM was in their organization thus filled in their own blanks.
If it is none of the above, well, you have encountered what we call in our industry - an asshole. My recommendation for such EMs - get out as fast as you can. It is not worth it. You are better than this.
Let me tell you this - your opinion as a TPM matters. There is a reason why there is a Technical in your title. You may not need to deliver code but you need to hold your own in engineering discussions, understand how systems work, the in/outs of software development from planning to maintenance. How can you effectively drive cross-functional projects if you don’t understand what you’re working on.
Again - your voice matters. Person B understands that. No. They value that.
TPMs are the EM and their team’s Robin and Alfred combined into one. Depending on the moment in the project, you will switch between these two personas.
Sometimes you will need to support the team in their endeavors. Other times, you need to be the voice of reason and bring a contrarian view to the conversation based on your experience on other projects; a gut check.
So - if you encounter Person A, is there a better way besides just quitting?
Yes, let me share my experience of how I handled my Person A at Apple.
You can never directly argue with Person A to win your case. They have made up their mind and they will not relent. Your manager and leadership will have expectations of you to make it work.
Before you know it, Person A is holding team meetings without you (because they don’t believe TPMs belong in engineering team sync because “it will prevent the team from being open”). They will not bring you into engineering meetings unless they need you to write minutes. There is an Uber Person A that writes their own meeting minutes and never shares it.
Project plans are being crafted without your knowledge and oh yeah, those status reports the entire organization submits that you are used to doing together with Person B, Person A hates those and will tell you to just send them the template and deadline; they will write it in their own style and let you fix it. We didn’t have 1:1s and even if we did, they usually wrapped up in 15mins.
Feeling useless yet? I was.
I never felt so out of loop in my career. Emotionally it was very taxing watching my peers collaborating with their EMs while I am waiting for things to happen. The only time in my tenure at Apple I woke up filled with anxiety and looked at my wife and said, “I want to quit my job at Apple.”
I needed a plan.
So - I leaned on what I expect all TPMs to be really great at: Observing patterns.
There are a few things I noticed about my Person A:
They were extremely defensive and protective of their team.
They valued those who didn’t blindly follow process; “Project Managers don’t do critical reasoning anymore these days” Person A said all the time whenever I needed something.
They were really great at managing up.
They had a tendency to roughshod in contentious cross-functional meetings often times storming out.
My plan of attack:
If Person A wasn’t going to spend productive time with me during our 1:1s, I started having 1:1s with the engineers on the team - socially and project wise.
In a remote world, this would mean more dedicated zoom and google meet time.
This 1:1 team created trust with the team. Turns out they started surfacing things they were afraid to surface to Person A. I started handling risks before they happened.
For general process like Project Status, I gave up on forcing Person A to follow the org approach. I let them have their way here. I needed to pick my battles. I just made sure I knew what was being written and format it properly.
In cross-functional meetings, I started echoing Person A’s positions. I slowly worked my way to being Person A’s Robin.
If they were being the bad cop in a meeting, I was the good cop. I started playing off their energy and balance them out.
This created trust in me from the cross-functional teams allowing them to bring me project issues first.
In our 1:1s, I started surfacing issues to Person A with technical details. I didn’t offer my opinions but my goal was to just showcase that I knew the details. I knew what was happening even if they weren’t letting me in.
Result:
I started getting included in team meetings.
Suddenly, Person A started asking for my opinions in our 1:1.
I was driving conversations in cross-functional meetings but still being mindful to defer to Person A as the ultimate decision maker.
When I quit Apple to go join Google, my Person A was the most vocally upset about my departure. In my exit interview, our departments HR partner was quite shocked that Person A finally found TPM they were happy working with. I had cracked the puzzle.
Why should I care about this?
We don’t always get to choose the EMs we work with and we definitely don’t get to choose whether we end up with Person A or Person B. If Person A is the kind that has had a bad experience with a TPM in the past, there is a way forward for you:
Observe how the EM works.
Find the quirks, the patterns, the kinks in their armor.
Identify ways to exploit the above.
Never tackle them head on; you can’t change their mind with a reasoned argument. Your actions have to speak for you.
Make sure your manager is aware of your struggle and how you are approaching it.
Above all - be patient. Trust building is a marathon, not a sprint.
Alas, if the Person A you have encountered is the asshole variety, then as I said, if you can, find another EM to work with or quit. It’s not worth the mental anguish. If neither swapping the EM or quitting is possible then be patient for when you can switch the EM and know this, IT IS NOT YOUR FAULT. You are a Technical Program Manager. You know your shit.
Until next time 👋!
-Aadil
How was this week’s newsletter?
Love it Aadil. Thanks for this one :)