During my annual clear out of my LinkedIn DM’s of recruiter spam I noticed that the title “Staff Software Engineer” is now appearing regularly in recruitment approaches. It stopped me in my tracks. What exactly was that job? In software, nothing is solid, at least not for long. Job titles shift, levels blur, and hierarchies morph. This ambiguity, when contrasted with my previous experience working at Zone Cognizant, where the software engineer career ladder was clearly defined, left me puzzled. We had our Junior, Midweight, and Senior Developers, then Lead Developers, Technical Architects, and Solution Architects. My uncertainty led me to Will Larson’s “Staff Engineer: Leadership beyond the Management Track,” a book that attempts to demystify this increasingly common role.

I’m generally sceptical of applying the rules of Silicon Valley wholesale to the rest of the tech industry. The Valley is a unique beast, a product of an unprecedented concentration of capital fueled by nearly two decades of zero interest rates. The resulting bureaucratic structures are, in my view, a historical anomaly unlikely to be replicated elsewhere, at least in the West. However, it would be naive to dismiss it out of hand. Software engineering, at its core, has fundamental principles that emerge regardless of scale or environment. Certain organisational challenges and the need for specialised technical leadership roles will likely appear in any rapidly growing tech company, even if the specific titles and structures differ.

With that in mind, I dove into Larson’s book. Based on interviews with Staff Engineers from companies like Slack, MailChimp, Etsy, Dropbox, and Squarespace, “Staff Engineer” is a far more wide-ranging work than Larson’s previous book, “An Elegant Puzzle: Systems of Engineering Management.” While “An Elegant Puzzle” was insightful, it felt heavily focused on the specific culture of Silicon Valley and Stripe in particular. In contrast, “Staff Engineer” offered valuable advice that resonated with me, a frontend-focused tech lead in a smaller company far from the Valley.

Larson argues that “Staff Engineer” isn’t just a title but a distinct career path for senior engineers who want to remain technical while exerting significant organisational influence. He posits four main Staff Engineer archetypes: The Tech Lead, The Architect, The Solver, and The Right Hand.

The Tech Lead guides a single team, ensuring technical consistency and alignment. While often embedded in a stable team, they also collaborate with managers of other teams on larger projects, setting the technical direction for specific features or areas. They are deeply familiar with the team’s context and facilitate cross-team collaboration, working closely with Product Management. Importantly, Tech Leads shouldn’t be the team’s biggest individual contributors; they delegate complex tasks to scale the team’s impact. This archetype seems the most common, with Larson suggesting a ratio of roughly one Tech Lead for every eight engineers. In my experience, this role aligns closely with what many companies might call a “Senior” or “Lead” engineer, even if the responsibilities are not as formally defined.

The Architect owns the technical direction, quality, and approach within a critical system area. As systems scale, having a single expert focused on user needs, technical constraints, and providing organization-wide leadership becomes crucial. Architects are responsible for the success of their specific domain, whether it’s API design, frontend technologies, storage, or cloud infrastructure. Larson emphasises that successful Architects have an intimate understanding of the organisation, its users, and the technical landscape. This archetype is particularly valuable in complex, interdependent systems or when teams have accumulated significant technical debt. While I haven’t seen this role formalised to the same extent outside of larger tech companies, I’ve certainly witnessed senior engineers who naturally gravitate towards this type of ownership and influence.

The Solver tackles the most complex, often undefined, problems on the organisation’s horizon. Some Solvers are deep specialists, while others have a broad understanding of the organisation’s systems. They are typically long-tenured engineers trusted by leadership to work independently, often under conditions of high organisational risk. This archetype is less common in smaller, sprint-focused companies, emerging primarily in organisations with long-running systems and the corresponding levels of accumulated technical complexity. However, even in smaller settings, I’ve seen individuals who possess this knack for problem-solving and are given the latitude to pursue solutions, even if they don’t hold the formal title of “Solver.”

The Right Hand is dedicated to supporting a member of the executive leadership team. Found only in organisations with hundreds of engineers, they have minimal direct management responsibilities but act as highly mobile technical fixers for their executives. They must remain closely aligned with their leader, often jumping into critical problems and identifying the appropriate teams to address them. This archetype is clearly specific to very large organisations, and I haven’t encountered anything directly comparable in my experience.

