Building Trust With Engineering Teams

You have no authority over them. Trust is the only currency you actually have.

A technical program manager runs work through people who do not report to them. No one on the engineering teams has to do what I ask. They have their own managers, their own roadmaps, their own priorities, and most of those priorities are not mine. On paper I have no authority. In practice I have one thing, and everything I get done runs through it: trust.

For a long time I thought trust was about rapport. Be friendly, build the relationship, grab coffee, and people will help you. That is not wrong, but it is not the engine. I have watched perfectly likeable program managers get quietly ignored, and I have watched blunt, awkward ones get teams to drop everything and help. The difference was never charm. Engineers do not need a program manager to be their friend. They need one to be useful and honest. That is the whole thing.

So I stopped trying to be liked and started trying to be trusted, and I found that trust with engineering teams comes from three things, done over and over until they are boring.

Speak their language

The first one is credibility, and with engineers credibility is technical. You do not need to be able to write the code. You do need to understand the system well enough to follow a real tradeoff conversation, to know why the thing they are worried about is hard, and to not ask the same basic question for the fourth time. The moment an engineer realizes you actually understand what they are building, the conversation changes. You stop being overhead and start being someone worth talking to.

I learned this carrying programs across hundreds of services. When I could sit in a design discussion and understand why one approach added risk and another added latency, the leads started bringing me the real picture instead of the cleaned-up status. Credibility is the entry ticket. Without it, nothing else you do lands. With it, you get into the room where the truth is.

Remove more than you add

Here is the rule I actually run my weeks by. Every interaction with an engineering team is either adding to their load or taking something off it. A status ping, a surprise meeting, a re-ask for something they already sent you, those are withdrawals. Unblocking a decision, killing a meeting they did not need, settling a cross-team argument so they do not have to, shielding them from leadership churn, those are deposits. My job is to stay net-positive. If the teams I support would be better off with fewer messages from me, I am doing it wrong.

This is the part program managers get backwards. We confuse activity with value. Chasing status all week feels like work, but to the engineer it is pure cost, you are taxing the very people you are supposed to be helping. The program managers engineers trust are the ones who reduce their load. You are the rare person on the program whose actual job is to make everyone else's job easier. Act like it.

A horizontal security remediation I ran is the clearest version of this. I had to get a couple hundred teams to stop what they were doing and fix something across nearly two thousand services. Every one of those asks was a withdrawal from a team that did not plan for it. So I spent my effort making the ask as close to free as possible: a clear, specific fix, guardrails that did the hard part for them, and no ambiguity about what done meant. The teams that move for you are the teams you made it cheap for. Demanding does not scale. Removing load does.

The other half of removing load is refusing to be a tax yourself. Early on, my instinct on every program was to chase: ping each team for status, collect it, assemble it, repeat next week. It felt productive, and it was quietly making everyone's week worse, because every update I pulled was time an engineer spent reporting instead of building. So I flipped it. Instead of chasing status, I built one shared place where every team updated their own piece once, and everyone, including leadership, could see it. The teams stopped getting pinged. I stopped chasing. The status actually got more honest, because nobody was performing it for me in a one-on-one. That is the move: when you notice you are adding load every single week, go build the thing that removes it.

Tell the truth in both directions

The third one is honesty, and the test is harder than it sounds, because a program manager sits between the engineers and leadership and the temptation is to tell each side what it wants to hear. Resist it. I represent the engineers' reality upward, the real constraints, the real dates, even when leadership wants a more comfortable number. And I bring leadership's reality back down without sugarcoating it. Engineers can handle hard news. What they cannot handle is finding out you smiled, nodded, and then committed them to something they never agreed to.

The hardest version of this I lived through was a company-wide shift that moved a kind of work onto teams that were genuinely nervous about what it meant for them. Leadership wanted it kept vague and slow to keep everyone calm. I went the other way. I told the teams exactly what the end state was, exactly what would be asked of them, and exactly how they would know they were done. It was less comfortable in the moment and it was the only thing that built any trust at all, because the teams could see I was not managing them, I was leveling with them. You do not earn trust by being reassuring. You earn it by being straight.

And being straight has a cost you have to be willing to pay. Sometimes the honest number disappoints leadership, and you are the one standing there delivering it. Sometimes the honest answer to an engineer is that you pushed for something and lost. I have had to go back to a team and tell them the date they wanted was not going to happen, and that I had argued for it and been overruled. It is not a fun conversation. But a program manager who only ever carries good news in both directions is not trusted by either side, because everyone can tell the news has been laundered.

How you know it is working

Trust is hard to measure, so here is the signal I watch for. You have it the day an engineer brings you a problem before it becomes a crisis. Not in the status report, not when it is already on fire, but early, quietly, because they would rather you knew. That is the entire payoff. A team that trusts you tells you the truth sooner, says yes faster, and lets you see the real state of the work instead of the polished version. A team that does not will be perfectly polite and keep you exactly one step away from anything that matters.

None of this requires authority. It requires being credible enough to be useful, generous enough to reduce people's load, and honest enough to be worth listening to. Do that for long enough and you end up with something better than authority. You end up with teams that actually want you in the room.