Ease the Transition

Created: December 28, 2020

Having dealt with all of the paperwork - but only a few of the butterflies - on the first day of my first NetSuite job, the remainder of the day went to setting up my computer and a few quick meet-and-greets. I walked out of the office that day feeling excited by all the nice people I had met, but also very nervous. I had no clear picture of what the next few days might look like, let alone what my normal work would involve. There was no plan laid out for me, no overview of a typical day, no schedule set.

What the next few days ended up looking like were:

1. Day 2: an hour or two with a senior developer giving me an introduction to SuiteScript
2. Also Day 2: a few hours shadowing another senior developer on a client project
3. Day 3: another few hours shadowing the developer who had started the week before me
4. Also Day 3: my first client task

I had barely figured out how to adjust my chair correctly, and yet I was already entrusted with the keys to a client's NetSuite account and asked to make a fix to an existing script. It was completely terrifying - like your parent showing you a bicycle for the first time, describing how it works, then demanding you ride it with no training wheels or assistance.

It would remain terrifying for about the next six months. That's when I finally started to feel like I was becoming competent with NetSuite and SuiteScript. There were very few NetSuite resources available at the time (2012-13). The people around me were extremely supportive, but they had their own work to do. I fell off that bicycle so many times, and I know I'm not alone. Many developers added to busy organizations and teams get this same introduction.

Instead, could they have provided me with a full-time trainer or months of classes for preparation? Absolutely not. For most companies, that's not economically feasible. More importantly, it's not even necessary to do something so elaborate. Fortunately, there is a ton of middle-ground between the two extremes. There is a lot you can do in a short amount of time to ease the transition for your new developers.

One of the more successful approaches I advise is to design a project for your new developers. It doesn't have to be anything complex; it's not there to test their technical mettle - presumably you've already done that, and that's part of the reason you hired them. Give them a helmet and some training wheels with that bicycle! Here are a few suggestions for the types of projects I've seen work well:

• a single, simple, repeatable project that every new hire does
• the "someday" tasks from internal projects where the pressure is low
• proof-of-concepts or betas you've been itching to build anyway

The idea is for this project to mimic "real" work as closely as possible while keeping any risk and pressure extremely low. Assign and deliver the project using the same project management tool(s) they'll be using in their day-to-day work. Communicate about project work the same way you would communicate about any "normal" project with the same people. Employ your standard development lifecycle: issue tracking, status updates, source control, code reviews, documentation, automation, etc. If you normally time-box your work and demo to each other, then time-box the onboarding project and finish with a demo.

Completion of an onboarding project is not necessarily the goal; rather, the goal is to guide your new employee in developing the relationships and habits appropriate for success in their role within your company. The closer the project is to "real" work, the easier it will be for them to establish those relationships and habits, thus the better you'll have set them up for success.

HTH

-EG

Survey: What does your developer onboarding experience look like?