Blog

I stood at the counter rinsing plastic cups in the church kitchen when the children’s director handed me her phone. The screen showed a simple agent interface she had built on a borrowed laptop two years before. Every Monday morning it still pulled volunteer names, checked availability from the shared sheet, and output a draft schedule that landed in the right inboxes without anyone asking.

Three different staff members had held her role since then. Each one inherited the same output on the same day. The agent had outlasted the org chart because it solved the exact pain of the person who first needed it, not the plan that came later.

John Wesley’s three simple rules give the clearest lens for why some side work keeps running when titles and teams shift. Do no harm. Do good. Stay in love with God. Applied to product work, they become a daily filter: build nothing that creates new work for the people already stretched thin, build only what removes friction for the actual user, and keep the artifact connected to the real ministry task rather than the latest roadmap slide.

The side project that survived three reorgs

The children’s director had started with one narrow problem. Volunteer scheduling ate her Monday morning and often spilled into Tuesday. She wrote a small script that read the existing spreadsheet and suggested names based on past availability and role fit. No new database. No new login. Just a Monday email that arrived ready to review.

When the first reorg moved her to a different campus, the script kept sending the emails from the same shared account. The new director found it useful and left it alone. The second reorg brought a different staff person who tried to replace it with a commercial tool. The commercial tool required weekly data entry that nobody had time for, so the old script quietly resumed after two weeks. The third reorg simply ignored it. The output never stopped.

I have seen the same pattern with curriculum tools. A volunteer-facing checklist built for one church’s print workflow continued to generate usable pages long after the original team had moved on. The artifact stayed because it never asked the next person to learn a new system. It only asked them to open the same folder on Monday.

Staying useful when the plan changes

Wesley’s first rule, do no harm, shows up in product decisions as a refusal to add steps. The agent never required the volunteer coordinator to maintain a second data source. It read what already existed. That single constraint kept it from becoming another system the next staff member had to fight.

The second rule, do good, forced the scope to stay narrow. The agent did one job well. It did not attempt to predict absences or manage background checks. Those tasks stayed with the human because the human already had context the script could not hold. The narrowness made the output reliable even when the surrounding process changed.

The third rule, stay in love with God, translates in this setting to keeping the work tied to the actual person doing ministry rather than the current leadership priority. The script existed because one director hated Monday mornings. Every later user inherited that same relief. The artifact did not need re-selling because it never depended on the current vision statement.

The simple rule that turns emergence into reliable output

Career paths in product rarely follow the org chart. They follow the trail of small artifacts that keep solving the same concrete problem for the people closest to the work. The children’s director did not set out to build a lasting system. She set out to free her Monday. The discipline was to keep the artifact pointed at that Monday problem even when her title changed.

I watched a similar pattern with a sermon prep checklist that started as a one-page printout for new preachers. Over four years and three different ministry leads, the checklist remained the default handoff document because it still answered the exact question a new preacher asked on their first week. The document never grew into a platform. It stayed one page because one page removed the real bottleneck.

The same discipline appears in larger tools. A volunteer completion tracker built for children’s ministry never tried to become the full church management system. It tracked only the single metric that mattered to the people printing lessons on Thursday night. Because it stayed narrow, it survived leadership changes that killed broader platforms.

Your Turn: Apply This Today

• Pick the one recurring task that lands on your desk every week and write down the exact output the person after you will need.
• Build the smallest possible script or document that produces that output from data you already have, with no new logins or fields.
• Test it once this week by handing the output to the actual next user and remove any step that creates work for them.
• Store the artifact in the same place the current process already lives so the next person finds it without searching.
• Run it again next Monday exactly as written and note only the one change that would make the output more useful, not more complete.
• Leave the artifact untouched for two full weeks and confirm it still produces the same result without your involvement.

The pattern in “The Agent That Kept Running the Schedule While No One Was Watching” and “The Voice File That Actually Survived Three Ministry Reorgs” shows the same outcome when the daily filter stays on usefulness rather than visibility.

I consult with product leaders and ministry technology teams on building narrow persistent tools, surviving reorgs without losing output, and applying daily usefulness disciplines to side work. Let’s talk.

Central recruiting functions produce the weakest matches for specialized ministry roles because they optimize against a generic description instead of the live constraints of the work itself. The people who actually run the systems already hold the models needed to see what the role requires; moving the mapping step upstream strips those models out.

