One of the biggest challenges when starting a new job, both from an employee perspective and a company perspective, is deciding what is a good task to assign someone who just joined the team. In fact, of all three companies I’ve worked at so far, I’ve experienced different approaches to the onboarding process, and, while some worked better than others, I feel that none of it was exactly what I would look for in my own ideal onboarding.

Typically, either one of these things happen:

• You are put, alone, on simply reading documentation about a framework you will be using. Just the docs, no real work happens for, who knows, maybe weeks. This doesn’t click with me, because, reading docs while trapped in a contextless void simply doesn’t cut it. You won’t absorb any real working knowledge, because you’ve never worked with the thing.

• You are assigned a ticket. Any ticket. A ticket that the team feels it’s easy or straightforward. This is a much better approach than the previous one. Because with this, at least, you are forced to go through the standard onboarding things that are usually one-offs: what’s the team’s branching strategy? What is the review policy? Are there tests? And while you learn about these details, you slowly start building up context which is really valuable in the long run. However, there’s a flaw in this approach too: what the team feels it’s an easy ticket, is usually riddled with bias because these folks have been with this codebase for much longer. Or, putting it in a SCRUM parlor: a ticket that is a 5-point effort for someone in the team for a year, can be easily a sprint-wide effort for someone who was just onboarded. Unfortunately, since the onboarding needs to be somewhat expedite by having a concrete chunk of work in place, the team will simply act upon their own feelings of complexity, forgetting that the lack of context plays a huge role;

• You do pair programming with a more experience colleague: This can feel a bit of an-between approach: you see the code being executed, you immediately know if there are tests or not, and, you can even slowly get familiar with how a more experienced colleague works, even if by only observing. The slight disadvantage of this approach is that it still a passive activity because when pair programming, there is usually a person on the “driver’s seat” and a simple “passenger” and, I believe that the best way to learn is by doing, so, while it can be a good experience to gain more context, I think nothing truly replaces doing it on your own;

Since I am very in favor of taking a practical approach to onboarding, where I believe that the best way to level up is to learn by doing, the main question suddenly becomes what is the best way to ensure that a new person joining the team has a ticket that has just the right amount of complexity in it in such a way that it’s not too hard to tackle, while at the same time providing a solid onboarding experience?

This is an area where the open source community has an edge over the corporate world! It’s common in many repositories (and this is a finding highlighted in the 2021 github report) to have an issue label defined along the lines of: “Good first issue” or “Beginner-friendly” or something along those lines, in order to really quantify how easy of an issue it really is.

It’s not uncommon to see that some open-source projects have dedicated teams of maintainers actually combing through the backlog and triaging the issues to really create these sets of simpler tasks that make for the perfect onboarding experience!

While this is a practice that I’ve never seen applied in any type of corporate team, I believe that this is one of the best ways to ensure that new people being onboarded can create an impact from the first moment! It’s not without its challenges of course, especially because it is not easy and sometimes downright impossible to afford to have FTEs simply managing issues and ensuring that the labels are set appropriately, but, maybe some middle ground could be found in this area.

What do you feel it’s a good way to have new team members increasing their impact?