Onboarding

When a new developer started at Haplo, they were productive within two or three weeks. By “productive”, I mean they were working at a decent pace, producing production quality work, and only using a small amount of their colleagues’ time by asking questions.

This was achievable because we recruited really good developers. But without an onboarding process, even they would never be able to manage to achieve this so quickly.

When designing an induction programme, it’s tempting to tell new colleagues everything there is to know about the company. But it’s far more effective to focus on what they need to know to do their jobs. So while we covered the essential company admin, like payroll and compliance with the law, the vast majority was a carefully thought out process to provide all the information they would need, and help them learn the basics.

Our process evolved as we learnt more about what was effective and required by the business. Working out what is needed to do a job takes time and effort, and needs continual tweaking to stay current.

It’s particularly important that everyone understands the importance of the onboarding process, and is committed to making the investment in time. It’s a big cost which slows your team down in the short term, especially when they’re busy with their own work. Everyone needs to understand that taking the time now will massively reduce the time they have to wait for their new colleague to contribute fully to the team.

Another important aspect of our onboarding process was security. We used it to introduce and reinforce our expectations of security, and provide evidence for our ISO27001 security audits.

Our onboarding process had several stages, and was run over two weeks.

Preparation

In the days leading up to our new colleague’s start date, we would:

Create accounts on all the systems they needed to use.
Completely set up a laptop for them, installing all the software, and storing credentials in the password manager.
Print out the paperwork needed.
Choose a mentor, and (in the olden days before Covid) adjust the office seating layout so they could sit together.
Set up their desk.
Send welcome emails and instructions to their new email account.

Contracts and laptops

After we had welcomed our new colleague on their first day, there were a few basic tasks to get out of the way. We provided them with an onboarding checklist, which listed all the administrative tasks they needed to complete on their first day.

Read the company policy handbook, with special attention to the security section.
Prove their right to work in the UK, usually by showing a passport (a legal requirement).
Sign their employment contract.
Additional signature in their employment contract against the “security” clause, as the first reinforcement of how seriously we took security.
Receive their laptop (with everything set up and ready to go)
A short security lecture, particularly about the importance of a good password and not trusting anything you hear by email or phone.
Asking them to set a secure password on their laptop.

Because we’d done the preparation before they joined, they now had access to all the systems they needed to do their job, and all their development tools would be set up.

Induction sessions

We set out a programme of sessions over the course of the first two weeks. Each session was designed as a conversation to get someone familiar with the basics, so they knew what questions to ask and how to find the answers.

For each session, there was a standard set of slides to make sure we covered the key points — and we would update them when things changed, or we discovered a new joiner didn’t know something they needed to know.

Sessions were run by the most appropriate person. This shared the work across the team, and started building working relationships across the company.

Your role: Main tasks and responsibilities, acclimatisation project, introduction to their mentor.
Meet the Haplo Team: Informal introductions from everyone, usually at lunch or at the beginning of a company meeting.
Business aims and values: History of Haplo, company values, company structure, aims and roadmap for each product.
Company procedures: Working hours, leave, key policies, how we schedule work, calendar of events, company tone of voice, etc.
Security: The importance of security and confidentiality, secure code, security policies, physical security.
Branching policy: How we branch and merge code, and how we write commit messages.
Codebase: How our code is structured, the various modules used, key concepts in our platform.
Hosting: Where and how, multi-tenancy, capacity planning, etc.
Code reviews: Why and how we review code, and the supporting systems.
Professional development: How we support professional development, quarterly review process, recommendation to be proactive about your career.
Support requests: How we handle support requests, and the role of the developers.
Product demonstrations: User facing functionality, and the concepts behind the products.
Implementation projects: The processes we use to implement our products at an institution, tooling, current projects.

This is a fairly long list, and each would take up to an hour. But the time taken to deliver the sessions, and answer questions ahead of time, saved an awful lot of time later.

Mentoring

On their first day, we’d introduce a new colleague to the key people who’d be helping them in their first couple of weeks. The most important introduction was to their mentor, who would answer all their questions.

Mentoring was very short term, and developers took it in turns to be the mentor. We didn’t need them to have worked with us for long to be a good mentor.

We encouraged new joiners to ask questions quickly, as we didn’t want them to waste any of their time. We set expectations carefully. While they’d gradually need to ask less questions, for now, we really wanted them to ask lots of questions. We expected their progression to look something like this:

Ask your mentor immediately.
Try solving it yourself, give up quickly, ask your mentor.
Gradually spend more time looking and working things out yourself.
Ask questions in chat, perhaps moving on to something else while waiting for an answer.

As soon as they started, our new colleague would be supported by the entire team, just as they would throughout their time with us. The purpose of the mentor was to make it easy to ask questions, and set the expectation that questions must be asked.

Acclimatisation task

When you start a new job, getting anything done at all is a massive hurdle to overcome. We set an acclimatisation task to introduce them to our tech stack and tools.

During the recruitment process, everyone writes a very small application, and then discusses it in depth during their interview. Rewriting it as a Haplo application is a perfect first task, as they’ve already thought carefully about the requirements and ways to structure the code.

We sent them a short email reminding them of the task, and links to all the specific documentation pages they’ll need on docs.haplo.org, our public documentation for the open source Platform.

We suggested that two days was about the right length of time to complete the task. Some people did it in half a day, and some people didn’t finish completely.

It was interesting that the length of time taken did not correlate in any way to future success. Colleagues who took longer did just as well as those who did it quickly. My theory is that it’s more about learning style than ability, as those who want to understand everything before they start will take longer reading and understanding all the details, whereas the pragmatists will just write the code and learn when they needed to know something.

If someone felt their progress was slow, I always pointed out that it meant nothing how fast they completed the task. It seemed to be reassuring.

When they’d finished, or at the end of their second day, we’d review their code and offer suggestions. In particular, we’d point out any good or bad patterns, and where their code didn’t match our coding style.

Real work

On their third day, new colleagues would start on real work, and usually they would get code live in their first week.

We would choose their tasks really carefully, gradually ramping up in difficulty and requiring more and more knowledge of our code.

It’s a huge task to get to know a new codebase, learn to find your way around it, and actually run the code. So, the first tasks would be as simple as “change this text”, usually resolving a support request.

Later tasks would be making more significant changes, and hopefully within a couple of months, independently implementing new functionality.

Paperwork

There’s a part of an ISO27001 security certification called “competence”, where you have to show that your colleagues know what they’re doing and have the appropriate skills to deliver your service.

The induction sessions showed that we were providing the right information, and then a final step in the process was a formal sign-off that all the sessions had been completed. The signed induction sheets were filed away for our next ISO27001 audit.

How this could go wrong

We knew our onboarding process was effective, because we could see new joiners becoming productive really quickly. We put a lot of effort into the design of the process, and running the programme, as our strategy of recruiting early career developers meant we couldn’t rely on “experience”.

As well as careful design, if an onboarding process isn’t kept up to date, it can be counterproductive. We made a point of keeping it up to date as part of our ongoing process of change, especially as we discovered gaps in knowledge.

Finally, we made sure that everyone understood why we did this, and took it seriously. We made sure it felt worthwhile, had measurable results, and was clearly a good investment of everyone’s time.

Table of contents