Staff+ engineers aren't promoted so much as absorbed into the system. The system has its own logic, and once you're part of the machinery, you start to see how it really runs.

At this level, the work is less about code and more about context. You’re expected to navigate organizations as complex as the systems they build: networks of people, incentives, and constraints that are never written down. Success comes from recognizing how decisions actually get made, how priorities shift, and where influence lives. A shared canon equips us with the language, ideas, and tactics for an ecosystem bigger than any one person.

Books:

The Staff Engineer's Path by Tanya Reilly

The perfect starting point for understanding staff+ work. Reilly lays out the three pillars of staff engineering: big-picture thinking, project execution, and leveling others up. This book provides the foundational framework for understanding what staff+ work actually entails, beyond just "senior engineer++." It teaches tactics like: how to actually lead big projects, debug "why have we stopped?" moments, and working within the constraints of finite time and attention.

The Manager's Path by Camille Fournier

Even if you're committed to the IC track, understanding management is essential at staff+. Fournier shows us what manager's actually do. There's plenty of overlap with technical leadership, but managing people is its own skill tree. We don't need to master it, but understanding how managers think, what motivates them, and how they're incentivized makes us more effective partner across the organization.

Release It! by Michael Nygard

It's easy for staff+ engineers to slip into the role of on-call firefighter, constantly debugging outages and spinning plates. To be effective, we need to limit reactive work and create space for strategic thinking. Nygard provides the practical toolkit for building resilient systems that don't constantly scream for our attention. He teaches us to design for production, not QA environments, and gives us names for the failure patterns we keep encountering. If "circuit breaker" is already a part of your vocabulary, this book is a big reason why.

Domain-Driven Design by Eric Evans

Staff+ engineers translate between business reality and technical systems. As systems grow, the hard part shifts from the code to the problem space. DDD gives us language and patterns to make that translation without loss: ubiquitous language, bounded contexts, and clear seams. It helps us keep product needs and architecture in balance so today’s design doesn’t box in tomorrow’s business.

Kill It with Fire by Marianne Bellotti

Every staff+ engineer inherits legacy systems. Bellotti's tour-de-force teaches us "old systems are successful systems" that have survived because they deliver value. The book gives us the tools for protecting that value while modernizing strategically. Instead of a one-size-fits-all answer, she offers a menu of approaches, showing how to evolve systems without breaking what already works.

Thinking in Systems by Donella Meadows

Meadows teaches us to see the hidden structure behind complex systems. Stocks, flows, feedback loops, and delays are the building blocks of every complex system. With them, we gain a diagnostic toolkit to spot persistent issues and identify leverage points for maximum impact with minimal effort. Once we see these patterns, we’ll recognize them everywhere: in code, teams, and organizations.

The Pyramid Principle by Barbara Minto

Staff+ is scaled influence, and writing is our interface. Minto shows us how to make thinking legible: frame the Situation–Complication–Question, then deliver the Answer → Reasons → Evidence. These techniques have endured because they help busy readers decide fast. We use them for RFCs, strategy memos, and status updates when decisions, not prose, are the goal.

Good Strategy, Bad Strategy by Richard Rumelt

Everyone loves a good strategy, but this book earns its place because recognizing a bad one is high leverage. With endless priorities, backing a bad strategy, even from the top, is an unforced error. As staff+, we can choose our battles, and Rumelt shows how to pick the ones worth fighting.

The Unaccountability Machine by Dan Davies

I'll admit something, The Unaccountability Machine isn't a shared cultural touchstone for staff+ engineers yet. But it's my dark horse pick, and I believe it belongs here.

Davies reframes cybernetics as the “road not taken” after computer scientists chose to explore information theory. It offers an alternate lens for understanding complex organizations. One of its most powerful ideas is the Law of Requisite Variety: to steer a complex system, your responses must be as varied as the problems it throws at us. If a system can produce 100 different failure modes, operators need enough knobs to respond to all 100.

The concept that will really haunt you is the accountability sink. These structures divert blame, preventing feedback that would let the system address the root cause. Once you notice them, you’ll see them everywhere. It’s cursed knowledge, but the kind we need.

Essays and Articles:

Tanya Reilly's Being Glue

Reilly leads off the blog section just as she did with books. Glue work is a crucial concept for staff+ roles. We're often the only ones in the organization with enough context to understand why a particular piece of coordination, documentation, or process work is essential. Equally important is Tanya's insight about why glue work appears invisible and undervalued to others who lack that broader perspective.

Will Larson's Staff Engineer Archetypes

Larson has an excellent blog, and choosing just one article was difficult, but Staff Engineer Archetypes is the clear winner. He explains why the staff+ role takes so many different forms and how two people with the same title at the same company can have completely different day-to-day responsibilities. Understanding these archetypes: Tech Lead, Architect, Solver, and Right Hand, helps us figure out which path fits our strengths and your organization's needs.

