11 Questions for a Better Developer Onboarding Program

Inspired by the Joel Test for better code, I’ve come up with a similar rubric for evaluating your Developer Onboarding program.

  1. Is your Onboarding program consistent and easily repeatable?
  2. Do you make new hires feel welcome before they start?
  3. Do you send them their paperwork before they start?
  4. Do you set up their systems and accounts before they start?
  5. Do you spread out social introductions over days or weeks?
  6. Do you include new hires in team discussions immediately?
  7. Do you start new hires on a training project that mimics normal project work?
  8. Do you provide technical skill training?
  9. Do you provide soft skill training?
  10. Do you pair new hires with a mentor who isn’t their manager?
  11. Do you incorporate feedback mechanisms?

Provide a simple Yes/No answer to each question, and score 1 point per Yes. Naturally an 11 is the ideal. An 8 or better is a pretty good program. With less than 5, I’d have significant concerns about the stress you’re putting on new hires, and I would not be surprised to see correspondingly high turnover rates among your developers.

If you’d like to share how your program scores with me, fill out this survey.

1. Is your Onboarding program consistent and easily repeatable?

The human brain is hard-wired to take the easy path, to expend the least amount of energy. It’s a survival mechanism. That’s why it’s so hard to change our routines and habits – because doing so takes concerted effort over an extended period of time, which the human brain hates. If we want to change our routines, we need to make the new stuff as easy and visible as possible while making the old stuff as difficult and invisible as possible.

This doesn’t change when humans are grouped together in teams or organizations; those groups have habits, too – we just call them “processes” instead. And because of the aforementioned phenomenon, if we don’t make those processes easy and efficient, they won’t be followed appropriately for any significant amount of time.

To make it consistent, document the entire Onboarding procedure. Define and assign all responsibilities and the timeline of events from start to finish for a new hire. Do not lock the documentation down; keep it open to all employees, and encourage real-time edits so that it remains up-to-date. Likewise for relevant team procedures; document them, share them with the company, and encourage updates. The easier it is to update documentation, the more likely it is to stay updated.

Some helpful things to document:

  1. Onboarding Program tasks, expectations, and timeline
  2. Email Templates: Acceptance Response email, Day 1 Introduction email, Welcome Announcement email
  3. Employee FAQ: What is the pay schedule? What are the company PTO/leave/sick/holiday policies? What are typical/expected working hours?
  4. Who’s Who?: Who does what around the company? Who can they go to for questions about certain topics?
  5. Timeline of Events with Dates and Attendees: 1 on 1s, team introduction(s), tours, demos
  6. Application Ecosystem: What are the applications used to run the business? How do they access them? Where can they learn more about the applications?

Make sure the Onboarding procedures are easy to follow and the Onboarding “environment” is easy to use. Use the same systems and tools that employees use in their normal course of work to manage and deliver the Onboarding program as well. For example, if you always manage your client projects with Jira, then your Onboarding program should be managed out of Jira as well. If there is a completely different process or set of systems to use specifically for Onboarding, or if new hires are sequestered away from their team until their training is complete, that will introduce a ton of friction into the process and make it less likely to succeed. The more closely the Onboarding program mimics real day-to-day work, the easier it is for employees to execute, and the more effective it will be at introducing a new hire to their job.

The most important part of Onboarding is the relationship-building that takes place. If the program is difficult to execute or unclear to follow, then employees will be frustrated and new hires will be confused, which is not a good foundation for new relationships. Use systems and tools to automate away the mechanical aspects of Onboarding (documentation delivery, task assignment, event scheduling, etc) so that you and the new hire can focus on the relationship aspects: fostering trust, confidence, and enjoyment within the team.

2. Do you make new hires feel welcome before they start?

Before the Dark Times (read: 2020), did you ever walk into a party or other social gathering knowing only the time, the location, and maybe one person there? I always get this nervous fluttering feeling in my chest. Then you find that no one is there to greet you or let you know how the event will unfold or introduce you to anyone. That fluttering feeling suddenly turns into a solid rock which then sinks slowly into the bottom of my stomach.

Magnify that feeling by about a million, and that’s what Day 1 can feel like for a new hire as the stakes are quite a bit higher than some meetup. As the person doing the hiring, you can help alleviate or prevent that feeling.

I’ve written previously about my own experience starting at a NetSuite firm along with a few recommendations for what you can do before a new employee shows up on their first day.

