Why All New Hires on Our Team Take on the Same Project

For the last few years, as our team grew, one of the biggest challenges we've had to solve was how to onboard new engineers onto the team. A big part of onboarding new folks is finding easy tasks for them to do that get them introduced to all the different parts of the codebase. When the team was small (<5 people) and the product's scope was relatively contained, this was pretty easy. We typically tag all easy, low-priority tasks with "onboarding". So, all we had to do was go through these and pick a few different tasks in different parts of the code. In fact, for many years, we kept a long-standing tradition of having everyone submit some code for review and get it approved and merged on their first day.

However, as the team grew (we're now upwards of 70), and the product became more and more complex, finding "onboarding" for new engineers became much harder. In some weeks, we'd have 2 people join and we would struggle to find easy and meaningful tasks that allowed them to learn about all the different parts of the system. It's easy to find simple tasks as we tag a lot of them. However, they often go stale, and it's hard to find a fair few of them in varying parts of the codebase.

I talked to some friends and found out that certain companies have a "mock feature" that everyone has to build as part of their onboarding. Sometimes, this is real functionality that the product already has. Other times, it's really just a fake feature. At first, I didn't like this idea. It's not elegant. Why have people work on something that won't even ship or provide any value to customers? And besides, it would break our long-standing tradition which I felt at odds with.

During a routine 1:1 with one of our longest tenured engineers, I brought up this idea as we were chatting about the struggles of onboarding new people. He loved it, and we sort of decided that he'd try to come up with a mock feature that new hires could build. This feature would be all-encompassing. This means that completing it would require touching a little bit of everything (database migrations, backend changes in different services, API changes, frontend changes, etc.). This took a few weeks to prepare, as the person who picked it up was also working on other things at the same time. However, by the end, we had something ready to test on some new hires. The testing went amazingly well, and every new person now goes through building this mock feature.

What does it look like?

  • We came up with a feature that our product could eventually have (but doesn't really need). This feature requires editing all the major components of our product.
  • We prepared an incredibly thorough document (it's 44 pages long!). It describes all the necessary steps for building this feature. It includes some of the code people have to write too, but not all of it.
  • The new hires work on this feature, over various merge requests that all get merged into a side branch. This side branch then gets discarded. All of these "diffs", or code reviews, get code reviewed like any regular change.
  • The feature only takes 1 week to build. Some people take a couple more days, but we try to help everyone complete it in under a week.
  • Besides building this feature, we also have a fairly typical Onboarding Checklist which is a list of things people need to set up (accounts, email settings, etc.). New hires can work through this checklist while they build their "onboarding feature".
  • After their first week, we can ramp people up with regular projects, or some loose tasks. But by the time they start on these, new hires already have a very solid understanding of the entire codebase.

We've been doing this for almost a year and as I look back on it, the quality of the onboarding has skyrocketed. And the feedback really has been overwhelmingly positive. The new hires really enjoy the process, and I even remember that a couple of people who were already on the team before came to ask me if they could still go back and start over with this feature!

All in all, it's not a perfect system. And it's most definitely not very elegant. However, it has allowed us to streamline and standardize our onboarding process. I didn't believe in this idea when it was first pitched to me, but I look back in awe at the impact it has had on our team. It's definitely something I recommend other managers look into depending on their situation (it probably doesn't make sense in really small companies, for instance).

Ending Note

I must give a huge thanks to Yamil, who led this initiative to great success! Your hard work has paid off tremendously. And also to Teja, who initially shared this idea with me.

Feel free to reach out on Twitter!