Thought experiment: design an open source new-hire process.

February 24, 2012 – 1:56 am

Little thought experiment today (pedagogy class is really getting to my brain): if I were creating a new-hire process for employees being assigned to work on an open source project, here what would it look like? Here’s a first pass; it’s randomly improvised and not particularly well-thought-out, adiposity but fun anyhow; it’s partially based on what I’ve (unconsciously) come to find myself doing each time I’ve launched into a new open source project over the past few years.

You spend your first week as a remotee, no matter who you are or where you’ll end up working. You have exactly the same access to the tools and processes that a community member would have; no internal mailing lists, no magical “you’re hired therefore you get the root password” shortcuts. If you want privs, you need to earn them the same way as any community member (or in some cases, when the hire is from the community, they’ll have earned them already). During this week…

  • You have constant access to orientation staff — hopefully in-person, but at the very least via a remote medium you’re already comfortable in. This is important; they’re your culture/tools coaches, and their encouragement will help you buffer the inevitable frustration you’re going to hit (new hires will be told ahead of time that it’s going to be frustrating).
  • You’ll get training in remote collaboration tools if you don’t already know them. Your project’s IRC channels, bugtracker, wiki, version control system, etc… you’re going to learn to use them. By the end of the week, you’ll be lurking on your project’s IRC channel(s), your blog will be feeding into Planet (and you’ll have posted on it), you’ll have introduced yourself on mailing lists, edited the wiki, triaged bugs… This is a lot like the material we teach in POSSE (actually, you could remix POSSE into this portion of such an orientation).
  • Ditto the above to open source culture. Things like “release early, release often,” “default to open,” open source business models, “ask forgiveness not permission,” and so forth will be brought up by your coaches.

The main point is that you’re going to try to start doing your job without any sort of magical special “I’m an employee” powers (other than the fact that you’re paid to work on this, which is a privilege that shouldn’t be discounted). Inevitably, you’ll run into issues; outdated documentation, discussions you can’t overhear because they happened inside an office and someone forgot to send notes to a mailing list, information trapped inside the heads of your coworkers. Since you want to get stuff done, you’re going to start poking your teammates to get documentation out there, to talk on IRC, to better practice the open source way and enable you to work as a “community contributor” — and if they do, they’re not just enabling you, they’re enabling the entire community.

And that’s your deliverable for the first week. You’re going to try to get work done, and it’s great if you can, but you’re probably going to end up with a list of “things I can’t access from the community world and need in order to do my job.” Some of the things on this list may be legitimately internal; I’m willing to bet a bunch of them will be externalizable. It’s going to be frustrating, but again, that’s the point; you’re going to experience exactly the same pain community members face, so that you’ll know firsthand why it’s so important to open them up once you do get “inside.”

Oh. And you’ll get through the normal new-hire paperwork and training (finance/payroll, legal, company history/vision/mission, etc) because some of that is stuff companies are legally obligated to do (I think).

You’ll actually be allowed inside the office at the start of your second week, but only for 4 days a week. You can join internal mailing lists now, see private documents, that sort of thing. But you’re still considered to be in training. Here’s what that means.

  • You’ll still get ongoing modules on the culture/tools/practices of the open source way. Maybe you’ll run an IRC meeting and get feedback on your meeting-running skills. Maybe you’ll shadow a “community-experienced” coworker to see how he/she handles certain kinds of interactions and tools. Maybe you read a little writeup on the feature selection process in your open source community and then blog about it.
  • When you learn something, you’ll document it as a record of your learning. Publicly when possible, on a shared internal wiki (or something) when not.
  • That one day a week you’re not allowed in the office? That’s your “community shift.” You spend that shift helping community members get their stuff done. That list of “stuff I needed access to during my first week that wasn’t out in the open”? Fix it. Hang out on IRC and answer questions. Review patches. Reply to mailing list posts. Triage bugs and thank reporters. Do some wiki gardening. Go to an open source event. Screencast a tutorial. You get to expense lunch, and you have to write a blog post (that will go to your project’s Planet) about what you (and your team) have been up to for the week — the stuff you can talk about publicly, that is.

Practicing the open source way is something that takes time and experience because it’s a paradigm shift; it’s about how you see the world, the subtleties of how you interact with it, and its effects are usually not immediately apparent. That’s what you’ll learn here — it’s easy to tell you, but in order to observe it, you need to live it.

You’ll learn that “but I have nothing to contribute!” isn’t true (remember, this is for all new hires, not just engineers). You’ll learn that your beginner’s mind is sometimes your most valuable asset. You’ll learn how your work with the community can bring a lot of subtle little long-term leverage to your employer (and some not-so-subtle, huge, short-term wins, if you’re lucky). You’ll learn what it’s like to welcome new people to the community in turn, and how quickly even a newcomer can become an even newer newcomer’s “old hand” and mentor. You’ll learn how much energy can be unlocked when you release a blocker and enable community folks to do stuff they’re already rarin’ to do.

This phase lasts for… some defined period of time. 3 months, 6 months, “until the release cycle you joined during is finished,” whatever makes sense for that project. But at that point, you get your first review…

Your performance review is based on your public record. If it ain’t public, it don’t count. The things you’ll bring before your boss are things like your git commits, meetbot IRC logs, wiki edits, list threads… your public portfolio of open source participation. If you don’t have enough of a public record (where “enough” is some standard we define somehow — I told you this was off the top of my head) then you remain in “trainee” mode for another round.