One of the simplest things you can do is to send a welcoming email response after they’ve notified you of their offer acceptance. Some helpful things to include in the “pre-boarding” email (or series of emails):

  1. Expression of genuine interest and excitement to work with them
  2. Agenda for Day 1, including start time
  3. Names and emails for important points of contact, especially for anyone they’re going to meet on Day 1
  4. Reminders for any physical materials they’ll need to have ready (e.g. voided check for direct deposit)
  5. Invitation to ask questions or start conversations before Day 1
  6. A quick summary of what the team is currently working on or what type of project the new hire will soon be involved in
  7. Expression of your feelings on why this person is a good fit for that team/project

You’re looking to strike a balance among being welcoming and informational without being overwhelming. Unfortunately I can’t tell you where those lines are; it’s up to you to find the tone and balance that’s right for your team.

3. Do you send new hires their paperwork before they start?

Nothing stymies all the excitement of the first day on a new job faster than a gigantic mass of paperwork. All too often, the first day is just form after form after form after form aftr from afr fmor.

What a waste of a first impression. Make your first day more engaging.

After you’ve excitedly acknowledged their offer acceptance, but well before their first day, send your new hire some or all of the relevant paperwork via email. Let them know they can gradually complete it leading up to their first day.

Keep track of any questions that come up regarding the paperwork, along with the answers, in an FAQ document; share the FAQ with new hires whenever you send their paperwork. Additionally, send them the contact information for any relevant HR or management personnel that can help.

If you’re not already paperless wherever possible in your HR processes, the Onboarding program is a good place to begin exploring that option. There are approximately 3,720 products/services that can help you achieve this. The only thing worse than being handed a stack of documents to sign is having to print then scan those documents yourself.

Avoid the deluge. Filling out paperwork is dull and mechanical. Automate the mechanical aspects of Onboarding; amplify the relationship aspects.

4. Do you set up a new hire’s system and accounts before they start?

Another sure-fire way to quash Day 1 excitement: have your new developer lose the entire day (or longer!) to setting up accounts and figuring out what software they need to install.

Provision all of their accounts ahead of time (email, chat, NetSuite, etc). Their accounts should be ready and waiting on Day 1. Many infrastructure systems like GSuite and others offer automated cloud application account provisioning.

If you purchase a laptop for your new hire, pre-load the laptop with the applications they’ll require for their development environment. If you don’t purchase for them, make sure to send them the list of applications ahead of time so they can download and install early.

While there are many IT automation tools to help streamline this process – Virtual Machine tools like Vagrant, Containerization tools like Docker or Ansible – these tools do require significant research, management, and maintenance all their own.

Either way, document the list of applications – both the cloud applications they’ll be using and the installed applications.

Even if you’re extremely flexible about what tools developers use, you should at least have a document describing your “recommended” setup. Share that document early with new hires so they can prepare accordingly.

5. Do you spread out social introductions over days or weeks?

Do you just love spending all day in meetings? Do you fill your days relishing the repetitive small talk and marveling at the mismanagement of the Mute button?

Alliteration aside, almost no one enjoys a day packed with meetings, so don’t subject your new hires to it, either.

Our inclination seems to be to introduce a new hire to as much of the company as quickly as possible – a nightmare carousel of people, processes, and projects. The first few days are often crammed full of welcome wagons and 1-on-1s and meet-and-greets and more. Chances are, both of you are planning on this person sticking around for a while. There should be no rush in introducing them to every possible person or piece of knowledge they might some day six months from now possibly need.

Compounding the issue are the personality types of your existing team members and the incoming new hire. Are you adding an introvert to a group of extroverts? Vice-versa? If you have an incoming introvert, having them introduce themself to various individuals and small groups over and over ad nauseum is going to wear them down. Throwing them on center stage to introduce themselves to an all-hands welcome wagon is going to be exhausting at best and terrifying at worst. An incoming extrovert might enjoy those sorts of interactions, but they shouldn’t be required, and shouldn’t consume the majority of any day.

Keep the required, formal meetings in the first week to the barest essentials:

  • Manager and/or Mentor 1-on-1s
  • Immediate team welcome
  • Immediate team standups/statuses
  • Immediate team problem-solving
  • Other important stakeholders gradually and only as necessary

