Influence Without Authority

I wrote an RFC, got stakeholder buy-in, and drove adoption across four teams.

It sounds like an influence story. It might only be a meeting story.

The sentence does not reveal why four teams would spend time on the proposal, what they risked by adopting it, whether their objections changed the design, or what “adoption” meant after everyone left the room. Agreement is cheap when the work belongs to somebody else.

Influence without authority becomes visible in the distance between a good idea and another team’s changed behavior. A senior engineer can cross that distance without controlling the team’s roadmap: find a problem the team recognizes, understand its cost, reduce the first commitment, test the idea against a hard case, and leave behind a way of working that does not depend on repeated persuasion.

Find a story in which no one had to say yes

A useful influence story has real freedom in it. Other teams could postpone the migration, reject the standard, narrow the proposal, or spend their roadmap on something else. You did not own all the people, the budget, or the final decision.

That separates influence from two neighboring stories. In a conflict story, people are already inside a contested decision and the work is to improve its quality. In an authority story, an accountable owner can require compliance. An influence story begins with a change that still has to become worth doing.

Look for architecture alignment, a shared reliability practice, a dependency migration, a security control, a data-quality convention, a design-review habit, or a developer tool whose benefit crossed team boundaries. The change should leave evidence behind: production use, reduced special cases, a working pilot, a new review path, an owned migration, or a standard embedded in the way future work starts.

Avoid the story in which a peer did a favor after one request. Also avoid the story in which leadership ordered the organization to comply and you merely announced the order. Escalation may belong in the account, but hierarchy should not be the only reason anything moved.

The API standard nobody was waiting for

Consider a modeled example. Several product teams expose retryable workflows through HTTP APIs. Their local designs are defensible, yet the combined system has three meanings for an idempotency key, incompatible error categories, and different retry behavior. Client SDKs carry service-specific branches. Design reviews rediscover the same questions. Support engineers struggle to tell a safe retry from an operation that may run twice.

An engineer on the client platform writes a comprehensive API standard and presents it to the architecture forum. Service leads agree that consistency would be valuable. Six weeks later, no team has adopted it.

Calling those teams blockers would hide the engineering problem. The client platform feels the inconsistency every week; service teams do not. They would do most of the migration work while much of the benefit appeared in SDKs and support. One team is approaching a launch. Another has an asynchronous workflow the standard does not cover. Previous platform initiatives promised support, then left service owners carrying the operational edge cases.

The proposal was correct about the system and incomplete about adoption.

Replace persuasion with investigation

The engineer begins again, this time with the work rather than the standard. They collect examples of retry defects, repeated review comments, client-side branches, and support ambiguity. These do not prove that the proposed standard is right. They establish a shared problem and show where its cost currently lands.

Then they meet service teams separately and ask questions that a presentation would have skipped:

• Which new workflow is likely to expose this problem next?
• What would a migration interrupt or make risky?
• Which edge case does the draft treat too simply?
• Who would answer questions during implementation and own failures after launch?
• What evidence would justify putting this work ahead of another commitment?

The answers change the proposal. Broad API style, pagination, and naming rules move out of the first version. The minimum standard now covers only idempotency key behavior, retryable versus terminal errors, and one example response shape. Existing endpoints do not face a forced retrofit; the first target is new or materially changed retryable work.

Narrowing is not capitulation. It gives the central claim a fair test without requiring the organization to accept every adjacent preference.

Choose the pilot that can prove you wrong

The easiest service would produce a quick success and weak evidence. Instead, the engineer asks the most skeptical team to pilot the standard on an asynchronous workflow with the hardest edge cases. That team has a reason to participate: its upcoming API would otherwise require another custom client integration. The platform engineer supplies example code and review support, while the service team keeps ownership of its design and launch.

The pilot exposes a defect. The draft assumes that a retryable request has one terminal outcome, but the service can accept work and fail later. The teams separate request acceptance from job completion and revise the error guidance. The hard case does more for the standard than an easy victory could have. The skeptical team has changed the design, and other teams can see that it survived real use rather than only a clean example.

This is where the interview story gains credibility. The candidate did not possess the answer and persuade everyone else to recognize it. They created a process in which a useful answer could be tested, corrected, and jointly owned.

Make the next adoption cheaper than another exception

A pilot is still only one team. Influence scales when the result changes the default path for later work.

In this example, the revised rules enter the API design-review checklist. The service template gains an idempotency example and shared error types. A platform reviewer owns edge-case questions for the next quarter, and a small tracker makes adoption blockers and support requests visible without turning it into a scoreboard. Teams schedule changes alongside planned API work instead of an emergency migration campaign.

