Impressions
“Staff Engineer” by Will Larson offers an intriguing glimpse into the roles and responsibilities of high-level engineers within large and mature organizations. While the book provides a thorough explanation of different archetypes of staff engineers, I found that it leans more towards the theoretical than the practical for those not already in similar environments.

Archetypes Explored

• Tech Lead: The most relatable role, essentially an advanced senior engineer with a focus on optimizing team performance and collaboration rather than purely coding.
• Architect: These roles emerge in larger settings, where the stewardship of a business-critical technical domain necessitates a dedicated overseer.
• Solver: A troubleshooter moving across teams to address critical, often complex problems—a rarity in organizations that are highly sprint-focused.
• Right Hand: An influential figure working alongside senior leadership, often without direct reports, to scale the leader’s impact across the organization.

Path to Staff Engineer
The book offers guidance on ascending to staff-level roles, peppered with anecdotes from those who’ve made the journey. It paints a clear picture of the staff-plus engineer as a proactive problem-identifier and advocate, a stark contrast to being on the receiving end of tasks within smaller companies or less autonomous roles.

Personal Reflections
Despite my current position, where work is often defined and ticketed, I can see the allure of evolving into a role that demands the identification and championing of priority work. The transition from executor to influencer, from completing tickets to shaping the engineering agenda, presents an interesting professional challenge. I do this at the project level, assessing areas of technical debt or improving developer experience, but expanding influence to the broader organization seems to be the Staff+ differentiator.

Managing Technical Quality
Larson’s book also delves into the progression of managing technical quality as organizations grow:

1. Address immediate, critical problems.
2. Implement established best practices.
3. Focus on high-impact leverage points.
4. Ensure alignment in organizational approaches to software changes.
5. Quantitatively measure technical quality for informed investments.
6. Consider establishing a dedicated team for building quality systems and tools.
7. Initiate a comprehensive quality program to ensure accountability.

These steps are meant to be taken slowly and progressively - if prod is constantly broken you need to handle that first, and if you can’t get developers to write unit tests then you probably won’t have any luck instituting some form of quality program. Take things one step at a time and work on the most important things first.

Conclusion
While “Staff Engineer” charts a pathway for aspiring staff engineers, its true value may be realized more by those in a conducive environment. Some companies simply don’t need people operating in this role, and I think it’s hard to have organizational impact like Larson describes in certain environments. For those in smaller organizations, or in contract work, it’s a peek into a different world of engineering autonomy, one that may not be immediately actionable but is certainly worth contemplating for future career growth.