Last month, I sat in a church basement with a tech volunteer who was struggling to set up a new AI tool for sermon transcription. His frustration wasn’t about the tool’s complexity — he knew the buttons to push. The problem was that nobody had told him why it mattered or given him any ownership over how it would be used. He muttered: “I just don’t get what this is for.”
That moment stuck with me. It wasn’t a skills gap. It was a purpose gap. And it’s the same pattern I’ve seen in product organizations far beyond church tech — teams that have been trained on the tools but not given genuine ownership over the outcomes those tools are supposed to produce.
Skills Without Agency Is Compliance, Not Capability
Here’s the thing about AI adoption in any team: skills are necessary but not sufficient. You can run workshops, build sandboxes, write documentation, and mandate usage — and still end up with a team that uses the tools only when required and abandons them the moment the pressure is off. What’s missing in those cases almost always isn’t knowledge. It’s agency.
Agency, in this context, means something specific: the sense of ownership over a problem, the authority to make decisions about how to address it, and the belief that those decisions will actually matter. Viktor Frankl’s work on meaning is useful here — he argued that humans don’t just need purpose handed to them; they need to discover it through engaged work. Teams that are handed AI tools without being given genuine problems to solve with those tools will never fully adopt them. They’ll comply, but they won’t own.
Ownership is what turns “I have to use this” into “I want to improve this.” And that distinction matters enormously for AI adoption velocity. Teams with high agency figure out use cases their managers never anticipated. Teams with low agency wait to be told what to do next.
Why Church Tech Teams Are a Clear Case Study
Faith-tech and church tech teams are a useful lens for this pattern because the stakes are highly visible and the volunteer culture makes authority structures explicit. When a volunteer doesn’t feel ownership, they leave. There’s no salary to keep them compliant. That makes the agency gap show up faster and more clearly than it does in corporate product organizations where people absorb the dysfunction because they’re getting paid to.
I’ve seen this play out repeatedly: a church tech leader implements an AI scheduling tool, trains the volunteers, and then watches usage drop to near zero within six weeks. Post-mortem almost always reveals the same thing — the volunteers were trained on the tool but not given any say in what problem it was solving or how success would be measured. They had skills. They had no stake.
The fix is deliberate but not complicated. When you introduce a new AI capability, don’t start with training. Start with a problem-ownership conversation: “Here’s the friction we’re experiencing. Here’s the outcome we’re trying to improve. I want you to figure out how this tool can address it — and I’m giving you the authority to make that call.” That framing changes everything about how the team engages with the technology.
Building Agency Into Your AI Adoption Process
The practical implication is that AI training needs to be sequenced differently than most organizations run it. The standard sequence is: introduce tool → train team → deploy. The agency-first sequence is: define problem → assign ownership → provide tool → let team define deployment. Those sequences produce dramatically different outcomes.
Small wins matter disproportionately in the early stages. When a volunteer or team member can point to a specific outcome they produced — “I set up the transcription workflow and it cut our follow-up time by an hour every week” — they develop a sense of stewardship over that outcome. They start to see themselves not as a user of the tool but as an owner of the process. That’s the transition that sustains AI adoption long after the initial training energy fades.
Your Turn: Apply This Today
Whether you lead a church tech team, a small product group, or a cross-functional product organization, here’s how to build agency into your AI adoption — starting this week:
- Identify one AI tool your team is underusing. Don’t ask why they’re not using it — ask whether they feel ownership over the problem it’s supposed to solve. If the answer is no, that’s your starting point.
- Pick one team member and assign genuine problem ownership. Not “use this tool” — “this friction point is yours to improve. This tool is available. Tell me in two weeks what you tried and what you learned.” The authority has to be real, not nominal.
- Define success in outcome terms, not usage terms. “Reduce admin time by 30% for small group leaders” is a real goal. “Everyone uses the tool by Friday” is compliance theater. Outcome-focused goals give people something worth owning.
- Celebrate a small win explicitly and tie it to purpose. When someone on the team produces a measurable improvement, name it publicly and connect it to the mission. “This saved the pastoral team four hours last week — that’s four hours they spent with people instead of on admin.” That framing builds the sense of stewardship that sustains adoption.
- Block 15 minutes this week to audit your own behavior as a leader. Are you delegating ownership or just delegating tasks? Ownership comes with authority to make decisions. If you’re telling people what to do with the tool rather than telling them what problem to solve with it, you’re creating compliance — not capability.
- Model agency yourself. Take one AI tool you’ve been handed or had recommended to you, identify a specific problem in your own workflow, and document what you tried and what you learned. Share that process with your team. Nothing builds a culture of agency faster than watching the leader practice it.
Agency in AI adoption connects directly to how you build and retain high-performing teams. The Stakeholder Management Mistake Most Product Leaders Make in Year One covers the related dynamic of alignment versus compliance in organizational settings. And AI Learning for Product Leaders: Stop Chasing Tools, Start Solving Problems addresses the same principle applied to learning investment.
Trying to build genuine AI capability — not just AI compliance — in your team or organization? I consult with product leaders and ministry innovators on building agency, aligning teams around mission-driven outcomes, and making AI adoption actually stick. Let’s talk.