Five things to help your developer onboarding process

July 18th, 2018

Your team is getting a new developer, and it’s up to you to get them up to speed as quickly as possible. This is something that every development manager faces.

On-boarding processes can fall into a few different categories. Each has it’s own pros and cons. The categories are:

  1. Here’s a computer, good luck. This method of on-boarding is the worst, and I’ve been on the receiving end of this approach before. This category of on-boarding process is also known in the industry as no process at all. The problem with this process is that the developer is left not knowing what it is that they should be doing. It can destroy their confidence that they felt after landing your new awesome job.
  2. Here’s a link to JIRA and Confluence, read up, there’s a quiz in a month. This is sort of the opposite to no process, but almost the same. New developers are expected to read through tickets and wiki pages full of information that they’d probably not understand without guidance. This process could also be known as we needed a process, so we ask you to read a lot.
  3. Welcome to your first week of all day meetings. This process was created to break developers with boredom. The developers are forced into all day meetings with generically catered lunches. In these meetings, stakeholders share how things work at this organization with the new developer. Like the JIRA process, the new developer is hit with a ton of information all at once, and will probably never comprehend most of it.

The list of bad on-boarding practices could go on for quite a while, but let’s just agree that many of process that exist for developer on-boarding are flawed. Many of them were created, or evolved, in a reactionary way to correct errant behaviors in younger developers as deemed unacceptable by the veterans.

In my career, I’ve been both a developer who was coming into a new project as well as a manager trying to find the best way to onboard new developers. It’s been my pleasure to be on the receiving end of these bad processes. I’m also not afraid to admit that I committed some crimes against developer-kind in the name of on-boarding process. I shall turn myself in to whomever is The Hague of these sort of internet things upon completion of this writing.

As I have aged though, I have come up with an on-boarding process that I like for myself.

  1. Get to know your new hire. While the person you may have hired was good enough to make it through your gauntlet of hiring, they’re going to be nervous on that first day. It’s important to help them being to get to know their new co-workers. Setup coffees and lunches between the new hire and a few co-workers. Avoid one on ones, unless it’s between the new hire and a manager.
  2. Start with the basics. Your new hire shouldn’t be overwhelmed by the sheer volume of information that you could throw at them. Instead, start small. If you have a customer support department, have your new hire handle some support requests. Get your new hire listening in on sales calls. Immerse your new hire in the basics of your company, so that they can better understand how the whole company works, not just the development team.
  3. Ramp up slowly. My first pull request to the redesigned Boston.gov as the lead developer for the City of Boston’s Digital Team, was a left margin change. My first 20 pull requests were equally mundane. Over time, they ramped up from minor layout changes, to new components, and finally taking over the management of whole project’s development process.
  4. Expect tension. The new hire is going to make mistakes, or is going to have pre-conceived notions of how things should be done. When new members are added to a team, there are going to be tensions. Old developers will be adverse to change, while newer devs will want to burn it all down. There’s a happy medium between those. Be supportive and understanding of both sides. As a manager, one of your responsibilities is to manage this tension to keep it healthy.
  5. Give feedback early and often. Let the new hire know that you see their work and are hopefully excited that they’re on the on the team.

Ultimately, the most important part of on boarding a new team member is to empathize with them. It’s new for them, no matter how experienced they are. Maintain human contact in that initial phase to help them feel welcomed. The kinks will iron themselves out over time.