As the Mozilla project has grown so too has our management structure. There are a number of people with various manager titles involved in the day-to-day operations of many Mozilla projects. You may know some of these people and have a sense of what they do. This post is to help clarify these positions so that you can better understand the value that people in these roles bring to the project and their relationship to your work.
There are four types of managers that I will discuss here: development managers, product managers, project/program managers, and release managers.
development managers
A development manager has responsibility for a development team, such as front-end, WebAPI, or performance. It is the development manager’s responsibility to guide the team’s work, balancing various requirements and the relative priorities. Development managers are people managers. This means that they are responsible for the professional growth of the people on their team and that of the team itself. They serve as reviewers, mentors, and advisers. Many Mozilla development managers are very hands-on writing patches and providing code reviews. Some people you may know in this role are Gavin Sharp, Andrew Overholt, and Taras Glek.
Takeaway, development managers:
- are people managers
- guide a development team’s work
product managers
Product managers are more removed from day-to-day development. They gather requirements for Mozilla products by reviewing market research and trends, following standards bodies like the W3C, and speaking with the engineering community. They have the challenging job of forecasting the requirements for our products based on their projected market needs 3, 6, 12, or more months into the future. Product managers provide strategic guidance for our development efforts through user and developer stories, use cases, and product roadmaps. They help with tough decisions about feature and product prioritization. Product managers spend their time looking at the big picture to ensure we can all see the forest for the trees. Some people you may know in this role are Asa Dotzler, Karen Rudnitski, and Chris Lee.
Takeaway, product managers:
- gather requirements from stakeholders and create roadmaps
- provide guidance and leadership to engineering
project/program managers
Project/program managers drive projects by managing project scope, schedule, and risk. They serve as a project steward and sounding board for stakeholder issues. Project managers coordinate work from various teams such as release engineering, product, user experience, support, quality assurance, press and pr, marketing, legal, privacy, WebDev, and IT. The result of working with these teams is that people in this role are typically well connected in the project. Unlike release managers, who, as I will discuss below, focus on individual releases, project managers focus on projects that may span multiple releases or multiple products. Many of the people at Mozilla who are in this role have strong technical backgrounds having come from the development organization at Mozilla or elsewhere. Some people you may know in this role are Sheila Mooney, Caitlin Galimidi, and me.
Takeaway, project/program managers:
- drive projects by managing scope, risk, and schedule
- coordinate the work of many different teams
release managers
Release managers are similar in many ways to project managers except their focus is on individual Firefox releases. The release management team manages and coordinates release schedules for the Firefox desktop and mobile Release, Beta, Aurora and Nightly trains, as well as Firefox OS. They monitor and control our risk profile and its impact on our product quality. They chase down critical issues and manage chemspill releases (point releases for critical issues). They ensure that the process flows from code check-in, to build, test, and release. They triage and track bugs in current and upcoming releases and coordinate the resolution of external issues, such as those due to plug-ins and add-ons. Release managers have to balance the needs of the various Firefox stakeholders including engineering, release engineering, quality assurance, support, documentation, and IT. Some people you may know in this role are Alex Keybl, Lukas Blakk, and Bhavana Bajaj.
Takeaway, release managers:
- drive Firefox releases
- triage and track bugs and coordinate the resolution of external issues
working with your managers
If you have worked with people in these manager roles you may have noticed that some people seem to be doing aspects of multiple manager jobs. The descriptions of each role above are the core responsibilities of each group. These roles tend to bleed into one another to a certain extent. All of the people in these roles are leaders within the organization and each have skills that allow them to play multiple roles.
Now that you know more about these roles and the people in them, use them. Talk to your product manager if you want to understand more about the product requirements and priorities. Talk to your project manager if you are blocked, unclear about project scope or timeline, or need some other help with your project. Talk to your release manager if you have questions about the upcoming release or have critical work that you think should be brought to their attention. And talk to your development manager about your engineering work and your career.
Lawrence Mandel 
Thank you Lawrence!!! This is tres helpful!
When I was at microsoft, Program Managers were tasked with creating specs. Is that true at Mozilla?
While Mozilla Program Managers may help create specs for certain projects, I would not describe this as one of our core responsibilities.
This post is helpful for those outside the corporation, too, since it’s only possible to follow the stuff that surfaces in the public. When there’s an imperfect representation of things there, it’s not always obvious either, because those who are affected by it aren’t equipped to fix it (almost by definition), and for those within who can, it’s harder to see because the communication deficiency is supplemented with the stuff in their heads.
So thanks.
I’m glad that you found this post helpful. My intention here was to inform the entire Mozilla community. All of these managers work on Mozilla projects, which typically involve both MoCo paid staff and volunteers. I would encourage all members of the community to interact with managers in these roles. They’re good people and they’re here to help.
Thanks for this Lawrence! I’ve been thinking about this too. I have a question for us collective p…. managers of Mozilla. Having been at Mozilla an entire three months, I have my ideas about this, but they may not be based in reality. Is there a difference within a Mozilla context, between a program manager and a project (or, “engineering project”) manager? My own thesis is that there is, that a program manager often deals with multiple projects and the relationships between them more than the details of a specific project, while a project manager, most especially the elusive and *fabulous* EPM (think Erin Lancaster, Marco Mucci, arguably yourself, though you seem to do both, actually) dives deeply into the guts of a specific project.
I agree. At Mozilla, the difference between program and project management is, for the most part, a question of scope. My first draft of this article included a few thoughts around this topic but I pulled it as I thought it detracted from the article’s goal. I may follow-up in a separate post about this topic.
That makes lots of sense to me. I agree it is scope and depth of engagement… and also maybe for people who are not us,it could be, as the rest of this article is, a clue as to “what to go to this person for”. Maybe. Anyway. Thanks!
There’s release managers for Thunderbird as well within Mozilla (and other apps have release mangers who are volunteers) 😉
Thank you for pointing this out. My bias towards Firefox projects speaks to my area of involvement in the project, nothing more.
This is a fantastic post, Lawrence! Thanks for taking the time to write it. It will be really useful to new employees (and maybe even old ones!) and especially community members who may not necessarily know much about the roles of individuals inside MoCo.