What do Staff engineers actually do?
The role of a Staff-plus engineer depends a lot on what the team needs and also what the particular engineer strengths are. From my experience the responsibilities of a Staff-plus engineer can change over time, but 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 a challenge. 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 easiest 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. They are doing those same tasks, but whereas previously they were the core of the work, they’ve become auxiliary work, and they have new priorities. Their daily schedule varies a bit by archetype, but there’s a shared foundation across all archtypes: 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 decisions 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’re motivated by, but in senior roles 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 than 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 ways to grow those around you is creating an active practice of mentorship and sponsorship.
Many career ladders have an obligatory checkbox around mentorship to qualify for a promotion into a Staff role, and mentorship is a key part of the role. Sharing your experience and advice, along with an ongoing relationship to understand the recipient’s context, is high impact work. In senior roles, mentorship is just the bar for admissions, and 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 for reviewing contracts for potential enterprise customers. Early on, there will be some contracts signed that the product and engineering teams is uncomfortable supporting. After that happens a few times, the process will include more stakeholders in the review steps, and overtime the right people will be in the right places at the right time.
There’s a second category of decisions, thoes which are both time-sensitive and important, and it’s more challenging to get the right folks into the room before those decisions get finalized. 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 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 keep engineer’s perspective heard. They’re also a moment when it’s easy to forget that your role in these moments is often to represent 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 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 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 sort of 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 diskspace 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, and it takes a great deal of organizational trust to be trusted with this work, including having the 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 needful to identify the right work and get it shipped. 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.”
Silvia Botros said, “I don’t do coding for the business anymore. I think the last time I had to pull up my terminal it was to refactor my dot files. This is an intentional decision by my boss, the Chief Architect. He’ll check in with us every quarter to make sure we didn’t contribute any code that goes into production.”
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.
Slow but rewarding
One unifying theme across Staff-plus work is that the timeframes are simply 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 feedbdack loop with one that takes weeks, months and years.
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, none of them regretted their transition into their current roles.