Mozilla Firefox: How We Make Sh*T Work.

Mike De Boer at UXDX Community: Amsterdam. Video: https://www.youtube.com/watch?v=TW4qBCCxTP0

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

What this talk is about

[00:00:09] Hi, I'm Mike de Boer. I'm here to talk about Mozilla Firefox, and that's basically two nouns, Mozilla and Firefox, so I'm going to dive into those two specifically, and how we make stuff work. And since this is, I heard, called UXDX, I was intrigued and wanted to focus on the UX and interaction, and how our UX team integrates and works together with our engineering teams. I hope that will interest you too, to some extent.

[00:00:49] So first let's get back to the basics. What's Firefox again? Let's reiterate. Then second, what's my place in this maelstrom of stuff and the internet? Well, that's a lot of stuff. Feel free, please feel free, to sit down. Challenges, things we face daily. That's just naming a few, not all of them, because we'll be here tomorrow. And our boulot[?], which is French for, well, stuff to do, and our stuff we do, basically highlighting our unique approaches. Conclusion, where I try to say something about what I've said before during the talk, and also try to peek into the future a little bit. And then it's time for questions, of course, and yeah, ask me anything, for real, that's totally fine. Hit me up after the talk as well, preferably with me holding a beer, I'm much easier to talk to.

What's Firefox, and why Chrome won

[00:01:54] All right. What's Firefox again? It's an internet browser, similar to Google Chrome, which probably most of you were using, which makes me really sad. So this is also one of the motivators for me coming here: actually to drive people back to Firefox. I'm going to say to you that it's actually fantastic stuff, you should really switch over. But for real, really.

[00:02:27] Yeah, we understand, we are the underdog. It's Chrome that has all the market. Recent February numbers for netmarketshare.com indicate — and those are not perfect numbers, we actually use different statistics internally to measure our reach, but these are the best available publicly, sorry, let's just go with that — it says that it's grown upwards, if we round up, seventy percent for Chrome total market share, and only about ten, or not, let's round down then, okay sure, nine percent for Firefox. Really, really.

[00:03:12] Let's look at why that might be the case. So why aren't we that much better and beating Chrome easily? Well, that's because a couple of years ago we were in fact worse than Chrome in terms of speed, and they launched the new browsers, so they were with a fresh code base, relatively fresh code base. They were able to make huge strides of progress in little time, and we were working in our old crufty codebase, trying to make things happen with long iterations, so we were unable to keep up. To put it simply, Chrome was better on all fields, and they had a massive, massive marketing push.

[00:04:00] Obviously Chrome is backed by Google, or it's a Google property, and they want you to consume ads. And what's better to serve you ads than to actually control the browser you're using, the one gateway to the internet? So that's their motivator. And through that they have massive, massive amounts of money to repaint bus stops, to own planes, to just do everything in their marketing power possibilities to get you to use Chrome. And when you're an easy target, you're slow, your UI is outdated, well, then this happens.

Firefox Quantum, and the scale of the project

[00:04:51] But that doesn't mean we didn't start fighting back. With Firefox 57 we relaunched as Firefox Quantum, and are now on par with or faster than Chrome actually is, along with a UI revamp which I'm particularly proud of, because I worked on that as a software engineer back then. We have over 330 million active users, so when we push an update to Firefox it reaches 330 million users. And you'll learn more about that when we talk about challenges, because that actually yields a number of challenges, to have that amount of users downloading and using your product daily.

[00:05:45] In fact we are, and have been for a long time already, since its inception probably, the largest open source project in the world. And there's something not a lot of people know, but the project is massive. We actually are one of the main drivers for DVCS, distributed version control systems, to improve their performance, because they can't cope with the Mozilla codebase. For example, when we started to migrate from CVS to Git, or to a DVCS, Git wasn't an option at the time, it just forked, it just failed miserably. So we had to choose, and we went with Mercurial, because it performed reasonably, and now it actually performs really, really nicely. Facebook thinks so as well, they use it too.

[00:06:39] Firefox is a melting pot of technologies as well. It's the birthplace of industry-changing programming languages. One of them you all know probably is JavaScript, invented in 1995 by Brendan Eich, who then later on became our CTO, had to leave sadly, and now is the CEO of Brave, one of our competitors. That just happens over time.

