What does a Staff Software Engineer actually do?
I’ve had a lot of job titles over the years. More recently I took a role with the title Staff Software Engineer.
“What does a Staff Software Engineer actually do?”
Someone asks me this question nearly every day 🙃
Admittedly, it’s kinda awkward to answer because engineering titles (and organizations) are different at almost every company.
Since there’s no authoritative definition of “staff” vs “principal” vs “senior” engineers, let’s step back and discuss how engineering teams are built more generally before deciding whether-or-not these titles ultimately mean… anything.
Engineering Levels
Larger organizations (and famously the FAANG tech companies) have various tiers (or “levels”) within their engineering departments. In many cases, these levels formally dictate what roles and responsibilities (and, by proxy, compensation) a given software engineer may enjoy
For example, an “L1” engineer would have the least amount of responsibility in the department — most likely given specific tasks (bugs or improvements) on which to focus.
L1 engineers are never asked to lead teams or feature development, and they rarely work in isolation. They are often still learning the tech, tools, and processes used by corporate engineering departments.
Every level an engineer climbs above “L1” assigns additional responsibilities:
- L2 graduates to minimal hand-holding; more independent work, though always under the direction of others. Understands the tech, tools and processes used by the team.
- L3 leads a team of L1/L2 engineers and is the point-person on the team for tech questions. Works at the direction of Product/Engineering management. May have enough responsibility to make decisions about technology, tools or processes for the team. May be the actual supervisor of L1/2 team members.
Beyond these lower levels, software engineers begin to consider the IC-vs-Management career track.
Those of us who really want to be hands-on with the tech continue in engineering-focused roles, but are required to have far greater organizational impact:
- L4 has a specialty within their department and may work across teams. Frequently parachutes into a project for tactical support, then delegates implementation to the rest of the team. May orchestrate several teams simultaneously to accomplish a medium- or long-term goal. Not an actual people-manager, but probably mentors others.
- L5 has high visibility with executives or upper-management, and uses those relationships to influence technology, tools and processes across the larger organization. Might orchestrate large, multi-team long-term initiatives. Spends a lot of time on “research” and thinking deeply about the impact of technology to the organization. Again, not an actual people manager.
Every company does things differently, but overall the idea should be clear: the higher your “level”, the more broadly you impact the organization.
Also: the higher your “level”, the less likely you are to actually spend time writing code every day. More on this in a bit.
So… how do titles like “Staff” map to levels?
Based on how I described each level above, you might generally assume the engineering levels to translate something like this:
- L1 === “Junior Software Engineer”
- L2 === “Software Engineer”
- L3 === “Lead Software Engineer”
- L4 === “Senior Software Engineer”
- L5/6/etc === “Principal”, “Staff”, “Distinguished” engineering roles
One company might call “Senior” L4 while another one calls it L3 or L5. Other companies might have “Senior” below “Lead”. But you get the idea. Something like this.
Wait… are you saying that “Principal”, “Staff” and “Distinguished” engineers are all the same thing?
Basically.
At this level, your role is simply to use technology in different ways that provide positive impact across the company. Sometimes you’re working on revenue products, other times you’re trying to untangle people and internal processes. It’s rarely the same thing every week, which also complicates my ability to describe my job 😎
And again, it entirely depends on the company. Some job titles/levels might be an indication of deep expertise in some specific area if the organization is large enough to support that.
In terms of the manager/IC organizational charts, L4/5/6/etc are not necessarily above or below each other. They all tend to report directly to a Director or VP somewhere.
Ultimately, if you want to remain an Individual Contributor as your career path you need to begin thinking in terms of engineering impact.
So what does a Staff Software Engineer actually do?
I’m finally going to answer this question!
From a high-level perspective, my day-to-day activities as a Staff Software Engineer generally cover:
- Answering tech questions from teams & management
- Researching tech & developing new product features
- Interviewing candidates & mentoring teams
- Fixing bugs
But… every week is different.
This week I haven’t written much code, though I shipped a couple of bug fixes. I interviewed one applicant. The majority of my time however was spent reviewing documentation for a new enterprise feature and evaluating some possible 3rd party solutions.
More recently I have spent all of my weekly hours shipping code — mostly building new product features, but some of it experimenting with a Chrome DevTools extension I’m developing for our team.
Next week? Who knows 🤪
“How is any of that different from what I do as a (Sr./etc) Software Engineer?”
Some of you reading this story probably just thought that exact question in your head. Honestly the answer could be “not much”.
Again, it totally depends on your organization.
But let’s think in terms of engineering impact.
At larger companies (where you typically see roles like “Staff” or “Principal” engineers) there are usually many teams within the engineering organization, with easily dozens of developers.
You can imagine how difficult and risky it can be to try anything new in an organization with lots of people, lots of code, and lots of moving parts. Don’t take down the SaaS cash cow that pays everyone’s salary! 😬 So things move more slowly, but also more deliberately. Few things are adopted or changed by happenstance.
Smaller companies (< 300 employees) are unlikely to have levels above “Senior Software Engineer” simply because it’s an unnecessary layer. Most days are probably similar at a smaller company, yet there are more opportunities for broad organizational impact because you’re already interacting with a large percentage of the total company!
How do I get to the “next level”?
If you’re at a larger company, this is the $64,000 question… and once you understand how the game is played, it’s much easier to orient your efforts towards specific milestones.
If you’re an L1 or L2 engineer, you should be 100% tech-focused and still learning. Focus all of your available time and attention towards learning the technology, tools, and processes that your organization requires.
For example: if you’re an L2 engineer building a React application:
- You should focus your next 12–24 months learning as much about your tech stack as possible (e.g. React, JavaScript, backend APIs, SQL, etc).
- You should master the tools you use on a daily basis (Git, VSCode, Jira, etc).
- And you should memorize the important engineering processes for your team: pull requests, code reviews, QA reviews, CI/CD and cutting releases.
If you’re an L3 “team lead”:
- You should begin focusing on how you (and by proxy, your team) fit into the wider processes defined by your Product/Engineering managers. You won’t control this (or be able to change it) but it will shape how you think about the work your team delivers and identify opportunities to create impact beyond your team.
- You should begin considering how the tech/tools/processes used by your team actually impact your day-to-day work. Start asking questions like “Can we do X faster a different tool?”, “What are the tradeoffs of using A over B?”, and “Are we going to be happy with this in 6 months? 12 months?”
Once you have successfully led a team of developers and demonstrated consistency in your leadership, your day-to-day technical skills start to become… less important.
An L4/5/etc engineer still will be expected to know their tech stack (or at least the part their team develops) inside and out. You’ll write some product code, but you’ll probably spend even more time reviewing others’ code and evaluating different approaches to existing problems.
For example, an L4/5/6 engineer is almost certainly the de facto expert for your product’s most complicated feature. But half of that person’s day-to-day at a large company is spent reviewing the team’s code, planning/researching upcoming work, or answering product/support questions.
Career Strategy
I wasn’t always sure I wanted to stay on the IC track. In fact I worked hard to pursue Engineering Management.
I attended MBA classes, I took every leadership opportunity I could at work, and I even studied to get my CISSP.
Eventually I became a Director at one company, which I enjoyed until upper-management changed… and then I learned some hard lessons about corporate middle-management.
Being a high-level Individual Contributor feels like a better fit for me because I get to remain a hands-on technical expert and impact multiple teams — without the aspects of people- and project- management that I find unappealing.
Are you considering the IC-track in your software engineering career?
Join my bi-weekly newsletter Strategic Software where share articles and resources that I find relevant or interesting in my day-to-day work as a Staff Software Engineer and solopreneur.
