What a Senior Staff Software Engineer Actually Does

Part 2: The Mindset and Focus of the Role

If you missed it, I talked about the specifics of the Sr Staff SWE role in Part 1. In this section, I want to focus more on how I think about the role and how I approach the various tasks I’m faced with.

My 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 I think about and approach my role. The percentage of time focused on different things has shifted as I’ve gotten more senior, but what truly differentiates my current role from when I first started out is how I view and approach my tasks. Different senior staff engineers see their jobs a little differently and do fill slightly different roles depending on the needs of their organizations, so this isn’t a template. Rather my focuses that I outline below are how I see my current role.

1. Ownership and Initiative; Taking Responsibility. Perhaps the biggest thing I see as different between me now and when I started out is the level of ownership and responsibility that I feel. Sometimes when I see a problem, I find myself assuming that someone else will fix it or someone else will find a solution. But who will that be? Are they even aware that this is a problem? This isn’t about me fixing everything, but it is about me making sure that the appropriate people are aware of the problems and if I’m the best person, then I should fix it.

The second piece is around empowerment. I obviously shouldn’t go off and do a bunch of unsanctioned things, but at the same time, there are a number of small initiatives or tasks that I somehow didn’t think I could do, but as soon as I asked someone, I got no resistance. 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. Don’t let a vague idea that maybe you can’t stop you from trying in the first place.

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

• 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. A big part of my job is making sure that I, and everyone around me is growing. It’s only through growing others that I will give myself the space to also grow. Delegation is something that I find myself constantly having to work at, but it’s also an ongoing process. There will always be more things that I should be delegating. As soon as I master something, I should be looking at if I can teach someone else to also master it or if it would be a good stretch or opportunity for someone and then hand it off. If I’m not constantly opening up my time, I won’t be able to learn or take on new things.

To further open up space for myself to grow, I also look at other ways I can scale myself. Sometimes the answer is to delegate, but sometimes the answer is to document the answer to a question I’ve been asked three times or to video tape a presentation so that I don’t have to give it again for a while. It may even be to automate a process or even let a few things drop — not everything is equally important.

• 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. This naturally follows growing others. I can’t truly delegate if I can’t trust them, furthermore, they can’t truly grow if there are always training wheels on. At some level too, I need to trust that other people understand the code and can also give the right answers. Just because I can answer someone’s question doesn’t mean that I should answer their question. Even if I know the area the best, sending the questioner to someone else for the answer can help build knowledge in the area and give the other person confidence in their knowledge and abilities and set them up to be seen as a subject matter expert. Furthermore, I don’t have the time or energy to dig into everything deeply, so at some level I need to trust the people working on a project. If I can trust them and only verify at high levels, I have the bandwidth to have an impact across more areas.

• 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. The job of software engineer at all levels is solving problems. Taking that to the next level is preventing problems. If we can solve the problem before it ever even happens, we’re in better shape. Bringing things up in a design discussion or documenting issues is an important part of this, but my favorite solutions are the automated ones. If we can find an automated way such that a test will fail if we re-introduce something, we don’t have to rely on anyone (including me) remembering.

• 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. A big part of my job is consulting on other projects or helping others review their designs. To be honest, I can’t possibly dig fully into any of these problems. There’s no way I can fully consider all possibilities the way the team directly working on the problem can and like my previous point, at some level I need to trust the team. To that end, I often find myself mostly asking questions to make sure that the main team didn’t cut corners and did their own due diligence. In fact, I sometimes don’t really even care what their answers are to my questions, just that they have well thought-out answers.

• 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. As a senior engineer, one of my jobs is to get important technical projects prioritized and to convince others when they’re doing something problematic. In some cases, these people are on my team or are people that look up to me and I have the advantage of seniority. In other cases, I’m trying to convince upper management or people on teams that barely know me. In both cases, I need to both be able to convince them, but at the same time, I need to make sure that they understand why I’m saying what I’m saying. While it can be useful to have someone blindly do what I suggest, they won’t learn anything and they’ll likely need just as much direction in the future. They also won’t feel as much ownership and if something goes wrong, they’ll be less equipped to react appropriately.

