Cheezburger Network Doesn’t Show Its New Employees the Bathroom Until They’ve Checked In Code

with 39 comments

What do your new employees do on their first day?

Fill out paperwork?  Collect up office supplies?  Fiddle around with the customizations on their computer?

At Cheezburger, our new developers write and commit code to our production software on Day One.  Yes, you heard that right…we throw a newbie into the fire before they even have time to know what hit them.

I would strongly encourage you to aim for this goal with your new employees on Day One.  The result will be happier, more empowered employees with an attitude of ownership and a focus on productivity.

Even if you don’t work with developers, you can find ways for your team members in other departments—marketing, sales, finance, operations, etc.—to contribute on their first day.  For example, for marketing it could be to identify an improvement to the copy on the site or run a new SEM campaign. For sales or customer service, it might be hopping on the phone with an actual customer.

To illustrate, let me explain to you what we do with our new developers at Cheezburger. Given that there are only eight hours on the first day, and the developer does, in fact, have some paperwork to fill out, that means there are a few puzzle pieces you need to have in place to prevent this from being a complete disaster.

1.  Start with a small, specific task that you want the developer to complete, such as a minor bug fix or a simple code change.

For example, our most recent developer fixed a bug where if a customer attempted to use a password that was too short the error message was unclear.  From a technical skills perspective, this basically meant adding a new test (to catch the bug) and a new case to a switch statement (to fix the bug).

Let’s be clear: the point of the exercise is not to have someone show you their amazing coding chops.  The point of the exercise is for them to learn the process for getting code from their keyboard into our software.  It’s simply impossible for a developer to be productive member of your team if they don’t know that process, so that’s what we teach them first.

2.  Have a well-documented procedure so that the developer can install a development environment on their workstation.

When our developers arrive on their first day, sitting on their desk is a brand new computer.  We have already setup all the accounts to all of our systems that they are going to need.  And, in their e-mail is the licence keys for any software that they are going to use.  In other words, there is nothing blocking them from getting started.

Next, we provide them a document with a 17-step process for transforming their machine into a development environment.  This includes steps for installing software they will need to develop on our code base, for fetching our code from source control, and, finally, for building and running the code on their machine.  All in all, it takes about 90 minutes to get up and running (which includes installing an IDE and database server).

In addition to the installation guide, we have also developed a few essential pieces of bootstrapping software to accelerate the install process.  One piece sets up and manages the database schema automatically, and the other manages application configurations from machine to machine.

Now, don’t think this comes for free.  We have invested in the creation of this process because it has more benefits than just setting up workstations.  When we need to build a new machine, we have the steps documented.  Or, heaven forbid, in the event of disaster recovery, we have the steps to be back up and running.

3.  Assign a mentor.

Even the best developers are not going to figure out how to follow your process and fix that bug on their own.  It’s just impossible.  On Day One, a new employee is still trying to figure out the location of the bathroom, for goodness sake!

So, we assign them a mentor to coach them through the day.  And, we don’t just say, “Oh, you can ask so-and-so if you have any questions.”  No…I take another developer and have him sit with the new employee, side-by-side, at the new guy’s desk, for the entire day helping him through the process.

Most companies don’t want to waste a second of developer time…they want developers pounding out code.  Yet, we’re “wasting” an entire day of developer time, so that we can get a second developer up to speed much faster.  In my view, that’s not waste because ROI on that day is spectacular!

In sum, the net result is that by late afternoon on a developer’s first day at Cheezburger they have been genuinely productive and are fired up to come back on Day Two for more!

—-

The inspiration for this post was that we had a developer start just last week, and he was thrilled to be productive on his first day.  That led to a conversation [via instant messenger] between myself and the three most recent developer hires at Cheezburger.  Here’s what they had to say about Day One at Cheezburger:

Me: So…how does it *feel* to commit on your first day?

John: Good.

Eli: Scary, and very good!

Me: Could you elaborate on that? Why did it feel good? Why scary?

Eli: At [my last company name], it takes at least a week to even get your box. At Cheezburger, you can feel productive immediately. It’s a little scary being so new and pushing something out to production to quickly, I didn’t want to make a mistake. But it’s awesome to have a system where you can push out so quickly.

John: Well put. Ditto.

Me: So, why was it awesome to do that? There’s something about that which feels….????

Eli: Empowering is a good term. I’d also say that there is a greater sense of ownership at Cheezburger.  At [my last company] there were several layers between the developer and production.

John: After coming from a big mega-corp with 6 degrees of separation between devs and the production environment, it was very empowering to be able to push the button without having to collect 12 different signatures or part seas.

James: At my last job, I spent 2 weeks trying to build a working dev environment.  It was so frustrating, and most amazingly (as I was just telling John and Eli) nobody was willing to help me.

Me: Wow!  That would make me want to quit.

James: I very seriously considered quitting in the first two weeks. It was a complete waste of my time. It was hard.

Eli: When new guys came into [my last company], you didn’t want to help them build their box because box building was excruciating. It’s better to hope the new guy figured it out from the out-dated documentation that you do have.

I’ll let you be the judge, but it sounds like developers enjoy being productive on their first day.  And, in my experience, happy developers are productive developers, so the efforts we make for Day One at Cheezburger are well worth it.

UPDATE: Based on the comments, some readers have interpreted the title of this post to mean that we actually withhold the location of the bathroom from new developers until they commit code.  Ha!  That would be funny…not.

We show everyone the bathroom…both, in fact, because we have two.  The title of this post was meant as a humorous way to illustrate the importance we place on getting people up and running.

If you read the post carefully, I never say anything about not showing new people where the bathroom is located.  I’m sorry if I caused confusion.

Written by scottporad

November 1st, 2010 at 9:30 am