The role of a Staff-plus engineer depends a lot on what the team needs and also what the particular engineer's strengths are. From my experience, the responsibilities of a Staff-plus engineer can change over time. Still, usually, their main focus is working on projects/efforts that have strategic value for the company while driving technical design and up-leveling their team. - Diana Pojar

Anyone who has been cornered by relatives at a party and asked to explain what software engineers actually do knows that explaining the work can be challenging. Over time you may have created a compelling answer for your relatives, but many folks' minds go blank when their coworker leans over and asks, "What's a Staff engineer do?"

The most straightforward answer is that Staff engineers keep doing much of what made them successful as Senior engineers: building relationships, writing software, coordinating projects. However, that's a misleading answer. Staff engineers do those same tasks, but whereas previously they were the core of their work, now they're auxiliary tasks. Their daily schedule varies a bit by archetype, but there's a shared foundation across all archetypes: setting and editing technical direction, providing sponsorship and mentorship, injecting engineering context into organizational decisions, exploration, and what Tanya Reilly calls being glue.

Setting technical direction

I feel most impactful when I can facilitate setting a technical vision for an area and get people moving toward that vision. I think we would all agree that we want our code to be better architected than it is or improved in some way. However, I've found that often people have some vague sense of wanting better without having a clear idea of what that thing they want is. I like to help the group decide on a shared understanding of where exactly they're trying to get (it's actually okay if we never get there) and come up with a general game plan of how to get there. - Joy Ebertz

Much as the Lorax speaks for the trees in his popular children's book, Staff engineers speak for their companies' technology. Technology cannot speak for itself and requires effective advocates on its behalf. Folks who successfully advance technology are pragmatic, deliberate, and focus more on the long-term trend of progress than viewing each individual decision as a make-or-break crisis. It can be helpful to think of this as being a part-time product manager for technology.

Some Staff-plus engineers are explicitly hired to lead a specific area such as API design, and in other cases, they find themselves editing and aligning approaches across a broad area. One constant across all roles is that the reality of setting technical direction is far more about understanding and solving the real needs of the organization around you and far less about prioritizing technology and approaches that you personally are excited to learn about. In earlier roles, you may have tried to influence decisions towards technology choices you were motivated by; in senior positions, you're accountable to the business and organization first and yourself second.

Mentorship and sponsorship

In my current role, I feel energized when someone I've sponsored sends an announcement that they've shipped their work, or when I see that I've helped shape or shift an engineering team's model of an important topic. It's these teams, not me, who are doing the hard work day-to-day of building and supporting their technology. I measure my impact based on their progress and, more importantly, the directionality of that progress and the alignment of their work to the company's goals. - Michelle Bu

There's a popular vision of heroic leadership that centers on extraordinarily productive individuals whose decisions change their company's future. Most of those narratives are intentionally designed by public relations teams to create a good story. You're far more likely to change your company's long-term trajectory by growing the engineers around you than through personal heroics. The best way to grow those around you is by creating an active practice of mentorship and sponsorship.

Sometimes folks see a requirement for mentorship in their career ladder and try to mechanically check that box, which is a shame because mentorship is one of the most valuable activities in a Staff-plus role. Sharing your experience and advice, along with building an ongoing relationship to understand the recipient's context, is high impact work. The most effective Staff engineers pair a moderate amount of mentorship with considerably more sponsorship: putting your thumb directly on the scale to help advance and support those around you. If you haven't read it already, Lara Hogan has written the canonical piece on the distinction between sponsorship and mentorship, What does sponsorship look like?

Providing engineering perspective

I have a seat at the table at higher level engineering discussions that occur at a level above individual projects and teams. We have recurring staff engineering meetings where we discuss problems that span teams which are both technical and non-technical in nature. - Dan Na

Effective organizations streamline routine decision making. A good example of this is the process of reviewing contracts for potential enterprise customers. Early on, there will be some contracts signed that the product and engineering teams are uncomfortable supporting. After that happens a few times, the process will include more stakeholders in the review steps, and over time the right people will be in the right places at the right time.

Even companies that are great at making routine decisions often struggle when an unexpected decision shows up. The sort which is both time-sensitive and important, and it's challenging to even pull the right folks together before the decision needs to get made. It's frequent for an organizational restructure to occur without valuable input that would have changed the outcome. Similarly, it's common for interview loops for infrequent roles--those where you might hire one person into them each year like executives or Staff-plus engineers in an early-stage company--to not evaluate the candidate on an important dimension. For some companies, even things like roadmap planning fall into this category.

Staff-plus engineers are the folks who will often get unexpectedly pulled into the room where this sort of decision is happening. This gives them the opportunity to inject the engineering context and perspective into a decision while it's still possible to change the outcome. These brief moments of input on critical decisions are unduly impactful and will allow you to inject an engineering perspective where it would otherwise be missed. Just remember that you're representing the interests of all of engineering, not just your own.

Exploration

In my current role within the incubator, I'm spending all day prototyping, but in my previous tech lead role, I did a lot of different things. - Ritu Vincent

Hill-climbing is a simple optimization algorithm. Imagine you're standing on a mountain somewhere and want to get to the top. You turn around in a circle, identify the highest nearby point, and then walk there. Once you get there, you turn around in a circle again, find the highest nearby point from your new location, and go there. If you keep doing this, you'll get to the top of whatever mountain you're on. However, imagine you tried this on a foggy day. Because you can't see very far, you might get to the highest nearby point and later realize there was a much higher point just out of sight.

Hill-climbing can't solve every problem, but it's so effective that many companies struggle to take other approaches. This can be a consumer-oriented company struggling to support enterprise deals or a mature company struggling to compete with a smaller competitor's release cadence. It can even be the case that your current business is so valuable that it's hard to prioritize new businesses, even though the valuable business' growth rate is trailing downwards.

In the long-term, companies either learn to explore, or they fade away; this isn't an ignorable challenge. Simply assigning a team that's mastered hill-climbing to do exploratory work is far from a sure thing, so many companies take a different approach. They find a couple of trusted individuals with broad skills, allocate some resources, and check back in a few months later to see what they've discovered. One of those engineers is often a Staff engineer.

This isn't always a business problem either; it can be any ambiguous, important problem that the company's systems are ill-shaped to address. It might be reducing your infrastructure costs by an order of magnitude. It might be identifying a multi-region strategy that takes six months instead of three years. It might be addressing the sudden realization that your primary database only has three months of remaining disk space, and you can't upgrade to a larger size (in my experience, a surprisingly frequent problem at fast-growing startups).

This is some of the most rewarding and the riskiest work companies do. It takes a great deal of organizational trust to be trusted with this work, including having enough respect from the business that if you fail, it's a reflection on the problem and not you.

Being Glue

Tanya Reilly wrote a wonderful post, Being Glue, which captures another core element of successful Staff engineers: doing the needed, but often invisible, tasks to keep the team moving forward and shipping its work. It's not glamorous, but high impact organizations often have one or more Staff engineer working behind the scenes expediting the most important work and ensuring it gets finished.

But will you still write software?

It's impolite to end any discussion of the Staff engineer role without opining on the first question that Staff engineers ask when they congregate in a room together: "Do you still find time to write software?" The answer is, of course, it depends!

Ras Kasa Williams said, "I still contributed code regularly—certainly less than the rest of the engineers on my team; but it was important that I sustained "hand to keyboard" work to ensure that my technical strategy (and other macro-level decision–making) was informed by the on–the–ground experiences of the rest of my team."

Katie Sylor-Miller said, "I'm a frontend architect, but by far the main thing I've been writing lately is SQL, because I'm doing a lot of data analysis. I've been looking at our performance metrics to figure out where the areas for improvement are, and what would be the most impactful issues to fix to improve performance and business metrics. I will write little bits of JS or PHP here and there, but it's mostly to help unblock teams or to run small performance-related experiments."

Joy Ebertz said, "The more senior you get, the less your job is about code. Sure, unlike a people manager, you still have a very technical slant, and even through principal, you'll likely be doing at least some coding. However, the higher you get, the more your job becomes about mentoring and growing the people around you (and more broadly), building your team through building your company's public tech brand, noticing larger technical trends that can be improved upon or corrected, helping to set the tech vision for your team or the company and advocating for resourcing for tech debt projects."

Most write some, some write none, but none write as much as they used to earlier in their career. There will be the occasional week that is purely coding, but those won't be the norm, and if they happen too often, it's usually a sign of working on something comfortable rather than important. Even if you're not writing much, you'll be reading a ton of your coworkers' code and doing a fair number of code reviews.

Slow but rewarding

One unifying theme across Staff-plus work is that the timeframes are longer. Early in your career, it's easy to get attached to software development's quick feedback cycle--write, test, ship, repeat--and most of the work you'll be doing at this level replaces that feedback loop with one that takes weeks, months, and years. These longer timeframes can feel surprisingly demoralizing when you first take on a Staff-plus role. It's normal to end some days as a Staff-plus engineer feeling like you haven't accomplished anything--keep at it!

The impact and the personal growth lives in those longer timeframes, and while everyone I spoke with wished they'd occasionally get more time to code, and admitted worrying some days that they weren't accomplishing much, none of them regretted their transition into their current roles.