The Staff Engineer's Path
Source: https://www.oreilly.com/library/view/the-staff-engineers/9781098118723/ ↗
A book about what senior individual contributors actually do in large organisations — the work that creates value when you no longer write most of the code yourself.
Reilly, a principal engineer at Squarespace, describes three pillars of staff-level impact: big-picture thinking, execution of cross-team projects, and levelling up the engineers around you.
The book is valuable precisely because this role is poorly defined at most companies, leaving staff engineers to either become shadow managers or retreat into isolated technical work, neither of which justifies the title.
For product directors, it clarifies the engineering counterpart to their own role: the person whose job is to ensure that technical decisions across teams are coherent, even when no single team owns the problem.
Central argument
Reilly argues that staff engineers create value not through direct code contribution but through three distinct forms of leverage: developing a coherent view of the technical landscape, driving cross-team projects that no single team can own, and systematically raising the capability of engineers around them. The central thesis is that the staff role fails — defaulting into either informal management or isolated technical work — when these three pillars are left implicit rather than deliberately practised. By naming and structuring the work, Reilly makes the case that staff-level impact is a learnable discipline, not merely a reward for accumulated seniority.
Critique
The book's framework is built primarily from the experience of large, well-resourced organisations where staff engineers can afford to operate at a strategic remove from delivery pressure — a context that doesn't map cleanly onto scale-ups or mid-sized companies where senior ICs are still expected to carry significant execution load. This creates a tension the book doesn't fully resolve: the three pillars presuppose organisational slack and a degree of role clarity that many companies granting the staff title haven't actually established. Readers in leaner environments may find the framework aspirational in ways that feel structurally unavailable to them.
Why it matters for product
For a CPO, the book clarifies the organisational design question of what a senior IC counterpart to a product director actually does — specifically, who owns the coherence of technical decisions across teams when those decisions have product consequences but no single team has the mandate to make them. This matters acutely in areas like platform investment, data architecture for analytics, or API strategy, where product direction depends on technical choices that fall between team boundaries. Understanding that the staff engineer's job is to hold this cross-cutting technical picture is a prerequisite for structuring the product–engineering partnership at senior levels.