This separation is the error that turns talent density into a spreadsheet exercise. Charlie Munger’s latticework of mental models requires pulling from multiple disciplines at once—systems dynamics, incentive design, and the specific domain of volunteer coordination—to even identify the real variables. A central team can only apply the models it possesses, which rarely include the daily friction of a seven-minute volunteer window or the print-first constraints of curriculum delivery.

The talent map that stayed in the spreadsheet

A curriculum platform serving children’s ministry volunteers once received a central list of recommended hires for a new support role. The list prioritized candidates with enterprise software experience and advanced degrees in education. None of those candidates understood the difference between a volunteer who prints the lesson on Sunday night and one who needs the entire script on a single page.

The mismatch surfaced only after the new hire began work. The actual team already knew that completion rate, not feature adoption, determined whether volunteers returned the next week. The spreadsheet had no column for that metric because the people building the map lacked the domain model.

When the mapping step moves inside the using team, the latticework appears naturally. The volunteer coordinator brings the incentive model, the product person brings the retention signal, and the engineer brings the systems constraint. Together they surface requirements that never appear in a job requisition written two layers removed from the work.

Direct pursuit beats posted roles in volunteer systems

Posted roles assume that interested people will self-identify and self-filter. In ministry contexts the opposite holds: the people who would perform best are already occupied and rarely browse job boards. They respond only to a direct ask that names the exact friction they already solve in their current setting.

The same pattern appears in product teams building for global discipleship tools. When a new quality role was posted centrally, applications came from generalist testers. When the existing pod instead listed three specific people they had observed handling edge cases in user feedback, two of those three engaged in direct conversation. One joined within three weeks. The difference was not compensation; it was that the ask referenced the actual pattern they already demonstrated.

Central posting severs this signal. It forces the candidate to translate their experience into the language of the requisition rather than allowing the team to translate the need into the candidate’s existing language. The latticework collapses when one node is removed from the conversation.

Why the fourth person on the pod still matters more than the model

Small teams that ship consistently develop an internal map of missing perspectives. A three-person group handling volunteer curriculum updates could articulate their throughput problem but could not name the coordination gap until a fourth set of eyes joined and simply asked how decisions moved between print production and digital delivery.

The model that predicted the need for that fourth person lived only inside the daily handoff rhythm. A central recruiter working from headcount targets had modeled the role as “content operations specialist” and missed the coordination variable entirely. The team that already ran the rhythm could see the variable because they experienced its cost every release cycle.

High-talent-density hiring therefore depends on keeping the mapping step local. The latticework forms only when the people who will absorb the new person’s output participate in defining what that output must actually change.

Your Turn: Apply This Today

• Open your current team roster and list the three people outside the team whose work you already observe solving the exact friction your group hits weekly.
• Write one sentence for each person that names the specific pattern you have seen them handle, without referencing any open role.
• Send a direct message or email to the first of those three people this week that references only that pattern and asks whether they would discuss how they approach it.
• Repeat the same message for the second person within five days, adjusting only the observed pattern to fit their context.
• Block two hours next week to meet with whichever of the three responds, using the time solely to understand their current constraints rather than to pitch a position.
• Document the three mental models that surface in those conversations and bring that one-page note to your next internal planning meeting instead of any requisition draft.

The Three-Person Pod That Still Needed a Fourth Set of Eyes traces how small teams discover their actual gaps only after they begin shipping together. The Ministry PM Who Handed Off Captain Duties Without the Handoff Log shows the same principle applied to knowledge that never transfers through posted processes.

I consult with ministry product teams on talent mapping inside using teams, direct sourcing for specialized volunteer roles, and building team structures that keep the latticework local. Let’s talk.

The “replace SaaS with open-weight models to cut your inference spend” framework from the 2025 AI economics reports names token pricing as the bottleneck that every team can attack directly. It assumes the move to self-hosted inference delivers savings once the GPU cluster is running and the prompts are routed locally. For teams shipping ministry tools, the calculation never reaches that stage because the data flows carry consent rules that no public checkpoint satisfies.

Ministry products sit at the intersection of volunteer hours, church membership rolls, and pastoral notes that require explicit, revocable permission from the originating congregation. An open model pulled from a public model hub cannot inherit those constraints without an additional governance layer that the original SaaS vendor already provided under contract. The framework therefore measures the wrong unit: it counts tokens while the actual cost accrues in delayed approvals, manual redaction steps, and the eventual rollback when a volunteer coordinator discovers their lesson plan was used to train an external checkpoint.

