Blog

I assumed a three-person pod augmented with the best available agents could ship reliable product increments without a fourth set of eyes. The assumption came from watching other small teams move fast in enterprise tools and ministry platforms. In practice the pod released a curriculum update for volunteer leaders that carried mismatched age-group tags across print and digital versions. The mismatch surfaced only after hundreds of churches had already printed materials for the quarter. The cost showed up in support volume, lost trust with volunteer coordinators, and two weeks of emergency fixes that pulled senior engineers off roadmap work.

That experience exposed the real limit. Smaller teams do not automatically gain leverage from AI by shrinking headcount. They still carry coordination work that does not disappear when routine tasks are automated. Charlie Munger’s latticework of mental models makes the pattern visible. One model shows incentive misalignment: the pod optimizes for output velocity while verification sits outside any single person’s measured goals. Another model tracks second-order effects: when routine coding and drafting shrink, senior contributors absorb more context-switching and cross-checks that used to be distributed.

The latticework also surfaces the model of scale. Coordination load does not track lines of code or tokens processed. It tracks the number of distinct decision points that must stay consistent across people, agents, and downstream users. Treating verification as optional overhead ignores that model.

The model that treats verification as overhead

Most pods describe their AI setup as removing repetitive checks. The agents draft, the humans review once, and the release happens. This framing collapses verification into a single step rather than a distributed property of the system. Munger’s approach forces the opposite view: verification is an ongoing cost that must be assigned explicitly or it migrates to the most senior person on the team.

In one observed case the pod used an agent to generate volunteer lesson outlines from existing sermon notes. The agent handled tone and length well. It did not maintain consistent scripture references across the three age bands the product served. The single human review caught obvious mismatches but missed the pattern because the reviewer had already internalized the source material. The error only appeared when a children’s director printed the materials and found the middle-school version referencing a passage the preschool version omitted.

The misread here is simple. The team modeled verification as a final gate rather than a persistent cross-check distributed across roles. Once that model is corrected, the fourth set of eyes becomes a deliberate assignment instead of an assumed safety net.

How senior ICs actually spend their time once routine work disappears

After agents absorb drafting and basic QA, the remaining work for experienced contributors shifts toward reconciliation. They reconcile conflicting outputs from multiple agents. They reconcile the product’s data model with the constraints of print-first users who cannot receive updates after distribution. They reconcile the pace of one volunteer’s planning cycle with the cadence the platform now pushes.

This shift is rarely logged as coordination time. It appears as individual deep work. In reality the senior IC is performing the latticework manually: holding the mental models of user constraints, technical limits, and agent behavior in tension at once. When that work stays invisible, the pod slowly loses capacity for new feature development because the experienced people are fully occupied keeping existing flows coherent.

The hidden coordination layer that still scales with headcount

Even at three people the coordination surface grows with each new agent or data source added. Each agent introduces its own context window and failure modes. Each new data source requires someone to decide which version becomes authoritative when they diverge. The surface does not shrink when headcount is low; it simply concentrates on fewer shoulders.

One ministry platform team added a scheduling agent to handle volunteer reminders. The agent needed access to the same curriculum metadata the human designers used. No one owned the mapping between the agent’s reminder logic and the print deadline the volunteer actually followed. The result was reminders sent after the print window had closed. The fix required a human to insert a manual gate that the original three-person pod had assumed the agent would manage. The gate still exists because the coordination rule was never assigned to a specific owner.

Your Turn: Apply This Today

• Map every recurring handoff in your current pod’s workflow on a single shared document, including steps currently handled by agents, and mark which person or role owns consistency for each one.
• Pick the three handoffs that have produced the most recent defects or rework and assign an explicit owner who is not the same person doing the originating work.
• Schedule a 30-minute weekly review where the owner reports only on whether the assigned consistency rule held, without discussing new features.
• Remove one agent-driven step that currently lacks an assigned human verifier and replace it with a manual checkpoint for the next two releases to measure the actual time cost.
• Document the second-order effect of each agent you rely on by writing one paragraph on what breaks when that agent’s output diverges from the rest of the system.
• Identify the senior IC who spends the largest share of time on reconciliation and surface that time in the next planning session as coordination load rather than individual capacity.

