Frustrations with hiring into staff level

date2022-10-02
tags

While writing my 2022 job search retrospective, I realized my takeaway about hiring into staff/principal levels was getting too long and covered topics outside of my job search. I decided it made more sense to spin it off into its own post. This is that post!

Table of contents

My background

My official job title has been "principal" for roughly the last 4.5 years. I've been contributing at that level for much longer because most companies require you to perform at a level before they will promote you to it. That means I am a very experienced software engineer who has shown leadership as an individual contributor and had significant, company-wide impact.

Levels are confusing

Leveling is complicated because every company does it differently. Some companies use either "staff" or "principal" to mean roughly the same thing. Other companies have both, and "principal" is a level above "staff." Some companies use numbering systems. The supposed "bar" for these levels also varies pretty widely across the industry. It's very confusing and frustrating.

For the sake of simplicity, I'm going to use "staff" going forward in this post as shorthand for "very experienced, high impact, individual contributor software engineers with varying titles." I've seen that term used more commonly, so hopefully it will make sense to a wider audience.

The resources below provide some insight into what levels look like across the tech industry:

In my job search, I was hoping to find a staff-level role to reflect my level of expertise and the value I deliver. I found this a lot more difficult than I anticipated. I suspect it's partly because of the challenges in the market right now, but it's probably more than that. A common refrain I heard from recruiters and hiring managers included things like:

  • We only have a really small number of staff engineers that have been at the company forever.
  • We can't hire staff engineers externally.
  • Our staff engineers don't really write code any more.
  • We only hire backend engineers into staff positions.

If I talked to you about this during my job search, I swear I'm not picking on your specific company. I experienced variations of this at my last job and ran into it with several of the companies I interviewed with. I've also heard similar stories from people in my professional network. My suspicion is that this is a relatively common problem, but I don't have any data to back that up.

Organizational problems

I don't think this is a hiring manager, recruiter, or team issue. These comments are usually a reflection of organization-level decisions (or the lack thereof) that teams have to work within. For example:

  • Inability or unwillingness to hire staff engineers externally.
  • Requiring staff engineers to move into an architect-oriented role instead of having multiple options.
  • Undervaluing the technical complexity of modern frontend development and the associated need for staff engineers with expertise in that area.

I'm going to spend some time digging into these various issues and why I think they are problematic for the company, teams, and engineers.

One track for staff engineers

A common pattern I see across these companies is only providing a single track for very experienced individual contributors that is more focused on "architect" work. Architects tend to spend less time hands-on with code and projects and more time in meetings and making high-level architectural decisions. Hence the "our staff engineers don't really write code any more" comments.

Architects are really valuable, especially at larger companies that need very experienced engineers to help coordinate, drive, and scale large, complex, cross-team projects and systems. I worked in this role for a couple years when I was at New Relic and had a lot of impact on company-wide projects and frontend development. I really appreciated the organizational and technical insight from architects when I was in other roles throughout my career.

While architects are useful, that is not the only way, or even necessarily the best way, to use staff engineers. Depending on the problems your company is solving, it can be immensely valuable to have very experienced engineers doing deeper, hands-on work with specific problems or projects. When you only have one archetype of what a staff engineer looks like, you are limiting options for career growth. You're essentially telling very experienced engineers who prefer hands-on work that they can't get promoted (and thus paid more) unless they stop doing that high value work and move into a role that is less suited to their skills, expertise, and/or preferences.

This reminds me of the bad old days when engineers had to become managers to progress in their career. It was a bad idea that led to some pretty negative outcomes. Thankfully, the industry learned from this, and most companies now treat engineering management as a separate role with a separate ladder and progression. I don't think architect needs to be spun off into a separate role, but I do think it needs to be considered one of multiple variations for staff level engineers. This enables individuals to find career progression where they can deliver a lot of value to the company in areas where they excel. Not providing this option, leads to results like:

  • Losing experienced engineers to companies that handle this better.
  • Engineers becoming architects to get promoted and then contributing less value to the company because it's not the best use of their skills.
  • Engineers staying where they are to avoid becoming architects, becoming disgruntled about stagnation in their career (and their pay), and no longer delivering at the level they used to.

Even architect-focused staff engineers could really benefit from more hands-on time. Technology changes all the time, and people will struggle to keep up with it and provide solid technical leadership if they don't have time to touch code any more. I've seen myself and others burn out in this role because our day-to-day responsibilities did not leave space for tinkering, so we were doing it on nights and weekends to keep up with our areas of specialization. On the flip side, I've seen architects not do this and become increasingly out-of-touch, and thus less valuable to the company.

Only home-grown staff engineers

Some companies seem unwilling or unable to hire staff engineers externally. Instead they lean heavily on growing them internally from people who have been at the company a long time. Creating a pipeline to grow engineers internally and provide career progression is important, but it shouldn't be the only way to add more staff engineers to your company.

