Where teams actually lose people
The common story about volunteer AV teams is that nobody wants to help. In our experience that is rarely the real problem.
People volunteer. They come once, sit next to someone at a desk covered in controls, watch a fast explanation of a system built over years, understand perhaps a fifth of it, and leave with the impression that this requires a kind of person they are not.
They do not say that. They say they are busy next month.
The loss happens during onboarding, not during the work. Which is encouraging, because onboarding is the part you fully control.
Why the usual approach fails
The instinct when someone new arrives is to explain the system. It is generous and it is backwards.
It front-loads everything. All the complexity arrives before any of the competence. The new person is shown twenty things they cannot yet connect to anything they have done.
It teaches the wrong layer. A new volunteer does not need to understand the system. They need to do one job. The system knowledge is what the experienced person has, and it was earned by doing jobs, not by being briefed.
It creates a knowledge debt they cannot repay. After the tour, they are expected to remember it. They will not, and now they feel behind on their first day.
It happens at the worst possible time... usually shortly before a service, when the person explaining is also preparing.
Give them one job
The alternative is narrow and immediate: one job, with a clear boundary, that they can do on their first day.
A camera is the ideal first job. The device is a phone, which they already understand completely. The task, keep this thing in frame, is visible and self-correcting; they can see whether they are doing it well. And a mistake affects one angle rather than the whole service, so the stakes are survivable.
Getting someone onto a camera should take about two minutes: scan a code, enter a code, and they are on. That is the entire technical setup. The rest of their first session is standing in a spot doing a job they understand.
Compare that with an hour at the desk being shown a system. One of these produces a person who did something useful and wants to come back.
Then widen slowly
Once someone has run a camera a few times, they have context... they have seen the service from inside the production, they know the shape of it, they have met the team. Now the next layer costs far less to teach, because it attaches to something real.
A reasonable progression:
Camera → they learn framing, timing, and how the service flows.
Lyrics or slides → the first job with a visible consequence for the whole room. Not to be given on day one, and much easier once they know the service's rhythm.
Cutting between cameras → decision-making under time pressure. This is where fluency starts.
The whole desk → last, and by this point mostly assembled from parts they already have.
The important property is that each step is a small addition to a working competence, not a new subject. Nobody is ever standing in front of a system they do not understand.
Roles you may not have considered
Teams often think of AV as one job, when it is several, and some of them suit people who would never sit at the desk.
Floor director. Someone in the room, watching what is happening, cueing camera operators. Requires no technical knowledge at all... it needs someone who notices things and can direct people kindly. Frequently the best role for a person who is confident with people and uninterested in software.
Camera operator with talkback. Once a floor director can speak to camera operators directly, camera operators need to know even less, because someone is guiding them. This lowers the entry bar for the largest role on the team.
Plan operator on a phone. Advancing the service plan from a handheld device rather than the desk. Physically less intimidating than sitting at a station, and it means the person can stand where they can see.
Backup singer with the lyrics on their own phone... not a production role, but it removes a person's dependence on the screen and takes pressure off the operator.
The general point: the more roles you can offer, the more people can find one that fits them. A team with one job has a recruitment problem by design.
What to do on someone's first day
- Give them a job before you give them an explanation. Competence first, understanding after.
- Put them next to someone, not alone. Not to be taught... for company, and so a question has somewhere to go.
- Tell them what happens if they get it wrong. Usually the honest answer is "very little," and hearing that out loud removes most of the fear.
- Let them be finished. A defined job that ends is far less daunting than an open-ended responsibility.
- Ask them what was confusing and write it down. New people can see your setup clearly for about two sessions, after which they normalise like everyone else. That window is the most valuable feedback you will get.
The thing to avoid
Do not make someone responsible before they are competent.
The fastest way to lose a volunteer is to leave them alone with something that matters before they are ready, and have it go wrong in front of the room. That experience does not produce a person who tries again. It produces someone who concludes, reasonably, that this is not for them.
Competence first. Responsibility after. In that order, most people stay... and the reason they stay is not that they became technical. It is that they were never made to feel they had to be.