How we onboard new hires with codelabs

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

When a new person joined the company, the default onboarding plan was another person. A senior colleague sat with them, walked them through the initial setup, answered questions, and showed them where to start.

It worked for one hire. As the company grew, the team repeated the same walkthrough every time someone joined. The result depended on who was available and what they remembered to explain. Two people joining in the same month could receive very different introductions to the same system.

The person leading the onboarding also lost days repeating work they had covered with the previous hire.

I led a codelabs program at a large enterprise to make this process repeatable. Here’s how we approached it.

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

Pairing still mattered. Senior colleagues provided context, answered difficult questions, and explained the decisions behind the system. But much of the initial setup followed the same path every time.

When that path lived in someone’s head, each mentor taught it differently. One remembered an important step. Another skipped it. One explained the complete workflow. Another assumed the new hire would pick it up later.

Codelabs captured the common path. New hires could work through the basics independently, while mentors remained available for questions that required context or judgment.

Start with the work new hires actually do

We listed the tasks a new hire handled in the first few weeks and used those to scope the documentation. The org chart stayed out of it.

New hires ran many of the same workflows regardless of team. Those workflows crossed several systems and ownership boundaries, where reference docs leave gaps tends to leave gaps.

A small set of codelabs covered the most common first-month tasks. Each one focused on a path that new hires would actually follow.

Use the same structure every time

Every codelab followed the same structure: a real scenario, a clear starting point, one supported path, checkpoints, and a reference solution.

When a thousand people work through the same exercises, they need to know what to expect. A common format also makes the codelabs easier to review and maintain.

I covered this structure in what makes a good codelab in a previous post.

What changed

The first task no longer took three weeks. New hires could follow the documentation and ship their first change without waiting for a senior engineer to walk them through it.

Mentors spent less time repeating setup. Everyone completed the same exercises, so the team also gained a shared baseline. When someone said, “I did the onboarding codelab,” everyone knew what they had learned.

The documentation handled the repeatable parts of onboarding. Mentors could focus on questions that needed context, judgment, or experience.