Main menu:

Site search

Categories

Archive

The MoCo Handbook for New Employees

Don’t you wish there were one?

That was my first thought upon coming across the Valve Handbook for New Employees. It has sweet comic book art and everything.

After skimming it, my next thoughts were along the lines of: 300 employees and no managers at all? Everyone just decides themselves what to work on? What kind of crap is this? Either Valve has a protected position in the market, so they don’t need to execute quickly on specific things, or there is a lot of structure, it’s just informal. (The manual actually does talk about temporary and informal structure.) I’m curious to know if either guess is on track.

But of course I also remembered that Mozilla is not so different. We have 600+ employees now (is it 700+ already?) and various kinds of managers, but there is still a great deal of autonomy, and everyone does generally get to/have to make a lot of decisions about what to do. And I think that is often hard for new people. So, to possibly make things slightly easier, I offer:

The MoCo Cheat Sheet for New Employees

(This is written by someone from engineering, so it may be engineering-centric, but I have to imagine it’s not terribly off-base elsewhere. Also, it’s not complete by any means.)

You’ll hear the word “open” a lot.

Mozilla is all about open. Open means you can talk about your work publicly. Anyone from anywhere might pop in and comment on your work. You can pop in and comment on any other project.

Open also means people won’t be telling you what to do very much, but rather expecting you to figure out how to contribute. Along with that, the org chart is never kept up to date, and is probably more of a dag or hypergraph than a tree. This is exciting and fun, but can also be challenging to navigate.

Becoming Effective. As a new employee, one of your first priorities is becoming effective at your basic job. For example, if you are on the JS engine team, your job is to fix bugs and add features to SpiderMonkey. Fixing SpiderMonkey bugs is hard, so it will take a lot of practice and learning to become good at it.

There are all kinds of new procedures, skills, and/or codebases to learn, but what’s special about Mozilla is that you need to learn how to decide what to work on. Even if you are producing top-quality code at maximum speed, the value of that code is still entirely dependent on how relevant the project is.

What to work on. It’s not a total free-for-all. You will probably get assignments. But the assignment may be very general, like “make GC not suck”. So you’d need to figure out what that really means. And you’ll probably get way more assignments run past you than you could ever do. So even if you try to just do those, you’ll have to choose. And quite often assignments are more offered than, well, assigned.

Why don’t we just tell people what to do? Speaking for myself, one reason is that I’m busy with all kinds of stuff, and I don’t really have time for that. But more importantly, I don’t know everything, so I’d really like your ideas and your help in making decisions. And most of all, I find that the results are far better when people choose their own projects–and choose things that they are fired up about, whether it’s because they’ll get to learn, they’ll get to feel badass, or for whatever reason it’s something important to them personally.

So how do you figure out what to do? In one word, listen. Talk regularly with people in and around your area to find out what problems need solving, bugs need fixing, enhancements are needed. In two words, listen intelligently. Simply aggregating everyone else’s opinion is OK to start with, but I’d really much rather see everyone else’s opinion blended with your own unique point of view. Plus you’ll want to pick out the projects that you currently have the skills to get traction on and that you’ll find interesting. And you’ll need to figure out who really knows what’s worth working on vs. who everyone else thinks knows what’s working on vs. who thinks they know what’s worth working on but really doesn’t.

That’s how I started out: at first Taras Glek gave me a bunch of ideas, and I tried to figure out which ones he needed most and which ones would be good for me to start off with and learn from. Over time, other people started asking me to do things, so I did those things too, and started talking to and hearing from more people. I heard about TraceMonkey, and I was really excited about it but I didn’t get a spot on the project right away. (After all, I knew next to nothing about SpiderMonkey at the time.) But I was patient and eventually TM reached a stage where it needed people to fix bugs and performance faults, so I jumped in. And then I started hearing more about TraceMonkey and JavaScript, and I got more ideas and opportunities.

One lesson from my experience is that figuring out what to work on is pretty hard. So if your first few assignments seem to turn out not to be of much value, don’t sweat it. (Often new people are offered low-priority stuff or weird ideas so they can learn without blocking ongoing critical work.) Just keep talking, listening, trying things out, and learning.

Also: watch out for tar pits. There are projects out there to work on that are ill-defined, or that are popular to talk about but not really useful, or that will have an ever-expanding scope, or that have been tried 3 times and have always failed. You want to work where you will have maximum impact, not minimum. So if you find yourself in one of these, call for help: get out or get someone to help you get out.