These mechanisms do not compel adoption. They alter its economics. The compliant path now has examples, tools, support, and a known review route; inventing another local variant requires more work and an explicit reason.

The result should stay bounded in the interview. Perhaps three teams use the standard for new workflows, repeated review comments decline, and client code removes several service-specific retry branches over the next release cycle. That is stronger evidence than claiming to have “aligned the organization.” It names changed behavior and leaves room for old endpoints and unresolved cases.

Preserve the boundary between influence and ownership

Cross-team leadership can become disguised control. The candidate should be able to say who owned each choice. In the example, service teams owned their roadmaps and production behavior. Architecture review owned the shared expectation. The platform engineer made the cross-team cost visible, proposed the smallest useful rule, organized the pilot, and supplied the adoption mechanism.

Escalation is appropriate when a risk genuinely belongs to a broader owner: for example, incompatible public contracts, regulatory exposure, an unsupported security exception, or a migration that no single team can fund. Explain the decision boundary that required escalation. “People would not listen, so I got their manager involved” makes hierarchy substitute for the missing adoption work.

Influence also has a stopping condition. If the pilot makes common workflows harder, reveals unacceptable operational cost, or cannot show meaningful benefit, the proposal should narrow, remain optional guidance, or end. The aim is to improve the system, not to win ownership of it.

Let the interviewer test the story

Stay inside the same event when the interviewer presses. The questions usually target the places where polished influence stories hide power or thin impact.

Interviewer: Why didn't teams adopt the standard when you first showed the
problem?

Candidate: The teams doing the work felt less of the pain than the client and
support teams did. My first proposal also covered too much. I had shown the
global benefit without making the local cost or support path credible.

Interviewer: Why choose the most skeptical team for the pilot?

Candidate: Their workflow contained the cases most likely to break the draft.
An easy pilot would have produced agreement, but not much confidence. They did
find a flaw: we had conflated request acceptance with job completion, and the
standard improved because of it.

Interviewer: Were you acting outside your lane?

Candidate: I did not choose their roadmap or own their launch. I brought the
cross-team failure evidence, funded the example and review work from platform,
and kept the service team as the design and production owner. Architecture
review owned the shared expectation after the pilot.

Interviewer: What was your personal contribution if several teams designed it?

Candidate: I identified that agreement was not the bottleneck, reduced the
proposal to a testable first standard, recruited a hard pilot, arranged support,
and moved the result into templates and review. The service team contributed
the completion-state model, which was essential to making the standard usable.

Interviewer: What would have made you stop?

Candidate: If the pilot had increased complexity for common workflows without
reducing retry defects or client special cases, I would have kept the document
as guidance or withdrawn it. Adoption was evidence about the design, not the
goal by itself.

Notice what the answers expose: unequal incentives, an initial mistake, shared credit, limits on authority, and evidence that could defeat the proposal. Those details make the influence believable.

Rehearse the adoption path

Take one influence story from your story bank and reconstruct it before you polish the delivery:

1. Name the people who felt the pain, the people who had to do the work, and the people who owned the decision. They may be three different groups.
2. Restate each objection as a deadline, cost, risk, ownership gap, missing case, or trust history that the other team would recognize as fair.
3. Cut the first proposal to the smallest change that could reduce the shared pain.
4. Choose evidence—a difficult pilot, review result, incident pattern, metric, or developer or customer cost—that could change the proposal as well as support it.
5. Name what you personally built or organized, what others contributed, and which owner made the final choice.
6. Show how later adoption became easier through code, examples, a checklist, a tracker, support ownership, or a review path.
7. Report a result small enough to defend, then state what changed in the way you approach cross-team work.

Invite a peer to interrupt after the first minute. Ask them to challenge why anyone should have adopted the change, whether the pilot could really fail, where authority entered, who carried the cost, and what happened after the meetings stopped. If the answer depends on other teams being irrational, your judgment is still hidden. If it ends at “buy-in,” the adoption story has not begun.

Keep confidential material bounded. Generalize employer and customer names, sensitive measurements, security posture, and proprietary implementation details while preserving the incentive and decision structure.

The mature reflection is not “I learned to communicate better.” It is a rule the next team could observe in your behavior: map who pays before proposing the change, recruit the hard case early, fund the support path, or make the desired practice cheaper than the workaround.

Related links

• Build the Senior Story Bank
• The Senior Story Spine
• Conflict and Technical Disagreement
• Decision and Trade-Off Log
• Complete Project-Deep-Dive Mock