Moving from engineering into project and program management changed the kind of problem I was responsible for. As an engineer, I could often investigate a technical question directly. As a program manager, I needed work from design, quality, operations, suppliers, and leadership—people with their own priorities and, often, their own managers.
My move from senior engineer to project manager at Hospital for Special Surgery was gradual. I earned my PMP during that transition, but the credential did not make colleagues report to me. The practical work was to understand each specialist’s constraints, make decisions visible, and follow through when a handoff was at risk.
That is the familiar challenge of leading without direct authority. It is tempting to solve it by sending more reminders or escalating earlier. I have found a better starting point: make the shared outcome and the tradeoffs visible enough that people can make a real commitment.
Responsibility is not the same as control
In a matrix organization, a program leader may be accountable for delivery while functional managers control staffing and technical decisions. PMI describes this tension in its work on influence without authority. It is not a reason to blur roles. It is a reason to clarify who can decide what, where capacity conflicts sit, and which commitments are possible.
Suppose a verification activity depends on a design update and a lab slot. The program manager can surface the dependency, test schedule options, and ask for a decision. The engineering and quality owners still need to judge technical adequacy. The functional manager may need to resolve capacity. Treating all three as “the team should just finish it” hides the real constraint.
Start with the other person's constraint
People rarely resist a program simply because they dislike coordination. Their team may be handling a regulatory response, a supplier issue, or another high-priority launch. An ask that ignores that context sounds like one more demand. A useful conversation begins with the desired outcome and asks what would make the requested work feasible.
That does not mean accepting every delay. It means finding out whether the barrier is capacity, unclear requirements, missing evidence, or an unmade decision. Those problems need different responses.
| If the obstacle is… | A useful program move | Who may need to decide |
|---|---|---|
| Competing priorities | Show the tradeoff between two delivery paths | Functional manager or sponsor |
| Unclear technical scope | Define the question and acceptance point | Technical and quality owners |
| Missing input | Name the dependency and its owner | Source function |
| Ambiguous authority | Agree who recommends, approves, and executes | Sponsor and affected leads |
The table is less about a formal framework than about avoiding a common mistake: treating every missed date as a motivation problem.
Make a request someone can answer
“Can you prioritize this?” is hard to act on. “Can engineering review these two design options by Thursday so quality can finalize the test plan on Monday?” is easier to evaluate. It names the work, the deadline, the downstream reason, and the decision that follows.
I try to leave a meeting with one of three outcomes: a clear commitment, a clear objection with an owner for resolution, or an explicit decision that the program will take a different path. “We will circle back” may be appropriate, but only if it includes when and what information is missing.
A decision log helps because it separates proposals from approvals and records the assumptions behind a choice. It should be short enough to use. The value is not the log itself; it is the reduced chance that two teams leave the same meeting with different interpretations.
Do not confuse influence with taking over
Strong program leadership does not mean making a technical, personnel, or strategic decision that belongs elsewhere. A PMI discussion of boundaries in matrix organizations makes that point clearly. The program manager can frame options, consequences, and a recommendation; the accountable owner must still make the call.
That boundary matters to trust. Technical experts are more willing to collaborate when their expertise is respected. Leaders are more willing to decide when the options are clear. The program manager becomes useful by connecting the two.
Follow through in public, troubleshoot in private
Once a commitment is made, make its status visible to the people depending on it. If it slips, investigate early and talk directly with the owner before turning the issue into a broad escalation. Public visibility should reduce surprises, not embarrass people.
Leading without authority is not a personality trick. It is a repeatable practice of clarifying outcomes, understanding constraints, structuring decisions, and keeping commitments visible.
For a practical example of using AI to reduce coordination work while keeping people accountable, read How I Use AI to Manage Complex Engineering Programs.
If you are moving from an individual technical role into cross-functional leadership, see how to work with me. I am happy to compare notes on the handoffs that are hardest to lead.
Keep reading
Free for subscribers
The Engineer-to-PM Starter Kit
A readiness scorecard, a first-90-days plan for new technical PMs, three templates and an AI prompt pack. Subscribe and the download link comes in your welcome email.
Leave a Reply