First off, not everyone wants to be a more senior engineer. In fact, being an IC3 - a senior engineer in Mozilla terms - is where most people are at today, and will be in the future. It’s a good spot to be between the “not knowing what you’re doing”-ness of a more junior engineer, and the “I’m responsible for the whole house of cards”-ness of a more senior engineer (hyperbole, for sure. not all software is a house of cards, but it paints a picture).
That said, many people are interested to know what the next step would be, regardless of whether they want to take that step. So hopefully this is somewhat valuable.
Generally speaking there’s two ways you can go as an engineer: you can develop deeper technical expertise or develop people expertise. Both are equally important and useful, but require some different skills and personality traits to really excel.
First off I want to break down what the skills and traits that I think make you successful in one or the other path are, and then I’ll mention a little about what each path’s next step is specifically as it relates to my team and how you might put your foot forward if you’re interested. There’s also some uniqueness to this, since the focus is about progressing as a quality engineer, but it applies generally to most software engineers as well (should you move departments, or if anyone reading this is not in QE). In time I hope to have some follow up posts to describe how one might progress all the way to being a QA Fellow, something I don’t think I’ve come across in my career but would be totally awesome to see!
Setting the stage
Generally the first few years of your career as a dev you spend a lot of time learning tools, patterns, standards, how to properly debug - things like that. Once you’ve mastered those ins-and-outs, you start to find things you’re interested in and you begin to specialize. For me, I got way into devops. Someone else might be really into low-level graphics, or network performance, or creating beautiful sites. Coincidentally, it’s around the time you specialize that you then may become a senior engineer.
I always think of a promotion to senior engineer as the cut-the-tether moment. You’re basically knowledgable and experienced enough that your managers are comfortable trusting you to own large pieces of work, and so you’re cut free from more direct supervision and given some autonomy over how, when and why things are done. Being a senior engineer is great! Seriously. I can’t think of many better jobs that are as abundant, well paying, and fun. But some times you want a bit more, you want a new challenge, or you think your skills might be better used in something a bit different.
Maybe, like me, you realize that what you’re actually really good at is taking complex problems and simplifying them down to actionable solutions. Thinking about the long term, setting goals, and organizing and delegating responsibilities to make sure the path we defined together is followed (somewhat) closely. Being able to grok and juggle many, many, priorities simultaneously, context switch, and solve problems for other people. That is essentially people management, and you also get to pretend you are a psychologist, accountant, project manager, and (hopefully rarely) firefighter.
Or maybe your skills are in going really deep into a problem until you understand every little intricate part of the domain. You have a tenacity and resiliency, that, even when you fail, you’re still thinking of ways to attack a problem. You find people are constantly coming to you with questions about how something works or what the best way to do something is. Your communicating beyond peer discussions, maybe via teaching, mentoring, or giving talks at conferences. Your developing a voice, an opinion, on how things should be done, and you can defend your stance well. Your finding yourself spending more time talking to folks from marketing or product, your expertise and opinions are carrying more weight. You are starting to see the longer term, that future roadblock because of a decision made last week, or where it might make sense to bring in new technology, people, or tools. Those may be signs that you’re ready to take on a leadership role as an engineer, and IC4 in Mozilla terms, or “Staff Engineer”.
Moving into management is kind of a tricky thing, mostly because it is completely different from everything you’ve done previously. Generally to develop management skills you have to actually, you know, manage. That’s not something usually just granted to someone, but it can be grown over time by taking on more and more tasks of a manager. Leading meetings, giving project updates to other teams and executives, delegating tasks, mentoring interns or junior engineers. You can start doing those things as a senior engineer to get a taste of what management might be like. If you find you’re enjoying that work more than your hands-on coding, then it might be possible for you to move into a lead or supervisor type role, where-in you aren’t fully responsible with things like budgets and performance, but you might have your own direct interns, contractors, or junior engineers to manage day-to-day with tasks and goals. Maybe that’s as far as you want to go, you like having a team of engineers, but don’t want to deal with the paperwork and HR/administrative tasks. Great! Team lead is a fantastic spot to be! Or maybe you like it but you want to see the whole picture, you want to take on more responsibility, and have more of a view into how organizations operate (internally and externally).
There’s a switch that has to happen for more those, I’ll call them business-minded, engineers, and that is when you have people under you that you are completely and solely responsible for. Good, bad, in between. They reflect you, who do you hire and how do you grow them. That’s a whole separate post that I may get into some day, but safe to say it’s a different beast from being a team lead. If that’s where you want to head, then it’s time to find or grow yourself a team!
Finding a team means you inherit a team, likely through a move within your company or into a different company. That has it’s own challenges (again a post for a later date), but the gist of it is they already have a way of doing things, they already know what’s going on and your job (initially) is to step in and learn from your team.
Growing a team is arguably harder. You have to get approval to hire, go through interviews and find the right candidate. That first hire is all important (blog post idea #3), it sets up your second and third hires directly. You have to set the vision and strategy for the team, what and how are you going to take care of your responsibilities. Contractors are an interesting new-manager learning path, low risk, if it doesn’t work out there’s no commitment or legal concerns beyond the contracts end date. But even that is different from having your own full-time employees. Given the choice, I think it’s best to cut your teeth with full-timers, and if needed supplement with contractors. You’ll learn a lot more, and faster.
With an existing team, a lot of these things are in place, it’s up to you to learn how the team already does things and then adapt them as you find your footing. That’s probably the ‘safer’ way to go, but I think ultimately you’ll get more out of starting a team from the ground up yourself, there’s some valuable lessons there that you won’t get otherwise.
Staff engineers basically have to know their stuff. You are an expert in a thing. Likely no one else knows as much about that thing as you. You become so good at that thing that you are known outside your team as the person to go to for that thing. How do you get to that level? Well, start by being really passionate about something. Security, performance, networking, graphics, quality, whatever. Use that passion to fuel your research into the latest and greatest tech, finding better ways to do things you already do, and find things that you don’t already do but should. There ought to be a real analytical quality to staff engineers, able to self-reflect and analyze problems without bias or ego.
Find something specific that you think you can make a difference on. This could be the implementation of a tool, or refactoring some code to make it more efficient or easier for new developers, or creating a feature that wows people. Commit yourself to it, and really engage in the problem space. You need to get comfortable setting and directing work, and work with more junior engineers to keep them pointed in the direction you’ve set out on. You have to be comfortable as a leader; technical leadership is still leadership. Architect new solutions, suggest ways to improve, get your voice out there if you have ideas or think something should be done differently. Set goals for yourself, and push yourself to not only meet them, but surpass them. It’s not all about just being successful every time you do something, the “best” senior engineers don’t automatically become staff engineers, it’s also about the attitude and discipline to not only be diligent and detailed in success, but being just as diligent and detailed when you fail. You continuously learn and improve yourself and your work. You show signs of growth as a communicator, as a leader, and as an engineer. Technical prowess is important, but not everything. You not only lead within your company, but lead within the community you are passionate about.
Every time you pick up a new project, come at it with the same diligence and detail. You’ll naturally learn and develop your technical skills, but pay attention to the leadership skills too. Figure out your own strengths and weaknesses, and how you plan to develop those skills. Discuss a plan to your manager outlining how you think you can take the next step, and then working with your manager to stay on target. Set a time horizon, and goals. Use the same care and attention you apply to your work to yourself and it will pay off in no time.
Whichever path you choose, whenever you put yourself out there or try things you haven’t done before, it can be a bit risky, and many engineers are risk adverse. That’s natural. But if you try something and fail, and you learn from it, it will cease being a failure.