Purpose-to-Practice: Chartering a New Squad Without Writing a Charter Doc

The charter doc for Recap CRM’s new Founder Digest squad was two pages long, written by me and two other people who would not be doing any of the work. It had a mission statement, a set of success metrics, a RACI table, and a proposed cadence. It was, by the standards of charter docs, pretty good. It also would have been read once, skimmed, and quietly ignored by week three — because nobody who had to live inside it had helped build it.

So instead of presenting it, I ran Purpose-to-Practice with the four people actually joining the squad, plus the support lead whose queue the Digest would eventually change. Two and a half hours. The charter that came out was shorter than mine and materially different.

The five elements, in order

Purpose-to-Practice is Lipmanowicz and McCandless’s structure for designing an initiative that can run itself — the claim being that a group needs five things settled before it can self-organize, and that missing any one of them produces a predictable failure. You work them in sequence, each one via 1-2-4-All so everyone writes before anyone talks:

1. Purpose — why is this work important, to us and to the people it touches? Not the metric. The reason the metric matters.
2. Principles — what must we always do, and what must we never do, to serve that purpose? Must-do and must-not-do, both stated.
3. Participants — who has to be included for this to work? Often the answer includes people not currently invited.
4. Structure — how do we organize and distribute control? Who decides what, without asking?
5. Practices — what do we actually do, and what do we do first?

The critical rule is that the sequence is a loop, not a ladder. When Practices contradict Purpose, you go back and fix Purpose. A group that reaches step five and discovers its stated purpose can’t survive contact with the work has learned the most valuable thing available that day.

Running it on the Founder Digest

The seed I gave the room was deliberately thin: “we’re building a weekly digest email for founders using Recap.”

Purpose took forty-five minutes and did all the damage. My deck said the purpose was “increase weekly active usage.” Written down individually and then paired, three of the four squad members landed somewhere else entirely: the digest exists so a founder who hasn’t opened Recap in nine days doesn’t feel behind when they do. Re-entry, not engagement. Those sound similar and they aren’t — an engagement-shaped digest is a nudge machine that lists everything you missed, and a re-entry-shaped digest is a short list of the three relationships that actually need you this week, with everything else deliberately suppressed. Same feature, opposite information design.

Principles got sharp fast once Purpose was real. Must-do: every item in the digest links to a single next action. Must-not-do: never include a count of things the founder failed to do. That second one is a must-not-do you would never write in a charter doc written by management, because the “you have 47 stale deals” line is exactly what a growth-metric brain reaches for. The squad banned it in the first hour.

Participants surfaced the support lead as a permanent member rather than a stakeholder — she was the only person who read every “I stopped using this” cancellation note, and the squad wanted that feed weekly, not quarterly.

Structure was one sentence: the squad ships digest content changes without review; anything that changes what data gets collected goes through the platform team. That single line resolved a permissions argument that had been vaguely pending for two weeks.

Practices started with something unglamorous — hand-writing the digest for eleven design-partner founders for three weeks before automating a line of it.

Why the sequence carries the weight

Most charters start at Practices and reverse-engineer a purpose to justify them. P2P forbids that by construction: you cannot discuss what to build until the room has said out loud why it matters, and the 1-2-4-All inside each element means the loudest person’s answer isn’t the room’s answer. The Principles step is the one I’d keep if I could only keep one. Purpose statements are easy to agree with and hard to violate visibly. A must-not-do is a tripwire — “we said we’d never show a failure count” is a sentence a junior engineer can say to a director without it being a fight.

When to skip it

P2P is expensive and it needs a genuinely open question. If the initiative’s purpose, funding, and staffing are already fixed by someone outside the room, running it produces theatre and resentment — the group discovers a better purpose it isn’t allowed to act on. Say what’s actually negotiable before you start, and if the honest answer is “nothing,” don’t run it.

It’s also wrong for short-lived work. A two-week experiment doesn’t need five elements; it needs a hypothesis and an end date. I’d reserve P2P for things expected to outlive their founding team — squads, guilds, product lines, anything that will still need to explain itself in a year.