Introducing the staff role

Introducing a new level in your existing leveling framework and organization is not trivial, but can be an effective way of scaling your engineering demands in a growing org. I outlined a cheat sheet of steps on how a new role can be introduced without creating havoc. The title of this article mentions the staff level since that is quite the hype nowadays to have, but the underlying principle works for almost all kinds of individual contributor and manager levels, especially after the senior stage.

This doesn’t fully reflect how things have gone in the past, but it’s rather an idealistic reflection of how I would go about adding a new role, based on my observations of both successes and failures.

This post is inspired by caution: While I am usually on board with trying things and seeing what works, introducing a new role is a one-way operation. You can’t take it back, and if you butcher it will take you at least a year, if not two, to undo the damage to morale and confusion created. So for once, let’s be careful in our steps:

Preparation

Most of the work needs to happen in advance before you can reveal your new role. I found it helpful to set myself an announcement date, and work the timeline backwards to avoid overengineering all these steps - you can polish a role description for months until it becomes procrastinating.

1. Define the organizational need

I think for roles after senior (usually called staff+ as an umbrella term) you should start with the needs of your organization as the main driving factor. This might initially be disappointing to Engineers actively looking for promotions. It might also be a hindrance in closing key candidates during hiring: They might not be willing to “step down” in title compared to their current role.

Ultimately though, without a clear match between the role and the organizational demands in reality, these people won’t have a chance at success: Their responsibility will be muddy, or worse, equal to people on a lower level. This way you’ll exchange a small “win” today for a bigger problem later down the road.

Equally, once you have set up the role in the right context people will thrive there and clear out the problems that you have.

I wrote about the different archetypes of staff engineers, and I think you don’t need all of them at once, but probably one after the other. It’s helpful to also be aware of that when you roll out the role, and maybe just roll it out “partially” to certain archetypes or variants of the role.

You also need to work with your finance department to update your salary bands and get the budget - which should be easier when you can paint the benefit you will get from the role precisely.

2. Timing

When is the right time to introduce the staff role?

The easiest answer is when your problems are big enough. Some indicators might be:

• You do have a good separation of responsibilities between teams, but you now get technical challenges that require many teams (5+) to cooperate, and many of your engineers struggle with the complexity and build “local optimums” rather than a globally well working solution.

• You have tried and failed more than once to solve a technically challenging problem that can’t be “bought” as-a-service, because it’s at the core of what you do. Your previous solution kinda works but fails at scale.

• With continued business success, your previous ways of engineering can’t keep up and your system degrades at an unacceptable rate - you need external expertise on how you can survive the next 10x growth. Costs grow disproportionally compared to new revenue.

• Your Engineering Managers are getting overwhelmed with being responsible for the technical excellence of the product and people working at the same time. You want to hire more people managers and coaches rather than finding “unicorns” of technically well-versed leaders that can guide architecture.

• With the growth of teams, probably at around 10 teams or more, you see too many inefficiencies popping up: Duplicate technology, incompatible APIs with too much duct tape to hold it all together because people optimize for the needs of their direct team, not for the whole product.

A good reason not to hire staff engineers is when your engineering organization is dysfunctional and builds more accidental complexity than needed, instead of aligning with the business goals. This is not something the usual staff candidates can and want to fix, that’s a leadership problem.

Another bad reason not to would be empire building: If leaders want (or need) to have staff engineers to grow their careers, you should become cautious.

3. Restrictions

The junior to senior roles are in most cases not limited (except for the hiring plan/headcount model): Once somebody can perform on the level, they get promoted. For Staff+ roles though, there is usually a limit and an organizational restriction on how many of these roles exist. The effectiveness of Staff engineers lies within their reach over multiple teams/units, and as such, you can only have so many of them. I think we started out with one staff engineer per sub-product, which proved to be enough scope. As always - don’t have too many staff engineers on hand, or they’ll suck the oxygen out of the room (absorbing all the interesting problems), and worst case, create more complexity than you need.

Talk to your local leaders about what problems they are facing, and if a staff engineer could clear these problems away. If you make it a requirement for leaders of a certain level to commandeer a staff engineer - guess what, problems that justify staff engineers will be found ;)

In summary, I would suggest understanding how many staff roles will exist before introducing the role, even though this can be adapted later as your organization grows.

4. Role Definition

You probably already have a career ladder or other leveling framework available, and expectations are written down for each level. Before introducing the role, you should have this in place. I believe this is something to be owned by senior engineering leadership themselves, and can’t really be delegated. If you absolutely have to, you can produce a rough draft and ask somebody to polish it to the end.

But you can and should solicit input from your leaders to make sure there is alignment and common understanding about the role. Of course, “clever” Managers might try to bend the definitions to open options for their reports, but this document should be supporting the larger engineering strategy, not your immediate promotion needs.

The definition of the previous level might need some iteration as well - maybe it was too wide, and is “bleeding” into the area of the staff role.

5. Role Model

A role only really comes into existence once somebody is holding it. I think it works best if you already have someone set up to fill out this role - not somebody “barely” making it or not fully fitting the role, but a living lighthouse of what you want the role to be. It can be quite successful to hire somebody who has been performing the role already somewhere else, and hire them in the previous level (if they’re up for it), just to re-level them when the new role is announced.

This way you have a very clear living example of the new staff role, and somebody other people who want to grow into the role can look up to.

If there is no one who could fill the role immediately, you probably need to hire somebody and align the starting date with the announcement. But in this case, I would suggest scrutiny, as a mis-hire will be quite painful.

6. Hiring

Based on the Role definitions earlier, you should have an easy time crafting some clear and inviting job ads. If you want to get market feedback from candidates, you can do some active sourcing with people that you think might fit, but I would avoid publishing anything before the announcement to the internal organization. Your hiring funnel might need some work as well - different sets of interview stages or at least different guidelines for candidate evaluation. A group of interviewers needs to be briefed and onboarded on the new role. You need to get your Talent Acquisition team on board and help them understand what you look for in potential candidates.

Execution

After all the preparation is in place, the key part of good execution is well-timed and tightly orchestrated communication.

I would assume the fact that a Staff position is up and coming will leak eventually, but without details, people will paint out the missing details in their heads, and will ultimately be disappointed with reality.

1. Leader Briefing

Depending on if you were sourcing feedback on Role Definition and Expectations, your Leaders might already be aware of the new role, if not I would run some feedback-seeking sessions with this group. Besides getting feedback and buy-in, you want alignment: These people need to understand the requirements for the role deeply, as well as the organizational need. Otherwise, they’ll coach people in the wrong direction.

2. Announcement

It’s all hands time! I would take a significant block of time for fan-out communication: Announce the role and the reason for the existence of the role. Lay out the high level role definition, and if you have, announce the promotions[^1] and the role model for the role. You can mention if this role can be filled internally, or if you will exclusively staff it with external candidates.

It might be beneficial to hold a Q&A / AMA session as well, or at least prepare a FAQ slide from the early feedback you got.

Afterward, you can share the updated Role Definitions / Career Framework documents with everyone.

3. Hiring

Now it’s time to upload your job ads for the new role and start the public pipeline if you chose to hire candidates. Good luck and have fun interviewing :)

• Hypergrowth
• Staff