A Staff-shaped Hole

tl;dr

Regardless of perception, (almost) nobody has an effective Staff+ program (yet).

What you should read before

What do Staff engineers actually do?

The Archetypes

Who am I?

For my day job I’m definitively in the right-hand category. Think of me as an “Office of the CTO”-type and working alongside the People team at a Fortune 500 in an engineering department in the neighborhood of 900 people. I’m not a manager in that people don’t directly report to me, but my job is entirely about engineering culture, leadership competencies, internal community, and the like. My primary focus is on our internal Staff+ community and making sure they’re set up for success. I’m also a career engineer with the right technical chops but it turns out organizational trouble is where I find the most leverage.

What do I mean by “program”?

I use “program” to refer to the holistic view of all the components of the employee lifecycle. It’s onboarding when folks join the organization, it’s the ongoing conversations to make sure people are engaged, it’s the deliberate spaces folks can go to when things aren’t working out well.

Who I talk to

I’ve been working with internal colleagues alongside my friends and contacts in industry to better understand the current state of the world. All in all, I’ve interviewed about 60¹ folks at this point with the following 30-minute interview:

1. What’s your experience been so far here? Has the shape of your current job matched your expectations?
2. Have you seen, at your current company or anywhere, a particularly effective Staff+/senior IC program?
3. What would you like to see from such a program?
4. What problems have you run into that are particularly important to you?

And some context notes:

• Mean years of experience of the interviewees: 18 years.
• Combined years of experience: 1,080 years.

The results of the second question (have you seen an effective program?) have given me pause. There were essentially only two answers²: “No” and “Yes, Amazon… but I hated the culture and left anyway.” Given the range of places folks have worked, from BigCo to SmallCo to startup, nobody, other than Amazon apparently, really understands what to do with an engineer with 15+ years of experience that also doesn’t want to manage.

What the symptoms of dysfunction look like

So if we ask people directly if their IC program is effective and they say no, what does that look like and how does it manifest? Here’s a collection of signals I’ve put together from feedback and first-hand observation to let you know that your company probably has some organizational development to work on.

Managers hiring senior folks to be “self-directed” when they actually mean “unsupported”

• Usually seen at: All companies.
• Missing: internal support.

A very common discussion I hear goes something like this: “We’re drowning. Headcount finally opened and we can hire for the team. Junior folks take too long to come up to speed. Let’s just hire someone senior that can be very self-directed.”

If a hire is made you can’t name the people who are accountable for that person thriving you can safely swap “self-directed” with “unsupported.” Healthy self-direction is about autonomy with support.

At larger companies, say 150+ engineers, it’s also a false dichotomy that junior folks need more time than senior ones. The key difference is where they spend their time ramping up. Sure, you’ll need to give junior folks time to wrap their minds around technical things, which might take a few months… but staff folks with leadership expectations typically need much longer to ramp up. Especially if they lead via influence (See “Lead with influence” below).

A related phenomenon is hiring/promoting managers saying “Don’t ask me what to work on. You should be telling me what’s most important.” Firstly, an external hire has no idea how your organization works. You absolutely need to give hints and help a new person come up to speed and find all the ways to figure out what is important. And secondly, someone trying to move up the ranks almost certainly doesn’t have all the necessary context to judge what is “most important” according to the business needs, especially if their primary network is entirely within engineering.

Exploration Prompts

• What does your onboarding process look like?
• Do you have structured feedback? How often does it happen?
• What’s the 30/60/90-day plan for a person stepping into the role?
• Will a new hire have the right support to thrive in a reasonable time frame?

“Lead with influence”

• Usually seen at: All companies.
• Missing: internal support.

This one is pernicious because leadership is largely about influence but it’s also usually said by managers who hold structural authority in the company. The reporting lines of the company naturally align with manager positions. Managers have a monopoly on power. If managers were disempowered to write performance reviews, decide compensation, or even their team makeup they would probably feel pretty trapped. And yet this is often the circumstance non-managerial leaders are expected to work from. If some random person has to choose between doing what some Staff+ person knows would be better for the technical health of the company vs the person who writes their performance review (and thus decides their pay) I can tell you who’s going to win. “You should be able to influence people to make choices that go against their self-interest” is an absurd position- but I’ve heard it.

Coming at it from a second angle, if someone needs to “cultivate influence” then onboarding and “becoming effective” is going to take 18-24 months while they prove themselves to colleagues. It’s a combination of unsustainable, expensive, and wildly disrespectful to folks’ time and experience.

