What even is Staff Engineering? No seriously, what is it?

“What the hell does a ‘Staff Engineer’ even do?” My coworker asked, his inflection implying something I wasn’t too enthusiastic about.

I shifted uncomfortably in my seat. Not because he was being a jerk or anything — the question was asked in jest — but because he’d been working very closely with a Staff Engineer for years at this point. For the most recent several months, that Staff Engineer had been me. If he didn’t know what I did, how was I supposed to answer this? And that was the weirdest part about this: I actually didn’t know how to answer this.

30 seconds before that conversation started, I would have told you that I was super confident in my abilities, my talents, and my position here at WillowTree. Now, I was questioning everything I’d ever known about my career. Nay, questioning everything I'd ever known about life. I had to take a long walk in the mountains (I like the mountains) and consult several oracles (confused strangers) in an attempt to find myself (ironically, I got lost on a hiking trail).*

One of the biggest reasons the title of “Staff Engineer” is so hard to wrap up in one quick explanation is because it entails such a wide scope. Over the course of my time as a Staff Engineer, I’ve had responsibilities that fall into all of the following categories at one time or another:

• Bugs on prod that need to be dug into
• Product-wide refactors
• Technical feasibility questions
• Building/editing pipelines
• Implementing brand new patterns or frameworks into a project
• Helping maintain a project’s full test suite
• Helping other devs with really off-the-wall issues
• Random, adhoc mentorship
• Fixing process issues or tweaking the process to get around things you can’t fix
• Oh and let’s not forget about that one time a client reached out and was like “Oh hey, all of our certs expire Sunday evening can you, like, fix this?” (I probably don’t need to tell you this, but this obviously occurred on a Friday at 2:30 because when else would it have happened.)

And the list doesn’t end there. I’d argue that it’s an endless list. The main point here is that the responsibilities that land on a Staff Engineer are less a list of responsibilities and more a general comfort and skill-level with the SDLC process and with software engineering as a whole. As a Staff Engineer, you’re your team’s (or teams’, depending on your given role) go-to individual for solving the tech questions you run into as you build out your product.

Questions a Staff Engineer is expected to answer will vary wildly from week to week, not to mention from project to project. They might be problems with your project’s software. Maybe your team just discovered a technical limitation they didn’t know existed and they need you to lead the conversation in figuring out a solution, or maybe a severe production issue just reared its head and needs to be fixed yesterday. Or, they might be software problems that would crop up if you didn’t foresee them. I spent a large portion of my time on the last project working on a number of large refactors that made the codebase easier to work in for our devs. If I hadn’t done those refactors, the project would have undoubtedly gotten too complex for any human (with our squishy, human brains) to maintain. My current project is one my team and I had to build from scratch. A large part of my role in setting things up was ensuring that good practices and patterns were built into the codebase from day one. Solving problems before they become problems is always going to be far easier and cheaper than the alternative.

Sometimes, the tech questions you’ll have to answer are literal questions from the client. “What if we built the thing we told you we definitely would never need?” “What if we scrapped all of the work you just spent 3 months on and did something else instead?” “What if it’s crucial that we have some piece of functionality that you’re only just hearing about 6 months into development that isn’t going to be a quick addition?” In a perfect world, our products would be fully and perfectly defined on day 1 and would never have any of these tech questions crop up. But, as anyone who’s ever worked in tech (or, honestly, anyone who’s just tried to get their computer to do something it didn’t particularly want to do) can tell you, we don’t live in that perfect world. Constraints change (sometimes for the better, often not). Key libraries you were hoping to lean on get deprecated. Software engineers are imperfect humans and write code with bugs. Your role as the Staff Engineer on a project is to make these obstacles as insignificant as possible for your team. And if the scope of potential problems is limitless it stands to reason that your list of responsibilities and the tech you work in will also be limitless.

That might sound intimidating, but worry not! You don’t need to be the kind of “10x” engineer who needs to do everything yourself. (Protip: don’t be. Not only will you be much cooler to work with, you’ll also be under a lot less stress.) The good news is you aren’t the only person on your team! You’re going to be surrounded by incredibly talented engineers, each of whom has their own specific area of interest and expertise. One of the most important parts of your job is to know what you can and what you can’t delegate. Because of the nature of the position, Staff Engineers tend to bounce from one thing to another in an endless game of Staff-Engineer-Pong. Often, multiple problems will pop up at once, and it’s your job in these instances to delegate work that can be delegated. If two high-severity problems are dumped on you at once, and your team mate is an expert in the field of Problem 1, you can ask for them to take it on while you tackle Problem 2. I spent a large portion of my time in my first Staff Engineer role figuring out where I was the single point of failure and making sure other people got trained in those responsibilities. This meant that I could delegate things that popped up if the need arose. Spoiler alert: the need arose. Many times.

So as a TLDR…well, there really isn’t one, which is why I need a few whole blog posts to walk you through what it looks like to be a Staff Engineer. If you’re doing your job well you’ll find that things like prod issues or other unexpected problems should be less common. In between those emergency issues there will likely be things you focus on more than others. I’m hoping to get into some of those in my follow-up posts, so keep an eye out for that beautiful name (mine) that induces calm and happiness: Chris Sellek. Thanks for reading! See y’all in a bit.

* Absolutely none of this happened.

If this topic interests you and you want to take a deep dive into it (or just hear someone else's perspective), I want to take a moment to highly recommend the book The Staff Engineer's Path by Tanya Reilly. Tanya does an excellent job discussing this topic in depth in her book, so go grab a copy!

Today’s blog post is actually the first in a series written by an incredibly talented and all-around amazing human (me) on what the Staff Engineer role entails. My credentials? I’m an incredibly talented and all-around amazing human! (Also, I guess I’ve been a Staff Engineer here at WillowTree for 1.5 years now.)