I’ve recently been part of teams that onboarded new developers and have also been the developer onboarding to a new team. During that time, I’ve seen firsthand some of the challenges faced by a new developer. At the beginning of a project, the whole team can participate in kickoff meetings and otherwise start on the same page. In contrast, joining in the middle of a project can feel awkward or even disruptive. To combat that, I’ve got a few standard considerations when onboarding somebody new.
What do they need to know about the project?
There’s typically no way somebody can jump onto a project and figure out everything they need to know on their own. One may not need to know the overall purpose of the project just to work on one ticket or story, but, in general, it’s valuable to get up to speed to know the direction all of the team’s work is taking them. So when a work item isn’t clearly defined, or has a mistake, there’s a better chance the new dev will identify it.
Who do they ask for help?
Beyond another developer giving technical help as needed, often, a new developer must seek clarifying information about one aspect of the project or another. For example, if there’s an integration with another team’s work, you should inform the new developer who they can reach out to on that other team to ask questions about that integration.
What tools do the other developers use?
Of course, many developers have their own preferred toolset for a given tech stack. But, I’ve found if a team is generally using the same set of tools, it’s valuable for the new developer to at least have those tools available to them. Non-IDE tools for development (e.g. Postman) are great for onboarding new developers, especially if there are collaborative features involved. Overall, it just reduces the friction when running into environment issues, establishing team development practices, and so on, when folks are using the same tools.
What will they work on first?
Finally, prep something for the new developer to work on. I’ve seen projects where the backlog of work is in a great place, but just for the developers already on the project. Stories might only be straightforward with some prior context a new team member may not have. If possible, move some bug fixes into the current sprint. Or, break up a complicated story into more manageable pieces, so that the new developer can have a simpler way to get familiar with the codebase. If this isn’t feasible, pairing is an equally valuable way to help somebody get started.
Perhaps these considerations are obvious, but, in practice, I’ve seen them ignored enough to warrant the reminder. Onboarding somebody can often feel like it interrupts your team’s flow, and it’s a tough responsibility to share. But with a bit of thought and preparation, it can go smoothly. In turn, that will enable your team to get back to their preferred pace of work faster on top of setting the new developer up for success.