Why integration stalls (and how to start anyway)

Maggie sat in her studio with the microphone on, three months into what was supposed to be the integration project, and realized she was about to make the scatter field worse.

The episode she was recording was titled A New Angle on the Framework. She had outlined it over the weekend. It was good material — a fresh way of articulating the signature framework, pulling from a conversation she had had at a conference in March, plus something she had been chewing on from a book she had recently finished. It would be a good episode. It would also be, by her own foundation team's count, the forty-ninth slightly-different articulation of the framework she had put into the public record in thirty-two years. The forty-eighth had been last week's Substack post.

The foundation project had been alive for three months. It had produced a first-pass schema. It had produced a working group. It had produced four meetings at which her team had tried to get her to commit to a canonical version of the framework, and three subsequent meetings at which she had not committed, and one meeting last week at which she had said, Let's come back to this. I need more time with it.

She was back in the studio because more time with it had turned into let me keep working on new material while the team does other things, which had turned into the podcast schedule is what it is, which had turned into this: the microphone on, the outline ready, another articulation about to be recorded, and the canonical version still undesignated.

She looked at the microphone for a while. Then she looked at the outline. Then she did something she had not done in twelve years.

She closed the session. She did not record.

She texted her foundation team: I think I am the stall. Can we meet tomorrow?

This chapter is for everyone in the seat Maggie was in that afternoon.

It is the permission chapter, and it is the chapter I have been watching land the hardest, in every engagement I have been part of, because it is the chapter at which the leader discovers that the fragmentation they have been diagnosing externally has been, in one specific way, a structure they have been personally defending.

The last three chapters of Part III have described what integration is (Chapter 6), how to begin minting the schema (Chapter 7), and how to design carry-forward (Chapter 8). You now know, in principle, what is to be done.

This chapter is about why you will almost certainly not do it — or why, if you begin, you will almost certainly stall — and what to do when the stall happens, because it is not the same as failure, and it is the second most common reason I watch otherwise-committed organizations fall back to the fragmented state.

I want to name the four stall patterns I see most often. Each of them is a way of continuing to believe that you are doing integration work while in fact doing none. Each of them is present, right now, in some form, in almost every organization that has committed to a foundation project. And each of them has a specific counter-move.

The four are:

1. The politics of canonicalization. You cannot get the working group to commit to a canonical version.
2. The fear of locking in. You know what the canonical version should be, but you are afraid to commit to it.
3. Tool obsession. You have redirected the integration project into an evaluation of platforms and vendors.
4. Perfectionism. The foundation is nine months in and still not live because the working group is still refining definitions.

I will walk each, and then give you a sixty-day starting plan explicitly designed to be small enough to finish even if three of the four stalls are active in your organization.

Stall one: the politics of canonicalization

The first stall is the one Maggie was just in.

Canonical designation — Move 4 from Chapter 7 — is the move at which the organization has to choose, for each entity, which version is authoritative. The choice is a political act, because it redistributes influence among the senior people who authored the competing versions. The working group can spend months debating which version should be canonical without reaching agreement, and the debate feels productive because it surfaces real substance, but no shared foundation gets built, because a foundation cannot be built on an undesignated framework.

The pattern has a specific tell. The working group produces memos and position papers. The memos circulate, get commented on, get revised. The leader commissions a synthesis document to resolve the debate. The synthesis document itself becomes the next thing to be debated. Six months pass. Seven memos have been produced. No canonical version has been designated. the foundation has no framework entity to populate.

For Maggie, this stall took the specific shape of a leader who could not commit against her own prior work. Each version of the framework was hers. Retiring any of them felt like disavowing the version she had taught in 2009, or the revision she had made in 2017, or the articulation she had been trying out this year. None of the choices were clean. So she deferred.

For Wes's nonprofit, the equivalent is the program description debate — development wanted one version, programs wanted another, and neither team was willing to be the one to lose. For Joelle's church, it is the theology of formation debate between pastoral generations. For Elias's seminary, it is the faculty disagreement that exhausted the conference room in Chapter 7.

The counter-move for the politics of canonicalization is a discipline I have come to call time-boxed designation.

The working group is given a fixed window — usually three weeks — to produce a designated canonical version. The window closes on a specific date. If the working group does not produce a designation by that date, the leader designates one, and the working group's role shifts from deciding to formally responding to the leader's designation.