• 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. In order to be able to influence, I first must be heard. Especially as a woman, I’ve sometimes found this difficult. I fully understand that people won’t always agree with me and sometimes won’t follow my advice. I’m actually okay with that. What I’m not okay with is when they aren’t fully listening to or considering my view point. If I don’t think I’m being heard, I will re-iterate my view point, sometimes over and over. It’s worth noting, that I’m also a big believer in picking my battles. I only have so much energy, so if it’s only a minor point that I’ve made, I might not fight to make sure you heard it. However, if it’s something I think is really important, I will keep bringing it up until I at least know that you’ve fully considered it and I can understand your view point and why nothing is happening.

• 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. Just as important as being heard is listening. I almost always find that others have much better ideas than I do. Collectively, we have much more experience than any individual. Additionally, most of my own good ideas were sparked by something someone else said. All of this is to say that I find that the best solutions, technical visions and designs are often the work of a number of people. Not only will the solution be better, but it’s much easier to convince someone of something if they helped come up with it in the first place. I often see my job as listening to others, prodding them to speak up and curating those thoughts rather than doing much of the thinking myself. It’s worth also noting that part of listening is also looking for other cues — not all communication is verbal and sometimes what’s missing or isn’t being said is just as important or meaningful as what is. Obviously though, as I’m curating or amplifying other people’s thoughts, I also give credit where it’s due. I find that giving others credit doesn’t decrease my impact and it also raises that individual, so everyone wins.

• 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. One of the most important pieces of communication is not wasting people’s time. To that end, saying something that everyone already knows is not super useful. Additionally, I can encourage other people to participate and grow if I allow them to shine in the areas that they know and instead focus on the areas where I have a unique perspective. For example, I did a project focusing on Domain Driven Design. Therefore, I can more easily approach new features with that lens — are they thinking about domains correctly? Are the abstractions reasonable? Does this fit in with our larger domain landscape? Meanwhile, a lot of people know our basic API standards, so I can instead allow someone else speak up about issues in that area.

Not only is it useful to make sure I’m providing a unique perspective, it’s also important to make sure that unique perspectives are well represented when I talk to people. If I’m hearing too much agreement, maybe I should find someone who doesn’t. This easily might involve seeking out people in other teams or possibly even other disciplines for input.

• 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. As with any senior position, strong leadership skills are important. Leadership is one of those things that can mean a lot of things and really encompasses some of the other areas that I’ve already talked about. While it’s all important, there are a few things that I specifically want to call out here. The first thing is related to maturity. Basically, to call on a Box value, am I doing something that would make my mom proud? Just like all of us, there are times I would rather not give someone the hard feedback or it’s easier to let something slide. And to be perfectly honest, occasionally I still do, but I think it’s important that I’m at least making the conscious decision around that. Along similar lines, I want to make sure that the things I’m doing are what I would want the other engineers around me doing. I can’t expect other people to show up on time or listen in a meeting or take the extra time to test if I’m not going to. I’m not always good about these things, but it’s something I try to keep in mind.

I also see my role as a partnership with the manager(s) for my team(s). With that in mind, it’s important that I’m helping to create a productive environment with a healthy team. Some of this is speaking up to my manager when I see issues so that we can work out solutions. Part of it too, though, is to make sure that we are cultivating a safe environment where people feel comfortable asking even the ‘dumb’ questions and providing even the hard feedback. I will sometimes do this by breaking the ice and making myself vulnerable through candid thoughts and I also do it by trying to get a read on people and interactions.

Not only is a safe environment important for a healthy team, but so is team motivation. Making sure that those around me are excited and motivated about their work is important and if not, I need to find ways to get them there. This might be through creating a clearer team technical vision or through creating a sense of urgency or through having clear milestones and making sure that we celebrate them. We all recognize our failures and problems, so it’s important to make sure we also take the time to recognize our successes and wins. Some of the biggest successes are the things that go out silently, so it’s important that we celebrate those all the more.

• 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 I look at my job now compared to when I first started out in software engineering, I think the most surprising thing as well as the most different is how I think about and approach my role.