Explanation of changes to Sociocracy 3.0 Practical Guide – 16th November 2017

Introduction

James:

It's been on our backlog for some time to up-our-game in terms of communication with the world and share a bit more of what happens behind the scenes of S3. It's challenging sometimes to find the time to write about that, so we've come up with this idea to transcribe this conversation where we run you through the details.

Bernhard:

We’re curious for your feedback; what lands with you, and how we can improve for the next time.

General changes

Lili:

So, first off there are some general changes that have to do with the way we present S3 on the website. This includes structural changes related to the fact that we added a glossary where we’ve begun compiling terms that benefit from explanation. Particularly, we’re describing those terms that have a specific meaning in S3 to reduce potential ambiguity and so that readers can have a reference point. This is work-in-progress and there are still more to be added. 

We also added an index of all the patterns. This is for the printed version. It comes in handy for finding certain patterns that are listed in alphabetical order and next to it you find the number of the category for that pattern. For example, “Organisational Structure” is a category and has been numbered ten. Next to this number you’ll find a number for the pattern itself.

Bernhard:

It’s probably helpful to note that pattern numbers are only intended as a reference specific to a particular release of the guide. When new patterns are added to the bottom of a category, then pattern numbers are going to stay the same. When we put new patterns in between, pattern numbers are going to change.

James:

Next up we added Lili as a co-author of the presentation. Lili has been involved with the development of S3 from the start. First, behind the scenes and then much more actively as we've moved forward. Today, every single word in this presentation has been thoroughly considered by Lili, Myself, and Bernhard. Sometimes, we spend quite some time drilling into things, objecting to each other's suggestions, sharing concerns to arrive at the text we have now. So, it's a labour of love and whilst time consuming sometimes, 3 is a great number for unveiling “both-and-more”.

On the topic of acknowledgments, those of you who've been paying attention will notice we've added an “acknowledgements” section. This isn't intended by any means to be an exhaustive list; I'm sure there's many, many more names that we could include here. But we wanted to make it explicitly clear that S3 “stands on the shoulders of giants” as they say. S3 has many influences, and reflects the combined work and inquiry of many people across generations. This is our first attempt to acknowledge some of those people, and if you have any suggestions about who else to include, please do let us know.

Bernhard:

We dropped the term "framework" from the slide deck and replaced it with “practical guide”. When people heard us refer to S3 as a framework, their initial feedback was often, "Oh, another agile framework!", which gave them a somewhat limited impression of what S3 could actually do for them. They would get the idea that it's probably hard to learn and you would have to hire a consultant to bring it to your organisation and then do a re-organisation and all of the other usual stuff that goes with frameworks!

S3 differs in that it is an invitation for people to pull in patterns that may help them, and overall to develop a sociocratic and agile mindset. It's not a methodology that is implemented in organisations. We continue experimenting with how to communicate the freedom and openness of S3 to people. Testing A Practical Guide, initial feedback indicates that this appears to resonate with people the right way.

To expand on how we communicate the idea of S3 to people, we included a slide called "What's In It For Me?" that explains that S3 is about improving performance, alignment, and also fulfilment and well-being of the people in the organisation, and gives a brief overview on how S3 meets organisations where they are and allows them to move forward at their own pace. They don't have to prepare much for this because you can just build the necessary skills as you go. I think that's a very important thing to clarify to people right at the beginning so they know what they're in for.

James:

We often make the invitation explicit, “start where you are, and with your area of greatest need”. Obviously needs correlate with people, so explicitly inquiring into "What's In It For Me?" is a good starting point. When people understand there's value in something, of course they're inclined to consider it, but not before. This point captures something of the spirit of S3. We all have enough to do without fixing things that are not broken to begin with. So, putting energy into change where it’s really needed, rather than just starting with some kind of generic prescription, is probably a good idea.

Changes to how concepts are described

Lili:

Moving on to changes with content, we’ve added some clarifications to the core concepts of S3. First off, we have the topics of governance, self-organization and semi-autonomy.

Bernhard:

