Sociocracy 3.0: Drivers


I am quite happy with everything I read about Sociocracy 3.0. It’s thorough but not too strict, it’s human, adaptable, feels natural (none of the crap I disliked about Holacracy).

We’re going to go ahead with using any and all tools from that going forward. I’m going to start posting items one-by-one as they seem clear to me and applicable. For today: Describing Drivers

In essence, “driver” is just another word for purpose. A domain can have a driver, but so can specific work tasks or projects etc.

Describing Drivers

Read that link. This is a simple, common-sense template to get a nice clear way to describe any particular case. Also, pages 6 and 7 of

Some other illustrations:

So, while the entire S3 system has a lot of elements, we can easily build the practice and make use of this sort of Driver Description right now before we make sense of or adapt the rest of the system.



Here’s a driver (first draft) about utilizing Sociocracy 3.0, Drivers specifically:

[normally I wouldn’t care to mark the sections, it’s too pedantic, but for learning the format, I’m trying it this time]

1. Current Situation

Our issues in GitLab have inconsistent formats. Some have user stories, others are just TODO checklists. We seem hesitant to format more things as user stories because that can feel like extra pedantic work that doesn’t come naturally.

2. Effect

It can be hard to review issues and quickly understand the motivations and contexts. We often take excessive time discussing issues because we aren’t all on the same page about the underlying tensions.

3. Need

We need to stay connected with why we are working on any particular task — for motivation, task management, and communication.

4. Impact

Using clear driver statements should help us better think about our work, spend less time talking past one another, and make issues more approachable to newcomers.

Actionable items

The driver statement itself isn’t the actionable response. And we’ll get to that and see how we feel about S3’s suggestions there. But for here, I’ll clarify some actionable next-steps:

  • Again, don’t necessarily list the 4 parts of driver statements, especially when short. That’s just a crutch for now while we build the habit. But if you like them, the labels are fine to include.
  • We should use this format in discussion as well as writing and reviewing of issues. We’ll adapt as we go. We don’t want pedantry, we want to find where this approach actually feels like it helps. Use it where it feels good.
  • Review existing issues and update them to this format, considering S3’s review suggestions (you, reader, could start by evaluating the quality of my draft statement above):
    • Is the description of the situation (still) correct?
    • Do we still associate the same needs with the situation?
    • Is the driver still within our domain?
    • Is the driver still relevant?

And everything I wrote above is a first-draft of me thinking about this. Happy to discuss/edit/improve. I don’t want this to feel like a rigid top-down mandate. I think getting to where this is natural will just feel good to everyone and help the org overall.