Hiring a Remote Web Developer

Part Three— Onboarding is kind of a big deal.

Handing someone (well, emailing them) their login to your chosen chat client, a list of what apps and software they’ll need to download and a schedule of regular meetings and leaving them to their assigned tasks is potentially the fastest way to lose your new remote web developer.

A company who’s good at hiring and retaining a decent remote team will know better and will put that new superstar through an onboarding process that works.

In this third part of the series, we’ll talk about the potential pitfalls of onboarding a new hire into a remote team.

BambooHR did a study and produced a breakdown of when people were likely to leave a new job. Nearly 17% would leave in the first week, 18% in the first month and 15% in the first 6 months.

BambooHR asked their respondents what the most important factors to them were when they started a new job. They mentioned things like introduction meetings and appropriate materials for training. Yet we see onboarding processes falling down all the time. It’s not something a business can afford to ignore.

Success starts before onboarding begins

Management pre-onboarding responsibilities

It’s not just your new hire who needs a checklist. You need to devise the best practice for onboarding. This means doing certain things before your new hire starts. This is called pre-onboarding.

What should happen during pre-onboarding?

• HR-related tasks for things like their contract, payroll, delivering an onboarding handbook, working from home checklist, review schedule etc.
• Tell the team when they’re starting and who they are! Encourage them to book short 1–2–1 meetings with the new dev to say hi.
• Work preparation tasks like ensuring they have the equipment they need before they start. Make sure you’ve communicated and know they have the right internet speed and access to all the systems they need.
• Find them a buddy to shadow for a while (and make sure that person has allocated their time to this).
• Ensure all your documents are up to date.
• Prepare a small project with defined KPIs and success metrics, plus all the tools they’ll need to complete it.
• Schedule their reviews ahead of time.
• Invite them to the relevant meetings.
• Create their personal onboarding booklet or document*

*What should be in the onboarding document for the new hire?

A good onboarding document will offer the new hire some peace of mind and will act as a bible in their early days before they’re familiar with everything.

It should include:

• A personalised schedule including a welcome meeting with their buddy and the company directors
• The company values, mission statement and goals
• Tell them how they’ll be contributing to these
• A note about the company culture
• Include things like typical working hours, when you take lunch and how you let people know (we used to use IRC where you could change your nickname, but now we use MatterMost and it’s polite to announce it).
• A meet the team page with contact details (or chat client nicknames, if you use them. You might know who @joe.bloggs is, but they won’t).
• A list of regular team meeting times and days
• A diagram illustrating the company structure
• A link to where all-important process documents live

New hire pre-onboarding tasks

Going click, click, click on forms isn’t something anyone wants to be doing. Especially when the content isn’t likely to be thrilling, albeit necessary.

The pre-onboarding stage prepares the whole company for the new dev’s first day. If you’re good at it, you can make this not only painless but engaging and even fun.

You want your remote dev to be prepared for their first day, not firefighting forms and tasks they should’ve already done.

Specsavers got this really right. They gamified their pre-onboarding phase and completing before the first official day ‘at the office’ meant they would donate to charity. This resulted in around £170k in donations and 71% of new employees completing the onboarding before they started their new jobs.

So, your new hire has started. Now what?

Buddy up!

As part of your pre-onboarding preparation, you’ll have assigned your new hire a buddy for a period of time. Don’t let them start by throwing them in at the deep end, all on their own.

Get their new colleagues to go through things with them and generally be around for answering questions. Ideally, the buddy will be a line manager or a senior member of the team who knows a lot of stuff about the company and processes.

Get your staff to book a short meeting each, just to introduce themselves and how their roles work together.

Plan the first week

Don’t assume giving them one or two days worth of tasks will be sufficient to then release them into the wild.

A decent structured week will be like a student’s first week at university. You get shown around your new campus (as well as getting lost), you try some classes, you get introduced to the groups you can join and you meet new friends.

In fact, plan the first month, then review it

Week one is going to be really daunting and probably overwhelming for your new dev. Again, don’t assume a week is enough time to settle in.

At Code Enigma, it took our marketing manager, Maygen, three weeks to work out that our chatbot wasn’t a real employee!

Schedule in a review. The best advice for this follow up is not to be solely focused on KPI achievement. Look at how well they’ve fit into the culture, not just their performance or punctuality.

Start them off on an onboarding project

A new dev shouldn’t be left alone with production code too quickly. Onboarding doesn’t guarantee they’ll stay forever (based on either their or your decision). Onboarding is also a trial period. You need to know how your dev performs without risking your clients’ code.

The easiest thing to do here is to give them a smaller, sub-project within a bigger one. Is there some internal software they could work on? Could they play with something on your own website? Is there a contribution they can work on? Maybe get them to evaluate a completed project and ask how they do it differently, or why the approach was the right one.

Let them do this for 2–3 weeks after their first week. This will act as a great stepping stone into actual and bigger work.

Make it personal

To this point, it’s been all about you as the hirer getting the most out of the dev, but it takes two to tango.

If you only focus on what you want, they’re going to feel undervalued pretty quickly. As we mentioned before, one of the most enriching things you can do is find out what a dev is passionate about and work that into their job as much as possible.

Your policies should also include something that empowers your employees to learn and develop their skills. At Code Enigma, our staff have an annual training budget that we can put toward anything we feel will aid our growth. Some people go on courses, some study for exams, and some go to events.

Let your onboarding process evolve

Your onboarding process isn’t a tick box exercise that you develop once and put hire after hire through. With every new starter, there should be a development that can be made to the process.

Asking your new dev for feedback is the way to achieve this.

If you can find out, see what other companies do so they don’t seduce your candidates away during the hiring stage.

Use a dev environment for code

You’re not going to let your new dev loose on your code on their first day (week, or month). You need to ensure their code matches the standards you expect. Letting them loose in your internal dev environment is a smart approach.

Summary

It all boils down to thoughtfulness and organisation. We all get that ‘back to school’ feeling and there are steps we can easily take to ensure any new remote hire gets going in their new role not only painlessly, but in such a way that bolsters their success.

Talk to us if you’re interested in making your company more remote. We can help!