Becoming Visible. I think visibility is important in pretty much any software company bigger than Dunbar’s number, but in such a fluid environment, it’s even more important. If you’re after external rewards, your managers and peers need to know about the great stuff you’re doing. If you’re after getting to work on the big cool projects and such, people need to know who you are and what you can do.

You don’t need to worry about becoming super-visible immediately, but you can start taking steps to improve your future visibility right away:

  • Starting a blog is an excellent thing to do. You may think you don’t have much to write about. But you do: your work and your experiences at Mozilla. There is almost certainly someone out there who’s interested. I started this blog talking about abstruse aspects of program analysis, and even that found an audience.
  • Talking to people regularly in person or on IRC is also great, of course. “What are you working on” is a good conversation starter and likely to be reciprocated.
  • Asking people for help automatically lets them know what you’re working on.
  • Helping other people gives them a chance to see what you can do.

There are also of course all the mailing lists and newsgroups and Yammer. I have the sense that a lot of the talk on there is not that productive so I’m hesitant to recommend spending more time on them to a new person, but YMMV.

Doing great work does also get visibility. One nice thing about our fluid organization is that although if you are just doing great reviews or a great job on some series of bugs it’ll get you visibility only with your peers, that actually counts a lot. Doing great work on a really important project gets lots of visibility, but that’s a total duh.

Being Visible. The common notion of visibility is mostly about telling other people about your accomplishments (which for us extends also to your capabilities), but because we are so open, there is another side, which is letting people see you working.

We are supposed to be “all open and stuff”. It can be intimidating to work out in public where anyone could see you fail or criticize you. I highly recommend responding by embracing it. In Bugzilla, use the assignee field to show what you’re working on. Post half-baked design ideas before you start coding. Post WIPs (works in progress) to let people see your crappy incomplete code. If someone asks you to do something and you don’t have time or think it’s a bad idea, say so right away.

The advantage of this is that you don’t have much to worry about. No one’s going to discover what you’ve been working on for the past 2 months and criticize you for wasting your time, because they would have been able to give you feedback right away. No one’s going to complain you’re not working on their favorite bug, because they can either see that you are, or you’ve told them you’re not. If it’s all in the open, and no one’s complaining, it’s fair for you to think you’re on the right track.

Just to make sure you don’t think I’m (totally) crazy, I should point out that there are times to be less open. When you’re working on a proposal to change procedures or do a crazy project, or a presentation, or something like that, it does make sense to get feedback from a small group before taking it public. And that is in fact OK around here.

Becoming Influential. You probably have all kinds of ideas about how to make the web better, or the JS engine, or Bugzilla, or our review process. That’s excellent.

But don’t be too surprised if at first most of your ideas are met with skepticism, misunderstanding, refusal, or are just ignored. There are way more ideas out there than there are people to work on them, so everyone already has 35 great ideas they’d love to try. They’d have to decide that your new idea is better than those 35 in order to think about it all that much. Or maybe they’ve already heard that idea and they rank it #67, so they’re not that motivated to think about it again. Getting ideas heard can be hard.

But also, don’t be discouraged if your ideas don’t seem to move people very much. It doesn’t mean your ideas are bad. It doesn’t mean no one’s ever going to listen to them. It does mean that if you want to be heard you’re going to have to rise to the challenge and work at it.

The easiest way to get more attention for your ideas is if you have “open source street cred”. If you are new, there is of course a good chance that you don’t have any yet. But as you become effective and visible, you will get that street cred and more chance to be heard.

What to do in the meantime? I don’t have a recipe. I recommend just to keep trying. That’s also why I said not to get discouraged. You can try an idea on different people. Maybe the first 5 are not too interested but the 6th has time and wants to work on it. You can try it over time. Maybe when people first hear it it is unfamiliar and weird, but after talking with you about it over time, they come to see its merits. You can write code or do some experiments to test the idea and show how it might work. You can change and refine the idea to see if different versions get more attention. If you keep trying and pay attention to what works and what doesn’t, you will gain skill in promoting your ideas.

One thing I think is clearly effective in getting heard is service. If you help other people solve problems, make their jobs easier, or help them get their ideas heard and implemented, there’s a good chance they’ll be more inclined to listen to you and help you out. That can go a long way even before you have any street cred.

Now you tell me. If you’re effective, visible, and influential, then you’ve made it. You’re not even remotely a n00b. It’s your turn to tell me (and other Mozilla managers and mentors) how you did it and what we can do to better help new employees.

Comments

Comment from Till Schneidereit
Time: May 3, 2012, 1:36 am

An important corollary of Mozilla’s openness is that your (most excellent!) cheat sheet pertains to outside contributors almost as much as is does to employees.

