A better way to onboard developers

I have been in many companies and, sadly, most of the time there was absolutely no onboarding. Some of them didn’t even think it could be a thing, and some others made excuses about being bad at it. Onboarding is a critical step as it defines how the collaboration will work, and it could make a big difference. I got lucky enough, to see some great onboarding that changed my views on it.

Before I start, I should tell you that I firmly believe that culture can make or break a company. Culture and vision is what makes everyone push in the same direction and deliver great things instead of fighting against each other and finding excuses for failures. Onboarding is a great way to communicate and show what is your company culture, for the newcomer but also for everyone else, setting up a clear example. If you don’t do it proactively, it will be done implicitly, and maybe not the way you like…

Onboarding is a grace period where everyone is happy, willing to make efforts and without any complicated background with the company or colleagues. This is an easy time to explain things before the daily routine, and the hundreds tasks, prevent a higher view. Don’t rush it, let the time for the new hire to learn and adapt to all the people, process, projects, tools and particularities of your company.

The challenge is to give a lot of information without taking too much time, preparing and updating them, and being boring. It should explain the company culture and purpose, introduce company organisation and key people, offer guidance to be quickly operational and give responsibilities. To ease this experience, having a contact person to welcome you and who to ask all your questions could be a great help. This buddy, as called in some companies, should be a colleague in another team in order to feel more free in conversation. He should drive the newcomer through the onboarding and afterwards, and clarify the company expectations to remove anxieties as much as possible.

Company culture and purpose

This step can be easily forgotten. It may seem obvious to people that have been there for some time. Or it may seem too vague to people that do not care much about people dynamics and motivation, and kind of ignore company culture and project/product purpose. To me, it’s the most important onboarding goal as it is very hard to recover afterwards. Going on, people may focus more on daily tasks rather than global company goals (depending on their attributions, of course).

The best way to share these, is by having an open discussion with the CEO as he is the best person to speak, with credibility, about the company culture. This way he could give his views on what are good and bad behaviours to anybody, and his words could be used to fix a future situation. Telling the company story and vision is also very important to understand some past choices and build some empathy for the legacy. This meeting is an opportunity for the CEO to know people working with him and have a better understanding of every company team or department. For the new hire, this connection will allow him to understand better the organisation he joined and have easier relations with his management. Also, taking all the needed time is crucial to set up the best possible collaboration. This meeting can be scheduled on a 2h slot (to be sure not to run out of time) or scheduled in some informal time, at lunch or for a drink in the evening, at the newcomer convenience.

You may think it is nice but way too heavy for the CEO. I’m convinced setting up a great and long collaboration has no price. This could make the difference between unengaged people doing useless work and enthusiastic employees solving company problems before you even hear from them. If your company is under 100 employees, you probably have less than one hire a week, and the CEO can handle this. If you hire a lot, maybe grouping newcomers, every two weeks for example, could still make it reasonable. As an example, when I joined Criteo, they were 3000 employees with 600 people in the R&D. I had many onboarding meetings to understand all the parts of the company, but the most memorable was the one run by a founder telling us the story of the company, how it started, the trouble they had and how they solved them, the many pivots they made and how they ended up in the advertising sector (not in the early days’ plan), the experiences they made and how it felt from the inside. After it, you don’t look at the company the same way, definitely! I also had lunch with the CTO (with about 10 other newcomers) where he asked us what we thought about the company, what could be improved and what was better in our previous experiences. The conversation was very open, and I was surprised on how many ideas were expressed and discussed. So if this size kind of company can do it, you also probably could; if you believe it’s important enough.

Meet people and understand organisation

In your daily work, you will have time and opportunity to meet your team and people you will work with. But what about other teams and departments ? You often have very few opportunities to meet them and understand their work and goals. As a company, it’s quite hard but key to keep all departments collaborating. You don’t want to notice that your progress is very slow due to internal war. That could be due to a goal misalignment between teams. Such as sale people sell non-existing things and ask developers to build it quickly. Or ops people refusing updates because they try to get a stable platform while developers want to push new code quickly to meet product deadlines. There are always such tensions, whatever kind of. Meeting other departments, understanding their work, goal and building some emotional links could help in such situations. Make them discuss more to work in collaboration rather than in confrontation.

This is also a way for the newcomer to understand more precisely how the company works, what are the departments and how they work together to serve the clients. As engineers, we often see and kind of understand the production part, but we often forget about the marketing and sales ones as well as the support or after sell ones and many more, depending on the company. We know they exist, but it’s hard to truly understand their dynamics, importance and role in the global strategy.

Planning a global presentation and meetings with different people in every department could make a huge difference in employee engagement and work efficiency. Not to forget that, not only the newcomer learns all these things, but also his whole team. He can explain new things to others based on what he saw and others didn’t because project, teams or challenges evolved. This can be an interesting way to spread knowledge across the organization.