Charity Majors' The Engineer/Manager Pendulum

Majors does an excellent job laying out the differences between individual contributor and management tracks, and the benefits of experiencing both sides. She makes the case that switching between IC and management roles throughout our career creates better leaders in both paths. I suspect this is the most widely read post on this entire list, and for good reason.

Patrick McKenzie's Don't Call Yourself a Programmer

McKenzie's article targets a junior audience, but it's worth revisiting with the perspective of experience. He makes a compelling case that engineering work isn't about writing code - it's about creating valuable software and operating it economically. The fundamentals of business value, communication skills, and strategic thinking become even more relevant as we advance to staff+ levels.

Dan McKinley's Choose Boring Technology

McKinley reframes “boring” as well-understood, operable tech. Boring frees attention for the truly new by keeping everything else legible and predictable. His “innovation tokens” give us a budget for novelty: pick one new piece and keep adjacent layers stable. That constraint lowers risk and speeds delivery when we adopt unfamiliar tools.

Richard I. Cook's How Complex Systems Fail

No Staff+ reading list would be complete without How Complex Systems Fail. Cook’s treatise explains why failure isn’t an edge case but the natural state of complex systems. For Staff+ engineers working to evolve the system, this perspective is essential. It reminds us that forgotten failures resurface, that resilience is built in layers, and that our real influence comes from shaping how the system adapts, not pretending it won’t break.

Steve Yegge’s Google Platforms Rant

If only we all had the wit and clarity of Steve Yegge in our writing. His Google platform rant is an instant classic. Part organizational case study, part culture critique, part technical architecture lesson. Yegge shows you how Amazon transformed itself through sheer organizational will (and fear), then dissects why Google failed to learn the same lessons. His insights about how technical choices reflect and reinforce company culture will change how we see every architectural decision. Oh yeah, he also explains why platforms are overpowered, which, despite being in the title, almost feels like a bonus insight compared to everything else he unpacks.

Newsletters:

Staff+ engineers operate at the intersection of technology and business strategy, where the landscape shifts constantly. While books and essays provide timeless wisdom, newsletters give us the ongoing context to apply that wisdom effectively.

The best newsletters do something books can't: they recursively build on themselves. When events validate or challenge previous ideas, authors link back to earlier issues with updated commentary. This creates a living knowledge base where important concepts are constantly resurfaced and pressure-tested against current reality. For staff+ engineers making decisions that will play out over years, watching these ideas evolve in real-time is invaluable.

Pragmatic Engineer by Gergely Orosz

Orosz has become the definitive voice for engineering in today's tech industry. His level of access to companies is unprecedented, providing insider perspectives on everything from layoffs to compensation trends to organizational changes. Every staff+ engineer should subscribe for situational awareness, knowing what's happening across companies is essential. That context helps us separate structural headwinds from local problems and pick the right fights.

Lenny's Newsletter by Lenny Rachitsky

Lenny writes for PMs, but we should read him to level up product literacy. His frameworks turn “what’s the user problem?” into testable hypotheses, experiments, and metrics. His guests, operators across growth, research, product and yes even engineering bring battle-tested playbooks. It helps us show up as credible cross-functional partners who align on outcomes, not outputs.

Stratechery by Ben Thompson

Stratechery is the macro lens for engineering decisions. Thompson ties industry structure to the constraints that show up in our roadmaps. He connects historical precedent to current events, revealing how earlier strategic bets shape today’s competition. The context shows the incentives and constraints driving technology choices, so the “irrational” starts to look inevitable and we can plan accordingly.

What's Not Here (And Why)

You won't find deep technical books on distributed systems, programming languages, or specific technologies in this list. No Designing Data-Intensive Applications, Effective TypeScript, or Database Internals. This is intentional.

By the time we reach staff+, we've already proven our technical depth. We know how to learn new technologies when needed. What differentiates staff+ engineers isn't technical excellence, that's table stakes, but the ability to navigate the organizational, strategic, and human complexities that surround technical decisions.

This list also skips the pure leadership and management books that dominate airport bookstores. While valuable, they're written for a different audience with different constraints. Staff+ engineers need resources that acknowledge our unique position: technical leaders without formal authority, architects who must consider organizational dynamics, strategists who still write code.

Read Write Execute

This is my proposal for the staff+ canon. I'll admit it's biased. My selections reflect a belief that staff+ engineering is fundamentally about executing in complex sociotechnical systems rather than just technical depth. This reflects my current role and experience. But as Will Larson shows us, there are many shapes of staff engineer, and different archetypes might benefit from different foundational knowledge.

Canons aren’t fixed — they are read, argued over, rewritten, and revised. What did I miss from this list? What would you add or remove? I'd love to hear how your experience as a staff+ engineer shapes your perspective on what belongs here.

The canon compiles, but it’s not bug-free. Patches welcome.