Sociocratic decision making

Sociocratic decision making


Quite often the challenges with making decisions are the following:

  • It’s difficult to get all parties involved aligned towards a decision.
  • Once a decision has taken, some degree of uncertainty remains if people actually support the decision.

Welcome to sociocratic decision making

Sociocratic decisions differ from autocratic (no to low support, but fast decision making), democratic (with majority vote) (at least 51% vote support), and consensus (broad support, but time-consuming process).

Sociocratic decisions are made with consent. Consent means there is no reason not to object. In other words, there are no compelling reasons not to agree to proceed and to try out whatever is being proposed. Any concerns raised can be taken into account. Objections must be taken into account and are to be resolved.

Prerequisites for consent decision making

  • participants involved are consciously thinking about moving forward with a proposal for next best action (“it’s good enough for now, and safe enough to try”),
  •  all participants consider each other equivalent.

Pattern for sociocratic decision making

  1. Introduce the matter to decide upon (in sociocracy 3.0 this called a “driver”: what’s happening right now that motivates us to present this matter?)
  2. Round of consent agreeing to the matter
  3. Present the proposal for next best action
  4. Round of clarifying questions
  5. Round of brief response – in order to get a first short indication of level of agreement
  6. Indicate consent (agree with consent, object, agree with concerns)
  7. Resolve objections (one by one) by improving the proposal (on the spot, or prepare for next meeting)
  8. In case of no objections (left): consider decision agreed upon: celebrate!
  9. Consider any concerns (optionally)

Note: the phrase “it’s good enough for now, and safe enough to try” is taken from sociocracy 3.0.

The next action of a decision agreed is to honor to check upon the outcome of the decision, and if necessary act upon improving it, in a next iteration.

Challenging Sprint Retrospectives

For the readers: A reference for organising retrospectives is the book “Agile Retrospectives – Making Good teams Great”, by Esther Derby & Diana Larsen. They describe the main steps of an agile retrospective.

The prime directive of retrospectives has been formulated by Norman Kerth in his book “Project Retrospectives: A Handbook for Team Reviews”.

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

You can find online all kinds and sorts of formats (games) for retrospectives; I’ve found back a description of a ‘base’ agile retrospective, and I’d like to recommend this to anyone. It focuses on what went well, what could better, and next on identifying and committing to action points for improvement.

What are your thoughts about retrospective facilitation techniques?

Reference to post: “Challenging Sprint Retrospectives

Plan Do Check Act


Een belangrijk element in een continue verbeteringsproces is een continue cyclus van plannen, uitvoeren, verifiëren en bijstellen. De uitdaging is om deze cyclus herhaaldelijk te blijven uitvoeren, zodat de zin voor kwaliteitsverbetering een continue gegeven wordt.

De indeling van deze stappen zijn de stappen zoals aanwezig in de wetenschappelijke methode: het formuleren van een hypothese, het uitvoeren van een experiment, en het evalueren van de resultaten (om de hypothese juist of fout te verklaren). Deze Plan – Do – Check – Act cyclus (PDCA) is gekend als de kwaliteitscirkel van Deming. PDCA vormt de basis voor continue verbetering en is een element van lean productie.

Scrum als ontwikkelingsraamwerk voor complexe producten heeft zijn origine in lean productie (lean thinking). Het artikel (The New New Product Development Game) spreekt over “incrementele verbeteringen”.

Hoe “Plan – Do – Check – Act” zichtbaar maken in een team?

Continue reading →