The Schedule Change That Came From a Two-Year-Old Side Project

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.