How to Onboard New Developers
One of the reasons people leave their jobs in the first year is the experience of not being fully productive within a few months. Usually, it’s a result of a faulty onboarding process.
Companies with a strong onboarding process have significantly better employee retention, and higher productivity levels. The way your onboarding process is structured, planned and how it allows your employees to grow, regardless of their seniority level, will be their first impression from the organization. And the saying ‘you never have a second chance to make a first impression” also applies to new jobs as much as new people.
As a developer in different companies and different teams, I saw the effect of highly detailed onboarding programs on my performance. I also felt how satisfying it is to jump in the deep end and push some code to production on the first day, but also how this method is ineffective for the long-term, and how it decreased my productivity over time.
As a (former) engineering manager and a mentor in Wix, I had the opportunity to develop our team’s on-boarding program, and I got a lot of feedback- either from the trainees, from other managers who used my program in their teams, or indirectly- by comparing to new employees in other teams that had a different onboarding experience, without a well-structured program.
In this post I’ll share my philosophy about on-boarding programs, how to structure them and how well-designed developer handbooks can significantly improve your new employees’ retention, satisfaction and performance.
One thing worth mentioning is that this program may work better for large companies with different teams and products. However, you can easily adjust to smaller companies. You can use it as a reference and adopt what works for you best.
Why a Structured On-Boarding Process is Better Than On-Demand Learning
During my career I saw a lot of managers who preferred to avoid a structured on-boarding program for their new team members. Rather, they just assign some bugs or small tasks, and hope they will learn the internal systems from these tasks over time, on demand.
This method has a clear advantage- this is a great way to quickly know the codebase, and small tasks may feel like a quick win which satisfies both the new member and the rest of the team. Obviously, they will notice the productivity improvement from the first day. However, in my opinion this method leads to a fake productivity, as it prioritizes the short-term goals over the long-term.
Why? From my experience, usually these “newbie tasks” are relatively small, and don’t involve enough concepts, internal systems or trivial techniques that are used by the team, such as defining a new A/B test or initializing a new microservice from zero to production. Fast forward to a few weeks or months later, I want to be able to estimate tasks without taking the learning time into account. I don’t want to spend a second on it, especially if it’s something that you rarely do, like creating a new microservice and deploying it to production. I want to consult with my team members about problems and suggest possible solutions, and they will simply understand what I’m talking about. I don’t want the onboarding program to last forever.
The goal is to be fully productive more quickly, and therefore allow the new hire to contribute to the business earlier on. They’ll feel better, and your business benefits. The other solution usually means working in a lower capacity for a much longer period, which decreases the overall velocity.
So instead of a kind-of on-demand-based onboarding, I allow the trainee to take a dedicated time for learning, with no rush. But once they successfully finish the program, they are 100% ready for the wild life, and so- my expectations. They can take any task like any other team member, and finish it in a reasonable time, like any other team member. In this phase, they are not newbies anymore.
Live Sessions vs. Recorded Videos
As developers, we always try to optimize the amount of time a task takes or amount of time it requires. According to this logic, I could easily record myself explaining everything or simply refer to other recorded videos, and that’s it. But you’re not a developer anymore. You’re a manager. And so, your responsibility is to take care of your team members before optimizing your time, and trust me- no one wants to join a new team, put on the headphones for a few weeks, and watch session after session on video. I doubt if more than 30% of the knowledge will be passed this way.
My solution for this issue is simply to balance. Topics that don’t change frequently such as some library or a technical concept, I usually recommend to watch online. Topics that are relevant specifically to the company, especially if they are changing constantly (product architecture, for example), or topics that usually raise a lot of questions, I prefer to discuss them in a live session.
Regardless of the medium, I set a feedback meeting after each recorded video/course, to make the new employee feel more comfortable to ask questions, raise issues, etc. and verify that we’re on the same page.
Yes, I know live sessions may feel like a waste of time. Remember that it’s not necessarily mean that you, the manager, will do it. Delegate it to other team members or other people in the organization, it’s totally ok. Optimize your team members’ satisfaction, and the productivity will improve. Optimize for time? don’t expect that the productivity level will be improved linearly.
Personalize the Program and Use a Shared Document
Max, an experienced Scala developer, with a deep knowledge in high-scale systems, is about to join your team. In a good scenario, you already have a “generic” handbook that is used to train new developers.
You can ask him to follow the generic handbook- Scala tutorial, some guides about backend systems, etc.. Hopefully, you didn’t forget to tell him to skip the Scala tutorial 🙂
But you can do it better- instead of “Dear developer”, you can open the program document with “Hey, Max! Welcome to the team!”. I was surprised how this small difference has so much impact on new hires. You can also remove the irrelevant parts, and invite to some meetings that are usually irrelevant to every developer. In other words, personalize your onboarding program to each developer, based on experience, previous knowledge and seniority level.
I have a document of the “base” program with all the resources, and for each new hire I duplicate it and adjust the program accordingly- remove irrelevant parts, change other parts if needed, etc. Then, I share it with the new hire.
Having that “base” document helps you spend less time thinking about what needs to be done, and creates a consistent process for new hires in the future.
Another advantage of a shared document, dedicated for the specific trainee, is the ability to track what has already been done, and it’s a place to collect comments and feedback easily, for each part of the program.
From my experience, people tend to successfully finish more parts of the program when it’s organized well and they are focused. When they are asked to skip parts or referred to different resources that are not mentioned in the program they simply stop following it.
Onboarding Plan Outline
I prefer to design the program logically, like a funnel, where each part depends on the knowledge learned in the previous part. The main reason is that usually it’s easier to follow from the most generic topic (e.g. Scala) to the most specific parts (e.g. guides about company internal libraries in Scala).
After each part I set a feedback meeting to review the tasks of that part and collect questions and feedback from the trainee. This is super important, don’t skip it. Sometimes the feedback is also related to the next parts, so you can adjust accordingly in real time, during the program.
The technical outline is the following:
- Administration
- Part 1: Tech stack- learning the technology (JS, Scala, Java, React, Spring…).
- Part 2: Company-related stuff- infrastructure, internal systems, etc.
- Part 3: Team-related stuff- know the products owned by the team, KPIs, roadmap, etc.
Before: Be Ready for the New Member
It may sound trivial, but have all the equipment a developer needs when they walk in for their first day. You don’t want to start without a laptop, for example. Also, it will be nice to organize the desk- monitors, good headphones, accessories, etc.
If the new employee works remotely- verify that the equipment will be arrived on time and take enough buffers if anything changes.
Another time-waster is document signing- tax documents, phone plans, etc. If possible, try to finish it before the first day.
Day One (and Possibly Day Two): Administration
The first day in a new place is overwhelming no matter what you’ll do for your employee. Your goal as a manager is to soften it as much as you can.
One way to make it is to provide a mentor or buddy to help the new team member get acclimated, guidance (”How do I….?”) and to be available for questions during the onboarding period.
I usually start the first day with an introduction session- who I am, a bit about my experience, and why I’m here. Then, we’re talking about some general administration topics:
- About the company- mission statement, core values, vision and plans for the future.
- About the team- team and group mission and a bit about the products we own (high level).
- Organizational orientation- reviewing the organizational chart bottom-up (”this is you, this is me — your manager, this is my manager, these are other teams we’re working with, and this is the CEO…”)- I don’t expect anyone to remember it, but just to understand what group X is doing, and who is John.
- HR-related stuff (better done by the HR itself, if possible), Policies, etc.
- Recurring meetings and work routines.
At the end of this session, we set the expectations about the length of the program and working guidelines of the team. I also ask the trainees to share their expectations from me, from the team and from the onboarding itself.
Usually this session takes ~1h.
After this session, the trainee is free to setup the machine (I simply share my Brewfile with all the required apps so it’s easier to install everything, but you can also share a list of required apps). Also, make sure there’s access to all important accounts- email, Slack, Github, etc.
Once the machine is ready, I usually ask to invest some time and play with our product, to better understand it from the user’s perspective, and I collect some feedback about it. If needed, it might be worth setting a meeting with the PM beforehand to get some overview about the product.
From now on, the trainee is part of the team. This means that joining all the team meetings is mandatory, like any other team member, with no exception. You may think that it’s a waste of time for the trainee, but I optimize for engagement, not for time. And you’ll be surprised how engaging it is for both the trainee and the team to join these meetings. You’ll also be surprised how fresh eyes will help you in design meetings, so if your trainee is quiet in these meetings, ask for opinions proactively, and encourage asking questions.
Week 1–2: Tech Stack Alignment and Intro Meetings
The first week has two objectives:
- Conduct intro meetings with relevant people- for example, PM, group manager or other peers.
- Alignment about the technical stack-
- Technology- NodeJS / Java / Scala / React / Whatever.
- Methodologies- for example, outside-in TDD.
- Software engineering and coding principles- for example SOLID and clean code.
As I mentioned before, the technical part is kind-of optional. I wouldn’t ask an experienced Scala developer to learn about Scala on one hand, and I wouldn’t expect a junior developer to finish it in one week. Sync with your trainee and adjust accordingly.
Software development is like driving. you can learn it from a book, but it’s crucial to gain practical experience. Therefore, I recommend the trainee to build something during the program, as part of learning the technical stack.
Also, remember that different people absorb information differently- someone may prefer to read online tutorials, someone else may prefer books or watching videos. Adjust the medium to the trainee’s preference.
I would move on to the next part once the trainee feels comfortable enough with the technology to develop a software from scratch. Also, understanding the concepts well (SOLID principles for example) and some experience in the company methodologies (e.g. TDD) are mandatory. I highly recommend to set a feedback session after each part, to make sure both you and the trainee are synced.
Week 3–4: Company Related
The objective of this part is to know the internal infrastructure of the company, and understand how the internal systems work, how to integrate them, best practices, etc.
Possible topics:
- Microservices infrastructure and how to start a new service.
- CI/CD systems and the process of deploying code to production.
- High level architecture, databases, queues, etc.
- Feature flags and A/B Tests.
- Monitoring.
- Logging.
- BI events and how features are measured, business-wise.
- Best practices- how do we do what we do?
If your company is microservices-based, I highly recommend to create and deploy a dummy microservice, from zero to production (usually called “nothing-to-prod” task), and play with the infra features such as feature flags and BI events on this service, isolated from the company’s real services.
Depending on the usage of these features in the company, I would move on to the next part once the trainee deployed some code to production and understood how to work with internal systems that are used the most. In other words, if you rarely add BI events, don’t waste your time on it.
Week 5–6: Team Related
The objective of this part is to engage with the team’s products, and gradually move out from the trainee position, to a fully productive team member. The idea here is to understand how these products work and how they are integrated to other products in the company, if any, both tech-wise and product-wise. Also, how they are measured, and how it’s related to the company’s goals and KPIs.
During this part, the trainee may take on some newbie tasks. In some teams it’s a synonym to bugs, but from my experience a balance of small bugs and new features work better, and are more engaging for a new trainee. The more impactful the task, the more proud and engaged the trainee will be.
A deep overview with the PM about the business-related stuff will be great. In addition to talking about the existing product, it is worth reviewing the future plans- short-term roadmap (upcoming quarter) and long-term one.
Another meeting you must set is with one of the team members about the product architecture and the codebase structure. If you have a knowledge base about past architectural decisions, it is worth reviewing it together.
How to Continue From Here?
Researches have shown that it takes 6–8 months for developers to be fully productive and make real contributions to the business. The purpose of this program, and mainly how it is organized, is to shorten the ramp up period as much as possible.
If you follow this suggested program, and mainly the ideas behind it, your new team member will probably feel more productive in the day-to-day tasks and more independent to implement features and suggest changes. Also, from my experience it also increases the confidence to take part in technical discussions of the team, especially if the trainee is a relatively inexperienced developer. I noticed that a well-organized program also lowers the turnover rate of the team and the company.
Remember that your onboarding program is also a way to express your company’s spirit. Don’t forget to update it regularly and to have fun while you’re creating it, the readers will feel it immediately. Most importantly- hire amazing people, allow them to learn and expand their capabilities and give them a large room to grow. Your program is just the first link in the chain, the rest is up to you.