We've been looking for a long time for a simple and unambiguous definition of what governance actually is. It can appear as a very high-level and lofty concept whereas actually it’s pretty straight forward. Finally we’ve described it as continuously deciding what to do to achieve objectives and setting constraints on how and when things will be done. I think that definition shows that governance is a very simple and basic activity, something everyone who contributes work to an organisation is on some level involved in, and can and obviously should contribute to. After nailing a definition of governance, we were able to pin down some other related terms in a simple and coherent way too. Operations as a complementary term to governance, doing what needs to be done, guided by governance. Self-governance, people governing themselves within the constraints of a domain. Self-organization, people coordinating work within the constraints defined through governance, and semi-autonomy, the autonomy of people to create value limited by the constraints of their domains.

We have used these terms for some time when describing certain patterns and now we have clearer explanations that people can relate to. We added all these terms to the glossary.

James:

Next up, driver. We made the definition of driver a bit more succinct and to the point. From the source of motivation to act to a person or group's motive for responding to a situation. An issue with the previous definition was that it could be taken to refer solely to an external event, whereas of course, motivation is something that arises within us in relation to events. So this new definition embraces both object and subject.

On the topic of driver, we already explicitly suggest including reference to What's Happening (the objective observation) and What's Needed (that area of deficit). We are learning that including reference to the effect of the current situation  and the impact of of responding to the need adds a further dimension of clarity regarding why a driver is relevant to respond to. In our latest release (March 2018) we made this explicit.

Bernhard:

We also updated our definition of domain. The previous explanation was rather abstract and it only made sense if you had a solid and deep understanding of drivers. Readers of this slide deck were unable to develop this understanding from the two or three slides we had on drivers and so it was not good enough.

With help from the community, we revised the definition of a domain to a distinct area of influence, activity, and decision-making within an organisation. This new explanation is proving to be clear and understandable. We’ve tested it with several hundred people now and everyone is able to relate to the concept of domains and point to them in their organization, e.g. HR, a particular product, role, engineering etc.

Lili:

In relation to domains, the topic of delegation comes in when we say that people delegate accountability for domains. With this in mind, we further defined the contract that happens between delegator and delegatee: the delegator being the one who's delegating accountability for a domain to other people – which can be a person or a group of a people, while retaining overall accountability; and the delegatee being the one who's accepting accountability for the domain. The terms of that delegation are specified in the domain description.

Changes to the patterns or how they are described

Lili:

So that covers changes to core concepts of S3, and now we're going to look at changes we made to the patterns. We grouped these changes into sections that make sense to describe together.

James:

We're often asked what's the difference between a Role and a domain or a Circle and a domain, and so on. So it can take people new to S3 some time to understand that people account for domains, and that this is done by people keeping a Role, or being a member of a Circle, Open Domain or Helping Team, all of which are different patterns for accounting for domains. So we adapted the pattern description for Role to make this more clear by clarifying that a role is an area of accountability defined by a Domain and assigned to an individual, the Role keeper, who has autonomy to decide on that within the constraints of the role's domain.

In general, we're working to bring more clarity to the concept of domains and the different ways to account for them in the pattern descriptions, so any feedback on that would be helpful.

We've introduced the term role keeper for a person in a Role.

We made it explicit that strategy is primarily developed by delegatees, but it's an agreement between delegatee and delegator. Why this is important is to ensure that a delegatee's strategy is aligned with a delegator's overall strategy whilst giving people as much autonomy as possible to define strategy for themselves.

We integrated this into the pattern Develop Strategy and clarified our definition of strategy to a high-level approach to how people will create value to successfully account for a domain.

We’ve made it explicit that just as a group of people in a Circle make governance decisions – and that keeping a record of important drivers and significant decisions in a governance board can be helpful – the same can apply for someone keeping a role. We researched by asking people in roles if they kept a record of significant decisions for transparency and to track outcomes and it turns out a lot of people already do this. Others thought it would be a useful practice to adopt.

So, as with many other patterns in S3, it's nothing per se, but rather a pattern people use when valuable. Of course, we have the pattern Governance Backlog and Logbook that people in roles can pull in for this.