This sounds authoritarian. It is not. It is a structural move that acknowledges something the working group pretends not to know: debate has no natural terminus, and a canonical designation is not the output of a completed debate but the precondition for a working foundation. The leader's job is to make the terminus structural rather than conversational.

Every time I have watched time-boxed designation applied honestly, it has worked. The working group completes the debate inside the window approximately seventy percent of the time. The leader has to designate in the remaining thirty percent. In both cases, the foundation moves. In both cases, the working group discovers it would rather influence a designated version than continue arguing about undesignated ones.

Maggie's conversation with her foundation team the day after the closed-session moment in the studio was a conversation about time-boxing. They set a three-week window. At the end of the window, she had committed to a single canonical articulation of the signature framework. The three earlier articulations were archived as lineage. The forty-ninth podcast episode never got recorded — it became, instead, the first episode in which she announced the canonical version publicly. the foundation had its first entity.

Stall two: the fear of locking in

The second stall is the one Joelle lives in, and it is the one most common in pastoral and theological contexts.

The fear of locking in says: if we commit to a canonical version of the theology, we will lose the flexibility to hold the nuance that real pastoral work requires. It is the worry that the foundation will produce rigidity — that the canonical articulation will become a cudgel, that the pathway will become a tunnel, that the designation will foreclose the evolution the vocation requires.

The worry is not baseless. There are organizations that have over-canonicalized and produced rigidity. The worry is also, in practice, almost always a misdiagnosis, because the rigidity those organizations produced was not a consequence of canonical designation; it was a consequence of refusing to evolve the canonical version after designating it. The foundation, designed well, has explicit mechanisms for evolution — the status attribute of the framework (current / retired / in-revision), the lineage that tracks how articulations have changed, the decision log that records why a version changed. A well-designed foundation holds current canonical forms and the history of how they got to be canonical. It is, in that sense, more honest about the evolution than an undesignated scatter field, which hides evolution as drift.

For Joelle, the fear takes the specific shape of a pastoral worry: if I commit to canonical formation theology, I will not be able to meet the congregant where they are. She has spent fifteen years developing the ability to adapt her theology to the specific pastoral moment, and she is afraid that canonical designation will produce a one-size-fits-all theology that cannot flex.

This is a real concern, and the counter-move is specific. The foundation does not produce a single canonical articulation preached to every congregant in every situation. It produces a canonical articulation plus explicitly-scoped pastoral variants. The pastoral conversation with a twenty-year congregant about grief is not the same articulation as the catechesis delivered to a new member. Both are inside the canonical theology. The canonical version is the structural commitment about what the church teaches; the pastoral variants are the explicitly-designed applications of that commitment in different contexts. the foundation holds both, with the relationships between them explicit.

The same pattern holds for Wes (canonical donor messaging plus context-specific variants for different major donor profiles), for Maggie (canonical framework plus teaching-context variants for different audiences), and for Elias (canonical theological positions plus discipline-specific applications across the faculty).

Fear of locking in resolves, in practice, when the leader sees the plural-with-scope option from Chapter 7 as a genuine third option rather than as a compromise. The foundation can hold multiple canonical forms of the same entity, as long as the plurality is deliberate and the scope of each form is explicit. This is not the absence of designation. It is designation applied with appropriate structure.

When this lands, Joelle stops experiencing the foundation as a threat to pastoral nuance and starts experiencing it as the only thing that makes pastoral nuance inheritable across staff and succession. Without it, her pastoral nuance dies with her. With it, the next pastor inherits not just the canonical theology but the full set of pastoral variants the church has developed, with the contexts in which each variant applies.

Stall three: tool obsession

The third stall is the one Wes drifted into, nine months after the Dean meeting.

Tool obsession redirects the integration project into an evaluation of platforms. The foundation, conceptually, is a new layer underneath the tools — Chapter 6 was explicit about this — but the leader and the team, finding the conceptual work uncomfortable, quietly convert the project into a tool search. The working group spends its meetings evaluating vendors. The budget gets redirected to platform licenses. The deliverable becomes a tool selection rather than a foundation build.

The pattern has a specific tell. Meeting agendas feature vendor calls and demo reviews rather than schema refinement or canonical designation. The documents under review are RFP responses rather than definitional articulations. The expertise the project is acquiring is tool expertise — how to configure Salesforce, how to deploy a RAG pipeline, how to set up a headless CMS — rather than schema expertise. Twelve months in, the organization has adopted three new platforms and still does not have a foundation.

