User Tools

Site Tools


8 Patterns for Decentralised Organising

In my role at Loomio and Enspiral, I worked with dozens of groups who are experimenting with decentralised organising. I noticed that each team faced similar challenges, and sharing experiences between teams helped them to innovate faster.

This year we’ve worked with hundreds of groups, sharing these “patterns”: each pattern is a challenge common to many decentralised groups, and some practical responses.

The patterns are designed to be remixed, adapted to your local context. We’ll share 8 of the most common ones here…

1. Intentionally produce counter-culture

You want to be non-hierarchical but you have hierarchical habits, e.g. telling people what to do, or looking to others for answers. We are conditioned by culture: if there is sexism and racism in your environment, it can be imprinted into your habits.

We can unlearn hierarchies together. We can co-design a culture that encourages each of us to develop our best qualities, making us all more generous, respectful, trusting, courageous, etc.

How do you produce culture? Fermentation! To make sourdough bread, you have a starter dough, mixed with fresh ingredients, and put it somewhere dark and safe for some time. To ferment a new group culture, your “starter dough” is a person or people who embody some of the qualities you want to develop. The “fresh ingredients” are new people who have a desire to grow in a specific way. We combine these ingredients in a retreat: safe, quiet, isolated from the outside world for a few days.

We learn about each other’s dreams and fears, building deep relationships of trust and belonging: the most important resource for all your upcoming challenges.

2. Systematically distribute care labour

Care includes the practical stuff of hospitality: preparing a comfortable room with food, lighting, decoration, refreshments, collaboration tools, and tidying up after. It also includes emotional work, like noticing tension between colleagues and supporting them to resolve it.

Hierarchical culture trains us to not share the care labour fairly. Most groups have one or two people, usually women, doing most of the care work. If they get overwhelmed or frustrated, they’ll stop, and the group loses its gravity.

Make all work visible, so you can share it fairly. E.g. the Loomio team uses “stewardship”, a peer-to-peer support system. Everyone supports one person, and is supported by someone else. Each pair meets once per month, the steward asks “how can I support you?” and they figure out the answer together. More info:

Builds deep trusting relationships; dissolves conflicts; continuously improving emotional intelligence of everyone in the group; more distribution = more resilience. —- Use this page for your own notes

3. Make explicit norms and boundaries

Norms = how we do things around here. Boundaries = what we don’t do around here. Many groups leave these things unsaid, relying on “common sense”.

Conflicts grow when people have different unspoken assumptions (everyone has different common sense). When you cross an invisible boundary, it takes huge energy to make the boundary explicit, before you can get to the behaviour.

Talk about your norms: how do we want to be together? e.g. open, honest, authentic, gentle, inquisitive…

Talk about your boundaries: what behaviour do we want to exclude? e.g. no mean feedback, no sexist jokes.

Buy-in — clarity helps people evaluate whether or not they want to be here. Expectations are clear. There is a process for challenging destructive behaviour, and a process for updating our agreements.

E.g. see roles + responsibilities described in Enspiral’s People Agreement

4. Keep talking about power

Power, influence, status, rank, social capital, volume, access… whatever you call it, I’ve never met a group where it was equally distributed between all members. Equality is a compass point to navigate towards, not a destination I’ve ever arrived at.

Groups thrive when anyone can safely talk about power differentials. Imbalance can be bad, e.g. inherited privilege, coercion, manipulation, the “old boys club”. Some imbalance can be good: earned trust, reputation, eldership.

Transparency reduces toxicity. Discuss together: “How’s the power? Who has it? How do you earn it?”

Some roles attract power (e.g. manager, facilitator, spokesperson, coordinator, director). Rotation increases access: take turns, step out, encourage others to step in.

E.g. Loomio team coordinators are elected by the team for a limited term; we intentionally support less experienced people to try the role. See|Loomio Coordination.

The best ‘elders’ use their status to praise, acknowledge, and encourage people with less.

5a. Agree how you’re using your tech

Many groups are dissatisfied with their communication technology. Information overload: too much data but can never find the thing you want. Half the team uses this tool, the other half uses another one. Too many tools, don’t know how to get everyone’s attention, can never find the document I need.

Agree together what tools are for what job. E.g. the ‘trinity of digital comms’:

  1. Realtime, like chat, messenger, or Slack. Informal, quick, organised around time: it’s about right now.
  2. Asynchronous, like email, forum or Loomio. More formal, organised around topic. Has a subject + context + invitation. Can take days or weeks. Makes a useful archive, considered comments rather than random messy chatter.
  3. Static, like a wiki, Google Docs, handbook, or FAQ. Very formal, usually with an explicit process for updating content.

Depending on your work, you will need different tools. The important thing is that you have an agreement together about what tools are for what job. With a shared understanding of the tools, they all fit together beautifully. When people have different ideas, it gets messy.

Great to have a “how we use our comms tools” document as part of the welcoming pack for new members.

5b. Introducing new tools

Introducing a new communications tool usually makes the problem worse. Most groups don’t know how to introduce new tech well.

