I’m currently joining a couple of new projects and the inevitable first step is introductions over Zoom and the usual questions: who are you, where are you based, and what is your role on this project. I’m a Principal Engineer here at Mozilla, which might make you think that my role is going to be a lot of development. But this isn’t the case and I thought others might be interested in what it actually means. Somehow along the way it ended up turning into a post about how I see the different career levels for engineers at Mozilla, but hey maybe that is useful for others too?
One quick disclaimer for Mozilla engineers reading this. I am not your manager. If you want to know the specifics about what your manager wants to see from you in order to progress in your career you’re better off talking to them first. This is also a simplification of a complex topic. I’ve talked in general terms about the career levels here, but no two engineers or career paths are the same, exceptions exist.
Like a number of companies these days Mozilla has two tracks for career progression. Engineers here are levelled along the Individual Contributor (IC) track. This didn’t used to be the case. Previously, other than a few exceptional cases, when engineers reached one of the more senior levels they were expected to move into people management. That happened to me and for four years I managed a team of about seven engineers and I very quickly learned that people management wasn’t for me. So I was extremely grateful when my manager at the time announced that Mozilla were building a more comprehensive track for engineers who wanted to continue to grow without needing to become managers. And they were talking with folks that they felt might have been pushed into management when there was no other option and giving them the choice to switch back. Which I jumped at.
Now Mozilla has an IC track that has 9 levels numbered from IC1 to IC8 (yes you read that right). We have the career level guide which is the hallowed spreadsheet that managers can point to to help engineers understand what the expectations are for the different levels. I actually helped write one of the original versions of this many moons ago so I have a lot of familiarity with it. And I find that those levels split into three chunks.
Engineers (IC1-IC3)
The first three levels (Software Engineer 1, Software Engineer 2, and Senior Software Engineer) are primarily about the work you do yourself as an engineer. You start by learning the ropes with your manager telling you what bugs to work on with other engineers helping you figure out how to fix things and help you when you get stuck. You grow to be more and more independent and by IC3 you are more self directing. You can generally figure out what bugs are most important to work on and how to unblock yourself. Your work is mostly directed by your manager at these levels but as you reach senior you’ll be helping your manager understand which bugs are hard or easy to fix to help inform their prioritisation decisions.
Engineers fix bugs and become more senior by getting better at fixing bugs.
Staff engineers (IC4-IC5)
The next two levels (Staff Engineer and Senior Staff Engineer) change things up. All of the levels are ranked in terms of the overall impact you have to Mozilla, but while in the first three levels your impact is fairly direct (the bugs you fix) at the staff level your impact becomes more indirect. You’re now growing into technical leadership. Figuring out and prioritising the issues that need to be worked on. Building a roadmap for your feature. Likely assigning bugs to other engineers. You work directly with other teams where there are dependencies and other functions of the organisation to guide the project as a whole. More of your time is spent helping the engineers around you get their work done than your own (though you still do a lot yourself too). The guidance from your manager is less about telling you specifically what to work on and more of a conversation where the manager brings the business needs and you bring the engineering needs and together you reach agreement on how to prioritise projects.
Perhaps the most important difference between staff and the earlier levels is that how you work becomes much more important. For the first three levels you can fix bugs largely in isolation. Once you reach staff communication becomes key. You have to be able to explain yourself well so others understand you and have confidence in your decisions. You have to be able to work productively with others, helping them do their work but also importantly listening to them when they have expertise that you don’t. A staff engineer is on a team to provide technical leadership and decision making. This doesn’t mean they have to be the expert on the project. Sometimes there might be an IC3 who understands the technology better. The staff engineer has to be humble enough to trust their subject matter expert in this case, this is often a hard shift in thinking for an engineer to make.
A staff engineer should make everyone on their project more productive.
Principal and above (IC6+)
The final levels start with IC6 which is where I am. Principal Engineer. I recall when we worked on the original level guide we got a bit stuck here. In part there were only a few engineers at this level or above to use as examples (this was back when this separate track was for the exceptional cases). But the other problem was that all of those engineers were different. I recall we basically gave up at one point and just wrote something along the lines of “You are an unstoppable force of nature”. The levels are thankfully better defined now but there is still a lot of difference between the principals.
Some specialise in technical depth. They work on extremely complex, risky, or mission critical projects with many moving parts and have a deep understanding of how it all fits together so they can guide the work on it. They may still write a lot of code.
Others may barely write any code at all and spend their entire time working at the higher level of projects that span large areas of the company. They understand how all the pieces of Firefox fit together and so when technical questions need answering they can either answer them directly or very quickly find the person who knows the answer. They help evaluate and steer new projects with an eye on the technical capabilities we have available and the business needs. They identify potential roadblocks quickly because they have that overarching view.
And there are many principals who sit somewhere in between those two extremes.
There are some commonalities though. While staff engineers tend to have their impact limited to a single project at a time, IC6 and above will be impacting multiple projects at once. Even those who are deep in the technical pieces of one project will still be working with other projects. Principals will also work directly with Directors and VPs to help decide what projects should and shouldn’t happen. The levels above principal will be working directly with the C level execs. We will also often be working with people from other companies, perhaps companies we are partnering with, or standards bodies, or even governments in some cases. Principals and above have to have a good understanding on the goals of Mozilla as a whole, not just those for any one particular part of Mozilla.
Principal engineers should make the entire company more successful.
What about me?
So what kind of a principal engineer am I? Well here is my commit graph for Firefox.
As you can see I do very little coding. I have ended up towards the other end of that spectrum and I spend most of my time advising projects. I was looking at a new ultra-wide monitor that became available the other day and my half-serious joke was “Damn, I could fit so many Google Docs on that thing”.
In the past I have been thrown into teams where a specific project has become blocked and they need help figuring out how to unblock it. Or a VP needs a more direct link with a critical project and wants me to act as liaison between them and the team, someone who they can trust to be their eyes and ears but also often their voice.
More recently I’ve done work where I’ve been the first engineer on a new project and I spent time working with product management and user experience to figure out the basics of what we are going to implement, what impact that will have on the rest of the product, which other teams we have dependencies on, and the technical feasibility of what we’re planning. This then helps us decide which engineers we need to do the actual work and how long we need them for. Sometimes once other engineers join to start on the implementation I step back, letting the new tech lead handle most of the decision making. Though I’m often having private conversations with them to help them if they need it. Sometimes a project has enough complexity and cross-team dependencies that I stay more actively involved, letting the tech lead focus on the decisions that need to be made for the implementation while I handle some of the burden of making sure that everything surrounding the project is running smoothly. These are the sorts of roles I took for the recent Tab Groups and Profile Management projects.
One of my new projects is a similar ask again, helping a new project get up and running. It has a lot of moving pieces both within Firefox and across the rest of the company. Identifying the hard parts so we can tackle them sooner is going to be very important. I’ll be doing very little implementation work here, possibly some prototyping. Another of my new projects has me diving into a team that wants a more senior engineer around to just generally help them with making decisions on tricky projects and figure out their priorities. This will be more mentorship than development work which is something I’ve been wanting to do more.
What I see at Mozilla is that the more senior the engineer the less likely you’ll be able to guess what they actually do on a day to day basis from their job title alone. Having not really worked at other organisations of this size I can’t really say whether the same is true elsewhere, but I suspect that it is.