Staff Engineer

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.