I'm trying to think of things to write that would be both easy to hammer out and valuable enough to garner upvotes during these few days when upvotes are extra valuable. So how about a topic I know a lot about: my job!

I'm a senior staff software engineer. What does that mean?

There's a couple ways to describe it.

Nominally it's a software engineering job equivalent to being a director, which is common big-org management speak for a manager who manages other managers (but not generally someone who manages directors—that's a VP). I often tell people I'm in "engineering middle management", which is a funny way of saying that I'm expected to be highly autonomous, mostly identify my own projects and drive them to success, and operate over multiple teams (if my projects aren't impacting multiple teams or groups of teams then that's too small a project and I should delegate it to a staff or senior engineer if I think it's important).

There's different ways to do the job, but most of the time it means I don't write code. Not because it's beneath me but because spending time writing code is almost never high leverage enough for it to be the right choice (there's almost always some other engineer who needs the growth opportunity of writing the code that I would be stealing from them if I wrote the code). This might be somewhat unique to me though because I seem to have higher comparative advantage in a few other skills: decision making (being accountable for making the right technical choices for the team and company), alignment building (getting everyone to agree on what we're doing), project management (making sure everyone knows what to do and when they need to do it by), and mentorship and teaching (helping others learn skills that will help them grow or at least achieve what they want). I have to find more than zero time to write code to stay connected to the ground truth of the work, but it tends to be restricted to side quests that don't have hard deadlines, hackathons, and Advent of Code.

Unfortunately, there's no good easy way to describe the job. I didn't understand it until I was already doing it, and I probably still don't understand it. This seems to be an inherent challenge for both managers and staff engineers: fundamentally your job is to decide what needs to get done and then get it done, and you do whatever it is that you can best do to make that happen. The rest is just details about your skills, the expectations of your organization, and what your org needs, thus it's somewhat hard to pin down what you do all day. For other perspectives, check out the StaffEng site.

That said, what if you want to become a staff engineer? How do you do it?

I can only tell you what I did. Hopefully it's helpful.

First, I spent 8 years as a software engineer (and more like 25 years as a programmer). I got really really good at writing software. So good that I got bored. It's not that there aren't interesting technical problems to still solve, only that they don't excite me the same way they used to because I have a deep, experience-based understanding of the work required to solve software problems, so there's less for me to learn about the world through the process of doing the work. I still get excited about doing cool things with databases and distributed transaction processing (my primary area of specialization), but mostly I know that if I wanted to do them it would take a team and a couple years of work to make it happen, plus I'd have to find a business reason to justify the investment to do the cool work. So first step to being a staff software engineer is get so good at being a software engineering that you start to get bored of it.

Once I started to get bored I had to figure out what to do. I thought I wanted to go into management, mostly because I didn't know about staff engineering at the time and figured it was the only option. So I went into management. First job: manage myself. My job became Head of SRE, which is a fancy way of saying I managed the Site Reliability Engineering function at a startup without any reports. This wasn't too different from my previous job as a senior software engineer, except now I had a mandate—a scope of responsibility to do whatever needed to be done within it. I planned my own work in coordination with the CTO, instituted programs (like oncall training for the engineers), and for a while even had a direct report working half-time for me.

I was able to jump on this opportunity because the startup had grown enough that it made sense to manage our infrastructure in house rather than outsource it. We had been deployed on Heroku and our bill was high enough that I could justify my salary in cost savings if I could get us running smoothly on AWS directly, so I did that. Over the course of 9 months I used this project as a springboard to go from senior engineer to head of a function. All I had to do was deliver on the project successfully and ask for the new job (by providing a clear plan about what I was going to do with it). So, second step was to identify an opportunity to become more autonomous, prove I could handle the responsibility, and justify the need for the role.

Now, along the way I did a lot of things that made it possible for me to pull this transition off. For example, in my first two years at this startup before becoming Head of SRE I was also the scrum master (aka the project manager). I took this role on mostly because I had seen really bad project management at other companies, and I didn't want something similar to happen to me again, so I jumped on the opportunity to own project management before I could be subjected to bad project management. Was the counterfactual of bad project management likely? Don't know, I didn't think about it that hard. I just wanted to not feel the pain again. All I can say is that it worked out in the end, because being a staff engineer generally requires you be good enough at project management to manage the work of at least an entire team (8-12 people).

On that point, a key experience in my path was managing an 18-month long database migration. This project was projected to cut COGS by 50% (and more than double operating margins) and improving our financials was a top company goal. I worked with 5 engineers over that time to take the project from proof of concept to roll out in production with no loss of data or downtime. This required solving a lot of problems across our stack, which made a lot of assumptions about the database layer and had insufficiently abstractions to make the process easy. Having a success like that was essential to making it to the staff level when I went for my next job. So it's worth saying that it's not just about project management skills, it's about using those project management skills to generate positive outcomes for the business.

I also got really into a few other topics. One is accounting. Might sound boring, but accounting is at the heart of all businesses. You need to understand and be able to speak the language of accounting to be part of management, and it has helped me as a staff engineer. Consider this one optional, though, as I think there's ways to be a staff engineer without much accounting knowledge (you can lean on your management partners to help you here).

I got into the idea of deliberately developmental organizations. Are DDOs a good idea? I still think probably yes, but they're easy to get wrong. What's important is that I spent a lot of time thinking about and then experimenting with ways to affect the culture of the organization and thereby understanding how organizations work. This is a key leadership skill you need to be a staff engineer. You have to be able to both navigate your organization and effect change in it. For example, maybe you need to foster a greater focus on quality or reliability among your engineers. This is not just about writing "better" code. It's about shaping the org to incentivize those things through mission statements, project stack ranks, 1:1s, and winning the hearts and minds of your coworkers. You can only do this if you have some gears for how a software engineering org works.

Finally, I spent a lot of time writing. This wasn't really for work, but clear communication is an essential skill for being a staff engineer. You'll need to talk to a lot of people and get them to do what you want, and you can only do that if they understand what you're asking them for. This isn't just about writing skills, either. Fundamentally I think good writing is about having enough cognitive empathy for your audience to understand what you need to say in order to generate the desired thoughts in their minds. You'll need to be able to do this as a staff engineer; otherwise your design docs, emails, status updates, etc. will generate more questions than they answer and that's not acceptable to function at this level. So get good at writing and communicating.

Now, as I said, I didn't know about staff software engineering until I was being offered jobs with that title. How did this happen? I see management and staff engineer as two sides of a coin: both are about achieving similar ends by slightly different means. Managers focus more on people and business needs. Staff engineers focus more on systems and technical constraints. Since I was functioning as a tech lead manager in my last job, it was easy to offer me a staff engineering position because it was simply specializing on one side of the management/staff divide. You don't necessarily need to grow and then later specialize, but it's what worked for me. Plenty of staff engineers specialize straight into it because they don't want to be managers.

So, to sum it up, if you want to become a staff software engineer, here's my advice:

get so good at programming you become bored
learn to operate autonomously to deliver results (become "highly agentic")
learn how to successfully manage projects with multiple contributors
build a rich mental model of how software engineering orgs work and be able to use this to change the organization

become a skilled communicator