This is the foundational misread that causes product teams to chase model hosting instead of mapping the actual permission holder in the workflow. The result is an inference bill that lands six months late, after the engineering hours, compliance review, and quiet reversion to the original vendor have already been spent.

Jensen Huang’s sovereign AI argument supplies the corrective lens. Huang located the value of sovereign compute in cases where data ownership or regulatory access, not raw price per token, determined whether the system could operate at all. Ministry teams face an analogous boundary: the data is not national security material, yet it is governed by local church polity and volunteer agreements that external providers cannot sign on behalf of the congregation.

Why the SaaS replacement math breaks at the permission boundary

One children’s curriculum platform processes lesson plans that a volunteer creates on Tuesday night and expects to remain visible only to her church’s approved users. When the team tested an open Llama derivative for summarization, the first compliance checkpoint required a new data-processing agreement that the volunteer coordinator had no authority to sign. The project paused for nine weeks while three separate church elders reviewed the model card.

That delay is invisible to a token-cost model. The original SaaS vendor had already absorbed the liability through its master service agreement with the denomination. Self-hosting transferred the liability back to the local church without transferring the legal staff needed to carry it.

The same pattern appeared at scale on a large sermon-manuscript platform. Pastors uploading sermon manuscripts wanted the AI assistant to cite only their own prior messages. The open model could not be constrained to that corpus without an on-premise vector store that the volunteer upload workflow never contemplated. The cost comparison therefore compared list prices while ignoring the new storage tier, the new access-control service, and the new audit log that the permission boundary demanded.

The hidden cost of keeping the coordinator in the loop

Every ministry workflow that touches personal data still routes through a human coordinator who holds the actual consent. When an agent summarizes prayer requests, that coordinator must review the output before it reaches the small-group leader. The review step adds latency that the inference call itself never captured in its pricing sheet.

Teams that moved to sovereign instances discovered the coordinator’s time became the new scarce resource. One mid-sized church network reported that the AI summary saved 14 minutes of drafting but added 22 minutes of coordinator review because the model occasionally surfaced names the original request had left anonymous. The net effect was negative, yet the inference bill showed only the cheaper token rate.

The permission holder is rarely the person who pays the cloud invoice. In volunteer-driven products the permission holder is the person whose name appears on the consent form, and that person has no line item in the engineering budget. Sovereign compute does not remove the need for that review; it merely moves the cost from a vendor line to an internal labor line that never appears in the original ROI model.

When sovereign compute actually changes the ministry outcome

Sovereign setups delivered value only when the constraint was data residency required by denominational policy rather than cost. One network required that all counseling notes remain inside servers physically located in their country because national privacy law treated pastoral conversations as protected health information. In that case the higher per-token cost was irrelevant; the system could not have run on any foreign SaaS provider without violating the polity document.

The same logic applied to a children’s curriculum product that stored parent contact data under a promise never to share it with third-party processors. The team stood up a small sovereign instance solely to satisfy the promise, then measured retention of volunteer users rather than token spend. Retention rose because the privacy commitment could be stated without qualification. The inference bill was higher, yet the product metric that actually moved was the one tied to the original constraint.

Outside those two conditions, the move to sovereign compute simply replaced one set of hidden coordination costs with another. Most ministry teams optimizing for token price were therefore solving a problem that did not exist at the scale or sensitivity level their data actually required.

Your Turn: Apply This Today

• Pull the last 30 days of agent logs for the workflow that summarizes volunteer-submitted curriculum and list every field that contains a name, church identifier, or prayer request.
• Identify the single person who must sign the consent form for that data category and schedule a 20-minute call with them this week to confirm the current sharing boundary.
• Export the actual inference line item from your cloud bill for that workflow and add a second column that estimates coordinator review minutes at their loaded hourly rate.
• Run one controlled test where the same prompts route through the current SaaS provider versus a small sovereign instance and record both token cost and end-to-end cycle time including human review.
• Document the exact policy clause that would be violated if the data left the current boundary, then note whether that clause changes under either hosting option.
• Present the combined cost and policy table to the product owner before the next sprint planning so the decision incorporates the permission holder rather than the token price alone.

The Agent That Kept Running the Schedule While No One Was Watching and Faster Code Does Not Move the Real Ministry Bottleneck both examined similar gaps between what the logs recorded and what the ministry actually required.

I consult with ministry product leaders on agent workflow audits, permission boundary mapping, and sovereign model decisions. Let’s talk.