This is what Wes discovered in February of 2026 when I asked him to pull up Dean. The integration project was the dashboard, the AI tool, the connected inbox, and the CRM. All of them were surface tools. None of them contained the foundation.

The counter-move for tool obsession is a reversal I call schema-before-stack.

No platform decision is made until the organization has minted its schema. The working group is explicitly forbidden from evaluating vendors until Moves 1 through 4 of Chapter 7 have been completed for at least the top five entities. The reason is structural: without the schema, the vendor evaluation has no criteria. The organization ends up choosing the most impressive demo, which is by definition the platform optimized for generic cases rather than for this organization's actual intelligence.

Once the schema exists, vendor selection becomes straightforward. The schema tells you what the tools have to support. Some tools support the schema natively. Others do not. A short list emerges quickly. The decision is not a matter of vendor skill or sales pitch; it is a matter of whether the tool can hold the schema the organization has minted.

Wes's organization, nine weeks after the Chapter 6 meeting, paused the dashboard project, spent six weeks on schema work, and then resumed the tool conversation with the schema as the evaluation criterion. The dashboard the consultancy had built was kept — it is a useful surface — but it was rebuilt on top of the foundation rather than in place of it. The AI briefing tool was reconfigured to draw from the foundation. The CRM was reviewed against the schema, and a migration was planned for the following year.

Schema-before-stack is a discipline that sounds obvious and is almost never followed. Most organizations reverse the order because vendor conversations are frictionless and schema conversations are not. The friction is the signal that you are working on the right layer.

Stall four: perfectionism

The fourth stall is the one Elias's working group is currently in, nine months after Chapter 7.

Perfectionism is the stall in which the foundation project continues to produce refinements of definitions without ever going live. The working group has minted a version of the schema. The version is adequate. The version could go live. The working group keeps refining. Month ten adds an attribute to the framework entity. Month eleven restructures the relationship between frameworks and pathways. Month twelve introduces a sub-kind of decision that the group feels the schema was missing. the foundation still has no populated entries in production.

The pattern has a specific tell. The working group's Slack channel is active and the foundation itself is not. Deliverables are internal — schema revisions, governance protocols, style guides — and no external surface is yet drawing from the foundation in its live operations. The group is producing work. The organization is not yet running on the foundation.

For Elias, perfectionism takes the specific shape of the faculty's scholarly instinct. These are careful thinkers. They want to get the ontology right before committing it to the institution's operations. The instinct is honorable. The instinct, unchecked, ensures the foundation never ships.

The counter-move for perfectionism is a principle I borrow from software practice and apply, without apology, to foundation construction. It is version one is live, version two is better.

The schema is shipped, in a deliberately imperfect form, at a defined point — ideally the end of the first thirty days of the initial build. It goes into production. Surfaces draw from it. The working group's job, from that moment forward, is to maintain and evolve the schema in a live foundation rather than to perfect it in a conceptual one.

The move is structural rather than psychological. The working group does not get to continue refining in isolation. The foundation is live, and evolution happens in relationship to actual use — actual surfaces, actual queries, actual populated entities. The iteration becomes evidence-based rather than aesthetic.

This is the discipline that makes the four-week initial build tractable. The four weeks produce a foundation that is live and imperfect. The next four weeks, and the next, and every subsequent month, evolve the foundation in response to how it is actually being used. The organization is running on a foundation within a month. The working group continues to refine for years, because that is how live systems work, and the refinement is what the organization's continued coherence depends on.

Elias's working group needs to hear this, and the hearing is difficult, because scholarly instinct reads live and imperfect as carelessness. It is not carelessness. It is the specific discipline that lets the organization have a foundation at all. Perfect-and-conceptual is the foundation that never actually exists.

The stalls share one feature

I want to name what the four stalls have in common, because it is the thing the rest of this chapter depends on.

The stalls are all ways of avoiding commitment.

Canonical designation is a commitment against prior versions. Locking in is a commitment against future flexibility. Schema-first is a commitment against tool-first. Version one is live is a commitment against ongoing refinement.

Each stall is, at its core, the organization's refusal to commit — to a framework, to a designation, to a schema-before-stack sequence, to a live imperfect foundation. The foundation cannot be built without commitments. The stalls are the places the commitments get deferred, usually indefinitely, under the appearance of doing the work thoughtfully.