To facilitate introductions and relationships with more extended members of the company:

  1. Send a “Please Welcome our New Hire” email to the whole company on Day 1
  2. Have the new hire write a brief intro/bio highlighting some of their personal interests
  3. Share the intro/bio with the company via email, chat, or an internal wiki page

Your job during Onboarding is to avoid inducing fear and exhaustion and instead build confidence and excitement.

6. Do you include new hires in team discussions immediately?

A long, long time ago, I worked for a small, private golf course. Not in the golf shop, mind you, with its racks of pressed polo shirts and walls of neatly arranged golf clubs and its air conditioning. No; I worked in the garage behind the shop, where we stored all the golf carts and the members’ golf bags and washed the golf balls picked from the driving range and sometimes had old metal folding chairs to sit on!

Every weekend, I’d have to sit in that garage and watch silently as players scurried excitedly this way to hit the tee box and start their round or that way to hit the bar after their round, and there I was, just stuck in the garage, arranging carts for use or washing range balls or cleaning the clubs of a member.

I imagine that feeling of being left out, of being a kept onlooker while others are happily going about their lives, is not all that dissimilar from the feeling a new hire has when they’re stuck in a room, all alone, poring over hours upon hours of pre-recorded video training. While an instructor they’ll never meet drones on, they’re watching all the excited activity happening outside the room or over chat, feeling disconnected and alone.

Don’t quarantine your new hires!

Incorporate new hires into normal team discussions immediately; don’t isolate them in some separate area of work for days or weeks. If the team has a project status meeting or a design session or a troubleshooting session, great! Make sure the new hire is invited – at least to observe, if not to participate. These are great opportunities to see how the team functions in action, and a fresh, outside perspective might be just what your team needs.

Encourage questions – even if it’s something your team has already hashed out. Not only will that bring your new hire up to speed better, but it will also force your team to explain their decision to someone who wasn’t entrenched in the original problem. Building a culture of engineering requires your team members to ask questions of each other and to be able to explain their decisions. It won’t hurt your team to reiterate their reasoning on past decisions.

7. Do you start new hires on a training project that mimics day-to-day work?

If you do happen to provide pre-recorded video trainings for your new hires, I certainly applaud you for investing in training. That said, we might be able to repurpose that investment and get much better results. Those trainings – especially in the NetSuite space – are always expensive, are necessarily generic, and are never engaging or interesting. Instead, we want an onboarding experience that is more interesting, more engaging, and closely resembles their actual work.

When it comes to training new hires, the closer the experience is to their day-to-day work, the faster they’ll take up those processes, tools, and habits. Any training work they do should use the same tools, follow the same processes, and adhere to the same standards as “normal” work. Show your new hires how to track and report on the status of their training work in the same way their team normally reports on project status, and set the expectation that they do so. If all code normally goes through review, then training code should go through review as well. If completed project work is normally demonstrated to the team and other stakeholders, then new hires should be prepared and expected to demo their training work. The closer our training mimics the way the team works, the faster new hires will integrate.

“Training”, in this case, doesn’t necessarily mean “fake”, either. While it’s irresponsible and counterproductive to throw them straightaway into a stressful project, it might be impractical and uneconomical to have them spend weeks on something that has no impact on the rest of the company. While I do typically recommend against using any client work as training – no matter how “small” – there are many other opportunities to combine a great training experience with something productive for the company as well.

If you or your team have a “someday” list – the projects/ideas you dream of getting to “when things are less crazy” – these make excellent training explorations. As opposed to languishing on a list in the dusty corners of your task system, bring them out for training opportunities during onboarding. A new hire gets the same amount of learning and habit formation, and they know that even their training work is making a positive impact on the team.

If you have internal projects you know need completed – tools you’d like to build, processes you’d like to implement – but can never quite prioritize the time to do them, these too make excellent onboarding projects. Again, any progress here is simultaneously a learning tool for the new hire and a boost to the company.

If you’re not tracking either of these – why not? Start now! Your onboarding program will thank you later.

Alternatively, you can design something specifically for onboarding. Maybe there’s a “big” idea your team has been kicking around but can’t get to. Proof-of-concepts make great onboarding projects. The work is exploratory anyway; let your new hires do some exploring for you. The work will naturally bring up tons of questions and code reviews that will involve the rest of the team in the process as well, and you’ll make progress on a big idea. I’ve seen entirely new products come out of just a few iterations of an onboarding program.

As we continue the series, I’ll expand on more detail behind each of these questions.

In the meantime, how did your program score?



Related posts