In August of 2019 I became a Staff Engineer, which is what a lot of companies
are calling their "level above Senior Engineer" role these days. Engineering
leveling is a weird beast, which probably a post onto itself. Despite my odd
entry into a career in tech, my path in the last 4 or 5 years has been pretty
conventional; however, somehow, despite having an increasingly normal career
trajectory, explaining what I do on a day to day basis has not gotten easier.
Staff Engineers are important for scaling engineering teams, but lots of teams
get by with out them, and unlike more junior engineers who have broadly
similar job roles, there are a lot of different ways to be a Staff Engineer,
which only muddies things. This post is a reflection on some key aspects of my
experience organized in to topics that I hope will be useful for people who
may be interested in becoming staff engineers or managing such a person. If
you're also a Staff Engineer and your experience is different, I wouldn't be
Staff Engineers Help Teams Build Great Software
Lots of teams function just fine without Staff Engineers and teams can build
great products without having contributors in Staff-type roles. Indeed,
because Staff Engineers vary a lot, the utility of having more senior
individual contributors on a team depends a lot of the specific engineer and
the team in question: finding a good fit is even harder than usual. In
general, having Senior Technical leadership can help teams by:
- giving people managers more space and time to focus on the team
organization, processes, and people. Particularly in small organizations,
team managers often pick up technical leadership.
- providing connections and collaborations between groups and efforts. While
almost all senior engineers have a "home team" and are directly involved in
a few specific projects, they also tend to have broader scope, and so can
help coordinate efforts between different projects and groups.
- increasing the parallelism of teams, and can provide the kind of
infrastructure that allows a team to persue multiple streams of development
at one time.
- supporting the career path and growth of more junior engineers, both as a
result of direct mentoring, but also by enabling the team to be more
successful by having more technical leadership capacity creates
opportunities for growth for everyone on the team.
Staff Engineers Don't Not Manage
Most companies have a clear distinction between the career trajectories of
people involved in "management" and senior "individual contributor" roles
(like Staff Engineers,) with managers involved in leadership for teams and
humans, with ICs involved in technical aspects. This seems really clear on
paper but incredibly messy in practice. The decisions that managers make about
team organization and prioritization have necessary technical implications;
while it's difficult to organize larger scale technical initiatives without
awareness of the people and teams. Sometimes Staff Engineers end up doing
actual management on a temporary basis in order to fill gaps as
organizations change or cover parental leave
It's also the case that a huge part of the job for many Staff Engineer's
involves direct mentorship of junior engineers, which can involve leading
specific projects, conversations about career trajectories and growth, as well
as conversations about specific technical topics. This has a lot of overlap
with management, and that's fine. The major differences is that senior
contributors share responsibility for the people they mentor with their actual
managers, and tend to focus mentoring on smaller groups of contributors.
Staff Engineers aren't (or shouldn't be!) managers, even when they are
involved in broader leadership work, even if the specific engineer is
capable of doing management work: putting ICs in management roles, takes
time away from their (likely more valuable) technical projects.
Staff Engineers Write Boring and Tedious But Easy Code
While this is perhaps not a universal view, I feel pretty safe in suggesting
that Staff Engineers should be directly involved in development
projects. While there are lots of ways to be involved in development:
technical design, architecture, reviewing code and documents, project planning
and development, and so fort, I think it's really important that Staff
Engineers be involved with code-writing, and similar activies. This makes it
easy to stay grounded and relevant, and also makes it possible to do a better
job at all of the other kinds of engineering work.
Having said that, it's almost inevitable that the kinds of contribution to the
code that you make as a Staff Engineer are not the same kinds of contributions
that you make at other points in your career. Your attention is probably
pulled in different directions. Where a junior engineer can spend most of
their day focusing on a few projects and writing code, Staff Engineers:
- consult with other teams.
- mentor other engineers.
- build long and medium term plans for teams and products.
- breaking larger projects apart and designing APIs between components.
All of this "other engineering work" takes time, and the broader portfolio of
concerns means that more junior engineers often have more time and attention
to focus on specific programming tasks. The result is that the kind of code
you end up writing tends to be different:
- fixing problems and bugs in systems that require a lot of context. The bugs
are often not very complicated themselves, but require understanding the
implication of one component with regards to other components, which can
make them difficult.
- projects to enable future development work, including building
infrastructure or designing an interface and connecting an existing
implementation to that interface ahead of some larger effort. This kind of
"refactor things to make it possible to write a new implementation."
- writing small isolated components to support broader initiatives, such as
exposing existing information via new APIs, and building libraries to
facilitate connections between different projects or components.
- projects that support the work of the team as a whole: tools, build and
deployment systems, code clean up, performance tuning, test infrastructure,
and so forth.
These kinds of projects can amount to rather a lot of development work, but
they definitely have their own flavor. As I approached Staff and certainly
since, the kind of projects I had attention for definitely shifted. I actually
like this kind of work rather a lot, so that's been quite good for me, but the
change is real.
There's definitely a temptation to give Staff Engineers big projects that they
can go off and work on alone, and I've seen lots of teams and engineers
attempt this: sometimes these projects work out, though more often the
successes feel like an exception. There's no "right kind" of way to write
software as a Staff Engineer, sometimes senior engineer's get to work on
bigger "core projects." Having said that, if a Staff Engineer is working on
the "other engineering" aspects of the job, there's just limited time to do
big development projects in a reasonable time frame.