By making it explicit that a person in a role makes governance decisions, it follows that the pattern Agreement is also applicable to people in roles. Obviously we make decisions as individuals, but we realised that we can treat those decisions the same as we would agreements. So we specified that guidelines, processes, or protocols created by individuals in roles are treated as agreements. We updated the agreement template illustration to reflect this.

Lili:

Moving on to the patterns for Building Organisations and Organisational Structure, we recategorized some patterns. We moved Open Domain, Helping Team, and Open System from the category “Organisational Structure” to “Building Organisations”, because these are actually building blocks for creating organisational structure. The category of “Organisational Structure” now contains only those patterns that can be created by combining these building blocks.

Bernhard:

We’ve learned that it brings value for people to understand domains and clarify them in the context of their organisation, so we’ve described all basic building blocks for organisations in relationship to domains. Now we explain a Circle as an equivalent, semi-autonomous and self-governing group of people collaborating to account for a domain. Whereas in the past it was described as a group responding to a Driver.

As mentioned above, we also added definitions for semi-autonomous and self-governing to the glossary.

James:

Delegate Influence is a new pattern. Previously, and from the beginning of S3, we had the pattern Nested Domains as a way to describe the concept of nested domains of accountability. It was always a little bit problematic, especially considering the fact that domains sometimes overlap other domains. So we dropped the pattern Nested Domains, revised the text describing the concept of domains and introduced the pattern Delegate Influence.

Delegate Influence is at the essence of developing organisations, and S3 is inviting that we delegate influence to the individual as much as possible so that human beings are free to decide for themselves and get on with things, referring back to others when it's valuable or necessary to do so. Making this pattern explicit helps people to understand about how to evolve organizational structure. It doesn't tell people how they should do that, or what the resulting structure looks like, but make explicit how power to influence is shared, and how Domains are established and can be developed over time.

Bernhard:

Moving on to the pattern Double-linked Hierarchy, we changed the illustration here. For a long time I’ve been unhappy with the previous illustration because it looked weird and it did not show how people are members of two circles in a double-linked hierarchy. The new illustration shows that a double-linked hierarchy is not really a top-down system and it also demonstrates much more clearly how the power to influence flows. On top of the old illustration there was also a “holding circle”, which was our reinterpretation of the concept of a “top circle” in the Sociocratic Circle Method (SCM). Obviously what we're really referring to in most cases is the function of a board, and in fact, even some people using SCM, refer to this as a board rather than “top circle”, for reasons I think are self-evident when you consider the word “top” in this context. But a “holding circle” or board is actually a service function, and therefore it's not necessary to define that differently from any other Service Circle.

James

Open Domains is a new pattern, although not so new for those of you who've attended courses with us more recently. This pattern was inspired by the work of Bonnitta Roy. You can find her on Medium where she writes about Open Participatory Organisations, and within that talks about "Open Locations” a pattern for organization that can be observed, for example, in the open-source community as a way of structuring an organisation. What's significant about Open Domain is that it's invitation-based, so there's a unique area of work, decision-making, and influence, and a call to people to come and do the work and maybe governance together.

Besides seeing this pattern in the open-source community where there is a fluid membership for a whole organization, we can also observe this pattern is within organizations too. It's basically a way to use the notion of invitation to invite people to get work done within a specific domain. As a Circle, for example, this could be a helpful strategy. If you've got a driver on your backlog and you define the domain, you put a call out to people with expertise and interest who do that work, while you monitor the progress of that work over time.

Bernhard:

Experience shows that Open Domain is best used in cases where there are people in an organisation who care about the domain, because then they are going to contribute. An example of when it would be less useful would be in an organization where there is, for example, a kitchen that needs cleaning but nobody actually cares about that. In this case you would prefer another pattern over Open Domain.

Patterns we renamed or dropped

Bernhard:

We’ve found that it helps understanding if the name of a pattern communicates the essence of that pattern and puts emphasis on the suggested action, using for example, words like describe, clarify, respond, develop for example.