Be operational immediately

Understanding the people and the company you will work with is quite crucial. You were hired for a specific task, and if you are lucky, you really like it, so you may be very impatient on starting. At least that’s me! First, you have to set up you PC, installing softwares, creating accounts, asking permissions, learning procedures… This can take quite some time and be painful. Documentation may be out of date, have big holes or even not exist. Definitely, this is necessary but quite boring to be done.

Maybe there is another way… Have you heard about pair programming ? Or even mob programming ? From your first day, you can dig into the code doing some pair or mob programming, start to learn the codebase and company practices, discuss with a developer knowing the context of past choices and discuss things you would have done differently. This could allow you to bring value to the company since your first day, sharing your experiences and coding with another developer. Maybe, deploying a new feature ? Being able to follow the full work workflow can be very rewarding and empowering for a newcomer. Even if the task is quite trivial. It can be a good idea for the team to prepare some easy story, that are not too large in the codebase, for the new developer to start.

Computer setup and broader impact can wait a few more days, or weeks ;)

As a developer, it’s also important to understand the technical environment you are working in: architecture, technical choices, coding practices and processes. Having some maintained documentation about them can really help in the ramp up. If you don’t have some, you can build and improve them on the fly when you need them. Instead of just explaining architecture to the next hire, draw it on a diagram with him. So the next one will have it and will be able to improve it with the missing or changed parts. For technical choices, having an ADR, and a best practice guide can be a great help. If you don’t already have them, bootstrap a document with a simple structure and find some hooks in your process to fill them gradually (story definition of done, after technical debates or explanations…). Do not throw these documentations on the newcomer reading list. Go through them with him. So you can notice incorrect parts, highlight important ones and even refresh your memory. Such documentations must live, be regularly read and be often updated to be useful. It’s not a task to make them, it’s a process to maintain them correct but also understood by everyone.

Give responsibilities

New hires have a lot to learn and adapt when they join a company, but they can also bring a unique value that nobody else in the company can. You know, all these broken tools, habits or processes you have learned to live with amongst time. You are now used to them, but this does not make them any better. You just don’t notice them anymore. But any newcomer will fail at them because they miss your historical knowledge or habit. Having a fresh eye can identify and fix a lot of battles you already have given up. Asking new hire to write an amazement report on what they like and what could be improved can lead to great improvements in many parts of the organization: process, tools, management, architecture… Not only because he has new eyes but also because he has other experiences with better or worst things. An other key point is to review his report with him and eventually let him solve himself some pain points he mentioned. With this, he will bring quick and unique value to the company and have a real ownership on improving what he sees.

An other interesting responsibility is to explicitly ask him to improve and maintain onboarding documentation. This is a task nobody wants because they don’t see the value, except when you are a newcomer. Making them identify onboarding pain points and solving them will lead to an amazing onboarding with time! He can even, eventually, take the responsibility to lead the next onboarding, so nice tips can spread easily.

The ideal process

Ok, so now let’s wrap up a little this already quite long article. I proposed a lot of things, and it could be not so easy to put them in play. Here is what I think an amazing onboarding could be.

Working in a team is first of all a social activity. So, my ideal onboarding would start one or two weeks before I join the company, meeting the team informally. It could be a lunch, an after work drink, or an invitation to a team building to socialize. On the first day, I would do the company global onboarding: discovering the environment, what are the company teams or departments, what do they sell and how, what are the specificities and the culture… It can be done by an HR person or by my buddy (ideally outside of my team) around a breakfast, and eventually with other newcomers. This first day should explain clearly what is the onboarding process and what they expect from me. I would also probably have to perform some administrative tasks and start to set up my computer, mostly communication tools (email, slack, …). The following days would be split between the specific company onboarding (meeting people in other departments / teams to understand deeper what they do and have some familiarity with them), the global team onboarding (what is the team goal, which are the other teams I would collaborate with…), and the specific team onboarding (project architecture, pair programming, installation…). Some time off should also be left to have informal discussions, read and improve existing onboarding documentations and take some notes for the amazement report. The onboarding should finish with meeting the CEO to go deeper on company culture and ask any remaining questions. Once finished, the amazement report would be discussed with the manager and key improvement could be planned.

This is what I would expect from a great onboarding: understanding the environment, being guided and being valuable quickly. Of course, it can vary a lot depending on company culture and size but one thing to keep in mind is that human relations (ambiance and people availability) can greatly balance any other discomfort.

What do you think about it ? What were your onboarding experiences ? And what did you miss or wish to have ?

This topic is quite large and specific, I would love to hear from you about it !