BA 27B/52: Conviction and Consensus
“Sometimes you just have to go with your conviction instead of worrying too much about consensus. Your job is always about keeping the project moving forward…”
Former Manager of Mine.
Should TPMs speak up in technical discussions?
Do we need permission from the Engineering Manager or engineers of the team to participate or even sit in technical discussions?
Does our voice matter and how do I make myself be heard?
I am of the belief that Technical Program Management is a halo function that operates optimally when unseen.
TPM is a team driving all organizational elements (Product, Design, Marketing, Engineering, Support etc) towards executing optimally a vision and goal established by the leadership.
The only time we must be seen is when we need to push through a roadblock preventing forward progress.
Now, this absolutely does not mean that we stay quiet all the time and sit there taking meeting minutes. There is an art to everything we do especially in technical matters.
There are two ways that TPMs leverage their voice to push things forward:
Conviction - some call it the get-it-done attitude.
Consensus - bringing everyone together and pushing them forward or to a decision.
At any moment in a project, you are activating between one of these modes.
A word of caution - conviction is not a mode you can operate in all the time. It has a taxing effect on the cross-functional team and you. Driving by conviction requires you have walked in the TPM shoes through some complex projects, otherwise you will look like a “Bull in China Shop” and burn relationships, our primary currency as TPMs (maybe an essay on this later).
Early in your career, focus on consensus driven approach and listen, watch, observe how the experienced TPMs drive with conviction especially when they and how often they lead by conviction.
At the organizational level, in order for TPMs to activate either of these modes, it is imperative that the Voice of the TPM is an organizational understanding, codified in the organizational culture under the “what does a TPM do” heading. All engineers, PMs, Designers etc including leaders need to understand this and be onboard with.
Of course, the onus is on the TPM leadership or leadership to hire TPMs that have either:
Excellent knowledge of modern systems (be it front end tech or backend architecture or how CI/CD works)
General technical systems knowledge and a hungry attitude to learn fast.
Why should I scare about this?
I get this question often where TPMs will self-regulate and not speak up when they see things going wrong or participate in technical meetings. They are afraid of sounding dumb or struggled with whether it was there place to speak up. I get it. When I started my TPM journey, imposter syndrome was always an ever present force in my day to day work. You also are still learning things.
At Google, TPMs are expected to meet the criteria of Software Engineer a level or two below. You are not expected to right code but can either participate or drive technical issues to solution. You would only set this criteria if you had an expectation that TPMs have a voice and it matters.
Your voice as TPM matters and you should never be afraid to speak up. Engineers should understand that there is a reason you have a Technical in your title. But, don’t speak for the sake of just speaking up. Yes, I have seen those TPMs who just reiterate what an engineer or someone else said just be visible. Don’t do that.
If you are struggling with Engineers recognizing this voice then see whether it is:
a trust issue
an expectation misalignment
Neither are impossible or immovable roadblocks.
Remember - your voice comes through either as conviction or consensus.
Forward progress is always the goal. So, go leverage your voice. Don’t be afraid.
Until next time 👋🏽!
-Aadil
How was this week’s newsletter?