Unsere initialen Erfahrungen beim Einführen von Soziakratie führten dazu, dass in jedem Kreis ein Circle Coordinator (CC) gewählt wurde und abschließend der General Circle entstand. Dieser bekam den zuvor definierten Auftrag die Domänen und Treiber für unsere Kreisorganisation zu definieren bzw. dies in die Unterkreise mitzugeben. Im Folgenden möchte ich auf den Ablauf und auf unsere Erfahrungen mit diesen beiden wichtigen Schritten zu unserer Selbstorganisation eingehen.

Wir nominieren die Circle Coordinators Bottom-Up

Der Circle Coordinator ist für die Organisation und den operationalen Betrieb eines Kreises verantwortlich. Er ist somit zuständig, die Erfüllung der Ziele des jeweiligen Kreises voranzubringen. Der CC ist zudem der Link zum Oberkreis.

Wir beschlossen mit unserer Kreisorganisation nicht auf der grünen Wiese zu starten. Somit nahmen wir die bestehenden Kreise und führten die Wahlen der Circle Coordinators bottom-up durch. Wie das ganze aussieht, möchte ich anhand unserer Kreisstruktur erklären, die in der folgenden Grafik dargestellt wird.

Kreisstruktur

Die Mitglieder der Kreise Frontend, MarketEngine und Backend wählen ihren CC. Die jeweiligen CCs dieser Kreise bilden den Kreis Tech zusammen mit einem von ihnen gewählten CC. Dieser Kreis ist somit ein Delegierten-Kreis, bestehend nur aus Vertretern der Unterkreise und einem CC. Der CC kann jedoch auch einer der Delegierten sein. Genauso wird beim Business-Kreis und seinen Unterkreisen sowie dem SPPM-Kreis verfahren. Die Circle Coordinators der Kreise Tech, Business und SPPM wählen nun einen CC und bilden zu viert den General Circle. Auch der General Circle ist somit ein Delegierten-Kreis.

Die Wahlen wurden von DDIS-Kreismitgliedern (Deep Dive Into Sociocracy) geleitet, um unsere bisherigen Erfahrungen mit in die Runde geben zu können. Die ersten Wahlen dauerten etwa 20 Minuten, da hier der Sinn und Zweck eines CC sowie der Wahlprozess/Nominierungsprozess erklärt wurde. Noch verzichten wir bewusst auf ein Double-Linking zum Oberkreis (zwei Personen, die in beiden Kreisen sind, um den Informationsfluss zu optimieren), um Komplexität zu vermeiden. Dieser soll bei Bedarf nachträglich hinzugefügt werden. Bei der Wahl wurde zudem berücksichtigt, dass Treiber und Domäne für die Kreise noch nicht explizit gemacht wurden und sich der CC somit noch zeitnah ändern könnte. Sollten sich etwa zu große Unterschiede zu den implizit in den Köpfen verankerten Treibern und Domänen ergeben, kann ein anderer CC sinnvoll sein.

Bei einer Wahl geht es immer darum eine Person für eine konkrete Rolle und einen definierten Zeitraum zu finden. In der ersten Phase nominiert jeder Teilnehmer verdeckt eine Person. Im Anschluss nennen die Teilnehmer nacheinander (-> in Runden) ihre Nominierungen und begründen, warum diese Person ein guter Kandidat für den CC sei. Die verdeckte Nominierung sorgt dafür, dass die Meinungen der anderen keinen Einfluss auf die initiale Nominierung haben. Somit kommen auch wirklich alle Meinungen und die jeweiligen Beweggründe zur Sprache. Immerhin kann jeder Input wichtig sein und sollte gehört werden. In der zweiten Phase hat jeder noch einmal die Möglichkeit seine Meinung mit Begründung zu ändern. Dies passiert diesmal nicht verdeckt. Abschließend schlägt der Facilitator eine Person aus den Nominierten für die zu wählende Rolle vor. Das muss nicht die Person mit den meisten Stimmen sein, sondern die, bei der die Argumente gefühlt am stärksten sind oder wo am wenigsten Einwände bzw. Bedenken zu befürchten sind. Einwände werden per Konsent behandelt und integriert etwa durch einen verkürzten Zeitraum bis zur Neuwahl.

Nach ein paar Wahlen brauchten wir für den Prozess nicht einmal mehr 5 Minuten. Der Prozess fühlte sich für uns sehr effektiv und wertschätzend an. Auch war durch die konkrete Benennung des jeweiligen Circle Coordinator eine Energie und Verantwortungsübernahme bei den Gewählten spürbar. Wir legten auch viel Wert darauf, die Unterschiede zwischen Freiwilligen und Nominierten zu formulieren. Dies beinhaltet bereits viele Prinzipien der Soziokratie, die ich im letzten Artikel beschrieben habe. Gleiches gilt für die initial verdeckten Nominierungen. Für die Teilnehmer bedurfte es jedoch einiger Wahlen, bis die Prinzipien wirklich verinnerlicht werden konnten. Die Schwierigkeit ergibt sich meines Erachtens daher, dass unsere sonst gelebten Prozesse sich doch stark von denen in der Soziokratie unterscheiden. Es reicht nicht aus, die Prinzipien nur erklärt zu bekommen. Es bedarf durchaus einiger Anwendung, um diese wirklich zu verinnerlichen. In unserer Kleingruppe (DDIS-Kreis) konnten wir zumindest schon Erfahrungen sammeln, in stattfindenden Kreismeetings einfließen lassen und die Teilnehmer zumindest immer wieder dafür sensibilisieren.

