Technical Leadership Without Authority

By Michael Samuel Naeem · January 9, 2026 · 5 min read

The staff engineer asked you to "just drive" the observability migration across four teams — no direct reports, no headcount, and one peer who thinks metrics are Someone Else's Problem. Technical leadership without authority is the default shape of senior IC work: you are accountable for outcomes you cannot assign. Success depends on trust accumulated before the hard ask, documents that survive hallway debates, and making other teams' wins visible when they help you — not on title power or escalation threats.

Clarify the mandate

Before acting, align with EM/staff sponsor:

## DRI brief: Observability schema v2
**DRI:** Alex (IC, payments)
**Sponsor:** Staff engineer Jordan
**Scope:** Adopt OpenTelemetry semantic conventions for HTTP + DB spans in payments, identity, checkout by Q2
**Not in scope:** Mobile SDK, log aggregation vendor change
**Decision rights:** Schema fields, rollout sequencing; EM escalates resourcing conflicts
**Success metric:** 3 services exporting consistent trace IDs; MTTR drill improvement in game day

Ambiguous "lead this" assignments fail when you assert decisions peers can ignore.

Trust before leverage

Sequence:

1. Help first — unblock teammate's prod issue, review PR thoroughly
2. Listen — understand each team's constraints before proposing schema
3. Pilot — prove value on your home team with measurable win
4. Invite — "here's what we learned; 2-day integration if we pair"

Skipping to step 4 breeds resentment.

RFCs that drive decisions

Structure for adoption:

# RFC: Standard HTTP span attributes
## Problem (1 paragraph + incident example)
## Proposal
## Alternatives considered (min 2, honest cons)
## Migration plan (phased, rollback)
## Open questions
## Decision log (updated after comment period)

Time-box comment period. Silence is not consensus — explicitly ask named dissenters. Record decision even if imperfect; stasis hurts more than reversible wrong choice.

Navigate conflict without escalation theater

When peer blocks:

• Curious 1:1 — "What would make this workable?"
• Split difference — phase approach incorporating their constraint
• Escalate with framing — "We disagree on X; options A/B; need decision by DATE for dependency Y"

Never win arguments in public Slack threads — move to doc comments or meeting.

Stakeholder map

Translate same initiative differently — one RFC appendix, multiple executive summaries.

Sustaining momentum

• Weekly written status — short, links to blockers needing sponsor help
• Demo wins — show trace linking incident root cause in retro
• Rotate ownership — others present their adoption, not your tour forever
• Exit criteria — declare done; do not infinite platform tour

Leadership without authority ends when bus factor remains you — build successors by documenting and delegating visible slices.

The tech lead triad

Even without direct reports, technical leadership usually involves three partners:

Role split for cross-team initiatives:
- Tech lead (you): architecture, technical decisions, implementation sequencing
- EM sponsor: resourcing, priority negotiation, people conflicts
- PM partner: scope, timeline, external stakeholder comms

When roles blur — you start assigning work like a manager, or the EM makes architecture calls without consultation — friction follows. Name the split in writing at kickoff.

Running effective cross-team working sessions

Working sessions beat async RFC comments for contentious decisions:

1. Pre-read required — RFC circulated 48 hours before; no pre-read, no opinion in meeting
2. Time-boxed options — present 2–3 alternatives with explicit trade-offs, not open-ended brainstorming
3. Decision owner named — who breaks ties if consensus fails
4. Decision recorded in doc — update RFC decision log before leaving the room
5. Action items with DRIs — not "team will investigate"; named person, date

I've seen RFCs die in comment threads for six weeks. A 45-minute working session with pre-read and a named decision owner resolves most deadlocks.

When to escalate vs persist

Escalate when:

• Decision blocks a committed deadline and peers won't budge
• Security/compliance requirement is being ignored
• Same disagreement resurfaced twice without resolution

Persist (don't escalate yet) when:

• First disagreement — give RFC comment period time
• Peer has valid constraint you hadn't considered
• Decision is reversible and low blast radius

Escalation framing that works: "We need a decision on X by DATE because Y depends on it. Options are A and B. I recommend A because [evidence]. [Peer] recommends B because [their constraint]. Can you help us decide?"

Building a leadership reputation

Technical leadership compounds over years:

• Ship reliably — teams trust leaders whose projects land on time
• Review generously — thorough PR reviews build reciprocity
• Share credit publicly — "Team X built this" in demos, not "I led this"
• Document decisions — RFCs become organizational memory
• Mentor visibly — pair on hard problems, don't solo hero

Authority follows reputation. The observability migration gets adopted because you helped three teams debug prod issues last quarter — not because Jordan said so.

Failure modes

• Leading without mandate — acting on "just drive this" without written scope and decision rights
• RFC without deadline — comment period extends indefinitely; decision never made
• Winning in public — humiliating dissenters in Slack; they block quietly afterward
• Bus factor of one — you become the only person who understands the system
• Ignoring EM/PM partners — technical decisions without resourcing/scope alignment fail at execution

Production checklist

• DRI brief with scope, decision rights, and success metrics documented
• RFC with alternatives, migration plan, and time-boxed comment period
• Stakeholder map with tailored messaging per audience
• Weekly written status with explicit blockers needing sponsor help
• Escalation path defined before deadlock, not during crisis
• Successors identified and delegated visible slices by project midpoint

Resources

• Staff Engineer — operating at visibility (Will Larson)
• Writing RFCs (Gergely Orosz)
• Influence (Cialdini) — ethical persuasion principles
• Crucial Conversations (Patterson et al.)
• Team Topologies — interaction modes