How do you train your new developers?

Created: January 20, 2021

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!

Say Yes to the sixth and seventh of our 11 Questions for a Better Developer Onboarding Program, which go hand-in-hand:

Do you include new hires in team discussions immediately?

First, let's not isolate our new hires in some separate area of work for days or weeks. Incorporate them into normal team discussions immediately. 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.

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.

Onboarding is the time to set a lasting impression on not only your new hires but on the culture of your team. The focus should always remain directly on creating meaningful bonds with your new hires and building a culture of engineering. There are so many beneficial, engaging options for Onboarding; don't waste the opportunity by stuffing them in the sweltering garage to do menial work alone.

HTH

-EG