How to Onboard a New Person to Your Experimentation Programme

Imagine someone joins your experimentation team on Monday. By Friday, you want them to understand what has already been tested, what was learned, and what decisions followed. You want them to be able to look at the backlog and understand why each idea is there and what evidence supports it. Now ask yourself: could your current programme deliver that? Is there a single place they could go to see the programme's accumulated knowledge? Or would their first week involve asking around, hunting through old slide decks, and hoping the right people are available to explain what happened before they joined? If the answer is 'they would need to ask people', this guide will be useful. But the harder question is what happens when those people leave.

Before Their First Day

Do not make the new joiner's first week a scavenger hunt. Before they arrive, assemble: a programme overview (a one-page summary of purpose, audience, and strategic connection), team structure and roles, tooling and access, workflow documentation, and key terminology.

Checkpoint: Does a programme overview document exist right now? Not in someone's head. An actual document that could be handed to a new joiner today. If not, that means your programme's purpose and strategic alignment are undocumented.

Checkpoint: Is your team's experiment workflow documented anywhere? Not 'people roughly know' but actually written down with stages, owners, and approval gates? If this documentation does not exist, that is a problem worth solving before the new person arrives, not during their first week.

Assign an onboarding buddy. Not their manager. Someone who can explain the unwritten rules.

Week One: Context and Orientation

Day one: the big picture. Walk them through purpose, history, current state. Cover business objectives, how the programme evolved, current priorities, and how leadership perceives it.

Days two and three: the learning history. This is the step most teams skip, and it is the most important one. Walk them through landmark experiments, patterns and themes, past mistakes and dead ends, and strategic decisions.

Checkpoint: Can you name your programme's five most important experiments right now? Not the most recent. The five that taught you something significant. If you can, try the next question: are those stories documented anywhere that a new joiner could read without you being in the room? If not, those learnings are attached to you, not to the programme.

Checkpoint: How many times has your team retested an idea that had already been tried and disproven? If you do not know, you probably cannot be sure it has not happened.

Days four and five: the process. How to submit an idea, write an experiment plan, use tags and naming conventions, navigate workflow stages, log results and decisions, communicate with stakeholders. Pair with a practical exercise.

Weeks Two and Three: Supervised Practice

Shadow existing work. Run a low-stakes experiment end to end.

Checkpoint: When the new person needs to find relevant past experiments to inform their hypothesis, what do they do? Is there a system they can search? Or do they ask a colleague, who searches their memory, who may or may not remember accurately? If the answer is the second, your onboarding process is only as good as your longest-serving team member's recall.

Introduce them to stakeholders by end of week two.

Week Four: Independence Check

Have a structured assessment. 'Walk me through how you would find out whether this idea has been tested before' is useful. 'Do you feel up to speed?' is not.

Checkpoint: Run that test on yourself right now. Walk through the steps you would take to find out whether a specific idea has already been tested. Count the steps. Count the tools. Count the people you would need to ask. That is what your new joiner's experience will look like, except they will not even know who to ask.

What Good Looks Like

A well-onboarded team member is productive within a month and fully embedded within two. They understand not just how the programme operates but why it operates that way.

If you worked through the checkpoints in this guide, you have probably identified which parts of your programme exist as documented, accessible knowledge and which parts exist only as tribal knowledge held by individuals. The onboarding method itself is simple. The question is whether the information a new person needs is structured and findable, or scattered and dependent on whoever happens to still be around to explain it.