I have the enviable task ahead of me to recruit a from-scratch team for MailCo, to help me lead Thunderbird in particular and email & internet communications in general. In this post, I highlight some of the requirements I’ve identified for MailCo, and what that means for who would be a good fit. I then give high level descriptions of the roles I’ve identified as being my first priorities.
What will MailCo be like?
This is going to be one unusual company. We’re going to be a small team (probably fewer than 10 people in the first year), with, from day 1, an awesome responsibility towards hundreds of contributors, tens of thousands of beta testers, and millions of users. People will also look to us to do innovative, industry changing (and still unspecified) things. While few will expect us to mirror Firefox’s success, for a variety of reasons, I think we have much to gain by simply trying. At the same time, while we’ll have an ambitious mandate, we’ll also have to carefully manage the existing codebase, support today’s community, and incrementally make both the project and the community stronger. We’ll be part of the Mozilla world, but have our own identity as an organization and a band of co-workers.
What does that mean for recruiting? I think the best summary of my thinking here is that I’m looking for “thoughtful, ambitious people who can have extraordinary impact through leverage”. By thoughtful, I mean that it would be a disaster to bring in people with wonderful blue-sky ideas as to how the world should be, and who will push their ideas forward without considering the existing state of affairs. By ambitious, I mean that there is too much stop energy in the world, and it’s too easy to look at any situation and see unsurmountable problems. Especially in a startup environment, I need people who, when faced with a roadblock, will either ask “where should we start clearing?” or “can we go around it?”. (I’m well aware that my job as a leader is to make those questions be questions that are both reasonable and safe to ask). By leverage, I mean that regardless of the functional role, MailCo’s success will depend on our ability to draw in contributions of code, sweat, passion, talent, and enthusiasm from people outside of MailCo. This will be as hard as it is rewarding. Bright, competent people are rarely comfortable asking for others to help them. It may even feel inefficient at times. But the only way we’ll ever be able to radically improve things is to build the same kind of thriving community that Firefox has built. So I’ll be looking for people who understand that and can help identify and amplify “scaling factors”.
The long-term goals for MailCo and Thunderbird will be discussed in detail later. For the purposes of today’s post, I can summarize the medium-term goals for Thunderbird as:
Build and continually tune a software production machine
This first goal has all to do with code, process, infrastructure. There’s a lot of work to do there, from build and test automation, architectural cleanups, fine-tuning of the release definition, bugflow, outreach to the various related communities, etc. The best news there is that many people seem to agree on what’s needed — all that’s been missing is time to do the work, and that’s exactly what the seed funding is for.
by Richard AM
Massively increase the number of people using Thunderbird
I believe that while today’s Thunderbird is a great product for several million people (!), there are some relatively small changes which could make it a great product for millions more, while not detracting from the user experience of its current fans. Simple things like spending time (key word again!) on UI cleanup and simplifying initial configuration could, in collaboration with a grassroots marketing effort, significantly
impact the number of people we reach.
Build a platform for long-term innovation
The Mozilla project (platform, community, infrastructure, people) is remarkable for its powerful customizability, extensibility, and reach, both enabling innovations and taking them into the hands of users. Thunderbird has already done a lot there, fostering great innovations through extensions, and as part of its product evolution. I think we should and can do more. We should increase our support of add-on developers through advocacy, marketing, and access to infrastructure. We should also use some of our resources to do some of the hard engineering and documentation work which will make it easier for the next generation of extension developers, partners, and advocates to do more.
Note that these three goals feed each other. You can’t reach millions if you can’t smoothly produce and evolve software, and market impact will make innovation relevant.
A few other important points before I dive into specifics:
- I’m in Vancouver, but not everyone has to be. I’d love to have people join me, for a couple of reasons: for some roles, especially those involving a lot of coordination, having people nearby is helpful. Also, Vancouver is a great city, moving here tends to be easier than many other places, and living here is a privilege I don’t mind sharing. At the same time, I expect MailCo will be a global organization, reflecting the nature of the project, and I’ll cheerfully consider remote workers.
- Experience with the Mozilla project is a huge asset to a candidate. Mozilla does software in a unique way. While each project has its own twist on how decisions are made, work is coordinated, releases are driven, etc., there is a general agreement regarding the basic model. If you’ve never encountered Mozilla technologies or the Mozilla process, you are at a disadvantage — however, it’s not an insurmountable one for many positions.
- At this point, I’m not looking to fill “management” positions. If you’re not interested in being an “individual contributor”, then check back in a few months.
With that in mind, here are the broad categories of roles that I’ve identified so far, after talking to Mozilla Corporation staff, Thunderbird, Seamonkey, and Calendar contributors, managers at other companies with relevant experience, and drawing on my own background.
In no particular order, and titles to be negotiated:
Thunderbird is a huge codebase. Lots of JS and C++. Some of it ugly. Lots and lots of known enhancement requests, bugs, interdependencies, protocols, use cases, preference switches, configuration options. I and others have ambitious plans to evolve it over the next few years. I won’t have the bandwidth to keep the entire project in my head, and I know that I don’t have the C++ chops to help orchestrate such large-scale changes gracefully. I need someone who can help lead that. Such a person must be able to assist the community of existing developers as well as nurture new developers and help them become productive. This is not a “management” or pure architecture job, by the way — code reviews & patches are the currency of the project, and for this person to be effective their coding and related practice must be top-notch. Relevant experience with client-side software and industrial-grade C++ is a requirement.
In collaboration with the big-picture role above, there is plenty of urgent, high priority work to be done in the codebase, and I expect at least a couple of people to be working at the module level or feature level to help drive changes, refactor cheerfully, and help others day-to-day through the usual IRC and bugzilla channels. I’m in particular looking for people who can think “vertically” about the software, understanding not only the engineering issues, but the user-facing issues as well. We’re building a tool to be used by millions of regular people, and people who are driven to make the “computer stuff” just work for end users will find this an opportunity to have a huge impact. People who have “shipped” software and understand the messy, stressful, frustrating but necessary compromises involved will have a leg up.
One effective lever is judicious use of computers in the software production process, including automation. There is urgent work needed to simplify the build machinery, building on the work that Mozilla’s build group has already done. Once that’s done, there’s work to build a strong test automation system. When that’s done, there will be more to do. The ideal candidate here is driven to make normal operations automatic and invisible, and yet always wants to improve processes. Experience and passion for build automation, test automation, sysadmin and configuration management skills required. Knowledge of Perl, Python, makefiles also required.
User Experience Lead
UI and user experience in general is a topic I have a lot of interest in, and I think it’s one of those areas where Thunderbird has been particularly starved for resources. I’d like to see someone become the driver for user experience for Thunderbird, using a similar model to what Mike Beltzner has been doing for Firefox. This is a prime example of where being good at your trade isn’t enough, and you also need to understand, appreciate, and leverage the community to broaden your own perspective, and scale your impact.
QA Community Lead
Thunderbird keeps some of the most personal and important data that people have, their email. For that reason alone, it’s important that the quality initiative for Thunderbird remain central to the project. There are tens of thousands of people who are willing to help in various ways, and at least one person will be needed to coordinate their efforts, lead test days, help drive the test infrastructure, assist with bug triage, etc.
I believe that the extension-writing community is one of the layers of community around Thunderbird with most latent impact, and I need someone to focus on them. This means making sure that extension writers are listened to when planning the product’s evolution, helping with our developer documentation story, implementing strategic extensions, demonstrating and stretching the extensibility of the platform, and looking out for Thunderbird extension authors and users in general. Experience with mozilla front-end technologies in particular is important, as well as strong people and troubleshooting skills.
If you think you have what it takes, let us know by emailing firstname.lastname@example.org. Feel free to send traditional CVs/resumes, as well as more idiosyncratic descriptions of what you do if that’s likely to be helpful (closed bug lists, screenshots, URLs to relevant work, etc).
If you think there are other jobs that are more important, or if you just want to put your two cents in on the above, feel free to add comments to this post. Don’t apply in the comments, please, that’s much more likely to get lost in the shuffle.
Note that this isn’t an exhaustive list of the roles I hope to fill over time. It’s just the first cut. And if you don’t fit neatly in one of the roles above but you think we should hear from you anyway, send us an email. I reserve the right to change my mind when faced with real people rather than job descriptions.