Working with people
Influence without authority
Shrink the ask, do their first draft, name shared upside, and escalate with options rather than a complaint.
You need another team to change an API. They do not report to you. They are mid-roadmap. Influence without authority is the pattern that still gets the change: homework, a small ask, a draft in their style, shared upside, a dated no if they cannot do it now.
Concept
This only works if you already deposited trust. A perfect one-pager from a stranger who always dumps last-minute tickets still reads as extraction.
The big idea
You are not convincing them you are right. You are making cooperation cheaper than refusal. People review faster than they author. People say yes to a day of work that also protects their pager.
The analogy is bringing a filled-in form to a clerk, not a blank complaint. The analogy breaks if the change is actually a quarter of their roadmap — then you need managers, a dated trade-off, or you build a compatibility layer and show the ongoing cost.
Walking through it
You need the payments team to add an idempotency key to a shared API.
- Homework first. Read their public docs and recent RFCs. Quote their constraints back so they know this is not work dumped over the wall.
- Smallest viable ask. Not "rebuild payments." "Add optional
Idempotency-Keyheader; ignore if absent so you can ship dark." Shrink until the cost is a day, not a quarter. - Do their first draft. Open a sketch PR or interface doc in their repo style.
- Name shared upside. "This also protects your team from duplicate charge bugs we hit in Q2" beats "we need this for our launch."
- Offer sequencing. "If you can't land it this sprint, can we get a committed week number?" A dated no is better than an open maybe.
- Escalate with transparency. If stuck, bring both managers a one-pager of options — not a complaint. Escalation is coordination, not prosecution.
Example
A platform team refused a "quick" schema change three times. The requesting engineer stopped asking for the change and wrote a compatibility layer, documented the 2× maintenance cost, and asked once: "Approve the schema change in Q3 or approve an extra engineer-week per quarter forever?" The schema change shipped. Framing the ongoing cost changed the incentive.
If new data kills your preferred option, say so quickly. People remember who protected their ego and who protected the outcome. Being visibly corrigible increases influence next time.
Common mistakes
- Maximal ask. "Rebuild payments for our launch" is easy to refuse.
- Private lobbying. Cross-team agreements that live only in DMs evaporate. Prefer a ticket or RFC comment with both teams tagged.
- Escalation as prosecution. A complaint without options makes both managers defend their people.
Check yourself
- You need an API change this month. What is a smaller ask than "rebuild the endpoint"?
An optional header or field they can ignore, shipped dark, with a sketch PR in their style.
- They cannot do it this sprint. What do you leave with?
A committed week number — a dated no — so you can stage your launch.
Key takeaways
- Shrink the ask until saying yes is a day, not a quarter.
- Draft in their style and name upside for their scoreboard.
- Escalate with options and dates, not a story about being blocked.
Further learning
Next: cross-team asks.
Related
Collaboration and disagreement
Build trust before you need it, disagree with data and options, and make cross-team asks easy to grant.
Building trust before you need it
Trust is credit you earn in quiet weeks. Keep small commitments, share context early, make others look accurate.
Cross-team asks
Other teams have roadmaps and review queues. Make saying yes the path of least resistance.