Agile Blog
Follow me writing about all sort of agile topics. Read about Scrum, Kanban and XP as well as anything related to startups and company culture in general.

Why onboarding is important

23. September 2015

Onboarding is the process on how to get employees and team members productive and motivated right from the start. This is about why you should be doing it, and how it works. In this article, I am referring to technical staff, but the situation is similar for other areas as well.

Reading time:

What is onboarding?

Or said in a very simple way: Onboarding is about getting your employees and team members productive and motivated very fast.

To achieve this, good preparation will help you. This includes a process description including all sorts of milestones like administrative issues, providing access to code and provisioning hardware. Also it requires to provide a mentor or similar to answer questions and guide your new team members into the right direction.

Onboarding, also known as organizational socialization, refers to the mechanism through which new employees acquire the necessary knowledge, skills, and behaviors to become effective organizational members and insiders. […] Research has demonstrated that these socialization techniques lead to positive outcomes for new employees such as higher job satisfaction, better job performance, greater organizational commitment, and reduction in occupational stress and intent to quit. These outcomes are particularly important to an organization looking to retain a competitive advantage in an increasingly mobile and globalized workforce.


The importance of onboarding

Companies usually invest a large amount in recruiting to find the right personnel. Budget is being spent on events like fairs, conferences as well as bar camps and usergroups. They send people to these events or even take over sponsoring, so they’re recognized in the communities. Budget is spent on recruiters and recruiting companies as well as job recommendation platforms.

When it get’s to interviewing candidates, a lot of time is being spend on the interview process to find the ideal candidate.

It is natural to take care of a good onboarding process to assure, that the amount of budget which has been spent to this point, is invested reasonably.

Even more than established companies, startups specifically are facing the challenge to get results quickly, before they run out of funding. So startups are most likely trying to save even more in areas, which are not producing output right away. Even while good onboarding procedures might not obviously provide a return right away, it will much quicker if you consider the following:

  • If you don’t have a good onboarding process, it will take very long for new team members to get productive. Instead of getting them up to speed in a very short time frame, it will take them a long time to find out about architecture, guidelines and such. As there is no guidance, coding guidelines will possibly not be considered as well as bugs might occur more easily through the lack of knowledge.

  • Consider that you found well experienced developers, they most likely have been discussing engagement with other companies as well. If you can not offer them a good work environment and guidance into the project, good quality control mechanisms and documentation, they might leave your team sooner than later.

  • Learn the wrong things: Imagine there is no guidance and documentation, candidates rely on asking questions and getting the right answers. They can not evaluate if they are working on the right things, and might spend their time on wrong parts of the project, get used to wrong coding styles and are not getting into the core architecture of the application at all.

  • Last but not least: You might choose the wrong candidate in your recruiting process. If it takes long to ramp up new employees to get productive, you might need a long time to identify these low performing candidates and bad hires.

Of course, the risks increase, the more people get hired. The initial time investment spend on good onboarding procedures pay off very quickly by having new team members being productive faster.

Building an onboarding process

So what is important for good onboarding procedures?

  • Introduction to stake holders and team members
  • Onboarding talks
  • Provide a mentor
  • Knowledge transfer
  • Provide infrastructure
  • Provide links and logins to intranet and code repositories
  • Structure and timing, like what happens when

These are just examples, I will go more deeply into some of them further below.

Consider that building onboarding procedures is an iterative process. Things which might be convenient today, might be obsolete tomorrow. Maybe because the project changes, possibly because the company grows. Also you can start on a small scale and try things first. You will learn what works good and bad, and adapt from it. It could even be the case that the onboarding goals change over time.

You could simple start with a document on how to set up a development environment, so the new employee can change code and see if things work out. It could be a good idea to let the new hire also extend this documentation. They will certainly stumble upon things and have new learnings, ideally the next candidate will have these learnings upfront available right away.

Introduction to stake holders and team members

It is very important to make new employees welcoming and comfortable on their first day. This is especially important for quiet candidates. It is important to integrate the new employee socially into the team. It will be easier for them to get in touch and ask stuff. This can include welcoming them at the door, walking them through the office and introduce them to the people. In a large company, it’s important to also introduce stake holders as well as the new team.

Possibly meet the team at their breakfast or for lunch if your company incorporates that, this depends on the culture of the company. If you have a chance to chat in a non formal way, it will make things easier for the new hire.

Onboarding talks

Spend time on onboarding talks. Things to discuss:

  • Company culture
  • Company structure and history
  • Teams
  • Projects
  • Internal tools
  • Guidelines

You might need to schedule a series of onboarding talks to get new hires up to speed. It might also make sense that there are different people presenting different areas or projects, so the new hire is getting to know the people very quickly as well. Still you should consider that there is one general contact introduced to the new hire right away, so he always knows with whom to get in touch.

Talks are also a great opportunity to ensure that the new team member learns about the values of the company and their employees.


With a good set of documentation, the new team members are able to become productive much quicker.

