Part 1: The Role and My Tasks
Almost every software company that I?ve ever talked to has both a technical track and a management track meaning that if you stay on the technical track, you can advance to equally senior levels without managing people. At the same time, almost every career talk or panel that I?ve ever attended is by someone from the management track. Now I?ve always understood, at least at a high level, what a manager does and what the management track entails. Part of this is because the more senior roles in the management track have a high amount of visibility both internally and externally. The same is also true on the technical track, but to a much lower extent, resulting in a bit of mystery around those roles.
I?m going to be perfectly honest here, when I first got into software, if you had asked me what job I wanted in 10?15 years, I would have told you I wanted to be a software architect. I wasn?t particularly interested in management and I also knew that architects were some of the most senior people on the technical track. However, I actually had no real idea what an architect did. It was mostly just my ambition and desire to advance that was picking that role. As it happens, that?s still more or less the trajectory that I?m on, but now I have a much better idea of what it means to be a senior member of the technical track.
Engineering Roles at Box
I?m currently a Sr Staff Software Engineer, but what exactly does that mean? While the exact titles and role dividing lines I use here are specific to Box (although we modeled them on Google), the general shape of advancement is largely similar across the industry. I started off as a Software Engineer (or SWE), moved through Senior Software Engineer (Sr SWE), (a brief stint through management) then Staff and now Senior Staff. We also have Principal Engineer and Fellow roles after that, although I don?t think we have anyone at the fellow level. 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.
I think 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 do I actually do?
I?m not going to try to claim that this is the only way to be a Sr Staff software engineer or even the best way, but this is what I do and how I see my job. There are two main ways that I think about my job. The first is the actual tactical ? what are the actual day-to-day tasks that I do? The second is much less tangible ? how do I approach and how do I think about those tasks?
I decided to sit down and try to actually capture the specific tasks that I work on and I came up with the diagram shown. I?m sure I forgot some things and there is also definitely fluctuation week to week (so this diagram is more rough guideline and less exact).
I realized that I only spend around half my time on tasks directly for my scrum team. This includes all of our team meetings, which I feel like this highlights even more the importance of streamlining process. I would say that this portion of the job is fairly similar to what it was when I was more junior. My approach may be a bit different, but a lot of the what that I might be doing is similar. This would include everything from writing design docs to writing code, doing code reviews and testing.
The next biggest portion of my time (around 20%) 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 this is for my immediate team, but much of this is for other teams across our organization. Some of the questions come up because of my seniority and some come up due to my tenure at Box. From the time I was no longer a new hire, this has occupied at least a small amount of my time, but has increased as I?ve worked on more projects. While I?ve been answering questions that entire time, how I think about and approach answering those questions or what I bring to the table for design reviews has changed over time.
The remaining portion of the time is pretty evenly split between mentoring, larger initiatives, tech brand and miscellaneous. In the mentoring bucket, I include 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, I?ve found that it actually makes up very little of the mentoring that I do. Instead, most often, I find myself answering questions on a single topic in one or two settings. The other type of mentorship that comes up is something I would describe more as peer mentorship or mutual mentoring. These aren?t mentor/mentee relationships, but instead are work peers who I share my problems with and who share their problems with me. We 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 my team or department. It could also include something like trying to improve diversity and inclusion within engineering. Basically, these are the longer term strategic items that cross multiple teams. Over time I?ve worked on a number of different larger initiatives (including both of the things I mentioned above). In some cases I?ve been pulled into a conversation, but often I?ll see a gap and initiate the conversation.
I see tech brand as anything that improves Box Engineering?s technical brand. For me, this is primarily writing blog posts but can also include talks or helping edit others? work. Some of this might be trying to recruit, but some of it is also more internally focused to share learning and get our engineers excited about some of the things are departments are working on.
Lastly, I?ve 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 I had read this task list when I first entered engineering, while it wouldn?t line up with what I was doing at the time, I probably would have thought that I was capable of doing most things on there and I wouldn?t have been completely wrong. However, what has changed significantly is how I approach these various tasks and what I focus on while doing each. Mindset can be just as important as what I?m doing. My specific tasks are only half the story.
Because this was getting long, I?ve broken this into two posts, but you can read more about how I think about performing my role in my follow up post.
