Most volunteer coordinator roles at ministry-tech organizations still get filled through standard inbound application flows. The number looks like proof that the system works. It is actually proof that the system only surfaces the people already looking, while the recurring decisions about curriculum scheduling, follow-up loops, and edge-case support stay locked inside the heads of two or three overcommitted staff members who never appear on any job post.
The gap is not a recruiting problem. It is a mapping problem. Teams keep treating the open role as the unit of work instead of tracing the actual decisions that must be made every week. Without that trace, inbound volume becomes a comfort metric rather than a signal of whether the right people are connected to the right choices.
Charlie Munger’s latticework of mental models makes the mistake visible. Munger argued that real understanding comes from holding multiple models at once so none of them can dominate. In talent work the dominant model is still the job requisition. The missing models are decision ownership, recurrence frequency, and relationship durability. When those sit outside the map, the funnel keeps producing candidates while the actual ministry bottlenecks remain untouched.
Mapping the actual decision owners instead of the job posts
Most product teams still begin with the posted role. They list responsibilities, then wait for applications. In practice the real decisions about children’s ministry follow-up or sermon resource approvals are already being made by a volunteer who has never applied for anything and a part-time staff member who reports to no one in the org chart. The posted role becomes a container that never gets filled with those decisions.
I watched one mid-size curriculum platform try to hire a volunteer coordinator after their print-first user base grew past 180,000 monthly active users. The job description mentioned “managing volunteer schedules.” It did not mention the Tuesday morning decision about which volunteer gets the new lesson plan when the original volunteer’s child is sick. That decision stayed with the children’s pastor who was already running three other portfolios. Six months later the new coordinator was still routing every exception back to the same pastor.
The lattice requires naming the owner of each recurring decision first, then asking which existing relationships already touch that owner. The job post comes later, if it comes at all.
Why direct outreach beats the application stack for faith-tech roles
Inbound stacks reward people who are between roles or actively scanning LinkedIn. Ministry decisions, especially the ones that touch volunteers, are usually held by people already inside the work. They do not apply because they do not see themselves as applicants. They respond when someone they trust asks a specific question about a specific decision.
One team I worked with replaced their coordinator posting with a six-week exercise of listing every recurring choice that affected volunteer completion rates. They then reached out to twelve people already performing fragments of those choices. Four of the twelve agreed to a defined scope without ever seeing a job description. Retention after six months was higher than the previous two hires who had come through the stack. The difference was not character. It was that the outreach started from the decision map rather than the requisition.
The application stack still has a place for senior product roles that require rare technical judgment. For roles that sit at the intersection of product and volunteer systems, the stack mostly filters for availability instead of proximity to the actual work.
Building the lattice that survives staff turnover
Turnover is the test. When the children’s pastor leaves or the volunteer coordinator moves cities, the decisions do not disappear. They simply lose their current owner. A living talent map records the decision, the current owner, the backup relationship, and the last time the handoff was practiced. Without that record, every departure restarts the search from the job post rather than from the work.
I have seen three consecutive coordinators cycle through the same platform because each new person inherited only the title and the inbox. The actual Tuesday morning exception handling never transferred. After the third departure the team finally built a simple shared document that listed the twelve recurring decisions, the two people who had touched each one in the prior quarter, and the last date the handoff conversation happened. The next coordinator started with that document instead of the job description. The role stabilized.
The lattice is only useful if it is updated on the same cadence as the decisions themselves. Quarterly updates are too slow. Monthly checks against the actual exception log keep the map honest.
Your Turn: Apply This Today
- List the three most frequent ministry decisions your product or volunteer system handled last month and name the single person who currently owns each one.
- For each decision, add the name of the person who performed the same task when the owner was out last quarter.
- Schedule one 20-minute conversation this week with the backup person to confirm they can still execute the decision without the primary owner present.
- Write the decision, owner, and backup into a shared document that is not inside any HR system or job requisition.
- Review the document with your immediate team in the next staff meeting and ask which of the three decisions has changed owner since the last review.
- Repeat the entire list for the next three decisions that will appear in the coming quarter rather than the ones already visible.
The same pattern shows up in the work described in “The Agent That Kept Running the Schedule While No One Was Watching” and “The Voice File That Actually Survived Three Ministry Reorgs.” Both posts trace how small, recurring decisions outlast the people who first held them when the connections are made explicit.
I consult with product leaders and ministry technology teams on decision mapping, volunteer system design, and talent lattice maintenance. Let’s talk.
Discover more from Dr. Joshua Read
Subscribe to get the latest posts sent to your email.

