How to grow staff engineers

Let’s discuss how Engineering Managers can support their people on the journey toward the Staff Engineer Role. Why should we as EMs care about that? Of course, their success is your success and having staff engineers in your group lifts you up as well. But more important is that having one or more staff engineers in your group will allow you to kick in a few metaphorical technical doors toward a larger organizational impact. These are the people that can solve big and tricky problems for you. Ultimately, without them, you won’t grow into a more senior manager role. I assume most “great” engineering organizations make it a career progression requirement for EMs anyway. But the growth path of someone from mid-level individual contributor towards senior is different from the growth towards staff, and we EMs get very little guidance on that.

As a disclaimer, I have successfully supported people in a promotion to the “Lead Engineer” role, which in Personio is an intermediate step between Senior and Staff, and might map directly to Staff in other career frameworks.

Staff Engineers are diverse individuals

Our architecture was simple until the staff engineers found out they need to have more impact.

This sounds pretty obvious, of course. But besides ‘diversity’ from a demographic perspective, I believe that the work styles of Staff Engineers can be quite different from each other, even though they share a career level. The career ladders we have usually fail to support this and try to pressure everyone into one stereotype. All of them exhibit a flavor of leadership without being people managers. Will Larson has a taxonomy of staff engineers available which is already really helpful, but I derived my own slightly different model. As all models are wrong, but some are useful, it helps me to reason about what people are exceptionally good at:

The rocket surgeon

This person knows a particular piece of technology (or concept) extremely well. If it’s open source, they may have contributed to the codebase of this project, they regularly give talks at user groups or conferences about this technology, and they guide others towards adopting and using the technology. They know how to run it, where to use it and how to tweak it. A good signal is that if every person in the company ends up at a certain person when things get hairy, you might have a rocket surgeon on your team. That’s also an explanation of why such engineers gravitate to expert roles in consultancies or very big tech companies. In your org, these engineers gravitate to platform teams, and they spend a lot of time with various teams in a 1:1 setting unblocking others.

The tunnel digger

This person has a pretty broad knowledge about all things computer science, but also a few unbelievable superpowers: They can read documentation, they are too stubborn to give up when weird things happen, and they are hopeless optimists. Equipped with these superpowers, they can grind down every problem there is if you just leave them alone enough. Very often they are very motivated by technical problems and less motivated by customer problems, making their promo cases in product organizations hard to write. In unlucky cases, the tunnel diggers also leave a lot of debris behind them, so they need to be accompanied by a few other engineers who like to clean up after them.

The party organizer

This person can motivate a group of totally random people to follow their lead - to either organize an illegal rave or to group around a larger technological initiative. They are good at writing, talking to groups and generally, influencing others. These would be your go-to persons to research, choose and introduce a new library or framework to your organization. They are not exclusively married to a certain technology or methodology, but are usually experts in something and bring a ton of opinions about everything with them. They are probably the closest to Engineering Managers in Mindset but refuse to let go of code, rightfully so.

The gardener

These people are upholding a certain value or trait throughout your organization. This could be a part of operational excellence or work methodologies. They are everywhere, and usually clean things up and encourage/bully everyone else to follow their lead. They are well-known throughout the engineering organization. For some of them, you will always find them in every outage call, war room or another emergency vehicle. They have accumulated a large amount of historic knowledge of how your system works, how it should be improved, and where it usually breaks.

Important here is that while all stereotypes are equally valuable, the organizational need for each stereotype might be in different demand at different times and growth stages. For example, you only need a rocket surgeon if you have enough complexity and load on a subsystem to justify this person’s presence. Before that, you probably want to fill that need via consultants. If the organizational demand is not there, it will be insanely hard to promote such a person to the staff level.

Your Job as their Manager

So you have a promising Senior Individual Contributor who is already exceeding their current role. What should you do now?

In most tech orgs that do have a career ladder (and where this whole train of thought around staff engineers applies), you will be promoted based on a document that highlights that the person in question has been working on the desired level already. I wrote a bigger piece about this here. Your job as an EM is to guide the person to invest their time into the right topics:

