Hack hack hack...

An open journal-- some of it written for you, but most of it is for me.

Onboarding

I’ve read a lot of articles about onboarding, but I’m not sure I come away with anything that actually changes my process. We all know that onboarding is important. Given how many juniors are on our team, it is essential for them to be brought up to speed as quickly as possible so that they have a chance at being productive.

Onboarding starts during the hiring process. This is why compensation negotiation is so tricky. People need to be excited about starting. A difficult negotiation becomes very personal. This is the purpose agents play. They are able to distant their clients for a painful negotiation so that it is less personal.

After the candidate has accepted, if given the opportunity, I really push for the new hire to take a good amount of time off. I refer to these as “bookends” and I believe there should be a good amount of space between her last experience and her new one. A new hire is usually surprised by this, but it sets the tone for a more caring managerial relationship than they have experienced before. The message is clear. You are a hard worker, you deserve a break. We will wait for you. Come when you are ready.

For the purposes of this article, I’m going to focus on junior hires because I think their onboarding process is likely more complicated than their senior counterparts. Juniors need a ton of attention when they arrive. I mean like daily check-ins, scheduled lunches and coffees and firm direction on what code to explore. I start with the onboarding readme on our team wiki. We also have a dev expectations readme.

I’ve pushed new hires to improve the docs as they read them with so-so results. The truth of the matter is, they can’t recognize what they need to know until a few weeks in and by they their attention has turned to feature development. Maybe asking them to take another scan after a couple months would be an effective way to improve the system.

The first few 1 on 1s are critical. This is a time to allay fears about imposter syndrome and provide a lot of encouragement upfront. Juniors have never seen a code base as large as ours and they are intimidated. Reminding them it is the exact same, there is just more of it will not be heard the first few times you say it. It will need to be repeated a dozen or so times before it sticks. You belong. We are confident you belong. We wouldn’t have hired you if we weren’t. We don’t make hiring mistake. Whether it is true or not, that’s the message and willl give you the best shot at success.

The first few assignments are also very important and I’ve learned to not be so cavalier with them. Here are some of my favorites:

  • Specs: There are always things to improve in the test suite and giving the new hire some space to go down a few rabbit holes will familiarize her with how the system works while at the same time immediately adding value.
  • Refactors: Improving your most incomprehensible code immediately makes the new hire a hero after they can untangle your mess. Again, giving him some space to explore how the system interacts is time well invested.
  • Small feature win: Shipping something immediately makes everyone feel good. Not only are they able to quickly get a win on the board, but they also can immediately feel the builder’s high and pride of owning a user facing feature.
  • Pairing: Pairing can be combined in all these scenarios but pairing takes the pressure off of the new hire by making sure they aren’t going it alone. Insisting the new hire to drive anecdotally also seems to increase confidence and ensures she doesn’t become a passive observer.
  • Onboarding the next noob: Allowing a new hire to onboard the next new hire has been really effective for my team since it proves how much he has learned about the code and our process. While the timing is a key element, I’ve seen confidence levels dramatically shoot up after shepherding a new hire.

There isn’t anything all that novel here. I think giving a new hire a lot of attention and making sure they don’t flounder too much is the basic goal (a little flopping around is OK). Even if they are working on a project, allowing for an orientation period takes the pressure off and allows them to explore the code. This is time well spent. For a new junior hire, I’ve made the mistake of putting deadlines around that first project with disastrous results.

Ramping up not only helps a new hire feel productive and competent, it also affects our team dynamic. We need all of our team members to participate in our difficult discussions and if a new hire lacks confidence in their code contributions they also sideline themselves in our team dynamics. Poor onboading is an opportunity lost to build rapport and establish confidence while good onboarding usually leads to individual comfort and immediate buy-in. So while it can be very time intensive, for me it has been worth the investment.

Comments