How to sequence onboarding the right way

I once sent a new volunteer everything we had: culture note, governance doc, subteam one-pager, and a wiki page for every recurring task.

They read the first one, skimmed the second, opened none of the rest. Then they asked me where to start.

The writing was never the problem. The order was.

Onboarding is not a library. It is a sequence.

One concept: hand the library over as a sequence

A new volunteer cannot absorb your documentation, and they were never meant to. Every page answers one question, and each question arrives on a different day. Send it all at once and you have answered nothing, because nobody can tell which page is for today.

Before you recruit: two documents.

  • A culture note. Formal or informal. Agendas, or voice notes between meetings. Four hours a month, or ten. It belongs in the recruitment call, because its job is filtering. People who would not thrive select themselves out before either of you spends an hour on it.

  • A governance and responsibilities doc. Who decides what, and how a disagreement travels upwards. Two documents is the whole starting kit.

Day one: one call, one link, one task.

  • The call starts with the team's mission, not the organisation's. It is narrower and it is the thing they are actually joining. Then let them ask about the team and about the org.

  • One short link, not a welcome pack. One place holding the resources, so nothing has to be hunted for later.

  • One small task, with a date on it. Willingness is highest on day one. Give it somewhere to go. A low risk task works perfectly for this case.

After that: the rest arrives when it's needed.

  • The workflow page travels with the task it explains, and nothing else attached to it. This is the only page most volunteers read properly in month one.

  • The subteam one-pager and the Manual of Me land around week three, once there is a person and a remit to attach them to. In a team where the lead is staff and the volunteers rotate faster, the Manual of Me is what stops every handover starting from zero.

Do this before you close the tab. Take your last three volunteers. Write down every document each one received in week one, then write down which document they were holding when they finished their first task. Usually one page did the work and the rest arrived too early. That page is where you want people to start.

Two quick asides before the sign-off.

On growth. Once a volunteer wants to lead, they can define their own subteam and draft their own responsibilities page, and you just update the governance doc to say who leads what now. The library grows as the team grows.

On scale. Past four or five subteams, a grounded chatbot behind the wiki genuinely cuts the repeat questions, as long as the pages stay current and it can hand a stuck volunteer to a person instead of a dead end.

Both are their own issue which we will explore in a future edition.

Where this helped me

The team I built this way grew from one person to 30 volunteers across five subteams. Each subteam got its own mandate, its named owners and more. Check it out here.

Your turn

How long after a volunteer says yes do they get their first real task? Leave a comment. The honest number is usually worse than the remembered one.


Ermal Asllani 

People Ops for Decentralised Organisations 

Behind the Mission goes out every second week, on the people side of running a decentralised organisation. 

Previous
Previous

What a bad offboarding actually costs

Next
Next

Twelve people signed up. Two of them ever showed up.