Treiber und Domänen mittels Driver Mapping finden ist anstrengend

Aktuell haben die einzelnen Kreise noch keinen klar definierten Sinn und Zweck, um autonom Entscheidungen innerhalb eines Verantwortungsbereiches zu fällen und Themen zu treiben. Daher entschloss sich der General Circle die Treiber und Domänen der direkten Unterkreise zu definieren, ohne dabei Überlappungen zu haben. Treiber definieren die Motivation oder Beweggründe für die Zielerreichung eines Kreises. Die Domäne beschreibt den Rahmen, in denen Entscheidungen durch einen Kreis getroffen werden dürfen. Hat der General Circle für seine Unterkreise SPPM, Business und Tech die Treiber und Domänen definiert, wird dies Top-Down weitergeführt, so etwa der Tech-Kreis für seine Unterkreise Frontend, Backend und MarketEngine. Analog wird beim Business-Kreis und seinen Unterkreisen verfahren.

Im DDIS-Kreis arbeiteten wir dafür angelehnt an Unterlagen aus S3 und SoFA einen Driver Mapping Prozess mit folgenden Phasen heraus:

  • Akteure ermitteln
  • Bedürfnisse zwischen uns und Akteuren ermitteln
  • Treiber und Domänen ableiten

Der ausgearbeitete Driver Mapping Prozess ist durch die folgende Grafik mit Beispielen veranschaulicht und wird für jeden Kreis einzeln durchgeführt. In den folgenden Abschnitten möchte ich noch etwas detaillierter auf die einzelnen Phasen und unsere Erfahrungen eingehen.

Driver-Mapping

Wer sind unsere Akteure?

Die Akteure definierten wir dabei in Runden, wobei der Moderator alles mitschrieb. Das fühlte sich schnell sehr zäh an, so dass die Teilnehmer dann selbst ihre Einfälle auf Post-Its schrieben. Das ging etwas schneller. Durch die Runden war klar ersichtlich, wer wann dran ist, und es war sehr fokussiert und strukturiert.

Was sind die Bedürfnisse?

In der zweiten Phase des Prozesses nutzten wir auch wieder Runden und Post-Its, um konkrete Bedürfnisse zwischen uns und den zuvor bestimmten Akteuren zu definieren.

Diese Phase fühlte sich sehr lang und anstrengend an. Es kamen teils sehr viele Bedürfnisse heraus. Zudem musste bei jedem Akteur stark umgedacht werden und somit waren viele Kontextwechsel nötig. Für diesen Prozessschritt benötigten wir auch die meiste Zeit.

Um ein Gefühl für den Umfang zu bekommen, möchte ich den aktuellen Stand der Akteure (rosa) und Bedürfnisse (gelb) für den Business-Kreis im folgenden Bild darstellen.

DriverMappingBizz_

Was lange währt wird endlich Treiber und Domäne

Beim letzten Prozessschritt suchten wir vor allem nach Mustern in den Bedürfnissen, die auf einen konkreten Treiber schließen ließen. So traten manche Bedürfnisse bei mehreren Akteuren auf. Daraus ließ sich dann meist ein Treiber ableiten und/oder unter Zunahme anderer Bedürfnisse noch konkretisieren.

Aufbauend auf das bisherige Wissen konnten wir nun die Domäne klären. Die Überlappungsfreiheit musste noch einmal geprüft werden, sobald die Domänen für alle Unterkreise definiert war.

Die Phase der Ermittlung von Treiber und Domäne gestaltete sich als etwas schwieriger als die vorherigen Phasen, da das Vorgehen hier nicht so konkret definiert war. Wir mussten aus den vielen Informationen (Post-Its an einer Wand) Gemeinsamkeiten erkennen. Jedoch war in dieser Phase auch die meiste Energie seitens der Teilnehmer spürbar, da diese nun kreativer werden konnten.

Es war ein langer Weg, doch wir sind über dem Berg :)

Insgesamt hat sich der gesamte Driver Mapping Prozess für uns auch nach Durchführung für 3 Kreisen sehr zäh angefühlt. Das kann an der fehlenden Erfahrung liegen, und dass wir den Prozess selbst erst durchleben mussten. Wir brauchten pro Kreis etwa zwei bis vier Stunden. Die Teilnehmer waren jedoch sehr zufrieden mit dem Ergebnis. Ein Vorteil im Rahmen unserer Kreisorganisation ist auch, dass hier nur wenige Teilnehmer waren und somit nicht alle an diesem zähen Meeting beteiligt waren. Wir sparten somit viel Zeit und Nerven. Zudem können sämtliche Informationen für das Driver Mapping der Unter-Unterkreise wiederverwendet werden. Dabei wird dann voraussichtlich eine Submenge der Akteure und Bedürfnisse benötigt und aus diesen werden dann Treiber und Domäne für die Unter-Unterkreise ermittelt.

Als nächstes müssen die Treiber und Domänen noch einmal in einem Proposal formuliert und per Konsent im General Circle verabschiedet werden. Dann können die Unterkreise wiederum für ihre eigenen Unterkreise die Treiber und Domänen definieren.