Video summary

LeadDev Bookmarked - The Staff Engineer’s Path: Tanya Reilly in conversation

Main summary

Key takeaways

Educational

Main ideas, concepts, and lessons

  • Staff engineering feels mysterious (“the rules are secret”) even though the role is long-standing.
  • A staff engineer’s job is leadership without relying on formal authority (“influence without authority”).
  • Many expectations are often unspoken, creating confusion for both staff engineers and their managers (e.g., “Do they need to code more to get promoted?”).

Leadership vs. management

Leadership is not the same as management:

  • Leadership
    • Broader in scope
    • Often influence-based
  • Management
    • Typically boss-like authority
    • Includes mechanisms like headcount/compensation/hiring

What staff engineers do (beyond technical execution)

The staff engineer’s work includes:

  • Setting direction, aligning teams, and building org capability
  • Leveling up others through mentoring, sponsorship, coaching, and culture shaping
  • Acting as a role model for engineering quality and culture

Methodology / frameworks and structured instructions

1) Three pillars of Staff Engineering (plus a technical foundation)

Tanya describes staff (staff plus) engineering as driven by three pillars, supported by solid technical skills.

Pillar A: Big-picture thinking

See a bigger picture in:

  • Space: broader across the org/teams, not just your immediate area
  • Time: beyond the sprint/quarter/half-year into longer horizons (e.g., next year, 5–10 years)

Evaluate:

  • Whether a problem is worth solving (not just how to solve it)
  • Whether it’s the highest priority for the organization
  • Feasibility: what’s achievable with current technology and constraints

Pillar B: Execution on bigger, messier projects

Projects at this level become:

  • More ambiguous (“mucky”)
  • Involving legacy systems, unclear support, and multiple stakeholders

The hardest parts are often not the coding itself, but:

  • Defining what success looks like
  • Aligning people across teams (especially when cross-team incentives conflict)
  • Handling ambiguity and coordination

Pillar C: Leveling up capability

Increase what the organization/team can do that it couldn’t do before by:

  • Mentoring, coaching, teaching
  • Sponsorship (advocating/helping others beyond normal mentorship)
  • Driving culture changes and improving how the org works

This also includes leveling yourself up deliberately (deliberate skill-building).

Foundation: technical skills are required

You can’t credibly do the three pillars without strong technical knowledge:

  • Big-picture and feasibility require real engineering understanding and best-practices literacy.

2) “Choosing what to prioritize” (project selection model)

Tanya provides a model for selecting projects that balances organizational importance with personal/organizational fit.

  1. Pick work that matters to the organization

    • If the work turns out unnecessary, senior engineers still “wasted scarce resource” (their time).
    • Senior work should avoid being duplicative or irrelevant.

  2. Consider constraints

    • Since only one person can’t do everything, you still must choose.

  3. Choose work that’s “good for you” (attributes-based tradeoffs)

    • Tanya proposes five attributes (framed as “bars to keep full,” inspired by The Sims):
      • Energy
      • Skills growth
      • Social capital / credibility
      • General quality of life
    • Projects trade off these attributes:
      • A project can be high social capital but exhausting.
      • A project can be important but not teach you anything new.

  4. When you have less “leeway,” start with what builds goodwill

    • New to an org: solve the most important problems quickly to build goodwill.
    • After you have goodwill/credibility: you can choose learning-rich work even if it’s slightly less critical.

  5. (Implicit leadership/capacity angle) Decide whether to do it or enable others

    • Senior engineers should think about scarcity of their time and leverage others.
    • Encourage others to perform at a strong level rather than always being the “single point of execution.”

3) Mentally reframing execution difficulty (how staff engineers should view blockers)

  • Don’t treat barriers as reasons to avoid the project.
  • Instead, staff engineers should:
    • Draw a “circle” around the project and recognize messy organizational factors are part of the job.
    • Shift mindset from:
      • “I can’t do it because legacy/ambiguity/stakeholders are in the way”
      • To “the hard part (alignment, success definition, cross-team coordination) is exactly why seniority is needed.”

4) Role model responsibility (quality + culture)

Tanya emphasizes the cultural impact of staff/senior engineers:

  • At staff level, you don’t get to opt out of being a role model.
  • Your actions implicitly set norms such as:
    • Test expectations
    • Document quality and readability
    • How people ask questions (psychological safety / openness)
    • Whether corners are cut
  • Being open about what you don’t know helps establish a culture of learning.

Speakers or sources featured (identified)

People / primary speakers

  • Tanya Reilly — Author; senior principal engineer at Squarespace (platform architecture & technical strategy); previously staff engineer at Google; host of Lead Dev Staff + conference.
  • Susan Bond — Moderator; former CEO of a scaling startup; executive coach specializing in tech leaders.

Referenced authors/books/figures (mentioned in discussion)

  • Camille Fournier — wrote the book foreword (mentioned as contributing to Tanya’s book’s forward).
  • Lara Hogan — suggested Tanya write/can help with writing process; referenced for “sponsorship” idea; also a future Lead Dev Bookmarked guest.
  • Will Larson — staff engineer community author; advised Tanya; his book and connection to the staff engineering community are discussed.
  • Melissa (O’Reilly) — emailed Tanya about writing another staff engineering book; O’Reilly is referenced as the publisher context.
  • Liz Wiseman — referenced via Multipliers (leadership book concept).
  • Michael Lopp — referenced via a prior Lead Dev talk about A/B performance rubric and coaching others.
  • O’Reilly (publisher) — referenced by name via Melissa.

Community / platform references

  • Lead Dev — global community organization hosting/hosting sessions.
  • Lead Dev Bookmarked — monthly book club format (named and described).
  • staffenge.com — referenced as the site where Will Larson’s interviews were posted (name mentioned).
  • Lead Dev Slack — referenced for ongoing Q&A.

Original video