Becoming a Staff Engineer

I was promoted into the Staff Engineering role last October (2022). Coming into it I've read a small portion of the few books that exist related to staff engineering, specifically Staff Engineering by Will Larson and The Staff Engineer's Path by Tanya Reilly. I've also been really enjoying a couple of articles by Joy Ebertz on the topic.

My Initial Thoughts

One of the reasons I wanted to write this is to document my early thoughts before too many of my opinions become ossified by the interactions I have with other people.

• Everyone has a different vision for staff engineering
• Code and Culture
• Getting Here and Going There
• My Theory about Wealthy People
• First "Bullshit" Role

The DALL-E Prompt for this was: someone who is a very important software developer but tries to stay humble

Everyone has a different vision for staff engineering

I've asked 3 different managers, multiple other staff engineers, and architects how they've been thinking about my role on the team, especially as it pertains to how much code I should be shipping and in what way I should be most effective for my team. I've gotten a unique answer for every one of them.

Some people say Staff Engineers should ship roughly the same amount of code as senior engineers but within a much more efficient time frame. Others say staff engineers should provide a bigger focus on setting other team members up for success and less time on code. And others talk about the divide between making an impact on the team and making a cross-team or cross-org impact.

Based on the small amount of reading I've done... they're all basically correct.

Which leads me to my major theory...

Code and Culture

Staff Engineers are responsible for shipping code that has outside impacts on company culture.

One of the main focuses of reading I've done in the last 5 years has been around how much CI, deployments, and testing processes have an impact on the team. Often your team culture will fall into the limits and supports described by that system. Basically, as a senior engineer, any time you're making the same sorts of arguments over and over in a pull request, you should find a way to automate that and put constraints that help the team perform better.

Staff Engineering is like that, but with a much sharper look at specific cultural structures that can be unlocked by the sharp application of tools and code to the problem. It's not just about seeing code issues or cultural issues, it's about recognizing the highest leverage issues you can and then hammering on them until something beneficial comes out.

My experience so far is often this means putting myself into situations where I know the least, so I can gather the knowledge and provide a semi-better trodden path for the rest of the team.

One thing I've noticed is a tendency to fall back on processes and agreements. And, as always the political stuff is a part of the system. That whole bit about building narratives and getting buy in is super important. But I truly believe at th end of it Staff Engineering is about producing something tangible (even if it's quite small) as a pivot point for other developers to operate on and against.

Which leads me to...

Getting Here and Going There

One thing that's stood out most clearly as a role that I'll need to give up is how much urgency I act with.

In my role as a Senior Engineer, the fact that I treated issues with importance, urgency, and care was a primary reason (I believe) I was able to make myself a valued member on the team quickly. But, moving to Staff Engineering I'm starting to see how the stakes of that game have changed rather dramatically.

Firstly, it's the realization that if I'm acting with incredible urgency on most tasks, I'm not giving myself the time to think about those high value things I talked about earlier. Secondly, if I'm taking those tasks I'm taking up valuable opportunities to lift the rest of my team to learn and grow. And finally, acting with urgency conveys a certain level of importance given the title and my team will likely map to my behavior. By giving things space to breath I'm actually sending a message that we can plan, think, and react to events as they come in, rather than rushing to solve every minor problem as it shows up.

Which leads to a weird thing...

My Theory about Wealthy People...

And how it applies to Staff Engineering. One random thing I've noticed from the Elon Twitter saga, and also watching way too much Million Dollar Listing, is how much the problems of wealth change and shape the way you see the world. Specifically, as more and more of your problems can be solved by throwing money at them, the problems that people seem to encounter are the problems that are constraints more closely aligned with our current scientific, political, and social reality. I.e. problems you can't just throw money at.

Similarly, moving up the "ladder" at work into Staff Engineering I've noticed similar constraints. There are very few actual constraints on what I have permission to do. If I just go off and work on a project for 2 days, I will get a wide swath of trust that what I'm doing is valid, correct, and adds value to the team (even if I'm just derping around). But conversely, "just doing stuff" isn't actually going to move the needle for me emotionally or practically. Most of the constraints I've noticed are the hard political constraints of building momentum for a course of action, getting team members bought into a new way of doing things, or trying to implement a new technique/technology within the constraints of the old system. There just aren't that many if this then thats left.

First "Bullshit" Role

The final thing I've noticed is that Staff Engineering is the first role where coasting feels... possible. This isn't a subtle critique of current or past employers, it's more a recognition of the nebulousness of the role and the ease with which it would be to fall into its traps. As a Staff Engineer I'm no longer as directly tied to my ability to commit code. If I don't code for 3 months it's easily conceivable I'm working on a big picture sort of project that's high leverage but long term. And I'm also not responsible for people the same way as a manager might be. If my team is hypothetically struggling, I can give feedback to my manager, but ultimately my role is to help raise the level of my team not necessarily hold them accountable.

It's a weird, scary, and unconstrained place to be, and something I'm going to have to learn to live with. If leadership is about :staking your beliefs, then dealing with the uncertainty (and the potential for bullshit) is part of the stake. Learning to make my own hypotheses, argue for them, and try to align myself best to the business and my teammates is the thing I have to do.

Let's See How This Goes

I'm excited to look back on this in a couple of years and see what sorts of things I got right and wrong. Here's to an exciting 2023!