How do you build trust as a program manager?
As a TPM, have you ever felt like engineering, product, and design see you as a bit of an anti-pattern with control issues?
I’ve heard it plenty: “the program managers tell us what to do,” or “TPMs cross into engineering manager territory and we don’t like that.”
Disclaimer: this is aimed at mature engineering teams and EPD (engineering, product, design) leads — teams where EMs and PMs already run Scrum or Lean, not ones where a senior TPM is filling that gap.
Here’s what’s worked for me.
1. Have frank conversations about roles and responsibilities
Address the elephant in the room early, informally. Let EPD leads tell you how they see their own roles, and ask what they need from you to do their jobs well. Stay out of their day-to-day — it’s not your job to run their Scrum ceremonies. You don’t need to be at standup, refinement, or sprint planning, unless, as with vampires, they invite you in. Be clear about what success looks like for your TPM org; for me, that means staying flexible about how I design the systems and conduits of communication.
2. Technical and business fluency
Technical fluency means speaking intelligently to a team’s risks and progress. Business fluency means articulating business priorities back to EPD and stakeholders. You’re the one anchoring both sides in shared goals — it has to run both ways, and you have to be good at it.
If you tell leadership a project will slip two weeks and can’t say why, you’re a pushover. A jerk, even. But if you and the EPD leads can say together, “the cloud instances are undersized, so data transfer is slow — upsizing for five days at $5K gets us back on track,” that’s a business decision the company can actually make, and a mitigation the team can stand behind.
A TPM bridges business units with different priorities. You need to understand that a late project costs the company money, and be able to say so plainly — the EPD team will bring the options.
3. Gather clear, accurate, data-driven information EPD leads can stand behind
Always have real data behind risks, tradeoffs, and status. If a team is cagey, hold them accountable for providing it. Be precise about exactly what you need to know — you’re enabling good communication across every level, all the time.
4. Design simple processes that protect velocity, autonomy, and decision-making
Individuals and interactions over processes and tools — thanks, Agile. No process should slow a team down or get in the way of shipping working software, compliance and accessibility aside. Sometimes the fix isn’t a process at all — it’s just a conversation with the right people.
5. Be curious about struggling teams, not judgmental
Don’t assume you know how to run someone else’s team, and don’t insert yourself into their standups and plannings. Your job is getting the right people in the room and surfacing risks early — not running the team yourself.
6. Show up A+ ready, with an agenda, every single time
Never host a meeting without a clear purpose — either a bulleted agenda, or people who know exactly what they’re expected to bring. Structured meetings need clear items; looser ones need everyone to know their part going in.
These tips have worked for me, and I think they can work for many others. While you work through these practical tips remember to always be authentic to yourself.