Once you “graduate” from new-hire training, you’re no longer mandated to do “the open source way” training modules (or at least not constantly), and you’ll be allowed in the office anytime. Maybe your “community shift” will shorten (half a day instead of a full day every week?) or maybe, depending on your role, it might vanish (although I would love to see, for instance, the new lawyer or accountant continue to lurk in IRC, comment on mailing lists, and so forth). Maybe on-site workers will still be required to take one “remotee week” a year in order to remind them; remotees are already typically expected to make trips to headquarters to meet folks in person at least that often, so why not reverse it?

Again, raw thoughtdump. Plenty of holes, I’m sure. I’m curious what people think – especially people who have careers in open source, or want them. Is this an orientation you’d sign up for? Is this an orientation you’d like your coworkers to have?

Know someone who'd appreciate this post?
  • Print
  • Facebook
  • Twitter
  • Google Bookmarks
  • email
  • Identi.ca
  1. 9 Responses to “Thought experiment: design an open source new-hire process.”

  2. I think that one of the key pieces on what you just wrote (which I definitely love) is the fact that you encourage people to be proactive. Sometimes at work people expect to receive a task with a lot of details, and usually get stuck or just stop when something is missing. Using the OSW is encourage them to *try* and not just sit and wait because *I’m an employee*

    This also happens on communities. Even if we *expect* that most of them will be proactive, is common to see people asking *ok, I’m an ambassador, what should I do now?* *ok I’m a translator, what are my tasks*; when reality is that the task is to *excercise THAT role*.

    Would be amazing if we could push this changes into all types of business. Love to read your posts Mel!

    By tatica on Feb 24, 2012

  3. Heya Mel,

    Wonderful stuff. Absolutely.I’d have prefer to have gone through this 5 years ago when I started off at a small company. And would love to have new hires go through all of this(though I’m ensuring most of it would happen in the new hires in my team) at my current place.

    PS: If your raw-dump is so crystal-clear. I wonder what would be your polished and carefully thought out post !

    Keep posting

    By Kashyap Chamarthy on Feb 24, 2012

  4. @Tatica: …ooh, that is an excellent point. I didn’t think of it that way before! It’s true; most people (my former self included) have been so conditioned to stop and wait to be told which path to follow that sometimes we actually need to explicitly retrain ourselves to be proactive and make our own opportunities.

    My other secret (ok, not so secret) hope is that community members will see the new hires doing these things during the first few weeks and go “oh wait, I should do that too” (or “I can keep doing that too!”) and then begin to model and pick up that behavior even more themselves, so it becomes the norm for new people in the project whether they’re employees or not.

    @Kashyap: I’m curious to hear how you (unofficially) teach new hires at your company how to do this — and how does it work out? Is it unfamiliar for them to learn, or does it make immediate sense? How do they feel about the things you show them?

    By Mel on Feb 24, 2012

  5. Mel,

    Maybe I should’ve mentioned in my first comment that I’m currently with Red Hat(QE) . And, as an emeritus community architecture member you know it better :)

    New people in our team do realize what kind of things are involved(I don’t want to repeat the things you listed)

    About your ‘how we do’ in our team — again, the very same things you mentioned – collaboration with upstream lists, discussing on upstream IRC channels, blog posting, etc.

    Like you pointed, sometimes, it does take time(I’m learning too) to very new people to ‘observe’ and to ‘feel’ and then get in the zone.

    Your post summarizes quite well.

    I hope you’re enjoying your study.

    By Kashyap Chamarthy on Feb 24, 2012

  6. I liked your idea. About the only “change” that I can think of is that after the training phase, the new member/hire is still required to do the “community shift” one day a month. Or maybe one week a year. I would say that one day a year is too long, since they will “lose” the insight that they gained in their time on shift.

    Maybe something like this: If your role is an engineering or other direct support of the product(s), then you’re required to do the community shift at least one day a month (or one week a year). If you’re in an non-direct role (advertising, lawyer, accounting, etc), then you’re required to do the community shift once every six months or so.

    Have a great day:)
    Patrick.

    By Patrick Dickey on Feb 25, 2012

  7. Only one week?

    Anyway… I recommend you to read the free “Producing Open Source Software” book by Karl Fogel. What you suggest is exactly what CollabNet does with developers of Subversion.

    By Why? on Feb 25, 2012

  8. Awesome–I like the focus on enabling the community! While teaching some lessons along the way!

    “Since you want to get stuff done, you’re going to start poking your teammates to get documentation out there, to talk on IRC, to better practice the open source way and enable you to work as a “community contributor” — and if they do, they’re not just enabling you, they’re enabling the entire community.

    And that’s your deliverable for the first week. You’re going to try to get work done, and it’s great if you can, but you’re probably going to end up with a list of “things I can’t access from the community world and need in order to do my job.” …. you’re going to experience exactly the same pain community members face, so that you’ll know firsthand why it’s so important to open them up once you do get “inside.””

    By Jodi Schneider on Apr 28, 2012

  1. 2 Trackback(s)

  2. Feb 25, 2012: VC2: Friday Night, Ambassadors and surprises! - tatica.org
  3. Feb 25, 2012: VC2: Friday Night, Ambassadors and surprises! | Fedora Colombia

What do you think?