Share this article

Share on facebook
Share on twitter
Share on linkedin
Share on reddit

What a Senior Staff Software Engineer Actually Does

This post lists the key insights from the two-part articles here and here, by a Senior Staff Software Engineer at Box, Joy Ebertz.

Engineering Roles at Box

The author is currently a Sr Staff Software Engineer, but what exactly does that mean? While the exact titles and role dividing lines she uses here are specific to Box (although we modeled them on Google), the general shape of advancement is largely similar across the industry: Software Engineer > Senior Software Engineer > Staff Engineer > Senior Staff Engineer > Principal Engineer > Fellow roles. She doesn’t think they have anyone at the fellow level though. To make it even harder to understand what the upper levels entail, while the first couple of levels are largely uniform, what it means to be someone on one of the upper levels can vary quite a lot between people in the same role.

At our lower levels — associate through Senior SWE, we expect a somewhat uniform demonstration of skills. We expect each person promoted to Senior SWE to have largely demonstrated competence in all areas (in our case, Technical Skills, Leadership, and Culture and Values) and to have met the bar in all areas, making the required skill set of all Senior SWEs fairly similar. It’s also worth noting that each level is a slightly different job. Gaining a new level is not just recognition of a job well done but rather is actually a different role. Because of this, while we expect people to advance through our first few roles, starting at Sr SWE, it’s perfectly acceptable for an engineer to just stay at a given role for the rest of their career. If someone likes being a Sr SWE and doesn’t want to become a Staff engineer, that’s fine, we need Sr SWEs.

The easiest way to describe the role change as you move up is to say that the impact increases.

This can be thought of in a couple of ways. Either you can have a broader impact or you can have a deeper impact. You can affect a lot of teams or you can very deeply affect one team. This has other implications as well. By writing code, I can only ever have somewhat limited impact. While I may write a super important or super complex piece of code, and that is important, I will only affect that small area. Meanwhile, if I can mentor a bunch of others on best practices or give input on multiple designs or influence how decisions are made, I have much more impact.

So this is still a little high level and hand-wavy, what does this actually mean? What do I actually do?

What does a Senior Staff Engineer actually do?

There are two main ways that the author thinks about her job. The first is the actual tactical — what are the actual day-to-day tasks that she does? The second is much less tangible — how does she approach and how does she think about those tasks?

Day-to-day tasks

  • She only spends around half my time on tasks directly for my scrum team. This includes all of her team meetings, which she feels like this highlights even more the importance of streamlining process. She would say that this portion of the job is fairly similar to what it was when she was more junior. This would include everything from writing design docs to writing code, doing code reviews and testing.
  • The next biggest portion goes towards some sort of technical consulting (all of the green sections in the chart). This includes consulting on various design proposals — both within my team and from other teams, answering technical questions and serving on an API standards council. Some of the questions come up because of her seniority and some come up due to her tenure at Box.
  • In the mentoring bucket, she includes both formal and informal mentorship. This might be anything from actually meeting with someone one on one to larger presentations to some portion of engineering. This might be a single meeting or multiple. While ongoing formal mentorship can be really useful, she’s found that it actually makes up very little of the mentoring that she does. Instead, most often, she finds herself answering questions on a single topic in one or two settings. The other type of mentorship that comes up is something she would describe more as peer mentorship or mutual mentoring. They both provide insights and thoughts to the other and both benefit from the other’s differing perspectives.
  • Larger initiatives include things like working with other senior engineers and managers to set the technical direction for her team or department. It could also include something like trying to improve diversity and inclusion within engineering.
  • She sees tech brand as anything that improves Box Engineering’s technical brand. For her, this is primarily writing blog posts but can also include talks or helping edit others’ work.
  • Lastly, she’s included the miscellaneous bucket to include everything else not easily covered in the other areas. This encompasses a variety of things including conducting interviews, attending tech talks or participating in company hackathons. These things are still important but typically take up a much smaller portion of my time.

If she had read this task list when she first entered engineering, while it wouldn’t line up with what she was doing at the time, she probably would have thought that she was capable of doing most things on there and she wouldn’t have been completely wrong. However, what has changed significantly is how she approaches these various tasks and what she focuses on while doing each. Mindset can be just as important as what she’s doing. Her specific tasks are only half the story.

Her actual day to day tasks are only a small snippet of what it means to be a senior staff software engineer. I’ve found that the more interesting part is more related to how she thinks about and approaches her role. Her focuses that she outlines below are how she see her current role.

The different focuses

1. Ownership and Initiative; Taking Responsibility.