Exploration Prompts

• How do you support folks coming in?
• What systems support non-managers from getting their work done?
• Are you comfortable hiring external leaders?

Micromanaging the leadership

• Usually seen at: All companies.
• Missing: leadership competencies, role clarity.

Ostensibly you’ve hired some very senior ICs to be leaders in the organization. While nobody wants to be micromanaged, it’s especially true for people you hired expecting them to be leaders. Sometimes it’s because very hands-on founders have to step away and the loss of control leads to micromanaging engineering’s schedule and sometimes it’s just because people are control freaks. Whatever the particular cause it always creates dysfunction.

The folks in charge seldom think things are moving fast enough… but the size of your organization is going to impose kinetic limits. Certain things are just going to be slow and nothing you can do will change that because organizations are made of people. One of the most effective leaders I’ve ever worked with (literally managing thousands of people) told me once “the hardest part about my job is that it’s going to take at least six months to know if we’re even on the right track.”

Install feedback loops to see the progress, but put them at a granularity that makes sense. Check-in on goals on a recurring cadence and resist the urge to ask for out-of-band updates.

Exploration Prompts

• What do you expect your leaders to be able to do?
• What do you think of as leadership competencies in non-managers?
• What are you doing to ensure space for leaders and experts to be both leaders and experts?
• Do your goals have reasonable time frames?

“Everyone should be coding”

• Usually seen at: All companies.
• Missing: leadership competencies, role clarity.

Every once in a while I read a hot take about how “all managers should also be working” suggesting that management is, somehow, not real work. All my seasoned manager friends then have a hearty chuckle about how nonsensical that is and get on with their day. The junior managers though often take pause because they’re still internalizing that message. It’s a difficult jump for most new managers to accept that “management is real work.”

So here’s the tough pill for a lot of new staff+ non-managers to swallow: all the non-coding you do is now the real work. Editing other folks’ designs, mentoring, planning meetings, coordination- All of it adds up to a full-time job very quickly. Further, if the job is expected to have “scope & impact” there’s almost certainly no way to deliver on that via code, and even if there was, you would be having a greater impact by teaching other people how to do it.

This problem is particularly thorny because it calls into question personal identity. Am I still an engineer if I’m not coding every day? It’s very easy to justify the position that everyone should be coding and “as hands-on as possible” because it’s what you personally want to be doing. I do get it… but it’s also just not your point of greatest leverage anymore. The first counterargument is often “but won’t our high-level ICs lose touch and start designing things they don’t feel the pain or accountability for?” To which I say: if they are the ones writing the design you’ve already lost- they should be editing and curating the design of the folks with that accountability to grow them. It’s about teaching the next generation what to consider and how to think about the problem- not telling them what to do or how to do it.

Exploration Prompts

• Do you understand what your non-manager leadership competencies are?
• What do you expect staff+ folks to spend their days doing?
• When do you know that coding is no longer the right tool for the job?

You hired brilliant people to change the way you do things… and everything is exactly the same.

• Usually seen at: All companies.
• Missing: change management, role expectations, support, leadership buy-in.

Here’s a pretty typical story:

At last, you’ve managed to hire the great soul that scaled company X to the cloud. Her expertise in a particular area you have great needs around is unparalleled… And then she quits after two years of a mostly-fruitless journey. She has made some appreciable impacts but not the key strategic ones she was meant to.

Any time you hire a great leader and they don’t deliver the magical result you expected and leave burned out, it’s basically always the organization’s fault. Sometimes it’s a lack of maturity in organizational change management and sometimes it’s a combination of the other failure states (especially “Leading with influence”).

Exploration Prompts

• What are you doing to empower your experts to make a change?
• Is your organization actually willing/open to change?
• Do you have a change management strategy for making things sticky?
• Why do you believe you need an external person to achieve the desired change?

All men

• Usually seen at: All companies.
• Missing: shared values.

Still shockingly common. In my experience, this is almost always a mismatch with the company’s values. The things you care about have to be actively reflected in what you do every single day. No exceptions. You can honestly and sincerely say you care about diversity & inclusion (and mean it!) but if you aren’t cultivating it as a leadership competency, connecting it to performance, and making it the air you breathe it just isn’t going to change.

Exploration Prompts

