After more than six years at Mozilla running Mozilla Research and five as my direct manager, one of the best managers I've ever worked with, Azita Rashed, is moving on to new challenges. This is not the end for the projects she has grown - Rust, Servo, Deep Speech, Daala/AV1, and the rest all have great new homes in the Emerging Technologies organization.
But since the organization will no longer exist and she will no longer be around to shape the projects and work we do, I wanted to reflect on some of the many lessons I've learned from her and the organization she built along the way.
Small teams make the biggest leaps
What's the difference between two people for six months and one person for a year? Or four people for six months and one person for two years? Everything!
One expert can take their time, report their results, and take frequent risks. New language? New tools? Do a novel integration of recent research publications to find a new approach? When you have a single person, all of that is reasonable.
When you have a team of even two people, but especially four or more, the ability to take technology risks moves to nearly zero. Risk probabilities are multiplicative, which means that for each additional "slightly ambitious" choice you make in a project, the odds that you will deliver on-time or provide full functionality drops rapidly. When you have many people on a project with a shorter duration, they need to be reporting incremental successes monthly (sometimes weekly!). This fundamental tension causes projects to grow more conservative as they get larger. And then ask why there's no major innovation anymore, causing a small team to be split off, which then grows to "accelerate the work," which then becomes more conservative and the cycle repeats.
I'd lived the dynamic many times at Microsoft, but Azita had a fundamental understanding of these tensions and how to manage the tensions in all directions: including within the team! Often the research team itself wants to grow too quickly, not realizing they'd ground the project before it learns to fly.
Everyone needs a career path
Never hire someone full-time for a job or a current set of work items. Hire people for a career path. If there isn't room for growth - either technical or management (or sometimes back and forth!) - there isn't need for a full-time employee and the work should be outsourced.
This dynamic is really important because there is an analog to Conway's law related to the need to promote people, which I'd characterize as:
A product's architecture and organization will grow to fit the needs of the promotion schedules of the individuals working on them.
That also applies to you, the manager! Once you can no longer grow, you will stifle the growth of those who work for you.
Demand the team work with trust and respect
It's common to manage to a minimum bar or a set of participation guidelines or a code of conduct these days. While that ensures that members do not feel excluded from a community, Azita demanded more of us all.
In particular, that we all treat each other with trust and respect. We have definitely caused some eyebrows to raise in the past for demanding more professionalism from our staff than we do of volunteers or corporate partners. And nobody is special or immune. Azita has (rightly) called me out, particularly early on when I brought a bit too much '00s Microsoft style to my interactions.
We used to have a quarterly offsite meeting of the Research managers and leads, and one of the most important rules that she enforced with us is that after a quick, initial complaint session the rest of the offsite would focus on a positive, optimistic path forward. And following that rule one last time, I wish Azita all the best in her next role and promise to do my best to deliver on all the potential she has lined up for me and my team!