I think the unwillingness to hire externally and the requirement for staff engineers to be architects reinforce one another. Engineers in architect roles are often expected to have wide, complex organizational impact that relies on strong relationships and a breadth of knowledge of the organization's systems (both human and technical). A senior engineer who has been working with those people and systems for years may be more easily ramped up to a staff level than an external hire with staff-level skills can be ramped up and integrated into the organization. There can also be a lot of political issues around hiring externally for roles people are trying to grow into internally.

The down side of primarily growing your own staff engineers is that the majority of your most experienced engineers built their expertise at your company. If your company is trying to grow (and most tech companies are), that expertise is focused more on where you are than on where you are trying to go. Those staff engineers are incredibly valuable. They bring deep organizational expertise and historical understanding of your systems, but that's not enough by itself. Homogeneity can be really limiting. Hiring some staff engineers externally enables you to bring on people who have more experience with the challenges and scale you are working towards. The varying experiences and perspectives can lead to better results.

Of course, that returns us to one of my previous points. It's really difficult to bring on an external hire and expect them to rapidly get to know the organization, build influence, and make architectural decisions while sitting in meetings all day. I think there is a real benefit to bringing on staff engineers and letting them get their hands dirty for a while by working on a project and getting to know people before moving to more architect-oriented responsibilities. In fact, I think it's a good idea for some staff engineers to stay in hands-on technical roles indefinitely or to shift between roles depending on what the company needs.

I suspect that interviewing is another challenge to hiring at this level. Companies struggle with putting together the right combination of exercises and behavioral interviews to identify if someone matches their "bar" for staff engineer. This isn't a good reason not to hire staff engineers externally. Companies hire directors, VPs, and all sorts of other high impact roles externally all the time without a guarantee that they will be a good fit. Organizations need to figure out an interview process that is good enough and a process to handle bad hires, just like they do with other roles.

Backend only

While it is rarer than the other issues, I think it is worth mentioning companies that only have backend-focused engineers at the staff level. Sometimes this makes sense because the company is building software that doesn't have a significant user interface. However, the majority of modern software has a user interface, whether it be on web, mobile, command line, or all of the above.

There is a sentiment in some corners of the tech industry that only backend engineering is difficult and complex enough to justify a staff level. Anyone who believes this has clearly not spent much time on modern web or mobile development. Both of these specializations are complicated, especially at scale. They're just complex in different ways.

Organizations that make critical technical decisions and organizational investments without considering the entire stack are more likely to choose poorly because they're missing an important part of the picture. Staff engineers are more likely to be in meetings or consulted about these decisions. If all of your staff engineers are backend specialists, you're only getting input on the backend. Hopefully, you at least have some managers in the room that can advocate for frontend and mobile, but it's not the same as having people with recent, deep, hands-on experience in those areas.

Requiring someone to be a backend engineer to get promoted has similar negative side effects as requiring someone to become an architect. Valuable engineers with skills and aspirations that aren't aligned with the limitations of the company's career ladder may become disgruntled, leave for another company, or one followed by the other.

Prove it again

Now that I've explained the negative impact on companies, I want to return to how this impacts me and people like me. The issues I described create a situation where engineers are expected to come in at a sub-staff level and work back up to staff when we change jobs. This is a really hard pill to swallow.

At most companies, titles are associated with pay, so taking a title cut can also include a pay cut. A title cut can also mean you don't get access to the level of work and impact needed for learning and career progression. Instead of continuing to grow, you get to spend time proving over and over again that you are worthy of "staff" like you're in some terrible tech version of Groundhog Day.

This is especially frustrating because the promotion to the staff level is usually really challenging. It often depends on the perfect storm of good projects, a good manager, budget, and intense work. Many of those things are out of your control, promotions only happen occasionally, and a lot of companies want to see significant time in seat before promoting to that level. It's especially challenging to sign on for that in the current austerity-minded market where companies aren't handing out a lot of budget for promotions.

Having to prove yourself over and over again is exhausting for everyone, but it can have some additional frustrating dimensions for people from underrepresented and marginalized groups. There's a pattern called "prove it again bias" that comes up repeatedly in studies and articles about diversity and equity in STEM. If you already had to do twice as much work to justify the first promotion to staff, it feels even worse to have to do it again. No matter how many times someone says that "titles don't matter," they can make a significant difference if you are running into biases about what an experienced engineer looks like.

Conclusion

Some companies are struggling to figure out what to do with very experienced individual contributor software engineers. I strongly encourage companies to think about how they are hiring, growing, and utilizing staff engineers. Below are some recommendations for you to consider.

  • Your staff engineers should not be a homogeneous group. This goes for internal/external hiring, areas of technical specialization, and the demographics of the people involved. Diverse teams lead to better outcomes, and this applies to your "team" of very experienced engineers.
  • You should have more than one model for what a staff engineer looks like, both to better serve the company and to provide more options for career progression. Architect-focused roles are not the only way to use very experienced engineers.
  • You should develop processes that make it possible for you to hire some staff engineers externally to support the growth of your organization.