This is why Chapter 3's reframe matters structurally. Fragmentation is adaptive, not technical. Integration is not a matter of getting the right consultant; it is a matter of the organization becoming willing to make specific commitments it has been avoiding for years. The stalls are the moments those commitments show up and the organization tries, gently, to avoid them.

The counter-moves are all the same move in different shapes: commit, imperfectly, at a defined point in time, and let the foundation receive the commitment.

The sixty-day starting plan

The rest of this chapter is the starting plan.

I am giving you a sixty-day plan because the research on behavior change and organizational initiatives is clear: commitments at longer time horizons fail at higher rates. A one-year foundation plan stalls. A six-month foundation plan mostly stalls. A sixty-day plan, small enough to finish and large enough to build something that carries forward, succeeds at a rate that makes it worth specifying.

The sixty days are divided into two phases. Days one through thirty are the preparation phase — the minting, the scoping, the selection of what goes into the first residency. Days thirty-one through sixty are the initial build phase — the four-week residency for a movement leader, or the four-week domain build for a nonprofit or church or institution.

This is a commitment a small team can actually hold. It is also, in my experience, the smallest commitment that produces a foundation the organization can run on.

Days 1–7: first-pass schema (the Chapter 7 exercise)

Name six to twelve entity kinds. Draft a one-sentence definition for each. Name five to ten relationships. Identify the canonicals in dispute. This is the document Chapter 7 closed with. A thoughtful leader can draft it in an afternoon. The team can refine it in a week.

Days 8–14: identify the two or three carry-forward carriers

The Chapter 8 exercise. Name the two or three senior people whose departure would produce a multi-year recovery. For each, name the top five pieces of intelligence they are currently sole carrier of. These become the first people whose intelligence gets poured into the foundation during the residency.

Days 15–21: canonical designation round one

Take the top three disputed canonicals from the first-pass schema. Time-box the designation to this week. Convene a small working group — no more than five people. At the end of the week, three canonical versions have been designated. Some of them will be imperfect. That is the point.

Days 22–30: scope the residency or domain build

For a movement leader: scope the four-week residency. What content gets ingested? What voice articulation happens? What pathways get drafted? What single course is produced?

For a nonprofit, church, or institution: choose one domain — governance, training, donor and fundraising, or content — and scope the four-week system build for that domain only. The other domains will be addressed in subsequent four-week builds. The discipline is to walk them one domain at a time rather than try to build the whole institution at once.

Days 31–60: the residency or domain build

Four weeks. A defined scope. A small team. An explicit end state: core content ingested into the foundation, the voice articulated, at least one course or key surface produced, pathways laid out for the domain.

At the end of day 60, the foundation is live for the scoped domain. Imperfect. Functional. Carrying forward from that point onward.

Day 61 begins the next phase — the next domain, or the first iteration cycle on the shipped domain, or the capture of the next carry-forward carrier's intelligence. Whatever it is, it is the evolution of a live foundation, not the beginning of a conceptual one.

The permission

I want to end this chapter with a permission, because the permission is the thing the reader most needs at this point in the book.

You are not going to get the first thirty days right. The schema will be imperfect. The canonicals you designate will, in some cases, need to be revised within a year. The entities will have attributes that are redundant and attributes that are missing. The residency or the domain build will ship a foundation you will, in month four, wish you had structured differently.

This is fine.

The foundation is a live system. Its imperfection in month two is not evidence that you have done the work badly. It is evidence that you are doing the work at all. Perfect foundations do not exist. Good foundations evolve, in response to use, over years.

The alternative — waiting to begin until the schema is right, the canonicals are resolved, the platform is chosen, the working group has consensus — is not a more careful version of the integration project. It is one of the four stalls, in dress clothes.

Starting imperfectly in sixty days beats starting perfectly never. Start.

The choice this chapter leaves you with

I want to ask you one final question before Part III closes.

When, specifically, does day one of your sixty-day plan begin?

Not this quarter. Not next month. A specific date, preferably within two weeks of closing this book. A date you write down, share with at least one other person who will hold you to it, and treat as a structural commitment.

If you cannot name the date, you have not yet decided to begin. The rest of the book will continue to describe what the integration pathway produces — activation, formation, multiplication, movement — but those later stages are written for readers who have begun the integration the first four chapters of Part III have described.

Name the date.

Then, on that date, draft the first-pass schema.

Part III is complete. Part IV, which begins with the foundation starting to answer, is next.