Posted on by & filed under Business, distributed teams, hiring, process.

My first month at every job is a period of self-loathing, usually characterized by frequent white-hot panics in which I believe that I’m not good enough for the job, not a real programmer, or just profoundly stupid. This experience is what I thought everyone meant by the term “onboarding.”

So, when I looked at the schedule for PyCon this year, the talk “Technical on-boarding, training, and mentoring” stood out. I ducked in and sat in the last row, so I could easily slip away if necessary.

Instead of what could have been a soul-crushing grind about resource efficiency, I was delighted to hear the presenters Kate Heddleston and Nicole Zuckerman describe onboarding techniques that they had used to make new employees feel like humans welcomed into a group of other humans. Imagine if the next person we hired at Safari didn’t feel like we had set them on fire and asked them to find the water!

Activities for new engineers

As the talk progressed, I began to realize that we are all doing onboarding wrong. I wrote typo-ridden notes, struggling to keep up with all the great examples of onboarding activities that the presenters discussed, many of which I had never done nor asked a new person to do. Here are a few examples, paraphrased and sometimes given a Safari twist:

  • Buddy up the new engineer with the last person who got the development environment running

Not the most experienced person on the team, not the team lead or the person who built the dev environment from scratch two years ago, but the last person who set it up.

  • Ask the new engineer to start emailing things they didn’t understand or learned every week (2–3 things per week)

This one is great because even if a manager or a more experienced engineer sets aside time for one-on-ones, a new person might avoid or delay asking questions for several reasons. They might not want to bother someone who is obviously busy, or want to avoid asking what they think are foolish questions. Asking them to send questions invites them to open up and sets the expectation that they won’t understand some things. This could be a big win for some of the more reticent personalities joining a team.

  • Give the new engineer a map of people on the team, what they work on, and their areas of expertise

I wish that every time I had joined a team someone had given me this document. Imagine if, as a new engineer, you could easily find the person on the team who knew the most about Redis, or a particular internal web service or build process. Invaluable!

  • If they are more of a junior engineer, ask them to give a 5 to 10 minute presentation on a small topic biweekly or monthly (internal products, Python or JavaScript language features, testing methods). These should be things they can research independently that are useful to know.

This one is cool because it sounds super annoying, but it could really benefit junior programmers and interns. Just the other day, my boss was like, “How does SAML work again?” and I struggled through a hand-wavy explanation before giving up and admitting that I still didn’t have some of the details down. I guarantee you that if a junior engineer joins the team, I will ask them to give a presentation on SAML.

There was tons of other great advice, like having “code labs,” which are times that a new engineer could ask a more senior person any question, even something simple or embarrassing [A reddit AMA?—Ed.]. Also shadowing or short-term pairing, where the engineer sits (or remote screen-shares) with someone on the team to get exposure to the whole development workflow that the team uses.

Summing up, and more resources

One of the main ideas that I took away from the talk was that a new engineer’s first month could be very explicitly about the team welcoming them and guiding them through what is always a very complex, fast-moving world of new code and people. It sounded great, and I immediately wanted to go back and make the onboarding process at Safari even more awesome. I put together a proposed schedule of onboarding activities that we can try with new hires based on what the presenters suggested. I’m stoked for our next employee!

Kate Heddleston & Nicole Zuckerman gave a talk "Technical on-boarding, training, and mentoring" at PyCon 2014

The video from Kate Heddleston & Nicole Zuckerman’s great talk “Technical on-boarding, training, and mentoring” at PyCon 2014

Now that PyCon is over, the talks are all online, so you can watch a video recording of “Technical on-boarding, training, and mentoring”.

For a completely different perspective on onboarding, check out how WordPress does it by making everyone rotate through their customer service team (from The Year Without Pants).


2 Responses to “How can we make your first month awesome?”

  1. homebuydallas

    Good post, but frankly I disagree with it, almost in entirety. I think the people giving the advice are too young to be mentoring (that is, they do not have enough experiential understanding to be advising what newbie tasks should or should not be… but since I wasn’t there for the Pycon session, maybe it’s just the blogger’s take on what they said). That means that I will now have another blog post of my own to do and it shall be so. Tip: Do not give a junior engineer a ‘biweekly or monthly’ task to give a talk on ANYTHING when they are still learning. What would be the point, really? All they would talk about is what they learned in school, and that is not important. By the way, writer of this blog-post, if you could not explain SAML to your boss then it was good of you to admit you don’t know. Because I have a PhD in MATH and I can explain ANYTHING I know to ANYONE in terms THEY can understand. That is how one knows what one knows, get it? :)