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!
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!
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).