This method makes it less likely to go badly:

  1. Agree the problem. What issue do you want to solve? Do other team members agree it’s a problem?

  2. Volunteer(s) test prototypes. One or a few people research options and come back to the wider group with a recommendation.

  3. Support people to learn. Once you’ve chosen a new tool to evaluate, make space for people to learn together how to use it.

  4. Reminders build a habit. It can take weeks to develop a new communication habit. Remind each other gently, “hey we said we’d try using Loomio for these kinds of conversations…”

  5. Evaluate + repeat. Most importantly, set a time-limit, e.g. “We’ll try this tool for 2 months and then evaluate together. Is the problem solved? Or do we need more training, or a different tool?”

6. Make decisions asynchronously

When you say ‘we’re going to be inclusive’, that’s code for ‘we’re going to spend a lot of time in meetings.’ Most collaborative groups make decisions in meetings or conference calls. You can think of this as synchronised or realtime communication: you have to synchronise people’s calendars to book the meeting, then when they arrive, everyone has to pay attention to everything at the same time. It’s very expensive, excluding the input of people who can’t attend, and often results in hurried decisions.

With a little effort, you can develop a habit of asynchronous decision-making. People can participate in their own time, contributing only to the issues relevant to them. This is what Loomio is for: more inclusion and collective intelligence, less time in meetings.

E.g. I’m on a Board of Directors. We meet monthly. We co-create the agenda in a Loomio thread ahead of time. A few days before the meeting, the secretary starts a poll to check everyone is happy with the agenda and we’ve all read the reports. We all arrive at the meeting prepared and focussed. We’ll make some decisions face-to-face. For decisions that require input from more people, or if we just want more time to consider options, one of the Directors will take the decision to Loomio. We also use the software to sign off the minutes, and find another meeting time.

Over time you learn the unique qualities of realtime and async communication. Meetings are good for bonding, brainstorming, and dealing with complex or sensitive topics. Loomio creates more space for deliberation: you can take more time, consider more options, hear from more people, and keep a record.

7. Use rhythm to balance chaos and focus

Hierarchies are designed to manage flows of communication and decision-making. When you remove the hierarchy, you need to replace it with something. If there is no agreed structure, your group can suffer from information overload (everyone asked about everything all the time) and exclusion (decisions made without appropriate input).

Rhythm helps balance speed with participation. People can trust each other to seek input at the right time, so they don’t need to be involved in every decision.

We create distinct communication spaces for different timeframes, e.g. today’s work is discussed every morning; if you want to discuss the long term strategic direction, we have a dedicated space for that every month.

Here’s a set of working rhythms we use in the Loomio team. You can adapt to your context, e.g. maybe it makes sense to align with seasons or moon cycles:

  • Daily “standup” meeting. Everyone answers, “What did you do yesterday? What are you doing today? Are there any obstacles we can help you with?” Quick info exchange, accountability and support.
  • Weekly “sprints”, a regular working period. E.g. on Monday we agree what work we’re going to do this week. On Friday we share progress and have a “retrospective” looking for improvements to try next week.
  • Quarterly objectives. Every 3 months we have a planning day, looking for agreement on 3 or 4 measurable targets to align all of the work in the cooperative. After we finalise the decision on Loomio, everyone has freedom to do whatever work they feel is most relevant to achieve those outcomes.
  • Bi-annual retreats. Every 6 months we go away together for 3 or 4 days. This deepens our relationships, and creates a space for the kind of conversations that can’t happen in the office, e.g. dreaming together about our shared vision, or dealing with a complex tension.

8. Generate new patterns together

If you’re not stopping you’re not learning.

If you’re going to try one thing, do this.

You can choose a frequency that suits you, but let’s say weekly. At the end of each week, stop working. Have a retrospective meeting. Review the week just been. What was good? Notice it and do more. What was bad? Discuss. Agree a change that you’re going to try next week to make it more good and less bad.

I’ve shared a bunch of collaboration patterns. These are just my way of describing things I’ve seen. We discovered them by a lot of invention, remixing ideas, making them our own, adjusting them to local conditions. This booklet is not a recipe for you to copy and paste, it’s a guide to a way of thinking. The retrospective is where you learn to notice your own collaboration patterns, and co-design new ones.

See the Retrospective Wiki for ideas of how to host a structure reflection process.


Richard D. Bartlett

Writing first draft in English

Contact me for…
Paid or unpaid conversations, consulting, coaching, training, workshops, retreats…

Natalia Lombardo

Co-designed first draft with Rich.
Spanish translation.


Portuguese translation…


License in the public domain. Do what you like with this. Feel free to add your contact details to the credits list if you have contributed.

Suggestions for future development

  • Produce an online course with videos from Rich or others
  • Add more sections
  • Add links to more resources, stories, examples, workshop format
  • Add exercises
  • Add “inspiration” section to name some of the people who have contributed to this way of understanding groups, e.g. people from Enspiral + Loomio and other communities of practice.
patterns_for_decentralised_organising.txt · Last modified: 2018/02/25 14:56 by luciano