As the application or project grows, it is even harder to keep track of the whole architecture. If it has been documented properly, it is easier for the team to work on different parts of the application. Also if the people understand the fundamentals and abstractions better, they will be able to provide better and more efficient work in the future. There is also less chance that the work is useless at the end, because all important parts of the application have been known before.

It could be a good idea to compile a checklist of things to catch up with, to get a good initial overview about the architecture. This way you make sure that new team members get a quick intro and have a good overview from the start on what they need to learn in the coming weeks.

If you use scrum, it could be part of your definition of done to update and extend the documentation, if you implement new features. If this is part of your process, it will be easier to keep it updated.

Provide a mentor

It is always a good idea to provide a mentor to new employees. Actually I think it is the only way to be successful with onboarding.

A mentor should be ideally coming from the same working area. Like for software engineers, you would have another engineer taking over the role of a mentor. It depends on the team and company size: You could have a specific mentor any time, or this is a rotating role within the team.

A few things to consider being part of that role:

  • Quality: Discuss coding guidelines, do code reviews or even pair programming.

  • Spirit: Make sure that the new team member is socially integrated into the team.

  • Environment: Check that the new team member has everything needed to be able to work and is comfortable with the surroundings (team, infrastructure, …).

For other fields of work, the tasks vary of course.

You might set an initial time span for the mentoring program. The mentor and the new team member could then decide that they want to extend it, or that they have no use for it anymore at an earlier stage. That’s ok, if both feel comfortable with it.

They could meet on a daily base and do a short review of the work, and later only weekly or biweekly depending on the outcome. Also the focus can shift from initial code reviews to discussing the overall architecture for a broader understanding.

As always, use your onboarding procedures only as a guideline, each candidate is different and coming from different backgrounds.

From a companies perspective you need to make sure to provide space and freedom for both, the mentor and the mentee to concentrate on the onboarding procedures. If there is no chance for the mentor to concentrate on the mentees demands, it might take a lot more time to ramp up the candidate. Possibly emphasize the importance of the onboarding process by making the mentor responsible for the success of the onboarding program (not the success of the candidate). I would consider that 20% to 30% is a good amount of time, which the mentor could spend on the new team member. As always, this is not a fixed number and depends on many factors, it’s just a guideline.

The mentor should always be available for all kinds of questions, which might not be limited to specific work, but can also be related to the company or overall procedures.

Getting started with code

Getting your hands dirty is one of the best ways to getting to know the application or project. After the introduction to documentation and team mates, it might be good to have simple tasks to work on. That could be made up just for this onboarding process and not be related to any specific task, if it provides a good base to get used to the application.

Schedule your process

As always, timing is important. There are a couple of things you need to prepare before the new employee arrives, and other tasks will be relevant much later. So let’s sketch how this could work out.

Before the first day

There is mostly administrative work to do, before the new employee arrives.

  • Sign contract with the new employee.
  • Organize hardware and a place work work.
  • Add a new mailbox for the candidate.
  • Email a contact list, onboarding checklist, documentation or anything else useful to the new mailbox.

First day

It’s always nice if new employees open their new laptops and find welcoming emails. Consider sending a welcoming email to the whole company, so everyone is informed. Sometimes new employees find responses from colleagues which have answered to that already in their mailbox. It is nice and a good start for further communication.

Pass along additional information which might be useful for the start.

  • Welcome the new employee.
  • Have another office tour, introduce the new employee to the various places like team rooms, conference rooms, kitchen and such.
  • Introduce the new employee to stake holders and the team.
  • Introduce the new employee to his mentor, and let them possibly work out a plan for the next weeks.
  • Sort out administrational issues if there is something left.
  • Discuss things like homeoffice procedures and anything else important.

Don't forget, that new employees will try to make a good impression on their first day, which is expected and nothing bad. They might get smaller tasks and instead of asking a lot of questions, they will spend time on trying to figure out things in their own. It is always a good idea to produce a welcoming and learning friendly environment, that they quickly consider that asking stuff is a good thing.

Second day

This is mostly about connecting to people, understanding where to find things.

  • Set up development environment.
  • Go for lunch with the team.
  • Get assistance for getting into the code.

First month

The new team member is getting used to the environment and the team. While slowly getting into the code, a lot of questions will come up, as well as it’s getting clear what fields should be covered for further studies.

  • Have onboarding talks.
  • Find out what competencies are missing and make a plan for solving that (Like learning a specific framework). Make a checklist, Trelloboard or similar to keep track.
  • Regular reviews and interviews with the mentor.

After 2 month

The mentor is phasing out his specific support slowly, as the new team member now knows how to cope with things, and knows whom to contact in certain cases.

  • Still keep interviews with the mentor in larger intervals.
  • Keep track on missing knowledge and how the progress is.


Ramp up a new employee as quickly as possible. The sooner a new team member is getting up to speed, the sooner you get meaningful output. And this is what you finally want. So spending resources on a good onboarding process is the best thing you can do to accomplish good results and spend your budget well.

Read a follow up on this article. In that, I am discussing the specific case of onboarding in the agile world.