Books for software engineers and managers

Staff Engineer

Staff Engineer

Leadership Beyond the Management  Track

by Will Larson, CTO of Calm

Engineering Manager,
Tech Lead,
Star Engineer

How strongly do I recommend Staff Engineer?
7 / 10

Review of Staff Engineer Book

What I like about Staff Engineer by Will Larson – the lessons and ideas presented are applicable not just to staff engineers, but also to engineering managers and many senior engineers.

I also like that Larson interviews staff engineers from a diverse mix of races and genders, without pigeonholing them into conversations about diversity and inclusion in tech.

What I don’t like about Staff Engineer – like An Elegant Puzzle (Larson’s book on engineering management), Staff Engineer is very Silicon Valley centric. The interviews and lessons all come from high growth tech companies like Uber, Dropbox, Stripe, Slack, and Auth0. Teams with hundreds or thousands of engineers and job titles like Tech Advisor to the Head of Infrastructure.

For the other 90% of software engineers out there, it may be difficult to see the applications of Staff Engineer to your own work and careers.

Staff engineers feel less control over what they work on, not  more

Autonomy. Many engineers assume that once they’ve achieved a staff title, they’ll get more control over their work.

But as staff engineer, your responsibilities to the business greatly increase. While you may have more autonomy, your decision framework is now driven by business value.

Avoid snacking on easy but low value  work

This was a small tip from one staff engineer that I really enjoyed and want to avoid. Snacking is taking on low cost but also low value work. For instance, an easy bug ticket that doesn’t really improve things.

Snacking is tempting because you get the instant reward – you shipped a fix!

But in a matrix of with axes for value and cost, you’re probably avoiding the high value, high cost work – which is largely the point of being a staff engineer.

Write a software engineering strategy  document

Engineering leaders at smaller to midsize companies often have a vision, but don’t document how that vision manifests itself as a technical strategy. Larson provides the framework for authoring this engineering strategy.

Many staff engineers previously managed  people

Half of the Staff Engineer book consists of interviews with staff engineers and about half of those people previously managed people. The other half would never consider it.

It’s a good sign that people feel comfortable stepping away from people management if they don’t enjoy it (or aren’t very good at it), often to take an individual contributor role.

However, many staff engineers also said that their role does consist of pseudo-management responsibilities. You’re frequently doing 1:1s, you spend less time coding, and you’re working on strategy. But you’re not responsible for things like performance reviews and evaluations.

Staff engineers get access to the  room

Many senior engineers complain about not being in the room when technical decisions are made. As a staff engineer, they’re finally invited into the room.

Once you’re in the room, Larson provides solid recommendations about how to stay in the room. For instance, a lot of software engineers will initially misunderstand the purpose of the room – they view it as the place where decisions happen, whereas the room members might view it as the place where tough topics are raised.

Along a similar line, getting the title of Staff Engineer helps people bypass credential questioning and critiques – effectively others see their title and assume a high level of competence. This effect is particularly true for minority engineers.

In senior engineering positions you are accountable to the business first, yourself  second

Being a staff engineer involves working on efforts that have strategic value to your organization. Typically these are the most complex engineering challenges and/or provide the highest business value through unlocked opportunities or increased leverage.

In the past, you may have thought that the organization should be set up for your success. As an engineering leader, you need to flip your mindset. You are now responsible for setting the organization up for success.

Look for hot spots where small issues cause many  errors

In many software systems, most of the issues are caused by a few hot spots. For instance:

  • A handful of queries might disproportionately affect your database performance
  • A few API endpoints might cause the majority of your exceptions
  • A single flaky test suite might cause most of your failed automated test runs and failed builds

Engineering requires pragmatic thinking and for staff engineers that includes being on the lookout for hot spots that you can directly address.

When mentoring others, ask yourself who else could complete the work you are doing and grow from the  experience?

As a leader, your job is to grow other leaders. When a piece of interesting engineering work comes your way, you as a senior engineering leader must evaluate whether it’s right for you, or if that work would be better suited for someone else.

Ideally you can find an individual for whom this piece of work exists on the fringe of their competence. Just far enough beyond their current skills that they can still achieve it but they will need to grow.

Three reasons you communicate with execs: planning, status, or resolving  misalignment

Of these three, I believe resolving misalignment is probably the most important for both staff engineers and engineering managers to get tight. Where planning and status reports can be regularly scheduled, resolving misalignment requires more skill. To resolve misalignment you first need to recognize misalignment, then you need to develop the courage to have a difficult conversation. These conversations are often ad hoc. While seeding the idea asynchronously over chat can work, having these conversations in person or video chat is much better.

Build relationships early when starting a new role or joining a new  team

At some point, you will want to plant a stake in the ground and when that happens you ideally have some rapport established with the people who will weigh in on the matter. While building trust with some individuals happens quickly, others may take six months or more of meeting frequently and with intentionality before they are willing to demonstrate any vulnerability with you.

Staff Engineer