Our new approach to on-boarding engineers

What do you do when you hire a new developer? How do you get them familiar with your code base, workflows, and teams? Do your approaches change when you’re on-boarding 15 new hires instead of just one? We wanted to explore an alternate approach to on-boarding at O’Reilly.

Maybe this sounds familiar

When you talk to recent tech hires, many of them seem to tell a similar story: the company is good, the work is interesting, but on-boarding was lacking. For a lot of developers, on-boarding was an invite to Slack, a quick meeting with HR and a manager, and a link to Confluence. At some places, it’s more involved, with a mentor to help you get your feet wet and some introductory tasks.

We used to do something embarrassingly similar at O’Reilly. When you started, you’d do the normal run of HR meetings, paperwork, and a visit with IT to set up your accounts and get your new computer. After that, you’d be assigned an “on-boarding buddy” who would help you get your computer set up with things like Docker. They’d also help you get started with a ticket or two for one of our many projects (the joy of micro-services).

Unfortunately, this method doesn’t really scale. The on-boarding buddy and their team will be slowed down by the buddy having to devote time, often a week or two, to the new hire. The new hire also only gets to really deal with the projects that their buddy is working on unless there is already a team waiting for them. In that case, though, they’re working on code that their buddy might not have any familiarity with. And since no one hits the ground running, the new hire’s team is still slower than they’d like to be.

All around, on-boarding seemed like a great process to update and to try and improve. We also knew we had a bunch of new hires coming in, so the sooner, the better.

RAMPing up

Our plan was to create a new team, named “RAMP” since it gets you up to speed, that would act as a soft landing for new hires. All new front-end and back-end engineer hires would be assigned to the RAMP team and stay there until there was a spot open for them on a standard squad and they were comfortable.

We wanted the RAMP experience to be very similar to the day-to-day work that engineers were doing on other teams. We asked all of the dev leads and project managers to look through their backlogs and find tickets that didn’t require a lot of context. We also defined many places where our internal documentation was lacking and could be updated by a new set of eyes. Everything would be done with a Jira board (Kanban, not sprint-oriented) and would go through the normal pull request and QA cycles. RAMP developers are full-fledged developers, they’re not on probation or anything, so they’re allowed to merge pull requests and kick off builds/deployments, too.

There were three major differences between being on RAMP and being on a standard team at O’Reilly:

• The RAMP team wasn’t concerned with sprints or velocity, though, since
  the point was to provide a place to learn and get comfortable. It’s
  hard to work in learning when you’re trying to finish a ticket before
  the weekend!
• The RAMP team works on tickets from many of the other teams. This is
  intentional so that RAMP members get to dive into as much of our
  code base as possible. This also gives them more interaction with
  other teams and those teams’ processes.
• Most engineering teams at O’Reilly use a two week sprint for work. We tried that for RAMP but it proved to be a bit unwieldy since RAMP members aren’t on the team for a set amount of time. And, also, we didn’t always have tickets available that nicely filled out some feature set. We switched the team to a Kanban board and it has worked out much better.

Changing lanes

Like anything else, RAMP isn’t finished and perfect. Another aspect of RAMP was that it was meant to provide a way for current engineers to re-train for a new position or discipline. Are you a front-end engineer that wants to learn our back-end stack? RAMP is the place for you! Or maybe you’ve been working on a more over-arching, architecture-style team and you want to move to doing product/platform work? Again, RAMP is here to give you that opportunity.

We’ve only had one engineer take this path so far, but we’re hoping to have many more in the future. It could even be used for people from other parts of the company that are looking to become an engineer or increase their coding skills!

We’re also looking at RAMP as a place for engineers that need a break or change of pace after a big push or long stint of difficult work. RAMP can, hopefully, provide them some low stress, varied work while they recharge their batteries.

How’d it work out?

We started the RAMP team in mid-December and it’s still going in mid-March. We’ve had around 15 engineers go through it from day one to being added to a squad. The results and feedback have been fantastic! Here are some of our major findings:

• RAMP made new hires more comfortable asking questions and asking for help. Part of this was the fact that they were on a team with other new hires. It’s less scary to ask a question in a room full of people that also probably don’t know!
• A lot of our tickets involved a custom in-house tool so this gave new hires time to read the documentation for this tool, work through the tutorial (written by other RAMP members!), and use the tool with some existing, production code bases. When they joined their squads, they were already familiar with tool and how to use it for development, QA, and production.
• Less overall slow-down from hiring. With 15 new hires, we would have had seven to 12 on-boarding buddies, many of which would have to be flown out to one of our two main offices for a week. With RAMP, no buddies had to be recruited or do any traveling. With no on-boarding buddies, we also kept all of the squads working close to full speed.

Having the RAMP team has also helped us shore up our internal documentation and make sure that our processes and approaches make sense, even from a beginner’s perspective. Can someone read these docs and get the project running without help? Can a new hire figure out who they need to talk to about a pull request or ticket? What common questions should we document and what software should we start providing with their machine?

Exiting

We’re really excited and happy with how RAMP has turned out. It has allowed us to hire, train, and place more engineers at once than would be feasible with our old system. At the same time, the engineers coming off of RAMP are more comfortable and familiar with our system than the engineers we hired before RAMP. We’ve also proven that it can work for engineers that want to develop a new set of skills, whether that’s a new language/framework or a new style of work.

It had a few speed bumps along the way (we found that a lot of documentation was missing, scattered, or incomplete) but nothing that would make us want to go back to the old system. As with everything, we learn and evolve as we go.

We’re now at a place where a new hire goes from talking with HR and IT to having set up guides to follow for each discipline, a full walk-through tutorial for our internal tool, and a set of tickets that are vetted and ready for work.

How about you? Have you tried any other on-boarding methods that have
worked out well? Does this sound like an on-boarding experience you’d like to have? Let us know! We’d love to hear your ideas!