Larson notes that the Architect only exists when companies reach 100 engineers, and the Right Hand is rarely observed in companies with less than 1000 engineers.

Beyond defining these archetypes, Larson emphasises the core activities that define the Staff Engineer role, regardless of specific title. These include setting and refining technical direction, fostering relationships through mentorship and sponsorship, and injecting crucial engineering context into organisational decisions. Outside of the interview transcripts, Larson then uses the rest of the book to impart nuggets of wisdom about how best to comport yourself in an engineering leadership role, referencing Tanya Riley’s  Being Glue – the often-invisible work of connecting teams, facilitating communication, and ensuring that projects move forward smoothly. This resonates with my own experience. As a senior engineer, the most impactful portion of my time is spent getting buy-in on a new approach or demonstrating patterns or processes via discussion and documentation, all aimed at ensuring alignment and shared understanding.

Larson also dives into the importance of strategic thinking for Staff Engineers.  He draws a distinction between “hill climbing” – a common approach where you iteratively improve by moving towards the nearest perceived improvement – and “exploration,” which involves taking calculated risks to potentially uncover much larger, more impactful solutions.  This connects to the idea, expressed by Katie Sylor-Miller’s interview, that Staff Engineers don’t gain more control over their work but rather the potential of more influence over the team as a whole. Larson urges Engineers to persuade and inspire rather than dictate. It becomes crucial to avoid what Larson terms “snacking”: focusing on high-visibility, low-impact tasks, chasing ghosts of past problems, or confusing familiarity with essentiality. Instead, the focus should be on projects with true strategic value, even if they require more time, effort, and organisational buy-in.

A particularly insightful section of the book explores the challenges of maintaining technical quality in a rapidly evolving environment. Larson advocates for a pragmatic approach, acknowledging that “the (on-call) roster is not the solution”. Simply adding more engineers to a scaling product’s on-call rota is not a solution to managing a product that is having reliability issues and also that adding premature processes can be more harmful than helpful if the underlying quality of the software is not baked in.
Instead, he suggests dedicating production time to improving quality system-wide via techniques like “hotspotting” to focus tightly on problem areas, leveraging techniques from Adam Tornhils’s Software Design X-Rays to identify areas of concern, and programs of work to improve it bit by bit. He emphasises the importance of defining and measuring quality, creating a shared understanding of what “good” looks like, and then using metrics to drive alignment. Larson notes that “Mmetrics keep you honest” and recommends implementing the DevOps practices detailed in Accelerate: Building & Scaling High Performing Software Teams.
He suggests creating a dedicated quality team for larger organisations who focus on building tooling to support the engineers working on product code. Larson suggests that for every 15 engineers working on product code, he would devote one engineer to working on tooling.
Larson emphasises that the most impactful way of maintaining quality as software scales is by effective architecture design. He emphasises the practices detailed in Building evolutionary architectures that seek to enable software to adapt to changing needs. Finally, in terms of quality, Larson emphasises that Conway’s Law is instrumental in maintaining quality over time as the team’s structure prefigures the software’s structure. This is where a staff engineer must use their influence to ensure that teams are structured appropriately to ensure that quality can be maintained.

“Staff Engineer” is a valuable resource for any engineer seeking to understand the evolving landscape of technical leadership. It has provided me with a useful framework to help make sense of the changing terrain of technical leadership. While rooted in the context of large Silicon Valley tech companies, its core principles – the importance of strategic thinking, influence over control, relationship building, and a focus on long-term technical health – are applicable across various organisations.  Larson’s book is not a prescriptive guide but rather a collection of insights and perspectives that encourage readers to reflect on their career paths and the unique needs of their organisations. It’s a reminder that technical excellence alone is not enough; true leadership requires a broader understanding of the business, a commitment to collaboration, and a willingness to embrace the challenges of navigating complexity.  The book’s emphasis on continuous learning, adaptability, and the importance of human relationships serves as a valuable compass for anyone navigating the ever-shifting terrain of a career in software.