With that in mind and being a very new contributor trying to become more effective myself, I can say that every bit of guidance helps in the beginning: The mentored bugs and Josh Matthews’ Bugs Ahoy as an interface to them are pretty good, but there are two problems with it: for many components, that list isn’t really extensive and it’s hard to tell which of these bugs it’s worth working on.

I know that that’d be quite a lot of work that nobody’s got time for, but what I’d really like to see would be a list of things that people agree are good ideas but that are too low on the list of priorities for anybody to work on right now. Maybe even with a (short) explanation of why they’re good ideas or some integration into a bigger context; Kilimanjaro comes to mind.

Comment from Robert Accettura
Time: May 3, 2012, 5:21 am

You could just call this the “Handbook for working on open source”.

Fantastic btw.

Comment from dmandelin
Time: May 3, 2012, 1:03 pm

I guess you’re right–it really does apply to volunteer contributors as well. I cast it as an employee handbook mostly just in parody of the Valve handbook (I’m a fan of Valve, btw), but also because in some ways, employees have it harder–it’s their job, so they can’t just drop away if they find it too hard to get started.

One thing that I think is much harder for volunteer contributors (and perhaps remote employees to some degree as well) is that you don’t have direct access (in the form of being able to just turn around and talk to them) to developers who can tell you what’s what. If a contributor could just stop by the JS pit for 30 minutes, I could tell them what we’re up to and what ways they can help out on their favorite project.

IRC is probably the best we have right now for that. I would strongly encourage people who want to start contributing to check in with people on IRC, just to ask questions and get ideas and/or help. #jsapi is a pretty friendly place, so give us a shot. (And now that makes me ask, how many people use IRC these days anyway? Are there people we can’t connect to on IRC?) Anyone should also feel free to just email me with whatever questions or ideas you have.

Thanks for your comments on mentored bugs, too. JS has 29, which is a good number, but the difficulty and relevance of those bugs is highly variable. The JS team would like to attract more contributors, so cleaning up that list a bit would be a good start. Also, I’m working on a new triage system, so I’ll think about how to add notes for contributors to it, and then we could even try to get them added to Bugs Ahoy.

Comment from Boris
Time: May 3, 2012, 8:06 pm

This is all spot-on. And yes, IRC is the way to just hang out and meet people especially for anyone not in a physical office. But even if you’re, say, in the London office and you want to chat layout or JS stuff… IRC is your best hope. How easy to use IRC is for people who haven’t used it before is a good question. :(

One other thing I wanted to add. It’s harder to do now with the checkin volume we have, but a very effective way to learn your way around the code is to skim the pushlog every morning, look for checkins that look interesting, and then skim the patch and the bug. Especially the review comments, if any. Of course you can also just look at a filelog for a file of interest and do the same, but the second benefit of the pushlog approach is you get an idea of what’s being worked on right now, and by whom.

Comment from Randall
Time: May 3, 2012, 9:13 pm

Hell, I’m impressed that you’ve got 700+ semi-autonomous people working together and it hasn’t turned into a Lord of the Flies office.

All jokes aside, I found your “cheat sheet” fascinating for non MoCo employees like myself. It’s a really nice primer for being an effective employee and engineer virtually anywhere.

Comment from Till Schneidereit
Time: May 4, 2012, 12:56 am

@dmandelin: Thanks for the feedback. I agree about #jsapi being a good place to get a feel of how the team works. Asking questions there is a different thing altogether, though: I did that a few times about specific things but asking open-ended questions in such a crowded place with everyone being busy with their work is somewhat intimidating.

I do think that IRC is easy enough for everyone to pick up, btw. Maybe an “official” read-only web interface simply displaying what’s going on could increase visibility and reduce the barrier to entry for people not used to IRC?

As for the list of mentored bugs: Cleaning up the list and adding notes from the triage process sounds great!

@Boris: I sort of do it the other way around; I have a save search of js-engine bugs changed in the last 24 hours in bmo and look through the list of changed bugs daily. I then open the ones I’m interested in and read the new comments. While that might (or might not, I’m not sure, tbh) be more work than reading the pushlog, it has the advantage of revealing things as they develop, often way before anything lands at all.

Comment from dmandelin
Time: May 4, 2012, 1:59 pm

Thanks. Following the pushlog is good. Given all the other things I have to do, I think that is too much volume for me to process these days. :-) Looking at bugs being filed and bugs being resolved (say, in the past week) is also fairly easy to do with Bugzilla queries, and gives a nice high level view of what’s going on.