Engineering Manager at Mozilla
January 14, 2019#build-engineering #distributed-systems #distributed-teams #open-source #remote
My background is as an open source release engineer and backend Python developer. I spent many years optimizing build and release pipelines to ship products faster and more securely on many different platforms. I spent a lot of time debugging distributed systems and migrating continuous integration farms to more modern tooling. Now I work as an engineering manager for build and version control systems at Mozilla, which is part of our larger Engineering Operations organization.
The year before I became a manager, I started thinking less about distributed systems and more about distributed teams. I would look at the team I worked on and think “I wonder how engaged they are in their work?” “How can we celebrate our successes as a distributed team?” “How could we share our skills more effectively among team members?”
I started reading a lot of books about being a manager, listening to podcasts about management and watching related conference talks. I started to think about the best managers I’ve had and what I could learn from them. I also talked to several managers in my organization at Mozilla about the opportunities that were available in terms of team leadership. Last year, there was a panel with several people in engineering leadership at Mozilla called “I’m a manager, AMA”. I attended it and one of the leaders said that she went into leadership to change the culture. This was the proverbial light bulb going off moment for me. I wanted to do that too.
Early in 2018 I had the opportunity to lead a team and transitioned from being a Staff Engineer to an Engineering Manager. I feel that it is very rewarding work. It is a completely different job than a software developer individual contributor with a completely different skill set. It is a steep learning curve but I feel like I’m learning something new every day.
My team is remotely distributed across North America, Europe and Australia. I work from my home in Ottawa, Ontario. I spend a lot of time in video meetings talking to people. I verify that projects are going as expected or if there are blocking issues at an organizational level, helping them get unblocked. I have weekly 1x1s with my team members to see how they are doing, ensure that they are working on projects that both align with the needs of the company and help them meet their career goals. I organize goals for the team and set priorities. Are we all focused on working on the most important thing? I also have peer 1x1s with other managers to learn what their teams are working on. Will they be starting projects soon that require resources from our team? What timeframes are they looking for the projects to be completed?
I do a lot of bug triage. See what issues people are opening-and if they require immediate attention or can be deferred until later. Are their patterns to these requests that point to a larger issue that needs to be addressed? Are these new requirements for projects we should have on our radar? Can the documentation we provide to users on how to build Firefox be made more clear and concise? I talk to people in Slack, IRC and write a lot of Google docs with respect to planning and organizing the work of our team. Basically, I write and talk to people all day.
I really like to see people learn new skills and grow as engineers. That’s what I find really rewarding about this job. I arrange mentorship and coaching that will allow people on my team have a greater impact. I also like to see more underrepresented folks work in the tech industry and rise into positions of technical and people leadership. Over the summer, I had the opportunity to be a secondary mentor to a couple of interns from underrepresented groups and that was very rewarding.
Given my history as a release engineer, I really like to ship. Write patches, test them, ship them and move on the- next thing to fix. The feedback cycle for a software developer is much faster than a manager and that has been an adjustment for me. As a manager, the timeframe for implementing change is much longer. I have to try to remember that I can’t fix things immediately and I sometimes find that frustrating. It takes time to build trust with people-and to build consensus that a new project is the right direction to focus the team’s efforts.
It feels fantastic to see your team ship something that had been in the pipeline for a long time and a positive reaction from other folks in the organization. It surprised me that it makes me happier than when I used to ship something as an individual contributor.
I’m also surprised to the degree that the job of a manager is emotionally challenging. Telling people difficult news is well, really difficult. People have all sorts of emotions tied up in their work. I always try to acknowledge people’s emotions. Build empathy with how they feel and understand their perspective. At the same time, you have to set priorities that help the business move forward.
A former colleague, Amy Rich, who is now an engineering director at Nuna told me that communication skills increase in importance the higher level that you are in an organization. That is so true. Every day I’m reminded of the importance of clear communication, clear expectations and reiterating goals. People don’t hear something the first time you say it so you have to keep repeating your message. Also, my personal mantra lately is that code is easy to patch, communication is not. So you really have to craft a message that is clear and concise the first time you say it.
Also from Amy, it’s much easier to get people to arrive at a consensus of what the most important work to focus on if you give them the context to do so. People are much happier if you ask them to investigate a solution and determine what’s the right thing to make the business successful versus explicitly setting goals without their input.
A former manager at Mozilla, Mark Côté, once said that the root cause of problems in relationships, business or otherwise is misaligned expectations. I think about that a lot. For example, an engineer may want to work with Python but the company decides to consolidate most of their stack to run on Go. If there are unaligned expectations on what a person wants out of their job and the direction the company is going, you have to work that through with them and decide the path forward.
Reach out to engineering managers who have made the transition and learn from their experience. Ask a lot of questions! Realize that being a manager is a completely different job than the role of an individual contributor software developer. Your role is to optimize the work of the team, not optimize your work as an individual, and that is a pronounced shift in focus. As a manager, you won’t be able to write much code anymore. And the projects you work on may be much smaller in scope than the ones you worked on as an individual contributor. Are you okay with that? If not, maybe you should stayon the software developer track. Being a senior IC and a full-time manager is not usually tenable in the long term due to the amount of focus required for both roles.
Read a lot of books about management. (I summarized a few of my favourites on my blog.). I also found joining the Rands Leadership Slack to be useful for talking to others who are transitioning to management. Talk to other leaders at your company and determine what management positions are available and what expectations you would need to meet in those positions. Take courses to prepare you for leadership, internally or externally. The LeadDev conference has many great talks on YouTube about managing software engineering teams.
Talk to your manager about your career growth and how they would like to move into a management role. They are probably aware of opportunities in other teams. Learn more about the culture of the larger team, what your role would be and the expectations you would need to meet.