With this in mind we renamed Domain Description to Clarify Domains. The new name makes it much more apparent what's actually happening, that through creating a domain description, a domain is clarified. We also refined the description of the pattern to make it more explicit how organisations benefit from clarifying domains and what information can be helpful to include in the description.

We renamed the pattern Strategy to Develop Strategy to put emphasis on the process that a strategy is not just created, but is also evolved over time and adapted to what's happening. That strategy is a living thing and not static. I think the new name gives a much clearer impression of that.

We also renamed what was called a Backbone Organisation to Service Organisation because this new name is more descriptive, and also highlights the similarity to the pattern Service Circle.

We renamed the Effectiveness Review to Peer Review to put emphasis on the fact that the review is done by peers and not, for example, by a boss.

James:

We dropped the pattern Coordination Circle because we realized it's just another Circle with a specific service function, so people can use the pattern Service Circle. A service in the sense that they are providing a certain function that is needed in the organisation in service for other domains. For those of you with a background in SCM, a "general circle." also falls under the category of Service Circle.

Lili:

We’d previously referred to driver statement in the illustration of all the patterns but there wasn't actually a description of this in the guide. When we started describing the pattern we realized that Describe Drivers is a clearer name for the pattern and that writing a driver statement is a helpful way to do this.

Also, the pattern Respond To Organisational Drivers now includes a part about qualifying drivers. We realised these two patterns belong together, so if a driver is qualified then it becomes and organisational driver. So we’ve included qualifying drivers as an explicit step.

James:

We made some changes to the Objection pattern too. A concern I've had about objections relates to how people qualify them. Historically with sociocracy I’ve observed cases where people argue that they have an objection that has to be considered, but it’s not actually yet clear if the argument is valid or not. In S3 we’d described a way of doing that by inviting people to consider whether doing something or continuing to do it would cause harm to the organization, or miss a chance to improve things that could be immediately integrated, but we wanted to make that even more explicit. We clarified that the people accountable for an action or proposed agreement are responsible for considering arguments and addressing qualified objections, and also inviting people to distinguish between an argument indicating a potential objection and an objection that's been qualified.

On the topic of Resolve Objections, we've updated the illustration to better reflect the process. Because we invite people to take one objection at a time and amend the proposal to integrate wisdom revealed, we have endeavored to make this more clear, along with the suggestion to check for objections to an amendment, followed by zooming out to the whole proposal again to see if there's any further objections to the whole proposal.

We find that following the pattern in this fractal way always bring you through resolving objections, but derailing from the pattern and not following it through from beginning to end can mean people get into confusion when things get complicated. So, the invitation is, follow the pattern!

Bernhard

Next up is the Development Plan where we have refined the template and the description of what goes into a development plan. We also clarified that the development plan requires consent from both the delegator and the delegatee to be put into action.

We made some changes to Evaluate Agreements, aligning the questions for evaluation with what happens in the Peer Review pattern. The Peer Review is a simple and elegant way to help people make sense of what a Role keeper does well and what might be improved and the same way of thinking can be applied to evaluating an agreement. The questions then are, “how did this help us?” and “what needs to be changed for the agreement to become more helpful to us?” I think these kinds of tweaks help make S3 simpler and more coherent, and as a consequence easier for people to learn and to remember.

Lili:

Regarding the Proposal Forming pattern, we specified criteria for selecting tuners. We realised we were using these criteria anyway and found it helpful to make it explicit for people. We also added a dedicated step for “prioritising considerations”, which in many cases is also valuable to do.

With Rounds, we clarified why a group might use rounds and we removed some of the ambiguities about how to facilitate them.

With Artful Participation and Peer Review we also made some minor changes to how they are described.

In closing

That covers most of the changes we made, with the exception of inconsequential adjustments to some words and terms here and there.

The content of S3 is is based on observations of what people do in organisations in various contexts. We’d like to invite you the reader to remember you are always welcome to get in touch with us to share any possible objections or concerns you have to these patterns as they are currently described or formulated.

We can only do so much is evolving and maintaining the integrity of S3 ourselves and it's predominantly through application in practice and feedback from others that we are learning about S3 and how to describe it to others in an effective way. Your help is gratefully received.