Who’s responsible for building a development team? A team leader? Scrum master? Senior engineers? I strongly believe that every team member contributes to its work culture. I also believe that one of the best benchmarks of a team’s performance is the way new developers are introduced.

Hiring a new developer is a big investment. Once a candidate passes all the recruitment steps and walks into our room, we want him or her to start proper work as soon as possible, so the investment would start returning. Most of the time we already know why we want that person even before he or she is hired. Perhaps we have certain expectations. Maybe an experienced team member just left, or we need more resources to deliver new features and bugfixes?

On the other hand, sometimes we are the ones who change jobs and need to dive into an unknown environment. We want to show off and bring value as early as possible to prove we are worth the time and money spent on hiring us.

Let’s see what we can do to improve the onboarding process in both scenarios.

Know the new employee (or employer)

A good onboarding process should use all the data gathered during recruitment. Our candidate already answered a lot of questions about his or her experience, favorite tools, career goals, and so on. Maybe he or she already solved a technical task or wrote a test prepared by our company? All of these data should be an input to the invididual onboarding process.

If you’re joining a company, you should also gather as much informations as possible. Help improving the onboarding by asking important questions during recruitment: what tools do you use, what is your work culture, how an average day looks like, and so on

If the company’s HR department or agency did not provide you enough details, ask for them. You should know as much as possible about your future coworker or workplace.

Choose a mentor

It’s good to have a friend in a new workplace. Most people cannot memorize the names and functions of everyone around in the first day. Onboarding is easier when a new employee have one person to ask most questions, like “where is this or that in the office” or “who should I ping about my Git access”.

But a mentor is someone more than that. A mentor helps setting career goals and evaluating them. A mentor tries to compromise company goals with the individual goals of an employee. A mentor shares experience and helps developing a position in the organization. Of course mentoring takes some time and attention away from pure coding. But programming is a team sport, right?

A mentor does not have to be that one senior developer who’s been here for ages. Even regular developers who spent only a couple of months in the team can guide new folks. A mentor should not pretend to know everything. It’s all about willing to work together and help out.

It’s good to spread the mentoring duties across different developers, so we don’t end up with one senior trying to guide the whole team. A bottleneck is made when all the questions and decisions go through a single person. Your team should learn self-organization.

If you’re about to join a team, ask who is going to help you in your first days. Maybe you could meet that person earlier and have a chat?

Prepare an onboarding plan

Don’t improvise. Every developer needs some basic stuff to work: a computer, a desk, a comfortable chair, internet and/or intranet connection, software licenses, e-mail account, repository and knowledge base accesses, and so on. Arrange them in advance.

Plan at least the first day which probably will consist of introducing a new member into the team, meeting some people, talking about the project and team habits and maybe visiting HR department for some additional paperwork.

Think about the first tasks a new member could be assigned to. A simple label change or a trivial bugfix would be the best. In the beginning, everyone has to know the workflow and team practices. A fresh developer will surely ask these questions:

  • How do I clone repositories? Do we use SSH keys?
  • How do I create my branch? How do I name it?
  • Should I include an issue number in the commit message?
  • Should I rebase my branch before pushing?
  • How do I launch tests and check their results?
  • Who should I ask for a code review?

Onboarding will take some time for sure, so remember to reserve it in your team’s calendar.

Review your documentation and communication practices

Everything that makes the work of experienced developers easier will also help the newcomers. It’s good to have some basic piece of documentation we can refer to. Check if it’s up-to-date and if it contains at least basic information which can help fresh people.

I’m not a fan of robust, official company documents. Often a simple glossary of terms and some architecture diagrams should be enough for newcomers to understand everyday conversations.

Consider improving your team’s communication. How do people communicate? Are there knowledge silos? Do you use public channels on Slack or maybe all decisions are secretly made in direct messages? How do you use an issue tracker? Do issues have precise descriptions?

Introduce a new member to the team, the project and the company

Most people cannot memorize more than a few names in the first day, but you can make it a bit easier. I once joined a team where everyone had different nicknames and avatars across Slack and GitHub. It’s good to have them unified. Later, my employer decided that everyone should put his or her photo as an avatar, instead of funny cats and other weird stuff. This made recognizing people in the hallway a lot easier.

A great way to increase people’s motivation is to let them know the details of the business they work for. Tell them a bit about the company and product history. Provide a business context and describe the reason this team exists. Maybe a new person could talk to someone else than just fellow developers? Do a product demo.

If you just joined a new team, be curious! Don’t hesitate to ask questions.

Establish goals and evaluate them

Our work should serve a purpose and every team member should feel it. Set individual SMART goals for upcoming 3-6 months, then provide support and inspect progress.

I believe that everyone can contribute to the organization from the first day. Discuss what specific value a person can bring in the beginning. I can think of:

  • Update documentation, especially the part about setting the development environment.
  • Write tests. In one project I started from writing numerous unit and integration tests for a module refactored by my experienced colleague. We cooperated closely and soon I started finding bugs in his code.
  • Review pull requests. Why not? Good questions from a newbie might help finding weak sides of PRs made by experienced developers. It can be also a nice variation of rubber duck debugging.
  • Pair programming sessions whenever it’s feasible to split work for two people.

These are some basic goals, but you should also agree on something more related to the specific product(s) your team is developing.

Wrapping up

Onboarding is an exciting process and has a massive effect on the team’s and each individual’s performance. It should be well-planned and conducted in a friendly, calm atmosphere. This is the time when people make new connections which will be crucial for their later work. It is also a great moment to review and improve team’s practices.