Reading of The Staff Engineer's Path

31 Mar, 2026

I recently completed my second reading of The Staff Engineer's Path by Tanya Reilly. This is my attempt to linger on my reading, as I posted earlier. It's not a review but a reflection on how the book affected me.

When I first read the book almost two years ago, I was a senior software engineer looking to get promoted. I looked for answers to questions like:

• What is a staff engineer?
• How do they differ from a senior engineer?
• Is being a staff engineer something I aspire to?
• If so, how would I get there?

Last summer I got promoted to Tech Lead. Returning to the book with this new perspective profoundly changed how I read it — this time I searched for ways to become a better Staff Engineer¹.

Funny how a book remains the same but we, the readers, have changed and see a book in an entirely new light.

There are a lot of valuable lessons in the book, but this is how it affected me most:

• A clear picture of what Staff Engineering is. The author presents a helpful mental model of three pillars (big-picture thinking, project execution, and leveling up), supported by a foundation of technical knowledge to create impact. This model captures the essence of a staff engineer's distinguishing skills. I often use it to reflect on whether I’m doing the right things.
• Writing code is NOT the highest-leverage activity. Coding less was tough for me, and the book helped me be more at peace with it. It was scary. Coding was such a big part of my career, the skill that made me valuable, and such a direct way of adding value. The activities that replaced it have much longer feedback loops but also larger impact.
• Being the grown-up in the room. The book made me aware that, in this role, how you act has a big influence on those around you. I’m using this knowledge to help the team keep their cool despite complicated or challenging situations and to keep morale up.
• Influence those within your orbit. People look to me as an example more than before. I’ve been using this to my benefit by setting examples in code, shaping how we work, and even increasing psychological safety. This point also reframed code reviews for me. I hated doing them, but now I see them as teaching and learning opportunities.
• Leading a project means actively steering it. Leading can take many shapes: tackling the hard problems, flagging issues no one sees, or unblocking the project, to name a few. Learning to steer a project is a big learning point for me. I’m in the process of figuring it out, but at least now it’s on my radar — front and center. I’m doing a lot more “glue work” than before, such as creating pathways for teams to collaborate, documenting decisions, facilitating discussions, and providing technical perspective in the near-future roadmap.
• Realizing I shouldn’t do it alone. Make room for others. Delegate. Rely on my team. As Tech Lead, I’m one of the most experienced members on a team, and it’s tempting to interpret that as having to solve the most problems. The book taught me that, in doing so, I’d hijack learning opportunities from others — short-term gain for a long-term loss. It also doesn’t scale. Time for coding in this role is radically less than before.

The Staff Engineer's Path is worth reading if you're a software engineer who wants to move beyond senior level but stay on the tech path. It answers questions like what a Staff Engineer is and how to be great at it. It has proven valuable to me, and I'll probably read it again in a few years. No doubt I'll see it with a completely different set of eyes again.

#books #career #tech