The same coordination visibility problem appears in different forms across the posts on context windows that close only with a real coordinator and permission gates that keep agents from running schedules. Both show how unassigned overhead eventually surfaces as lost time or broken trust.

I consult with product leaders building AI-augmented tools for ministry on coordination overhead, verification models, and small-team scaling. Let’s talk.

The “master voice document” framework pushed in most product playbooks, from requirements templates popularized by product leaders like Marty Cagan to the Notion template libraries that circulate in every ministry tech Slack, collapses once a reorg changes who actually holds approval power. The advice treats the file as a finished artifact that new teams inherit and apply. In practice the file sits untouched while the children’s ministry volunteer still prints the wrong lesson plan because the instructions never recorded the exact permission shift that happened in the last budget meeting.

This approach assumes clarity travels through publication. It does not. The file compounds confusion instead of value because no one returns to it after the handoff that actually mattered.

The result is a common misread: teams believe a persistent file earns its keep by surviving the initial write. In reality the file only stays useful when every real-world change gets tested against the same three filters John Wesley used for his own movement. Do no harm. Do good. Stay in love with God. Applied to a markdown file, these become questions about whether an instruction creates confusion for the next person who must act, whether it improves the outcome for the end user, and whether it keeps the work aligned with the actual mission rather than the last org chart.

Write the first version from a single observed failure

The first version of any persistent file should come from one concrete breakdown you watched happen, not from a general desire to document process. At one children’s curriculum ministry, a volunteer finished a 45-minute setup only to realize the lesson file assumed the church had already moved to the new curriculum platform. The failure was not the platform itself. It was the missing note that the transition required a one-time override from the children’s director before any volunteer could print.

That single observation became the seed paragraph in the file. Everything else followed from it. The paragraph described the exact email chain, the permission that was missing, and the two-minute fix that would have prevented the delay. No other history entered at this stage.

Starting here keeps the file short enough that the next person actually reads it. Starting from a template or a previous version bloats the document with rules that never caused a real problem in your context.

Force the file through the three-rule filter after each change

After every handoff the file must pass through the same three questions. First, does this instruction create any confusion that could harm the person who has to act next? Second, does it actively improve the outcome for the volunteer or the family using the resource? Third, does it keep the decision tied to the mission rather than to whoever currently holds the title?

In one reorg the curriculum team added a new review step that required the senior pastor to sign off on every children’s lesson. The file recorded the step. Then the filter removed it. The step created harm by slowing release by ten days. It did not improve the lesson quality. It only protected a title. The paragraph stayed out.

Running every edit through these questions turns the file into a living record of what actually survived contact with real authority. Without the filter the file slowly fills with the preferences of the last person who held power.

Delete anything that did not affect a real permission gate

Most voice files accumulate paragraphs that describe tone or audience but never decided who could release the next version. Those paragraphs go. If a sentence never changed who had to approve or who could override, it did not earn its place in the file.

One ministry kept a long section on “warm and accessible language for families.” The section never altered a single permission gate. It stayed decorative. After the third reorg the section disappeared. In its place the file now holds the one sentence that actually mattered: the children’s director alone can approve a print override when the platform update lags.

Deletion keeps the file short enough to matter during the next crisis. Retention of unused language turns the file into another ignored archive.

Your Turn: Apply This Today

• Identify the single handoff you observed in the last four weeks where verbal instructions caused a delay and write the exact failure into a new or existing markdown file before Friday.
• Run every existing paragraph in that file through the three questions this week and delete any line that never changed a permission.
• After the next team meeting, add one new paragraph that records the actual override or approval that occurred and note who held the gate.
• Schedule thirty minutes next Monday to test whether the updated file prevents the same failure for the person who will use it next.
• Remove any section that describes general tone or audience unless it directly names who must approve when that tone conflicts with a new requirement.
• Share the revised file with the one person who will inherit the next reorg and ask them to mark the first sentence that would have confused them.

