Staff Engineer — Chapter 1: Overview

Why I'm reading this

As stated before, I’m a Senior Software Engineer (frontend heavy) that wants to move to a Staff Engineer position, and in this process, this book came in handy — not only because of the title, but because it was one of the most recommended by others when I asked for pointers on that path. So that’s how we got here.

Chapter 1: the overview

The first chapter of the book is already eye opening in so many aspects. It settles the expectations about the role itself in a broader sense, and it also talks about who this book is for and who the position is for.

A major point is the definition of the staff engineer archetypes, those being the Tech Lead, Architect, Solver and Right Hand. The Tech Lead is the better fit for the “lead by example” approach; the Architect is the one who — like the name suggests — architects something and paves the path for others to continue; the Solver is the problem solver, no matter what the problem is; and the Right Hand is what I can see as the Solver+, the solver whose problems are defined by executives, for example. It also covers a bit of what the week of each of those archetypes looks like and what kind of work they tend to do.

A bit further in the chapter, it shows how to tell whether some of those are right for you, and also says it can happen that someone sits between multiple archetypes.

Then it covers, more generally, what a staff engineer actually does: setting technical direction, acting as a mentor and sponsor, being someone whose technical input is valuable, and someone who explores new domains and problems — like said before, to help pave the path in front, to discover, and to be the glue for the team, a force that keeps everything together and working properly.

It then finishes with some questions about the title itself. In some companies a Staff Engineer title is well defined but hard to achieve, while in others the title itself isn’t defined yet, but there will be Senior Engineers who act as staff engineers and get rewarded properly — just without the title. It also talks about the other stuff you get by being a Staff: being part of challenging topics, and not having to prove yourself, since the title carries the “I need to prove that I can do this” part of it, and so on.

What I thought about this chapter

First, the archetypes — those were eye opening for me. I do see myself in the Tech Lead one. I want to improve my skills as a fullstack developer to be able to solve more problems end to end, but not only this: I want to get to a point where I can lead a project from zero to something and see the team taking care of it, scaling it to more developers, to more users, and so on — all of this using my power as the “glue”. The person who checks how the team can optimize its building process to reduce recovery time from incidents, or to reduce time to production while keeping product development with no major frictions, so the product can grow and scale too — keeping product development and development speed in balance.

Also, the notes about agile companies rewarding and having a better space for the Architect and Tech Lead archetypes, while companies without a strong agile culture favor the Solver and Right Hand, were mind blowing. That explained to me why it was hard to fit some of my initiatives and ideas into another type of culture. Coming from two major companies with really strong agile cultures, and now being in one where the agile culture is there but isn’t that strict, made me question why that happened before — and now I want to get deeper into the book to see if it shows more details about that.

Now, let’s wait for the other chapters, the next one being “Operating at Staff”.

See you there!

Pedro M.