• Do you actually believe in Diversity & Inclusion as core tenents?
• Are your “core values” your actual values?
• What are you doing to make people feel like they belong?
• How do you institute real change?
• Do you know how to holistically include Diversity & Inclusion into your organizational practices?
• When was the last time a [category of person] was promoted in Engineering?³

The only engineer you have is a de facto principal/CTO

• Usually seen at: Small companies.
• Missing: role clarity.

This is essentially only possible in very small companies. The summary is easy: the most senior person you have is not a de facto leader/principal.

Levels are tools to talk about career stages and expectation setting for particular roles. If the most senior person you have is 3 years into their journey they probably aren’t a post-career-level expert. One day, if your small company is successful, you’re going to need to introduce levels and you’re going to have a very awkward conversation- especially if you start hiring other folks that do have the experience.

If you do want to hire particularly senior folks at a very early stage, go for it, but have a growth plan. Plenty of small companies have tried to hire a very senior staff only to have it turn into a bitter battleground because nobody knew who was going to get to be the VP of Engineering or the CTO.

Exploration Prompts

• Do you understand how your current staff capability compares to industry norms?
• What do you expect from principal engineers?
• If you double in size do you know how that’s going to affect your people?

Recruiters writing “we’re looking for a senior, staff, or principal” for a single role along with a list of technologies.

• Usually seen at: startups, small companies.
• Missing: role clarity.

This is essentially “we just need people.” As a former startup founder, I can empathize. It’s just too wide of a net and there’s likely no internal definition of what these titles mean. Luring people in with whatever title resonates with them is certainly a strategy but it’s not setting people up for success.

Exploration Prompts

• What is the job description for the person you’re looking to hire?
• Does it make sense to advertise this role to a range as broad as 3ish-to-20ish years of experience?
• Do you have a plan for when you’re larger and you’ve only hired seniors/principals?

“We know we don’t want architects, but…”

• Usually seen at: Small-to-Medium companies.
• Missing: role clarity, career ladder, shared values.

This is a rapidly-growing company trap. At some point organizations that are used to being very flat come up against the point where social forces alone stop holding everything together. I don’t have hard evidence on this, but anecdotally I believe it’s around ~150 people. At some point thinking about architecture and communicating it is going to be a full-time job for at least one person. You don’t need a blessed council of approvers, but you do need accountability for making sure it gets done and all the organizational levers for them to succeed.

Exploration Prompts

• How do you decide who is going to be accountable for the technical health of the organization?
• How much time do folks spend “thrashing” on trying to reach consensus or decide things?

Custom leveling system

• Usually seen at: Small-to-Medium companies.
• Missing: role clarity.

A growing company wants to introduce a sense of a career ladder so folks can see what the next steps look like. Instead of hiring one of the key HR firms or someone with expertise in ladder design to explain the how’s and why’s, your engineers come up with their own leveling scheme with custom rungs from “first principles.”

Every single instance of this I’ve seen has been nothing short of an unmitigated disaster.

In one case, a rapidly growing startup of about 150 predominantly senior people decided to introduce levels via a quota system. The idea was only 1 in 10 engineers could be “senior” and only 1 in 10 of the “seniors” could be “staff.” It was essentially determining title by stack ranking people behind closed doors. Attrition was through the roof and A Lot(tm) of very good folks left (for good reason).

There are very good and valid reasons that nearly every company listed on levels.fyi looks almost identical. If you’re going to customize the levels and “meaning” behind them proceed with extreme caution.

Exploration Prompts

• How do you believe you’re going to do better than the experts here? (Sorry, you really just need to have experts do this.)

Folks aren’t thriving / under-utilized & under-stretched.

• Usually seen at: Medium-to-Large companies.
• Missing: role clarity, support.

You’ve hired a ton of great people… and they’re bored. If you hire someone accustomed to a very broad scope & impact in their previous role, and you hire them specifically based on that experience, and then don’t provide that immediately you’ve essentially bait & switched your new hire. If an individual is expected to “lead through influence,” and you don’t offer shortcuts to acquire that influence, don’t be surprised when senior folks show low engagement. Similarly, if someone is used to leading very complex efforts and they’re suddenly in charge of a single, small service they’re probably dissatisfied.

Exploration Prompts

• Do you check in with folks after they’re hired to see if the job matched their expectations?
• Are folks challenged? Are they engaged?
• Can you articulate what “optimal challenge” looks like for your folks?