[00:07:06] But then we did another breakthrough, which was in parallel programming, and that was the creation of a systems programming language called Rust, which probably does ring a bell somewhere here and there. It's one of the biggest trending languages right now, and we are not even the biggest consumers. They have teams at Facebook and Google, hundreds of engineers working on secret projects that I'm not allowed to share, working with Rust only. So it has huge momentum.

[00:07:43] And then we have Gecko, which is our layout and rendering engine. It's bundled with our JavaScript just-in-time interpreter, or just-in-time compiler I have to say, and also hosts a new web technology which is WebAssembly, which is the web version of assembly, the lowest level of programming language you can get. It is particularly useful for computing intensive applications, like gaming engines. They do a lot of calculations on matrices and offload a lot of their stuff through GPU pipelines and stuff like that. So Gecko, the engine, also encapsulates the internet as it's shown to you, as it's presented to you. I have to hurry up.

Mozilla as a movement, and my place in it

[00:08:33] All right, it's also a movement. We have a manifesto, which, as we were one of the first open source projects, we also have a couple of rules to bind us and to ensure that the internet is a global public resource, open and accessible to all. Because Mozilla, and therefore Mozilla Firefox, is a nonprofit, unlike Google developing Google Chrome, for example. We went from Netscape, which was then closed source, to Mozilla, which is open source, and it was a while ago, it was '93 I believe.

[00:09:08] We have a foundation part and a corporation part. The foundation part is basically our biggest client. We make Firefox for the foundation, they give us the job. They don't say, yeah, we need this feature, this feature, but basically it's like, in order to fill our mission to keep the internet open, we need you to build technology to make that happen and make that reality.

[00:09:39] So what's my place here? I started as an engineer six or seven years ago. Started young, self-taught, got caught, can't escape. So I got myself into trouble and started doing software engineering. Of course I'm not completely self-taught, because that doesn't exist. I met great mentors on the way that helped me get to where I am. Started with PHP, evil things, and did some smaller galleries, that was a while ago. eBuddy.com, which you might remember, was on the canals here, is that correct? And Ajax.org, or Cloud9 IDE, which was an online development environment in the cloud, and that was also here on the Keizersgracht[?].

[00:10:25] Got funding multiple times, so I got to live the startup life. We did company ski trips and all kinds of crazy stuff. And Mozilla is much more mundane, maybe, in that sense. So, complex JavaScript applications, yes, obviously. And the mentor story comes back again and again. Now, having done a couple of management gigs at startups during startup phases, I'm now a manager at Mozilla, back again, and I manage the search team, which is in fact the team that brings in all of the revenue, all of the five hundred million dollars of revenue that we have to spend on building Firefox and all our other products.

The challenges: time zones, culture, process

[00:11:18] So there are organizational challenges that we face, and we have to find non-conventional solutions due to our organizational structure. And this is going to be a recurring one, so remember it: it's agile, but different, because of that.

[00:11:37] So here are the challenges, divided into three columns. First is time zones. We work remote, there are a lot of remote workers. 46 percent of our workforce works from home. Our workforce is, about, now let's say give or take, a thousand and fifty people, and 55 percent obviously then work from an office, and 39 percent of that works outside of the US, spread over 14 countries worldwide. And that goes from New Zealand, Australia, Asia, Japan, China, to North America, and multiple offices in Europe, being Berlin and Paris, of course, and not Amsterdam. So I have to work all alone from my office at home. But not too lonely, because we have a nice video system that always works. And we get together twice a year at all-hands[?].

[00:12:41] So, culture. We take open source seriously. We were one of the first open source projects, we are one of the founding partners and part of the EFF for ages, so we have good ties with them. The Electronic Frontier Foundation, the ones that try to keep your digital rights intact, somewhat, somehow. And we are really much based on participation models, so there's a lot of volunteer contributors coming in from all over the world, and we have to be able to cater to such a diverse and inclusive community.

[00:13:24] So there's again also many nationalities, religions, traditions and politics, but also genders. They are rapidly increasing, the amount of genders that you can have. Just kidding, of course. But that's important, to have an open community that accepts everything that you might come across in the real world.