The same discipline that kept one voice file intact through three ministry changes also shows up in how we track real retention for volunteer tools and how we decide which AI instructions survive contact with actual users.

I consult with ministry product leaders and faith-tech PMs on building persistent documentation systems and applying mission filters to AI instructions. Let’s talk.

Most teams racing to adopt AI for faster code generation are optimizing the part of the process that least determines whether the final product serves its intended users. The bottleneck was never raw output speed. It sits in the handful of inputs that still require a human to score before any generated work can be reviewed.

Teresa Torres built continuous discovery around the idea that product teams must keep live contact with the opportunity space rather than batching assumptions into long development cycles. When AI multiplies the volume of code or content produced, the same principle applies but inverted: the inputs themselves must be locked and validated first. Without that step, teams simply generate more of what they already misunderstand.

This pattern shows up in ministry tooling whenever an engineering group adds an LLM step to an existing workflow. The volume of pull requests rises. The time from ticket to merge drops on paper. Yet the handoff to content reviewers or volunteer testers still stalls on the same three questions that existed before the model was introduced.

Identify the three inputs that still need human judgment

The first input is the problem statement framed as a user outcome. In a curriculum tool, this might be the exact constraint a volunteer faces when preparing a lesson in seven minutes on a phone. AI can expand that statement into code, but only a person who has watched the volunteer actually work can confirm the outcome is stated correctly.

The second input is the definition of done for any theological or pastoral alignment check. A generated component that handles scripture references must still pass a human filter on whether the references respect the intended teaching emphasis. Torres would call this an explicit opportunity, not a solution detail. The filter cannot be automated without first freezing the criteria in writing.

The third input is the edge-case description for the least technical user. Ministry products routinely break when a user lacks admin rights, reliable internet, or comfort with digital forms. These descriptions must be written by someone who has observed real failure modes, then locked before generation begins.

Once these three inputs are captured and signed off, generation can proceed at any speed. The human scoring step happens once, upstream, rather than repeatedly during review.

Shift review effort to automated verification on those frozen inputs

With the inputs fixed, automated checks can run against them instead of against the generated output. A simple script can confirm that every new component references the approved outcome statement. Another can flag any code path that touches scripture data without the pre-approved alignment criteria attached.

The remaining human review then narrows to two questions only: does the output still satisfy the frozen inputs, and has anything changed in the live user context since the inputs were locked? Both questions are cheaper to answer than re-evaluating the entire feature from scratch.

Teams that adopt this pattern stop treating every PR as an occasion for fresh discovery. Discovery work moves earlier and happens less often, which is exactly what Torres observed in high-performing product groups.

Measure time saved at the handoff point, not at generation

Generation time is easy to instrument and therefore tempting to optimize. The real constraint appears at the moment a reviewer or ministry partner first sees the work. That handoff point is where accumulated misunderstandings surface.

One team building volunteer scheduling features tracked the interval between PR creation and the first external reviewer comment. After freezing their three inputs, the interval dropped by more than half even though raw generation time stayed roughly the same. The reviewers no longer had to reconstruct the original intent; they only had to verify it still held.

The metric forces the team to keep the frozen inputs visible and current. When the inputs drift, the handoff interval lengthens again, giving an early signal before users ever see the product.

Your Turn: Apply This Today

• Pick the engineering workflow that produces the most reviewed artifacts this month, such as new components for a children’s ministry scheduling tool.
• Write the three frozen inputs for that workflow in a shared document before the next ticket is started.
• Add an automated check in the repository that fails any PR missing a reference to the frozen problem statement.
• Run the next PR through the checkpoint and record the exact time from merge request to first external reviewer reply.
• Compare that interval against the average from the previous three PRs in the same workflow.
• Adjust one of the three inputs based on what the comparison reveals and repeat the checkpoint on the following PR.

Two earlier posts on the blog explored how continuous discovery habits transfer to ministry product teams and why opportunity framing beats feature velocity when the users are volunteers. I consult with product leaders building ministry tools on continuous discovery practices, frozen-input checkpoints, and measuring handoff time in AI-assisted workflows. Let’s talk.