My career in engineering came about very much by accident – a literal wrong turn. As a recent graduate of American constitutional & legal history, I was on the hunt for a historian job when I walked into the wrong career advisor’s office at my university. They were looking for developers and promised to train me in coding for six months before offering me a job. I signed up, skilled up, and never looked back.
Years later, the experience I had during those six months has shaped my thinking about the art and science of onboarding developers. Research shows onboarding programs, when done well, can significantly increase employee retention and productivity – but it’s also just the right thing to do.
There is no one-size fits all approach to culture and processes, and the same goes for the way we onboard. I’ve been responsible for designing and revamping onboarding programs at a number of major technology companies, including in my current role as Head of Engineering at Prospa, and I can attest that a copy and paste approach never works.
I’ve devised a series of questions for an effective onboarding program, partly inspired by the style of ‘The Joel Test: 12 Steps to Better Code’ (a must read for any software team). I recommend any company serious about getting the best results from new recruits, both short and long term, should ask (and be able to answer ‘YES to!”) the following:
Do developers have equipment, access to all necessary systems and accounts created before they start?
Onboarding should start before your developer’s first day. You’ve spent time and money recruiting the best person for the job, and your new employee is excited to be joining the team. Having that person come in just to create their accounts is a tedious experience for both of you. Ensure their computer is set up and they have access to any equipment they need on Day 1.
Does your company have a specific list of goals to accomplish for the onboarding?
You want your new developer to have a series of goals that underpin the tasks you set them. You might want them to understand the team structure by the end of the day or familiarise themselves with the environment – for example, do they know how to use the coffee machine and alarm code? The first few days at a new company can often feel like an endless array of random tasks or documents to read.
Defining and clearly communicating goals helps developers to immediately understand the value of what they’re doing.
Do the goals explain and reinforce company values and mission?
It’s essential the goals you set reflect the company values. At Prospa, we ‘obsess about customers’. We always have our developers sit with the team and listen in to customer calls. This has nothing to do with coding, but it’s important that they understand who our customers are and how we support them.
You can’t develop solutions for a customer or problem that you don’t ‘get’.
Are the people involved in onboarding active members of the team, and trained on how to deliver information?
Remember to train the trainers. Someone on your team may be an engineering superstar with years of expertise, but that doesn’t mean they have the skills or attitude to train another person. Not everyone has a natural talent for management, but it can be learned. Invest in training not just current managers, but your aspiring and emerging leaders as well.
Do developers have a fully functioning developer environment before lunch?
If you’re not able to build a developer environment on your new employee’s first day, you likely have a whole list of other problems you should be looking to fix. This question helps to reflect on the efficiency of your developer environment and gives you the opportunity to make necessary changes.
Do developers write and commit non-trivial code for production systems on the first day?
This may seem intimidating, but it’s not about testing your new developer. Rather, it’s about testing your engineering environment and culture. Another Prospa value is ‘deliver value fast’. We ask every new developer to write a line of code and fix an issue on their first day – and not only does this task show we’re serious, but having someone fix a problem for the team on Day 1 can create a shared sense of accomplishment and belonging that is hard to replicate.
Are developers instructed in hidden/institutional knowledge early on?
Make sure new team members have access to key knowledge, whether that’s a glossary of acronyms or a guide on how to apply for a conference or an education course. There is so much information people want to know but don’t feel it’s appropriate to ask in the early days.
Giving people that information before they need to ask for it can take unnecessary stress off the onboarding period.
Do developers have a designated person they can go to for help?
It’s important this person understands their responsibility – don’t surprise them on the day with the role, and be sure to adjust their workload accordingly. If you need someone to be a human answer board for the next month, communicate this from the start.
Is the program (mostly) uniform across locations, teams and varying seniority levels?
It might not be realistic to completely replicate the onboarding program across locations, but try to make it as uniform as possible, particularly in scaleup stage.
If the first week of onboarding in HQ means Friday drinks, socialising and lunch with the executive team, then a packet of chips and a welcome card won’t cut it at the satellite office. Make a genuine effort to provide a similar experience, whether that involves technology or travel.
Is your onboarding program inclusive?
In order to build an inclusive culture, you need an onboarding experience that reinforces your company’s commitment to diversity. Be clear about company initiatives and the strategies in place.
Share real examples, whether it’s how you celebrate different cultural events or the introduction of a new leadership program. You want new employees to feel welcome and part of the community from day one.
Is the onboarding program regularly improved with input from new hires and participants?
Every time new people come through the onboarding program, ask them how you can improve the experience. Encourage them to identify at least one thing that they would change. New hires have a fresh pair of eyes and their insights are invaluable.
Your onboarding program shouldn’t look the same in six months’ time. That’s exactly why I developed the Ted Test with questions, rather than statements.
Asking yourself these questions gives you the opportunity to reflect and build on your onboarding program as you scale. How you do these things will change over time, but if you can answer yes to these ten questions, you’re giving your new developers a strong environment in which to succeed.
Ted Tencza is Head of Engineering at Prospa. He has been a Software/Web development professional for 21 years, the last 13 of which have been in leadership roles. Prior to Prospa, Ted managed multiple teams at finder.com.au, Bigcommerce, and Atlassian, focusing specifically on SaaS offerings, as well as working on improving the recruiting, hiring, and onboarding of new developers.
Image: the Prospa team. Source: Supplied.