[00:13:48] Process. We have a classic hierarchy, a CTO, a bunch of c-level organizations. There's a board that controls and fact checks what the senior directors are doing, and then we have a very large layer of middle management, which I'm part of. And due to this there is a strong focus on individuality. Actually there's only 20 people or so working on the front end, on the Firefox UI that you see. So it's largely based on trust. We trust in each individual to do their job according to what we discussed, or towards what we agreed on, what each other committed to. Again, all trying to fit in an agile but differently structure.

Our solutions: making everything asynchronous

[00:14:38] So, our solutions. What are they? We have to make all the things asynchronous. What that means is that we have to use our tools to basically bridge the gap between time zones and countries, geographical locations that are so diverse. You have one team that can have members spread across the world, and of course we try to group that a little bit, but you also need to get to the true diversity goals. So that's interesting.

[00:15:09] We use online tools as much as we possibly can to async-ify communication. We have a dedicated video conferencing network. It's super important, especially if you're working from home, that you have a semi-reliable one. It's super hard, that stuff, it's a problem in the world. I mean, we will have people on Mars earlier than we have a dedicated, really working video conferencing system. But still, what we have is relatively decent, unless my entire neighborhood goes on Facebook at the same time. Pretty much solid: five o'clock in the afternoon.

[00:15:51] And there's a strong focus on goals. As you can imagine, getting all these obviously fantastic individuals to gear up and move in the same direction, it's important to start working from top-line goals, and that goes down in a pyramid-like shape down to individual goal-setting.

[00:16:16] Tools that we use, for example, are Bugzilla, which is Jira, everybody tends to know, but then cruder, and looks like you're back in the 90s, but actually works pretty damn well when you're into it, whereas Jira fails me more often than it doesn't. And MediaWiki, where there's a large part of our organization that focuses on developer documentation. So the entire Web API and JavaScript APIs are documented on MDN, Mozilla Developer Network, developer.mozilla.org, and that's all in wiki format, so volunteers contribute, and it's an important part of keeping the internet open.

[00:17:04] Trello, which is a team organization tool much like a Kanban board where you move stickies across. Smartsheet.com is where we manage all our OKRs, or team level objectives and our company level objectives, and our objective breakdowns. And Google Sheets: we produce an amount of Google documents that you won't believe. Well, probably you do, because your organization does the same thing, probably. So yeah, Excel isn't dead, everybody does spreadsheets now in the same way.

[00:17:42] GitHub: a large part of our development cycle is not on this monolithic Mercurial repository, but we have many products, many projects, and a lot of them live on GitHub actually. We use InVision to share wireframes and designs, so that's a bit of our UX team coming in there. And Phabricator, which is a code review tool developed by Facebook. That's just a sample of the full list.

Culture in the open, and agile but different

[00:18:19] Focusing on culture. We do everything out in the open. We are an open source organization, we live and breathe the open internet, so everything we do is looked at through a looking glass. We have to be aware that everything we do, touch or communicate is visible to a huge community that is behind you, that's in it for the same values.

[00:18:50] People. Again, especially as a people manager, it's a lot about people and diversity, as I touched upon before, and the value of a manifesto comes across again. And it also touches on having top-level goals, that goes down to the individual goals, down the organization more broadly, and you have a single thing that binds you, that everybody stands behind, and an ideological belief that is motivating you to make your best effort.

[00:19:24] So we have a mix of agile going on, because of this async structure that we have, many remote workers. We have a project manager, the project manager has the role of scrum master. The product manager has the role of product owner, keeping track of product requirement documents, PRDs, and specifications, and also managing the backlog items. UX, engineering is a scrum team, together with UR, our user research.

[00:19:58] Daily standups are costly, so we don't often do them, because trying to get a team together spanning across multiple time zones is impossible. So we do them, but we do synchronization meetings, sync meetings, once a week, and then we mostly communicate asynchronously through mail, IRC or Slack or whatever is most comfortable. Planning poker sessions are costly, again, planning a large session over multiple time zones is expensive, so they are rare. Business value game is costly, so also rare.

The backlog problem

