Your Volunteers Are Competent

There is a persistent myth in the community sport sector that volunteers are technologically unsophisticated. That they need everything simplified. That they can't handle complex systems. That any new tool requires extensive training and hand-holding.

This myth is wrong. And it's costing the sector.

Who your volunteers actually are

Let me describe a real person. I'll call her Sandra, though her name isn't Sandra.

Sandra is 47. She's the secretary of a suburban football club — 180 members, four senior teams, six junior teams. She spends about 14 hours a week on club administration.

At her day job, Sandra is an operations manager at a mid-size logistics company. She uses Salesforce for customer management. She runs reports in Power BI. She manages projects in Monday.com. She does her team's scheduling in Deputy. She handles procurement in SAP. She communicates through Slack, Teams, and Outlook.

Sandra uses more software before lunch on a Monday than most community sport programs will ask her to learn in a year.

When Sandra sits down at 9pm on a Tuesday to do club work, she opens a spreadsheet. A spreadsheet she manually updates with membership data she's copied from emails. She reconciles payments by comparing the spreadsheet to bank statements she downloads as PDFs. She communicates with members using her personal Gmail because the club doesn't have a domain. She tracks volunteer availability in a WhatsApp group by scrolling through 200 messages.

Sandra doesn't do this because she lacks capability. She does it because nobody has given her anything better.

The competence gap is a myth

I've heard it from state bodies, from national bodies, from government grant assessors: "We need to keep it simple because the volunteers can't handle complex systems."

This is patronising. And it's factually wrong.

The average age of a club committee member in Australia is 44. That puts them squarely in the demographic that uses digital tools extensively at work. They're not retirees unfamiliar with computers. They're professionals in the middle of their careers.

A survey of club volunteers we've worked with found:

• 73% use cloud-based software (Google Workspace, Office 365, or similar) daily at work
• 61% use a CRM or database system at work
• 58% use project management tools at work
• 44% use financial software (Xero, MYOB, QuickBooks) at work

These are not people who need a training manual to use a web form. These are people who would look at most community sport technology and wonder why it's so behind what they use at work.

The real constraint: time, not skill

The problem isn't that volunteers can't use good tools. It's that they don't have time to fight bad ones.

When Sandra does club work at 9pm on a Tuesday, she has maybe 45 minutes before she needs to go to bed. In those 45 minutes, she needs to check whether the new member registrations have come through, follow up on three unpaid fees, reply to the council about the ground booking, and update the team sheet for Saturday.

If the system she's using takes five clicks to do something that should take one, she runs out of time. If it requires a 30-minute onboarding tutorial before she can start, she doesn't have 30 minutes. If it emails her a 12-step "getting started" guide, she closes the email and goes to bed.

This is the design constraint that most technology in the community sport space ignores. They design for a user who has time to learn. The user doesn't have time to learn. The user has 45 minutes at 9pm, twice a week, and if the system isn't obvious within the first 3 minutes, it's dead on arrival.

Stop building training programs

Here's a sentence I see in grant applications and strategic plans across the sport sector: "We will deliver training to club volunteers to build their digital capability."

This sounds reasonable. It is almost always a waste of money.

Not because training is inherently bad, but because it solves the wrong problem. If your volunteers need training to use a system, the system is the problem. Not the volunteers.

Think about the tools that have achieved mass adoption without training programs. Nobody trained you to use WhatsApp. Nobody trained you to use Google Maps. Nobody trained you to use internet banking. These tools work because they were designed so that a person with no prior experience can accomplish their goal within minutes.

That's the standard. If a club secretary can't figure out how to register a new member within 3 minutes of logging in for the first time, the software has failed. The answer is not a training webinar. The answer is better software.

I've seen state bodies spend $50,000 on "digital capability programs" for their clubs — workshops, webinars, PDF guides, helpdesk staff. The completion rate of the training? Around 15%. Not because volunteers are lazy. Because they're busy. They have 14 hours of club work to do and no spare time for a 2-hour workshop on a Thursday afternoon.

The $50,000 would have been better spent on buying the clubs tools that don't need training.

Design for 9pm on a Tuesday

If you're building technology for the community sport sector, here's your design brief: Sandra, 9pm Tuesday, 45 minutes, tired, simultaneously watching TV with her partner.

She needs to:

1. See what needs her attention (new registrations, overdue payments, messages)
2. Do the most important thing in under 5 minutes
3. See that it's done
4. Move to the next thing

If your system requires her to navigate through four menu levels to find the membership list, you've failed. If it requires her to export a CSV, open it in Excel, and re-import it, you've failed. If it sends her a notification that says "Action required" with no context about what action, you've failed.

The system should surface the work. Not hide it behind a navigation structure designed by someone who uses the system 8 hours a day.

The respect question

There's something deeper going on here, and it's worth naming.

When we design systems for volunteers that assume incompetence, we disrespect the people who hold community sport together. These are people who give thousands of hours of their time — hours they could spend with their families, on their hobbies, resting — to keep clubs running. They do it for free. They do it out of genuine care for their communities.

The least we can do is give them tools that respect their intelligence and their time.

When a state body sends a PDF form that has to be downloaded, printed, signed, scanned, and emailed back — that's disrespectful of the volunteer's time. When a system requires 20 clicks to do something that should take 3, that's disrespectful. When a training program assumes the volunteer can't figure out a web form without a 45-minute tutorial, that's disrespectful.

These people run businesses. They manage teams. They handle budgets. They use enterprise software. They are not confused by technology. They are underserved by it.

What this means in practice

For governing bodies: stop assuming your clubs can't handle good technology. They can. Give them tools that work the way their work tools work — cloud-based, real-time, mobile-friendly, obvious. Spend your training budget on better systems instead.

For technology providers: design for the 9pm-on-a-Tuesday user, not the 9am-on-a-Monday user. Your user is tired, distracted, and has 45 minutes. Every unnecessary click is a betrayal of their time.

For clubs: stop accepting bad tools because "that's what we've always used." Your committee members deserve better than spreadsheets and personal email. The tools exist. The capability is already on your committee. What's missing is the expectation that volunteer work should be supported by professional-grade systems.

Sandra doesn't need training. She needs software that's as good as what she uses at work. She needs 45 minutes to be enough. She needs her Tuesday nights back.

Give her that, and she'll keep volunteering. Make her fight bad systems on top of everything else, and she'll resign at the next AGM. She won't make a fuss. She'll just quietly stop.

And the club will lose someone who was never the problem.