Leading Without Authority: The Operating System of a Technical Program Manager
Every technical program manager eventually runs into the same uncomfortable fact: you are accountable for outcomes you cannot command. The engineers do not report to you. The architects do not need your sign-off. The executives who set the deadline will not write a line of the code that meets it. And yet, when the program slips, the first question lands on your desk.
The usual name for the answer is "leading without authority." I want to be precise about what that phrase means, because it is easy to get wrong. Here is the test I use: if you have to pull rank or escalate to get something done, you have not influenced anyone. You have borrowed someone else's authority. Real influence is quieter. It is when people follow your recommendation because they want to, because they trust that you are right and that you have their interests in mind.
After more than fifteen years running cross-organizational programs, I have stopped treating this as charisma and started treating it as a system. The job is simple to state and hard to do: make it easy for people to say yes. You get there by removing the reasons they would say no, the missing evidence, the unmanaged risk, and the extra work you are quietly asking them to absorb. Four practices do most of that work.
1. Lead with data, not opinions
People resist opinions and accept data. An opinion invites a counter-opinion, and you are suddenly in a debate that neither side can win on merit, only on volume or seniority. A number changes the conversation. It moves the discussion from "I think" to "here is what is true," and it lets the other person change their mind without losing face, because they are responding to evidence, not surrendering to you.
So when I want a team to change course, I do not arrive with a position. I arrive with the data that makes the right answer obvious: the cost of the current path, the measured risk, the comparison they have not run yet. The goal is not to win the argument. It is to make the argument unnecessary.
2. Align before you ask for commitment
Most "no" answers in a big meeting were earned days earlier, when someone was surprised. People do not object to your proposal so much as they object to being caught flat-footed by it in front of their peers.
The fix is to do the alignment in private, before the room. Walk the proposal around to the people who will have concerns, hear them out, and fold their input in while it is still cheap to change. Surface the objections early, when adjusting costs a sentence, not a re-plan. By the time you ask for a commitment in the meeting, the decision should already feel inevitable, because everyone who mattered has already been heard.
3. Do the work yourself
This is the practice most people skip, and it is the one that builds the most trust. It is easy to propose a solution and hand it to a team as a new obligation. It is much harder, and far more persuasive, to carry part of the load yourself.
Consider a project where we were rolling out a tool that converted projected business growth into hardware requirements for the annual planning cycle. The first design was ambitious: it asked every system-owning team to write custom code and commit real engineering time. The pushback was immediate and, frankly, fair. Owners argued that forecasting their systems took human judgment a calculator could not capture, and they pointed at an existing provisioning tool that already did some forecasting, asking why we did not just use that.
I did not try to win that argument with authority. I changed the design to lower the cost of yes. Instead of custom code, each team would express its forecasting logic as a handful of simple formulas built from key-value pairs, a fraction of the effort. Then I did the part that actually mattered: I sat down with every team, one at a time, learned how each system was forecast by hand, and helped them translate that judgment into their own formulas. I was not asking them to adopt my tool; I was helping them encode their own expertise into it. I also resolved the overlap with the existing provisioning tool by drawing a clean boundary, that tool owns provisioning, this one owns the growth-to-hardware conversion, so nobody was defending turf.
One team at a time, I collected sign-off until the entire ecosystem was on board. The outcome was the organization's first automated, standardized way to turn business growth into hardware needs, and because the formulas were simple, teams could adjust their own numbers each cycle without coming back to me. None of that came from a mandate. It came from doing the unglamorous work alongside the people I needed.
4. Build credibility over time
The first three practices compound into the fourth, which is the most valuable thing a TPM owns. Credibility is the interest you earn on every promise you kept. It cannot be requested, demonstrated in a single meeting, or charmed into existence. It can only be accumulated.
A senior leader I work with relies on my read of people and programs, not because I am persuasive in the moment, but because years of consistent, honest delivery have made my word a reliable signal. That is the whole game. When you have a long record of saying what is true even when it is inconvenient, and delivering what you said you would, your recommendation starts to carry weight on its own. People say yes before you finish the sentence, because the sentence has been right too many times before.
Influence that scales: design yourself out of the bottleneck
The most advanced form of leading without authority is building ownership models that no longer need you in the loop. Influence that depends on your presence does not scale; influence baked into how a system is owned does.
For years, a platform team I was part of forecasted specialized compute capacity on behalf of every product team, and all of that capacity sat in a central ledger we owned. It felt like control, but it made us a bottleneck. Every deployment, every ramp, every change meant our team had to shift allocations, track who was using what, and coordinate the details. Product teams had no visibility into their own capacity and could not serve themselves. We were spending our days on coordination instead of the platform engineering we were actually there to do.
The fix was not a better tracking process; it was a change of ownership. I introduced a policy to move capacity ownership to the teams that consumed it, and then I ran the migration to make it real, systematically transferring every allocation out of our central ledger and into the hands of the respective product teams. I aligned the product, capacity, and infrastructure partners on a new model: teams forecast their own needs, own their allocation, and control their own usage, while the platform team's role shifts from gatekeeper to provider. For the inevitable edge cases, like forecasted capacity sitting idle, I wrote explicit rules so everyone knew exactly when they could request temporary capacity, which kept the new autonomy from turning into a free-for-all.
The bottleneck disappeared. Product teams gained full visibility and could self-serve. Our team got its time back for reliability and velocity work. And forecasting accuracy actually improved, because the people who understand their own growth best now owned the numbers. I had more influence over how capacity was managed after I gave the control away than I ever had while holding onto it.
[[ IMAGE 2 — bottleneck-to-selfserve.png ]]
The real lesson
"Leading without authority" sounds like a constraint. It is closer to a higher standard. Authority is a blunt instrument: it can force one team for one quarter, and it spends down the moment you use it. Influence, earned through data, alignment, doing the work, and a long record of keeping your word, makes people want to move in the same direction, and that scales almost without limit.
So treat the urge to pull rank as a warning light. When you feel it, the real work, earning the yes, is still in front of you. Authority is granted. Influence is built, deliberately, one kept promise at a time.
