[lacker]

When you are trying to become a good junior engineer, or a good senior engineer, it feels more like "checking off the boxes on the checklist". There are many skills that are expected of you, and you should gain them.

But you are kind of past that point. There are a lot of different "archetypes" for being a really good staff engineer. You can become very skilled at a particular technology, or very knowledgeable about a particular product, or very politically effective within a particular organization. For different people, the best strategy here is different. It depends what you're good at, and what you really want to be good at.

For your question - if you joined a new team, what skills would you really need? The answer is, it depends on what the team needs.

I think you might be focusing on the wrong details. The first step in taking your career further is to find a team that is a good fit for you. That means two things.

1. The team's mission is big enough that it needs a staff engineer (or another staff engineer)

2. The skills needed for the role of staff engineer on this team are skills that you have or can acquire

On some teams it will just be impossible for you to become a staff engineer, because there just isn't enough opportunity or importance, as perceived by the management. On some teams it will be impossible for you to become a staff engineer, because it will require a skill that just isn't you. So go find the right team, and then it will be far more obvious what you need to do to become a ridiculously good backend staff engineer.

Feel free to email me if you'd like to chat more, I have been the engineering manager for a number of people who have gone through the senior -> staff period in their careers....

[andher]

Thanks for the reply, this reframing of the question is insightful. I'm definitely more in the camp of generalist backend with some political savviness, because I tend to enjoy collabs and getting things out more than a technical deep dive. This leaning does make me question the utility of my skills vis a vis the more technical depth that a lot of folks acquire working in focused areas of interest. I guess I hadn't thought of politically / generally effective as an archetype for higher level eng positions, especially since that seems harder to translate when moving to new teams and companies. Folks have described the 'T' engineer as the most desirable shape for eng, and I assume the depth in that T is some particular tech niche or stack that you should be building out to grow.

> Feel free to email me if you'd like to chat more

Appreciate this.

[lacker]

The depth in the T does not have to be technical. The word "political" is often not specific enough and people think "well I'm not political so that isn't me" so maybe I can give some more detailed example scenario of how someone could give a staff engineer performance without being a narrow technical expert.

Let's say... an important piece of business functionality is divided between five backend services, each of which has its own engineering team. For the past couple years there have frequently been either performance problems or system-wide outages and nobody seems able to resolve it. Engineer X is on one of these five teams. They organize some processes, find some key people on each team to work with them, and convince the relevant managers to allocate resources to their project to improve reliability. The initial project is a success. For the next couple years, usage of these backend systems goes way up, since they are important to the business and now much more reliable. As usage grows, naturally reliability problems keep popping up, but Engineer X keeps their cross-team process operating and engineers participating in the process rapidly fix the reliability problems.

You could call these skills "political" but it might also feel just more like "being organized and communicating with the wide variety of stakeholders".

[rajacombinator]

Thanks for these insightful posts. I’m in a role that is exactly what you described above. (Perhaps prior to the “initial success” phase, due to political challenges.) It feels like I’m tilting at windmills in a management vacuum. Any general thoughts on how to detect in advance if these kind of projects are worth pushing through or if one should deftly sidestep them? Seems to be an unfortunate but necessary corporate skill.

[aprdm]

Yeah it's an interesting balance of asking per permission and pushing forward & begging for forgiveness. There's no true answer and it really depends on trust + culture + teams you're interacting with.

I've often error-d on the side of side stepping once I get a feeling that people have enough context on what I'm attempting and won't hate me for it :) even if not green-lit by upper management..

[andher]

Thanks for the concrete example, I can relate to this much more. It seems much harder to know, when interviewing new teams to join, whether this particular kind of skill set would be useful or valued, as opposed to being an expert in some technical niche.

[lacker]

When interviewing, tell the team's manager that you're really interested in working somewhere that you can have a big impact. Ask about the most important projects they have upcoming and about the biggest problems the team is facing, and politely dig into it. Once you are aware what the biggest problems are, you can usually theorize without too much trouble what skill sets are needed.