A Gathering Pattern is a documented structure for how people and other actors in soft systems [^1] can work, gather, or collaborate. Gathering Patterns are designed to be adapted, not followed blindly.

Think of it as a recipe with two parts:

  1. What you can't skip (the chemistry that makes it work)
  2. What you can adjust (quantities, timing, ingredients to taste)

Gathering Patterns exist for the same reason open-source software exists: good solutions shouldn't stay locked in the head of one person, team, or organization. If a structure works (for running a meeting, facilitating a creative sprint, building community) it should be portable. Others should be able to pick it up, try it, and improve it.

What Gathering Patterns Are Not

  • Not rules. They're structures. Rules demand compliance. Patterns invite adaptation.
  • Not templates. Templates are fill-in-the-blank. Patterns require judgment about what fits your context.
  • Not best practices. "Best" implies one right way. Patterns assume many right ways, bounded by a few real constraints.

Anatomy of a Gathering Pattern

Every Gathering Pattern has:

1. Intent

What is this pattern for? What state is it trying to produce? This is the compass: if your adaptation still achieves this, you're on track.

2. Essentials

The non-negotiable, load bearing walls. Remove or reverse these and the pattern stops working not because of dogma, but because of how humans (cognition, attention, social dynamics) actually function.

These are identified through use, research, or hard-won failure. They're prescriptive because deviation causes collapse, not because someone prefers it this way.

3. Suggested Defaults

Everything else. Group size, duration, frequency, specific techniques… these are starting points. They work, but your context might need different settings.

Defaults come with flex ranges where possible: not "2 hours" but "2 hours (1–4 depending on depth needed)."

4. Underlying Rationale

The why. Gathering Patterns show their work. If you understand the mechanism (cognitive science, group dynamics, whatever), you can make smarter adaptations. You're not just following instructions, you're reasoning from principles.

5. Permission to Fork

Explicit. You can take this pattern, change it, rename it, publish your version. That's the point. If your fork is better, it should spread.

How to Use a Gathering Pattern

First time: Run it close to the defaults. The pattern earned its shape through iteration. Trust that briefly before modifying.

After that: Adjust based on what you observe. If something feels off, check whether you're violating a load-bearing wall (problem) or just running a suboptimal default (tune it).

Share back: If you find an improvement, publish it. A pattern that only lives in your head helps no one else.

How to Read a Gathering Pattern

Skim-first structure:

  1. Title + description → Is this relevant to my situation?
  2. Intent → What's it actually for?
  3. Load-bearing walls → What can't I skip?
  4. Suggested defaults → What's a reasonable starting point?
  5. Rationale → (Only if you want to understand or adapt deeply)

You should be able to decide "yes/no/maybe" within 60 seconds. The pattern should be usable within 5 minutes of reading.

The Gathering Pattern Ethos

A few beliefs that run beneath this:

  • Coordination is a design problem. How people work together isn't natural or inevitable; it's structured, and structures can be better or worse.
  • Soft systems deserve the same rigor as hard systems [^2]. We version-control code. We should also iterate deliberately on how we meet, collaborate, and create together.
  • Transparency compounds. When you show your reasoning, others can build on it. Hidden logic dies with its holder.
  • Prescription should be earned. Only constrain what needs constraining. Default to freedom with guidance.

Start With Gathering Patterns

If you're new to Gathering Patterns, pick one that matches a need you actually have. Run it. See what happens. Adjust.

The pattern isn't the point. The outcome is.

[^1] Soft system (as used here): A system whose function depends on human interpretation, participation, and adaptation.

Unlike engineered systems (software, logistics, machinery), soft systems cannot be fully specified in advance; they emerge from the interaction of people, context, and intent.

Examples: a weekly team ritual, a community gathering format, a creative collaboration structure.

Any situation that warrants a soft approach is, by definition, one where complexity cannot be engineered away.

You can design structures and suggest defaults, but the system only becomes real through use.

This contrasts with hard systems, which have well-defined problems, clear objectives, and optimal solutions that can be calculated or engineered.

For the theoretical foundations, see Peter Checkland's Soft Systems Methodology (1981) and work on Complex Adaptive Systems (Holland, 1992).

[^2]: The distinction between "hard" and "soft" systems originates with Peter Checkland's Soft Systems Methodology (SSM), developed at Lancaster University from the 1960s onward.

Hard systems have well-defined problems, clear objectives, and optimal solutions; think engineering, logistics, computation.

Soft systems involve human activity, contested goals, and multiple valid interpretations; think organizations, communities, collaboration.

Checkland's insight was that methods designed for hard systems fail when applied to soft ones, because the involved entities/actors often disagree on what the problem even is.

Gathering Patterns extend this thinking: coordination structures like meetings, creative sessions, and group rituals are soft systems. They can be designed and improved, but never "solved."

For more, see Checkland's Systems Thinking, Systems Practice (1981/1999) or the Lancaster University overview.