[00:20:31] Process, this is the agile but different nonsense: the problem of the backlog. So the challenge is keeping the backlog rolling, always keeping the backlog to a certain solid size, so that engineering teams always have enough items to work on, to pick from when their sprint ends. The problem is that the product owner is responsible for this, and solely responsible.

[00:21:02] So our proposed solution to this is to apply the principle of cross-functional teams into backlog grooming. So instead of focusing on the engineering team, that this should be an engineering team that takes in work, there's a UX person involved, and there's a UR person involved, and a project manager involved, that does all the things. I'm out of time, sorry.

[00:21:21] So, agile but differently. You actually do the same thing, but then in a mirror, and then also apply that to the backlog creation process, the speccing process. So you have a product requirements document that sets the requirements, the features, which is usually meant to communicate upwards to senior management about what you're doing, what your bigger plan is, if you need a stamp of approval, that kind of thing. Whereas the goal of the backlog is actually to have actionable items on there that engineers can just pick up and go with and fill the sprint with.

[00:22:04] So the agile but different thing is that we start off with a kickoff meeting that is timeboxed to 30 minutes, where we collect a set of requirements and pull everything together, and we spec out together as a team, with UX, UR and engineering together with the product manager. We're also co-signing that backlog document, and a set of requirements that spans minimum one iteration, so one sprint length, usually two weeks or three weeks, and then preferably three sprints in total.

[00:22:37] So this is the process, how it starts, and like I said: kickoff, collect requirements, then you have different scoping sessions to prune your backlog items, and then the team picks one iteration out of that list and starts working on it. The advantage of this system is that it's async viable, so people can just push in requirements from their field of expertise onto the backlog document, and then during these different scoping sessions you can just go through them and also estimate those backlog items.

Q&A

[00:23:13] Mike: Let's skip the conclusion, because otherwise I'll be slapped instead of getting a beer after. And I'm open for any questions.

[00:23:27] Host: But not just now, because the next speaker is actually dying to talk as well. We can take one question just to keep the conversation going, and then you're staying for the drinks, right, so you will be around?

[00:23:37] Mike: Yes, of course.

[00:23:37] Host: So, anybody has one spicy question for Mike?

[00:23:40] Audience: Thanks. What's the first thing you would like to change?

[00:23:58] Mike: Could you clarify what you mean, which area? That I don't seem happy?

[00:24:08] Audience: No, not necessarily.

[00:24:10] Mike: I mean, I'm not in an unhappy place. Well, generally I am, using Chrome.

[00:24:22] Mike: I called them challenges, but yes, I think that they are tensions, they cause tension sometimes. And that's actually the exciting part, or the less exciting part, well, sometimes it's the exciting part of working like this. Like, I'm a hundred percent remote, I don't work at an office, so I have to rely on digital tools to get my job done and to communicate with people.

[00:24:53] Mike: So, first part, how do we catch up to Chrome? It's to put the user first instead of the ads first. Google is focused on making money, that's all they do, all they want to do really. They actually only want to do that, and we don't necessarily want to do that, even though we need money to be able to evolve and fund our research and technology endeavors. So what we're going to focus on primarily this year, for example, is tracking protection on by default, so that we block tracking for all users right away. It also makes the web faster, so hey, that's nice.

[00:25:38] Mike: Another part is better integration, so that you're not forced into silos, into verticals. You're not forced into Facebook and have to stay there, they're not allowing you to leave ever, and the same for Google, Google properties. So the idea is that we have our own UI, like the Awesome Bar, like the address bar, to basically provide more usable results, get your things done there in the browser where your focus is, instead of being redirected to one of those silos. So those are directions to get us to a more happy place. And yeah, our users need to be conscious choosers. We don't have billions of marketing money to spend, so that's always going to be a tough call and a really hard problem.

[00:26:27] Mike: And from the at-home thing, how do I change that, how do I become more happy with this way of working? I think that's part of it. It's never going to subside unless I move to Silicon Valley, but I have made the conscious decision not to do so. So yeah, I'm actually more accepting, and basically my remarks were more on the sarcastic side, I think, than they were actually trying to be really over-serious about it. But it does pose challenges, you know, in different styles and methods of working that you need to adopt. And remote working is going to grow, all right, it's going to be more common. We've seen that over the period of the last five years.