How we onboard new hires with codelabs

One-to-one onboarding doesn't scale. Codelabs do.

When a new person joins the company, the default onboarding plan is another person. Someone senior sits with them, walks them through the first setup, answers questions, points them at the right places to start. It works. But also, it doesn’t scale.

Every new hire pulls a person off their own work for days. The quality of the onboarding depends on who happens to be free that week and how good they are at explaining things. Two people who join the same month get completely different starts. And whoever onboards them spends the same afternoon explaining the same process they covered last month.

I led a codelabs program at a large enterprise to fix exactly this. Here’s the thinking behind it.

One-to-one teaching doesn’t scale, and it isn’t consistent

The problem with pairing isn’t that it’s ineffective. It’s that it’s expensive and uneven.

The cost is obvious: senior time is the scarcest resource on any team, and onboarding spends a lot of it. The unevenness is the quieter problem. When the lesson lives in a person’s head, every delivery comes out a little different. One mentor remembers to explain a key step, another forgets. One walks through the whole process, another says “you’ll pick it up.” New hires end up with different mental models of the same system, and the gaps show up months later.

Codelabs move the lesson out of the mentor’s head and into something repeatable. The senior person’s knowledge gets captured once, and every new hire works through the same path. Mentors are still there for the hard questions, but they’re not re-teaching the basics every time someone joins.

Start with the use cases new hires actually hit

It’s tempting to document the whole system. We didn’t. We started by listing what a new hire actually has to do in their first weeks, the real tasks, not the org chart.

These were the core workflows they'd run no matter which team they landed on, the end-to-end processes that touch several systems at once. They're also the steps that cross team boundaries, which is exactly where reference docs leave gaps.

A handful of codelabs covering the most common first-month tasks does most of the work. We weren’t trying to teach the whole system. We were getting people through the paths they’d actually walk in their first weeks.

Build each one the same way

Every codelab in the program followed the same anatomy: a real scenario, one golden path, a starting point, checkpoints along the way, and a reference solution to compare against.

Consistency matters at scale. When a thousand people go through the same set of exercises, the structure has to be predictable, and the quality can't depend on who wrote which one. I wrote about what makes a good codelab in a previous post.

What changed

The first task stopped being a three-week ordeal. New hires went from an empty starting point to shipping something real on their own, without waiting to catch a senior person at a free moment.

Mentors got their time back. And because everyone worked through the same exercises, the team finally had a shared baseline. When someone said “I did the onboarding codelab,” everyone knew exactly what they’d learned.

Onboarding stopped being a tax on our best people. It became something the system could absorb at scale.