The defining structural fact of the Technical Program Manager (TPM) role is that you are accountable for a program landing across multiple teams, but you do not manage any of them. The engineers, the other leads, the partner functions: none of them report to you. Everything you accomplish, you accomplish by influence, not authority. That is why influence without authority runs through most behavioral questions in a TPM loop, even the ones that never use the phrase.

Candidates who miss this tend to describe their programs in terms of what they organized: the meetings they ran, the trackers they maintained. Candidates who land it describe how they got people who had no obligation to prioritize their program to do so anyway. This guide covers where that influence actually comes from and how to make it visible in an interview answer.

Why the Authority Is Absent by Design

It is worth being explicit that the missing authority is a feature, not a flaw, of the role. Organizations use Technical Program Managers precisely because cross-team work does not fit any single manager's span of control. The program cuts across the org chart, so no one person has formal power over all of it. Your job is to create alignment where the reporting lines do not.

This reframes the interview. The interviewer is not checking whether you can give orders. They are checking whether you can make a team want to move in your direction when they could reasonably say no.

Where Influence Actually Comes From

Real cross-team influence rests on a few sources, and strong answers draw on them explicitly rather than gesturing at "building relationships."

Shared goals. The most durable influence comes from connecting your program to something the other team already cares about. If you can show a team that your program advances their own Objectives and Key Results (OKRs), you are no longer asking for a favor, you are helping them succeed. Making the program's value legible in each team's own terms is the highest-leverage move you have.

Credibility. Teams move faster for a Technical Program Manager who clearly understands the technical work than for one who is seen as a scheduler. It is part of what the technical mix round checks: enough depth to reason about the dependencies earns you the standing to coordinate them, as covered in how to read a system design.

Reciprocity. The classic model of influence without authority, developed by Allan Cohen and David Bradford in their book Influence Without Authority (1990), is built on exchange: people cooperate when there is a mutual "currency" being traded, whether that is future help, visibility, a removed blocker, or a smoother path to their own goals. Being the person who reliably unblocks other teams builds a balance you can later draw on.

Coalition. When one team is resistant, influence often runs through others. Getting a respected peer or a shared stakeholder aligned first changes the conversation before you ever have it with the holdout.

Escalation Is the Last Resort, Not the Tool

Every candidate eventually gets asked what they do when a team simply will not cooperate. The instinct to answer "I escalate to their manager" is a trap. Escalation is sometimes necessary, but leading with it signals exactly the inability the question is probing for. A strong answer treats escalation as a final step taken transparently, after the influence-based approaches have genuinely been tried, and framed around the program's risk rather than the person's behavior: "here is the dependency at risk and the decision I need," not "this person is blocking me."

A Worked Answer: Getting a Platform Team to Move

This answer is illustrative, written to show the structure, not a real case. The question: "A team you depend on has your work at the bottom of their backlog. How do you get it done?"

I was running a checkout redesign across four teams, and we needed the payments platform team to add idempotency keys to their API by week six. It sat at the bottom of their backlog, and their goal for the quarter was cutting on-call pages.

Before asking for anything, I read their incident log. Duplicate charges from client retries were one of their biggest sources of pages, and idempotency keys remove exactly that class of incident. So I went to their lead with their problem first: this change cuts your pages, and my program needs it by week six.

I also came with the design. I had walked through it with one of their senior engineers, who sketched a narrower version that cut the estimate from three weeks to about one and a half, and who backed it in their planning meeting. Their team was short on test capacity, so I offered our QA engineer for the regression tests.

I had an escalation ready: if the work was not scheduled by week two, I would take the date, the risk and the decision needed to both directors, with their lead in the room. I did not need it. The change shipped in week five, and the duplicate-charge pages stopped.

What the interviewer hears: shared goals (their pages, not my date), credibility (the narrower design), coalition (their own senior engineer), reciprocity (the QA help), escalation prepared but kept for last and done in the open, and a specific outcome.

How It Shows Up in Interview Questions

Typical questions: "A platform team can take only one of your three requests this quarter. How do you get the one that matters?" Or "An engineering lead says your integration date is unrealistic and will not commit to it. What do you do?"

What a strong answer does:

It names the source of influence it used, most often connecting the program to the other team's own goals, and it shows credibility earned through understanding the work, not just tracking it. It describes making the ask legible in the other side's terms, and it reserves escalation for last, framed around program risk. It ends with a specific outcome: the team moved, the dependency cleared, the program stayed on track.

What a weak answer does: describes organizing and reminding, or jumps straight to escalation, both of which read as coordinating activity rather than genuinely moving people.

Common Mistakes

Confusing activity with influence. Running the meeting is not the same as changing what a team decides to do.

Leading with escalation. It is the answer that most reliably signals you cannot influence without it.

Ignoring the other team's incentives. Influence that is not grounded in what the other side cares about is just repeated asking.

Under-investing in credibility. A Technical Program Manager seen as a scheduler has far less pull than one seen as a technical peer.

Influence in a TPM Interview

Influence without authority underlies almost every behavioral question in a Technical Program Manager loop, and it connects directly to structured decision-making: the DACI framework is often how influence gets operationalized, because naming a single Approver resolves the exact ambiguity that lets a resistant team stall a decision.

For the product manager version, with separate playbooks for engineering, design and executives, see How to Influence Without Authority as a PM.

For the full interview process this skill runs through, What Is a Technical Program Manager Interview? Complete Overview for First-Timers covers every stage of the loop and what each round tests.

Cala Voice runs you through behavioral scenarios built around cross-team influence, so you can practice narrating how you moved a team that did not report to you, out loud, before it comes up in a real interview.

Start your preparation →

Influence Without Authority in TPM Interviews: Where It Comes From and How to Show It