When it comes to being apart of a development team nowadays, two things that are certain. One, things will break and you will have bugs that need fixing. Two, the team you are a part of now is likely going to change, new folks are likely to join. This is fantastic because it brings in talented folks with a fresh perspective.
That said, on-boarding a new person into your team should not be overlooked. It is critical to approach someones on-boarding with importance. It should receive the same thoughtfulness and planning that you put into a new feature you are building.
This doesn't mean that you need a detailed on-boarding plan with dozens of checklists. It means that you have a general plan. That plan brings the person up to speed in a reasonable time frame without burning them out in the first week.
With that in mind, here are 5 things that have worked great in my career. These come from joining a new team myself and on-boarding new folks to existing teams I have been on.
1. Get those early wins and celebrate the hell out of them
This cannot be overstated. Early wins for a new team member are like adrenaline shots that last months.
No matter how big or small that first commit to the codebase is, celebrate the hell out of it. Joining a new team is intimidating, scary, and riddled with imposter syndrome. So when that new person contributes their first bit of code, suggests a README update, or points out a new bug, celebrate the hell out of that.
This not only boosts their confidence but it highlights that new perspectives and ideas are welcome here and we celebrate our wins.
If you only do one thing when welcoming new folks to your team, do this one. It has a real impact on the confidence of the person and the culture of the team that pays dividends for a long time.
2. Provide space to let things soak in
Many people think of an on-boarding plan as a big checklist that the new person needs to walk down. The bad ones have specific deadlines as well. This might work for some people but it can induce unwanted anxiety as well.
But wait, we need a plan, you might be saying. Yes, you should have a plan outlined. But that plan should be communicated as a guide, not a requirement. "It's OK if we don't get to everything in here and we will adjust as we go" is all it takes.
Built into this idea should be time for the new person to let things soak in. A time where they are not in a meeting or getting a whiteboard session from someone else on the team. This is time to reflect on things they may have been shown and to explore other areas.
This time turns a feeling of urgency into a feeling of were ramping up. Two very different feelings that can yield far different results. The former might get someone up to speed quicker but the latter will allow things to marinate. Marination allows room for questions or other perspectives to bubble to the surface.
3. High-level before detailed overviews
Developers tend to have a habit of thinking about solutions at very low levels. To the point to where we often have to snap ourselves out to remember the problem we are trying to solve.
So, getting into detailed architecture overviews is not a great place to start.
Instead, start at the high-level. Why did we build this product or service? What problems is it solving? Who are our users and how are they using it?
Provide the context and constraints before going into the implementation. This helps the new person to become familiar with how this system has evolved over time. Having this context with the user use cases is far more important than any AWS architecture diagram.
4. On-boarding buddies for the win
This is a person that has dedicated time to bringing a new person on board. It may not be their entire focus, but it is a large part of it for a set amount of time.
The on-boarding buddy is a goto resource for blocking issues questions. This isn't meant to be somebody that oversees. Rather it is someone that has dedicated time to help with anything. This doesn't mean a new team member doesn't interact with the rest of the team, they should. But, when others might be in a meeting, the on-boarding buddy is there to help.
An important thing to remember, buddies help when needed. It is OK if a new team member doesn't have a metric ton of questions. Let them soak things in at their pace and gauge how much help they need via observation not looking over their shoulder.
5. Centralized documentation
It can be hard, but keeping your developer setup documentation up to date makes a huge difference.
Nothing can deflate the enthusiasm and confidence of someone quicker than not being able to get setup. Starting to go through the setup README only to hit roadblock after roadblock because it's out of date.
So when something changes in the architecture or application that requires a new tool, update your setup documentation as part of the pull request. When you switch over to a new monitoring system, make sure there is a note to create that account when onboarding a new person. It's all straightforward things, but we tend to forget them.
One big improvement you can make is to centralize your setup documentation. Don't spread it out in a bunch of git repos when the developer might need to use them all. Create a centralized repo that has all the things they should configure to be up and running in no time.
Conclusion
Joining a new team is daunting for anyone. It's full of excitement, fear, and enough imposter syndrome to make your head spin. We all feel it, but we often forget about that feeling once we have settled in.
But the next person is on the horizon. Remember that feeling when they are joining the team. Set them up for success by keeping documentation up to date and having a process in place to bring them up to speed. Pair them with an on-boarding buddy that is dedicated to welcoming them and helping them on their journey.
Most importantly, celebrate the hell out of their wins because it shows how important they are to the team. Without new folks, you wouldn't get the help you need or the new perspectives that propel things forward.
Want to check out my other projects?
I am a huge fan of the DEV community. If you have any questions or want to chat about different ideas relating to refactoring, reach out on Twitter or drop a comment below.
Outside of blogging, I created a Learn AWS By Using It course. In the course, we focus on learning Amazon Web Services by actually using it to host, secure, and deliver static websites. It's a simple problem, with many solutions, but it's perfect for ramping up your understanding of AWS. I recently added two new bonus chapters to the course that focus on Infrastructure as Code and Continuous Deployment.
I also curate my own weekly newsletter. The Learn By Doing newsletter is packed full of awesome cloud, coding, and DevOps articles each week. Sign up to get it in your inbox.
Top comments (2)
Centralized documentation should get all of the claps.
Sometimes, there's a slow period when a new person starts. Being able to point them to one place for documentation, to review and reference if things are slow is helpful. They may even see gaps that people more familiar with the codebase may have overlooked.
Totally agree. On my last onboarding process, I was made to install a very complex app (all by hand) and at the end I didn't work on that app Arrgg!
I would add to the docs clear instructions on how to have a dev environment up and running really quickly. From specific versions to code conventions