Perhaps the biggest thing she sees as different between her now and when she started out is the level of ownership and responsibility that she feels.

The second piece is around empowerment. Often, the biggest reason something isn’t happening is that no one cares enough, feels empowered enough or has enough energy to make it happen, so if you’re willing to be that person, no one will stop you and in fact others will often be very happy.

The other piece here is initiative. Her role and responsibilities and day to day tasks have gotten more and more vague as she’s become more senior. It’s more and more rare that anyone will tell her exactly what needs to be done or how to do any particular task. Even my manager doesn’t precisely know a lot of what she works on and instead trusts that she will work on the most important things in effective ways.

Questions you should ask yourself as a senior staff engineer:

  • When I see something wrong, if I don’t fix it, who will?
  • What’s stopping me from doing it?
  • Am I working on the most important projects? Are the most important projects being worked on?
  • What are the weak points or gaps in our technology or our organization? What can I do to fill those?

2. Growing Everyone.

Questions you should ask yourself as a senior staff engineer:

  • Who will learn the most from working on this?
  • What can I delegate?
  • How do I scale myself?
  • How can I never answer/do this again?
  • Is this particular task really worth the amount of time I’m spending on it? What would happen if it didn’t get done?

3. Trust Others. 

Questions you should ask yourself as a senior staff engineer:

  • Who else could or should answer this?
  • What’s the worst that will happen if I stay out of it?

4. Preventing Problems; Future Proofing. 

Questions you should ask yourself as a senior staff engineer:

  • How can we make sure this never happens again?
  • Is there a way to add a test or linting or otherwise enforce that no one will make this mistake again?
  • Might this project end up with the same or similar problems as something I’ve seen before?

5. Asking Questions; Ensuring Due Diligence. 

Questions you should ask yourself as a senior staff engineer:

  • Was the solution carefully thought through?
  • What other options were considered?
  • If something sub-optimal was chosen, why was it chosen? Is there a path to the more optimal solution? Have they thought that through?
  • Is this similar to other problems I’ve seen? If so, would any issues (or successes) we ran into there also apply here?

6. Influencing With and Without Power. 

Questions you should ask yourself as a senior staff engineer:

  • How do I get others on board?
  • How do I get a project or initiative prioritized?
  • How do I make sure that people aren’t just blindly following my suggestions, but understand the why?

7. Being Heard.

Questions you should ask yourself as a senior staff engineer:

  • People won’t always agree with me, but are they hearing me?
  • Are people misinterpreting what I’m saying? Are they taking it in the right context? If not, can I change my approach or how I’m presenting my thoughts?
  • Do I understand my audience? Are they even the people I should be talking to about this topic? Am I presenting it in a way for them to understand and relate to it?
  • How much do I push a topic? Is this a battle worth fighting?

8. Listening to Others. 

Questions you should ask yourself as a senior staff engineer:

  • Is everyone’s voice being heard? How do I get others to open up and share their thoughts?
  • Am I keeping an open mind to other perspectives?
  • If something seems crazy to me, am I truly understanding what they’re saying and where they’re coming from (people are rarely actually crazy)?
  • What aren’t people saying?
  • Is someone’s body language, actions or demeanor saying something even if they’re not explicitly saying it?
  • Have I gotten a diverse set of input? Have I sought feedback from everyone I should?
  • Am I amplifying the people who deserve it?

9. Providing and Leveraging Unique Perspectives. 

Questions you should ask yourself as a senior staff engineer:

  • What experiences have I had that are unique?
  • What unique perspectives do I bring to this problem?
  • Is there an important perspective that is missing in this conversation? Who can provide that?

10. Leadership. 

Questions you should ask yourself as a senior staff engineer:

  • What’s the ‘adult’ or ‘right’ thing to do? If I’m not doing that, what’s stopping me? Should I probably just do that?
  • Am I leading by example? Do I want others copying me?
  • How do I create an environment where people feel safe to share their thoughts and opinions?
  • Are the people around me motivated and excited about their work and the technical direction? If not, what can I change?

It’s really easy to get caught up in the what of a role and lose site of how we get those things done. In many cases, these are just as important if not more so. If she looks at her job now compared to when she first started out in software engineering, she thinks the most surprising thing as well as the most different is how she thinks about and approach her role.

8 min​ read

Subscribe to our newsletter Weekly Bytes to get our curation of the top 5 articles of the week.

Subscribe to our newsletter Weekly Bytes to get our curation of the top 5 articles of the week.

Need visibility in your software development lifecycle?