Asynchronous Mowing is the practice of doing the “mowing” half of Moaning and Mowing without needing everyone in the same workshop at the same time. Instead of one big wall and a facilitator with sticky notes, you use a set of lightweight tools to let the community. - Merge duplicates (or deliberately keep near-duplicates). - Argue about wording without arguing about people. - Propose and revise causal links over time. - Curate small, local map fragments that can later be composed into larger Causal Maps.
The goal is not to eliminate meetings. The goal is to move the slow, thoughtful work out of the meeting, so synchronous time is used for decisions, not for wrangling text.
# Why bother mowing asynchronously - Workshop mowing is fast, social, and energising, but it has biases. - It rewards whoever speaks first. - It can compress dissent into silence. - It forces complex causation into a single afternoon.
Asynchronous mowing gives the group time to: - Check examples and evidence. - Reflect and come back with better language. - Notice missing voices and invite them. - Keep contested links alive as hypotheses rather than “resolved” by fatigue.
# The smallest unit: a problem card with a traceable source Asynchronous mowing starts from a shared pool of problem statements, often collected via Asynchronous Moaning.
Each statement is stored as a “card” with: - A short negative condition phrase. - Optional context and tags. - A link back to the source (workshop photo, WhatsApp message, audio note timestamp).
This traceability matters because mowing is editing, and editing needs receipts.
# Asynchronous duplicate handling Duplicates can be handled without a meeting if you treat it as a social editing process, not as an admin task.
A useful pattern is to let people propose one of three actions on any pair or cluster. 1. **Exact duplicate**: merge immediately. 1. **Near-duplicate**: keep both but link them as related. 1. **Same theme but different level**: keep both and propose a causal link.
This avoids the classic failure mode where a single editor merges everything and accidentally deletes meaning.
# Asynchronous causation discussion - Causal links are where politics hides, so asynchronous mowing needs gentle structure. - Instead of “argue in comments,” use a simple protocol for each proposed link. - State the link in plain language: “A tends to cause or increase B.”. - Optional polarity: “increase/decrease” if you want CLD compatibility. - Provide one example or observation. - Optionally flag uncertainty: “weak”, “contested”, “context-specific”. - Invite counterexamples.
Over time, the community is not just drawing arrows, it is building a shared library of causal claims with attached evidence and nuance.
# Tools we can build: a community map garden A practical app for asynchronous mowing does not need to be heavy. It can be a garden of tiny edits and votes. - A merge proposal tool. - A “related” link tool. - A causal-link tool with optional polarity and confidence. - A way to tag and filter. - A way to fork contested versions rather than forcing false consensus. - A way to keep provenance and revert changes.
The product principle is simple: make it easier to do the honest thing than the shortcut thing.
# Using Federated Wiki as the substrate Federated Wiki is a good fit for asynchronous mowing because it treats knowledge as many small pages, encourages forking, and supports local curation without needing central permission.
One pattern is: - Each problem card is a small wiki page. - Causal links are expressed as page-to-page references. - Near-duplicates can live as parallel pages until the community chooses to merge or keep both.
Different groups can fork and adapt the same problem statement without destroying each other’s context. This gives you “plural truths” without chaos, because forks are explicit rather than hidden.
# Small graph elements as first-class artefacts Instead of trying to build “the map,” you collect “map atoms.” A node: a problem statement page. An edge: a proposed causal relationship between two pages. A cluster: a set of pages that a community tags as “similar” or “same family.” A loop hint: a set of edges that might form a reinforcing or balancing loop. Asynchronous mowing is the craft of curating these atoms until they are clean enough to compose. # From curated atoms to algorithmic maps Once you have a growing set of nodes and edges, you can generate larger maps algorithmically. Build a directed graph from the curated edges. Generate subgraphs by tag or theme. Detect highly connected nodes (useful for identifying “peaks” or summary problems). Detect strongly connected components and cycles (useful for suggesting CLD loops). Generate multiple “views” rather than one definitive map. A key principle is that the algorithm does not decide truth. It proposes structure. The community remains the editor. # Avoiding the smuggling problem in software form Asynchronous mowing tools can quietly smuggle control unless designed carefully. Do not make merging irreversible. Do not allow one role to overwrite everyone’s phrasing without trace. Do not hide provenance. Do not collapse minority interpretations automatically. Do not let popularity replace validity, especially for causation links. Design for reversible edits, visible forks, and explicit uncertainty. # What the output looks like A well-run asynchronous mowing process produces. A cleaner, less duplicated set of problem statements. A visible record of how wording evolved. A library of causal links with examples and confidence markers. Curated fragments that can be composed into Problem Tree views and Causal Loop Diagram views. And most importantly, a community that can keep learning between workshops, rather than resetting to zero each time.