“Staff+ is a qualitatively different role”… but that’s clearly not true.

• Usually seen at: Medium-to-Large companies.
• Missing: role clarity, support.

This one is more of a trap for internal promotions. Sometimes companies, big and small alike, create a step in their ladder/thinking that says “at a certain point, the career ladder rungs are qualitatively different” usually with a bias toward leadership. There’s even a cute quip that goes “senior engineers work in Docs, staff engineers work in Sheets, and principals work in Slides” to suggest how it changes as you rise. Your people have to justify not only that they have the scope, impact, technical chops, and whatever else, but also have to prove that they fundamentally “get” that the next level is “different.” Then they get promoted… and nothing changes. They’re still doing the exact same thing. They look around and it turns out everyone else who was also promoted is also still doing whatever it was they were before. If you use Radford style numbers where a senior engineer is 4 and a staff engineer is 5, the staff role ends up looking more like 4+1.

Exploration Prompts

• What changes when someone is promoted? If they were already “performing at level” does that mean their peers are doing something different?
• How do you communicate the change in expectations?
• Do new mechanisms of organizational support become available?

No language to discuss specialization

• Usually seen at: Medium-to-Large companies.
• Missing: role clarity, career ladder.

It turns out there are many different ways to practice non-managerial leadership and all of them are important to the long-term health of an organization. If you have more than a handful of services or engineering teams you really need a consistent approach to architecture if you plan to enjoy any economy of scale. It’s also likely the person or people doing architecture are also likely different from, say, PhDs specialized in machine learning.

Exploration Prompts

• Do you have a way to capture the difference between the breadth of the architect and the depth of the specialist? What about the engineers that focus on the organization itself?
• What does your career ladder look like?

A high percent (20%+) of engineering is Staff+

• Usually seen at: Medium-to-Large companies.
• Missing: role clarity.

This is also connected to level inflation. Healthy organizations tend to be shaped like a triangle or a diamond.

• Triangle: few people at the top building a wider-and-wider base of more junior folks to level them up.
• Diamond: A few at the top, and a few at the bottom, with a very healthy middle band.

If 1/5 of your entire organization is “post-career leadership” you’re setting up a very unsustainable situation. It’s usually a vicious cycle of “we can’t hire junior folks because we don’t have the bandwidth, so hire senior folks” except all that specialist knowledge they don’t know how to pass on… continues being specialist knowledge and is now also compounding over time. Top heaviness is a self-reinforcing problem.

Exploration Prompts

• Do we need this many leaders?
• Are we adequately challenging our people?
• Are you hiring enough junior folks for your leaders to actually lead?

What you can do about it / Organizational Development

If reading through the failure states was uncomfortable I have at least some good news. Your company is 100% not special in this regard. There are off-the-shelf solutions: hire a good People/HR team and make sure they have partners within engineering.

If we classified the failure states into buckets you’d be left with something like this:

• Lack of shared values. This is always the biggest issue. Does the organization articulate what it actually believes is valuable?
• Lack of role clarity. What is it you expect people to do? How do you know they’re doing it? Why do you want them to do it?
• Lack of support. What do folks need to do their jobs? Are they getting it?
• Lack of leadership buy-in. Does leadership believe that the role and “the clarity of what that role should be doing” are useful?
• Lack of leadership development. Does leadership know how to think about the problem space? (Startup founders, take particular note here). Does leadership know how to think of their own development?
• Lack of change management. Do you know how to introduce change in a way that makes it stick?
• Lack of learning & development. Are you investing in your folks’ career development? Do your managers know how to further and develop their reports?

This is all Organizational Development work. It’s important and necessary because as nice as “hire smart people and get out of their way” sounds, it’s just not how it works.

Returning to “Yes, Amazon.” I’ve never worked there and it’s large enough I’m sure these don’t universally apply, but plenty of folks I’ve talked to did and what they said could be summarized:

• Expectations on the role were well-documented and supported.
• You had same-level⁴ managerial leadership support to execute on the job.
• You had well-established institutional rails to succeed.
• The criteria you were judged against largely made sense.

If I were to generalize this into advice it would be: take organizational development seriously.

Thanks!

I would also like to give a special thanks to the folks that helped me with edits and feedback.

• Samantha Branham @glompix
• Marc Hedlund @marcprecipice
• Tim Kordas @timothyzillion
• Ryan Burkhardt @ryanburk
• Steve Conover @sconover

Footnotes