On Becoming Staff+

Recently, a long-time mentee of mine made an introduction to a friend who was interested in learning more about the role of [what he called] “Staff+” engineers. I agreed to setup a call and spend 30 minutes or so on the phone discussing what these roles look like in big companies, and what the job entails. Beforehand, he sent me a handful of questions that he wanted to dive into, so I figured I’d share my responses in this post.

What does success look like at the Staff+ level?

Two words: Resounding impact. Your job is to regularly make very few high-quality decisions that have a measurable, long-term impact on the people/product/team/organization that you’re working with. Think things like: an architecture design, a new customer opportunity, a software framework, a development flow/methodology, a layout of how 10 teams should work together, etc.

What kind of skills do you think are needed to succeed that are generally not required or under-developed for lower-level engineers?

Public Speaking — You really have to know how to lead a room. One of the most important parts of the role is aligning groups of people, and as it turns out, speaking to them is a requirement.

People Leadership — Not people management. You need to know how to get people to listen when you speak, and follow when you walk. The trick of it is, you need to do this without authority…

Being Quiet — Know when to shut up and listen. Know when to ask questions and wait for the answers.

Politics — Unfortunately, getting groups of people to align usually requires some sort of organizational knowledge, political capital, relationships, etc.

Force Multiplication — Do things that allow you to move faster than you would on your own. Don’t build the whole thing yourself; instead design it, document it, build the framework, bring in others, etc. Getting a team to work together and execute on your vision multiplies your force.

Delegation — Learn to ask others to own pieces of the pie. You need to be in a position where others ask you what they should be working on, rather than you assigning them work. Delegation without authority is another tricky one…

Autonomy (and the ability to identify the right things to work on) — Understand what tasks should be done by what roles. Sure, you can write that request handler, but can’t 100 other engineers do the same? You should be focussing on things that require your expertise, not simply things that you are capable of. You are also no longer a person who moves tasks through a board, but still need to get things done.

What is some advice you wish you had been given when you were first promoted in the role?

Don’t build products that change the world, instead build people who build products that change the world. — For me this was the biggest realization. Growing people is a much higher-leverage operation than building products and features. Think of what you could accomplish with 50 of yourself…

Find ways to leverage your team to execute your plan. — See “Delegation” and “Force Multiplication” above.

Learn to choose the right things to work on. — See “Autonomy” above.

Be humble — Nobody likes an asshole in this role.

Empower others to succeed, but more importantly, to fail. — The “to fail” part of this is really hard to swallow for some. Letting people know that failure is an option and supporting that will go a long way… And chances are you’ll all learn something along the way.

How would you define impact at the Staff+ level?

Work that lives on and make noticeable noise throughout a particular technology, product, or team. It’s really that simple… If what you’re working on will [still] pay dividends 3 years from now, that’s the right kind of impact. You no longer regularly work on things that yield short-term results.

What’s your day-to-day like?

A lot of design, discussion, white-boarding, alignment work/meetings, etc. Not a ton of code these days except in crunch time or for force-multiplying activities like architectures, interfaces, etc.

What’s the path to the next level?

Demonstrating that you consistently have impact across an organization of a few hundred people. Showing that what you’ve spent your time on has impacted the results of the company.

Any specific advice for people aiming for the Staff/Principal levels at companies in the FAANG orbit?

The “decision” to try to get to this level is a common inflection point for a lot of ICs. You need to ask yourself if you really want to be an upper-echelon IC, or do you want to start managing people. There’s a difference between management and leadership, and the former comes with authority that makes [a veiled form of] leadership easier, while the later is an art and requires significant soft-skill development. You need a strong answer to the “do I want to manage people” question before you move forward in this quest.

Aside from that, a really specific piece of advice is: Learn to filter, then prioritize. Most people try to look at the list of 100 things they have to do each day and rank them… That’s a fool’s errand (especially at these types of companies) as it requires a deeper understanding of each item on the list, which is impossible. Learn to execute a function that produces a square curve, either a 1 or a 0, then only prioritize and rank the things that return 1. Get really good at identifying what to focus on before [even subconsciously] focussing on it.

I think the main take away for me with this discussion is that the upper levels of the IC engineering ranks are much more about people than they are technology, though technical excellence is still really important. There are some exceptions to that, where you have brilliant engineers who are creating new art who get these titles for their technical leadership alone. However, the vast majority of the people in these roles got there by being good people leaders, and having strong technical judgement.

Technical judgement is a funny thing though, you can’t really learn how to make good judgement calls, it’s something that unfortunately only comes with time and experience… A fact that a younger version of myself would’ve hated to hear.