Cross-Org Influence Vocabulary

Influence without authority is the defining challenge of staff+ engineering — you need broad architectural alignment across teams that don't report to you, which requires sophisticated communication and relationship skills rather than management authority.

Tanya Reilly's "Staff Engineer" and Will Larson's "Staff Engineer: Leadership beyond the management track" both identify this as a core competency. Practical techniques: (1) Pre-alignment — talk to key stakeholders one-on-one before the group meeting so no one is surprised; (2) Create shared ownership — involve people in designing the solution rather than presenting a finished proposal for approval; (3) Name the trade-offs — don't advocate for your solution, present the options honestly with trade-offs; (4) Appeal to shared goals — frame your proposal in terms of what others care about (their team's velocity, their users' experience). The trap to avoid: relying on expertise authority ("trust me, I know better") — this creates compliance without understanding, which breaks down as soon as you're not in the room.

Key vocabulary:
• influence without authority — the ability to drive decisions and alignment in groups where you have no management reporting line
• positional authority — the power to mandate decisions derived from a management or leadership role
• pre-alignment — having individual conversations with key stakeholders before a group decision meeting to build understanding and reduce surprises

Being a stakeholder is both a right (to be consulted) and a responsibility (to engage constructively) — declaring stakeholder status creates an obligation to participate in the decision, not just observe it.

In technical decisions, relevant stakeholders are often broader than the immediate implementing team: teams whose services will integrate with the new component, teams whose users will be affected, platform teams responsible for hosting or operating the decision's output, security and compliance teams, and technical leaders responsible for architectural coherence. The RACI framework (Responsible, Accountable, Consulted, Informed) is a common tool for mapping stakeholders: "Consulted" stakeholders are the ones whose input is sought before the decision is made; "Informed" stakeholders are notified after. A staff engineer claiming stakeholder status is saying "I should be in the 'Consulted' category for this decision, not just 'Informed'."

Key vocabulary:
• stakeholder — a person or team with a legitimate interest in a decision's outcome because it affects their work or responsibilities
• RACI — a decision framework: Responsible (does the work), Accountable (owns the outcome), Consulted (input sought before decision), Informed (notified after)
• decision owner — the person accountable for the final call; distinct from stakeholders who provide input

The RFC process is both a decision-making mechanism and a knowledge management system — it captures not just what was decided but why, including the alternatives that were rejected and the concerns that were raised.

Well-known RFC processes: IETF RFCs (internet standards), Rust RFCs (language changes), React RFCs (framework changes). Internal company RFC processes vary but typically include: a template (problem, proposed solution, alternatives, open questions, success metrics), a review period (1-2 weeks for non-urgent decisions), a process for resolving disagreements (escalation to a tech lead or architecture forum if consensus isn't reached), and a decision record that archives the final choice and reasoning. The RFC process is particularly valuable for decisions that: affect multiple teams (cross-team alignment), are difficult to reverse (architectural choices), or are contentious (where perspectives differ significantly). For small reversible decisions, an RFC is usually overkill.

Key vocabulary:
• RFC (Request for Comments) — a structured proposal document for significant technical decisions that invites broad input before committing
• decision record — a document capturing a technical decision, its rationale, and the alternatives that were considered
• asynchronous review — a review process where participants contribute feedback on their own schedule rather than in a synchronous meeting

Sponsorship is organisational advocacy — the sponsor uses their relationships, credibility, and access to create conditions for the initiative to succeed, particularly when the implementing team lacks the seniority to navigate those organisational layers themselves.

Lara Hogan and others have written extensively on the distinction between sponsorship and mentorship: mentorship is giving advice and guidance (one-to-one, private, developmental); sponsorship is publicly advocating, making introductions, creating opportunities, and removing barriers (visible, organisational, impactful to career and work). For cross-org technical initiatives, a staff engineer sponsoring a junior team's work might: nominate their work for inclusion in the company's technical blog, advocate for their approach in architecture reviews, connect them with other teams who are solving related problems, and present their work at all-hands. Sponsorship amplifies impact by lending the sponsor's credibility and relationships to the initiative.

Key vocabulary:
• sponsorship — using organisational credibility and relationships to advocate for and unblock an initiative or a person
• advocacy — publicly supporting an initiative, approach, or person in organisational settings
• organisational credibility — the trust and relationships earned through a track record of delivering and communicating well

Earned authority is the primary mechanism of staff+ influence — it accumulates through demonstrated technical judgment over time and creates a presumption that the principal engineer's recommendations should be taken seriously, even without a mandate.

Tanya Reilly describes this as "the weight of your opinion" — senior engineers build up a track record where their assessments are consistently accurate, their architectural decisions age well, and their concerns turn out to be prescient. This track record means that when they express concern about a direction, the team pauses and considers carefully even if they could theoretically override. The risk: principal engineers who rely on "I've been right before" rather than explaining their reasoning undermine the team's ability to make good decisions independently. The most effective principal engineers share their reasoning explicitly, which both builds team capability and makes the recommendation more persuasive.

Key vocabulary:
• earned authority — influence derived from demonstrated expertise and a track record of sound technical judgment
• soft authority — influence that can be questioned and overridden, as opposed to positional authority that can mandate compliance
• technical credibility — the reputation for sound judgment that makes one's technical recommendations worth taking seriously

Sarah's message demonstrates influence by proactively identifying a potential issue and proposing a course of action. She's not simply stating a problem; she's suggesting a solution related to coordination – this is crucial for cross-org alignment. Option A incorrectly frames her role as solely responsible, while options C and D misinterpret the tone of the message.

David's comment showcases his influence by referencing a prior discussion and proposing concrete solutions. This demonstrates he's not just flagging an error but actively shaping the development path based on established priorities. Options A and D are unnecessarily demanding or accusatory, while option C lacks context and value.

'Flag' here means to bring something to someone's attention – in this case, the API errors. It's not about fixing the issue itself, but about initiating an investigation. The other options represent alternative meanings of 'flag' that don't fit the scenario of raising awareness.

'Impact' refers to the downstream effects of the change. It doesn't mean complete removal or just improving performance. Maria is highlighting that this refactoring could have consequences for other parts of the system – a crucial point when considering potential risks and dependencies.

'Taking ownership' signifies a higher level of responsibility than just participating. Ben is asserting control over the process, indicating he'll be accountable for its success and will coordinate with the DevOps team to achieve the desired outcome. This highlights leadership within the engineering context.

Chloe's comment focuses on the code itself – specifically its complexity. The goal is to propose a refactoring—a change in structure—to improve readability and maintainability, which are core engineering principles. Criticizing coding style or demanding a complete rewrite aren't the primary intent.

'Dependency mapping' is about understanding how one system relies on another. It's a crucial practice in distributed systems to proactively mitigate risks and ensure smooth integration. The other options represent different activities related to system management but don't capture the core concept of identifying and documenting relationships.