Gradual Changes Afoot

I've been a manager at Mozilla for several years now. I became a de facto manager by necessity, when we established the Auckland office, and became a de jure manager a little later when the increasing size of the platform team meant we couldn't all report to the same manager. (It's hard now to remember what those days were like!) I've never been passionate about being a people manager, and I've always looked to reduce or eliminate that part of my role, but our pace of hiring always outstripped my ability to send my direct reports to other managers. Lately that's changed, partly because our hiring has slowed in the areas I touch, but also because we have more and better managers in the platform team to take up load. So, the people-management side of my role is finally shrinking. I think this is good for me and Mozilla --- I think my time and attention best serve Mozilla when used for tasks other than people-management.

This means if you're looking for someone responsible for running a Gecko platform team, it's probably not me anymore. For layout, it's Jet and David Baron, for graphics it's Jet and Milan, for media it's Anthony Jones, and for WebRTC it's Maire. Those areas also have their own technical decision-makers.

My decreasing management responsibilities have been offset by increasing responsibilities for leadership in other ways. As Mozilla has grown in size and scope, and my tenure lengthens, I've been playing the "senior figure" role more and more. Sometimes this is nothing more than repeating what a lot of engineers know, but putting my status behind it. Sometimes it's about drawing on broad knowledge of Mozilla and the Web platform to instruct people. Sometimes it means trying to modify or review code no-one else will touch :-). This is all necessary and important, but I'm not completely comfortable in it yet. Sometimes I'm hit by imposter syndrome. Most of the time I'd rather be writing code :-).

Developer Parallelism

In Gecko we've often had N large projects be implemented by just one person each. This has some benefits; in particular it can be quite efficient, since coordination costs are low. It's also a good way to reduce the amount of code learning developers have to do. Another approach is to put N people to work on one large project, and hopefully get it done in roughly 1/N of the time. I think the latter is probably a better way to work. I think we get better reviews, since at least for me, I do much better reviews in code I've actually hacked on than in code I've never touched. It means that if someone gets hit by a bus --- or worse still, leaves Mozilla --- we've got people who we know can work on the code. Projects getting completed faster means there's less bitrot to deal with. It makes us more agile (I hate that word though). Perhaps most importantly, it's more fun.

Most of our projects go through a startup/prototyping phase where we write some new code and get things basically working. Then there's a grind phase where we get the code working on all platforms, iron out the corner cases, fix all the regressions, fix all the fuzz bugs, write tests, and get it landed. The latter phase is usually a lot more work than the startup phase, but it's also the phase that parallelizes across developers fairly easily. So I think we should consciously try to work this way: when a project enters the grind phase, we should shift developers onto it until it's over the line. We've done some of this recently with fixing rooting hazards in JS, and in the layers refactoring.

In cases like OMTC there's some flexibility since getting the project "over the line" isn't all-or-nothing. Having people individually bring up platforms one-by-one works OK and brings incremental benefits. Same goes for converting code from XPIDL to WebIDL. So for those, the benefit of having a lot of people pile on is reduced (especially, in a conversion project, if we know that for some reason or another we will never be able to completely eliminate the stuff we're converting from).

In any case, I hope that from now on, for any project of significant size we have at least two people working on it during the grind phase, to capture the benefits I mentioned above. If someone sees this not happening, let me know and we'll fix it :-).

Meeting Absenteeism

I have a bad habit of missing meetings that I should (and want to) attend. This is inexcusable given that my meeting load is actually very light.

I have identified a few contributing factors. Many of these meetings are outside normal work hours (especially early in the morning, given my timezone), so sometimes I fail to check my calendar before I go to bed and wake up after the meeting. Sometimes I want to wake up but forget to set my alarm, or set it incorrectly. Sometimes the alarm just fails to wake me up. Sometimes I know about the meeting and I'm awake and working, but I get caught up in something and don't realize that the time has arrived. I use Google Calendar and GMail, and when people send time change notification emails Google Calendar adds them as new meetings instead of replacing the existing one, which sometimes confuses me about when the meeting is. I quite often quit and restart my browser, which means my Google Calendar tab often isn't really loaded and can't produce notifications. Most of my meetings are teleconferences of some kind, and sometimes I don't plan ahead and when I try to join the meeting, I find that Vidyo isn't working or some other technical problem prevents me from joining the meeting immediately. None of these issues are excuses, since this isn't a very hard problem.

I could try setting up the FxOS calendar app, but I'm not very vigilant about keeping my phone charged so that might not help much. Maybe I should do that and also ensure that I have a desktop calendar app capable of producing audible notifications, that launches on startup. To some extent I may just have to be trained by pain and humiliation.

Until that happens, consider this blog post an apology for the meetings I've missed, and an apology in advance for the meetings I miss in the future. Also, consider this a blanket permission and indeed recommendation to contact me by whatever means necessary when I've agreed to a meeting but I'm not there --- IRC, email, cellphone, even my home phone. The numbers are in the Mozilla phonebook.