1. Understand this person’s archetype.
2. Understand the organizational need for this archetype.
3. Map out with them what kind of work they need to do more to build a track record
4. Guide them doing the right kind of work
5. Collect the evindece
6. Advocate for them

Doing the right kind of work

For this to work out, the person needs to be exposed to the right kind of work without having the title yet. Sometimes this work is to be found in what the team is currently doing. But very often, this is not the case and you need to search for extra activities that have a larger organizational impact. This could be done as part of a “working group” or a project group that forms around a larger problem. For underrepresented groups, but to a lesser extent, everyone else, the staff title gives access to “the room” (or the projects). You as their manager need to support them to bridge the gap. With you bringing a neutral external perspective you can make sure all these dimensions are covered:

1. Delegation

To get enough headroom, your engineer needs to have enough time available to be able to contribute to all kinds of impactful initiatives. Some people are good at this (or just good at dodging work), but most of the time your senior engineers carry a lot of load in the team and not just feel responsible for delivery, but iron out all gaps themselves. Even if mentoring and coaching are likely an expectation at the senior level, managing yourself free to have additional capacity needs usually to be trained. This is where you can support them in 1:1s by going over their calendar and topics they are working on - if they are continuously swarmed with daily business, you need to help them on that first. Without that, any other initiative will drown or they will burn out eventually and not be prepared the life in the role.

2. Visibility

As their manager, you can’t simply delegate opportunities in someone’s direction until they have a track record. You can and should advocate for them, but they need to do the heavy lifting. They need to grow themselves into these work pieces. For this, they need to wrangle themselves into the room first - by being visible and outspoken about the topics they care about and want to do more of. Technical writing helps here, being part of guilds and working groups, and giving internal and external talks about topics. Usually, when a relevant project gets kicked off, a lot of people have positioned themselves already by being vocal about the topic and building up domain knowledge. These people will always have a headstart when groups around topics get formed.

Another very important aspect of this is that the engineer in question needs to understand this pattern, and not wait for opportunities to be handed over to them by you.

3. Filling the gaps

As we discussed earlier, you will most likely work inside a career framework that condenses the staff role down to one single set of expectations. No matter how outstanding your person is in their specialty, they need to have enough “wideness” to their work and impact to warrant a promotion. You need to support them to understand that and check in regularly so that they don’t lose sight of the unpleasant (to them) boring parts of the role expectations.

4. Covering the base

All of this will only work if their team is still doing well. Since your person will likely be ambitious and want to be promoted yesterday, you need to watch if the team-internal contributions are still on an expected level and if their team is not struggling by too much gap left while this person is doing impact work outside of the team’s scope.

Patience

Your candidates will likely be very ambitious individuals - it’s a prerequisite to get this far on the career ladder, you need to be pushing a lot. But all Senior+ Levels require a certain amount of manifested impact - usually things runnign in production and facing users - before a promotion can be determined. Since it’s downright impossible to take a promotion back without everyone collectively losing their faces and minds, a certain confidence for a promotion needs to be established. Conceptual work is important, but may pretty plans blew up specatularly before. This means it will take a bunch of time to get a promotion - if you haven’t gravely misleveled on hiring, you’re probably lookign at an average case of 2-3 years.

Connections

Many problems in Engineering Management can be sovled by telling people to talk to each other

If you can, I suggest to connect your candidate to recently promoted staff engineers, preferably from the same archetype. If they are willling to share their own promotional document, you get a lot of very clearly tailored insight towards what your organization values the most. Equally important would be rejected staff cases, if you can get interally access to this. This will tell you a lot about the “base level” of contributions that must be there before you can submit

Summary

I think getting people promoted to the staff level is quite doable and clear once you have internalized that the process to get there is very different from the process to get people to the senior engineering level. Making people walk the right path, in reality is a lot more tricky. But ultimatley, it’s very rewarding for both IC and EM to accomplish it. If you want to learn more, I recommend reading this book about staff egineers

• Staff