Wie sich VSHN mit Hilfe von Soziokratie 3.0 entwickelt

Als wir über 25 VSHNeers (so nennen wir unsere Mitarbeiter) hinauswuchsen, erkannten wir mehr und mehr Aspekte, die uns daran hinderten, die Bedürfnisse unserer Kunden zu erfüllen, innovative neue Produkte zu entwickeln oder unsere einzigartige Mitarbeiterkultur zu erhalten. Je größer wir wurden, desto mehr glaubten wir, dass wir die Organisation weiterentwickeln müssen, um fit für die Zukunft zu bleiben. Hier geht es um die ersten Schritte auf unserer Reise, wie Sociocracy 3.0 uns hilft, unsere Organisationsstruktur weiterzuentwickeln, Menschen zu befähigen und den Kundenservice zu verbessern.

VSHN automatisiert Software Build, Deployment, Provisioning, Backup, Observability, Alerting und Incident Management für Produktionsanwendungen in jeder Cloud mit 24/7-Support. Eine Top-Down, “waterfall” ähnliche hierarchische Organisation hätte uns wahrscheinlich nicht geholfen oder dorthin gebracht. Wir haben immer auf eine sehr agile und demokratische Weise gearbeitet. Außerdem glauben wir, dass Menschen ihr Bestes geben, wenn die Organisation sie effektiv dazu befähigt. Die meisten organisatorischen Veränderungen wurden einfach durch Bauchgefühl und Gespräche untereinander durchgeführt.

Identifizieren von Problembereichen

Wir hatten das Gefühl, dass es nicht mehr skalierbar oder vorteilhaft ist, unsere Tech-Teams nach Technologien zu organisieren (wie OpenShift oder Puppet Managed Services). Diese Trennung funktionierte gut, solange die Kunden den einen oder anderen Technologie-Stack verwendeten. Die heutigen Kunden profitieren von allen Technologien, in denen VSHN Expertise hat. Infolgedessen wurden die Kunden von zwei oder mehr Teams bedient. Um diesem Mangel an Kundenzugehörigkeit etwas entgegenzuwirken, haben wir das Konzept der Service-Manager eingeführt, die die Verantwortung für einen Kunden über mehrere Teams hinweg übernehmen.

• Letztlich führte dies immer noch dazu, dass die Kunden uneinheitlich bedient wurden. Die Kunden mussten mit zwei oder mehr Teams in Kontakt sein. Beides ist keineswegs effizient oder kundenfreundlich.
• Die Teams fühlten sich manchmal von den Service Managern kontrolliert und überstimmt. Es führte auch zu einer Art „Kampf“ zwischen den Service Managern, wer zuerst die Hilfe eines Teams erhält.
• Die Teams konnten auch nicht selbst entscheiden, wie sie einen Kunden am besten bedienen oder ihre Arbeitsmethoden ändern.
• Das Tagesgeschäft und Kundenprojekte hatten meist Vorrang vor der Produktentwicklung. Das lag daran, dass es keine klare Trennung zwischen diesen Tätigkeitsbereichen gab.
• Es war oft nicht klar, wen man bezüglich eines bestimmten Produkts oder Kunden fragen musste.
• Um solche organisatorischen Gegebenheiten zu ändern, fehlten uns die Strukturen, um wichtige Entscheidungen als Unternehmen unter Einbeziehung aller Betroffenen zu treffen. Dies führte dazu, dass einige Entscheidungen von Einzelpersonen getroffen wurden, was sich negativ auf einige der Teams auswirkte. Bauchgefühl war nicht mehr gut genug.

Wie Sie sehen können, war es an der Zeit, Aspekte unserer Organisation zu überdenken, um VSHN fit für die Zukunft zu machen – und um VSHNeers besser in die Lage zu versetzen, ihre Arbeit zu gestalten und auch die Kundenerfahrung zu verbessern.

Wo anfangen

Eine der ersten organisatorischen Änderungen, über die wir nachdachten, war die Organisation unserer Teams nach Kunden und Produkten statt nach Technologiegruppen. Eine Idee, die bereits auf dem VSHNDay 2019 aufkam.

• Wir wollen mehrere funktionsübergreifende Customer Solution Teams, denen jeweils eine Gruppe von Kunden zugeordnet ist. Das bedeutet, dass ein Kunde ausschließlich von einem Team betreut wird. Mit dem Service Manager als vollwertiges Teammitglied könnte das Team selbstständig über die Arbeitsmethoden, die Arbeitsplanung und die geeignetsten Lösungen für ihre Kunden entscheiden, um den bestmöglichen Service zu bieten.
• Zusätzlich wollen wir ein oder mehrere Produktteams, die jeweils für eine bestimmte Gruppe von Produkten zuständig sind. Mit dem Product Owner als Teammitglied könnte das Team autonom über das Product Backlog, Arbeitsmethoden und technische Lösungsansätze entscheiden. So könnte sich das Team voll auf seine Produkte konzentrieren, um Features zu entwickeln, Fehler zu beheben und die (Code-)Basis zu pflegen sowie die Solution Teams zu unterstützen, die ihre Produkte nutzen.

Wie machen wir das also? Ende 2019 haben wir beschlossen, dass wir anfangen werden, Muster aus Sociocracy 3.0 zu verwenden, sobald wir etwas sehen, mit dem wir uns weiterentwickeln können. Sociocracy 3.0 – oder kurz S3 – (nicht der Simple Storage Service ), weil es am besten zu dem passt, was wir bereits implizit in den letzten Jahren gemacht haben – hauptsächlich das Prinzip über Gleichwertigkeit und Zustimmung (Consent).

Autonomie von Teams

Unseren Teams einfach die Autonomie geben, das zu tun, was sie für das Beste halten, richtig? Glücklicherweise steckt mehr hinter dieser Geschichte. Wir wollen einem Team Autonomie geben, solange das Team an den übergeordneten Unternehmenszielen ausgerichtet ist, seinen Einflussbereich, seine Aufgaben und seine Grenzen kennt. Oder anders ausgedrückt: Jedes Team muss die Parameter kennen, innerhalb derer es existiert, arbeitet und als Team wachsen kann. Aber das ist noch nicht alles, jede Person oder jedes Team wird auf Situationen stoßen, die sie nicht alleine angehen oder entscheiden können. Wir brauchen Strukturen, die unsere Teams dabei unterstützen, solche Themen zu diskutieren und zu entscheiden.

Wir (und S3) nennen dies Accountability, was Autonomie und Ausrichtung beinhaltet (Autonomy and Alignment).  Um Unternehmensausrichtung und Teamverantwortung zu erreichen, haben wir herausgefunden, dass wir Folgendes brauchen:

• Für alle transparent sichtbare Ziele, die eine klare “chain of purpose“ aufzeigen: Also begannen wir mit dem Aufbau eines eigenen Alignment Framework , das sich an der Idee von Spotify Rhythm orientiert.

• Klare Beschreibungen, wofür ein Team verantwortlich ist: Hier kommen S3 Domains und Circles ins Spiel.
• Sobald wir unsere Einflussbereiche innerhalb des Unternehmens (die Domains) kannten, konnten wir herausfinden, wie sie sich zueinander verhalten oder ineinander enthalten sind. Dies führte uns zu einer klaren Vorstellung davon, wer z. B. die “Accountability“ eines Teams delegiert.

Entscheidungsfindung

Der Beginn der Transformation unserer Organisationsstrukturen verlangte von uns eine Menge Entscheidungen.

• Wir brauchten einen Weg, um diese Entscheidungen schnell zu treffen und gleichzeitig die betroffenen VSHNeers einzubeziehen.
• Wir brauchten einen Weg, um Entscheidungen über „brauchbare“ statt „perfekte“ Lösungen zu treffen.

S3 mit den Konzepten und Mustern von Consent, Navigate via Tension und Proposal Forming ist der Weg, den wir wählen, um diese Herausforderung anzugehen. Jetzt könnten wir anfangen, Entscheidungen zu treffen, die für den Moment „gut genug” und „sicher genug” sind, um es bis zur nächsten Überprüfung zu versuchen (“good enough for now, safe enough to try”).

Gut genug klingt vielleicht falsch, oder? Nicht wirklich. In der volatilen, unsicheren, komplexen und mehrdeutigen Welt, in der wir leben, gibt es nie einen perfekten Plan oder eine perfekte Lösung. Etwas, das wir aus der agilen Softwareentwicklung kennen. Wir wollen iterative und kleine Änderungen, schnell lernen, welche Auswirkungen etwas hat und reagieren, indem wir die nächsten Entscheidungen schnell erneut überprüfen und treffen. VSHN hat das eigentlich vom ersten Tag an gemacht – nur dass wir das jetzt für Entscheidungen mit größerer Reichweite machen müssen, die viel mehr VSHNeers und Kunden betreffen.

Der Schlüssel hier ist “Consent” (Zustimmung). Consent bedeutet nicht, dass alle einverstanden sind (oft mit Konsens verwechselt, da es Consent in Deutsch eigentlich nicht gibt), es bedeutet, etwas zu tun, außer es gibt einen Grund, es nicht zu tun, bis wir es wieder überprüfen. Ein Grund könnte sein, wenn es ein Risiko für die Organisation ist oder wenn wir eine lohnende Gelegenheit übersehen würden, den Vorschlag direkt zu verbessern.

Wer entscheidet

Alle in jede Entscheidung einzubeziehen, die wir zu treffen haben, kann die Agilität und Geschwindigkeit behindern. Darüber hinaus würde die Einbindung in zu viele verschiedene Themen auch eine hohe mentale Belastung für alle bedeuten. Der Schlüssel liegt hier darin, die Einflussbereiche der Personen durch Domains zu begrenzen, d. h. klar zu machen, welche Entscheidungen in die Verantwortung welcher Gruppe fallen.

Als Antwort darauf adaptieren wir auch das S3-Konzept der Delegate Circles. Hier senden alle Teams, die betroffen wären, einen Vertreter, um einen „virtuellen“ Kreis zu bilden. Die Delegierten können dann im Namen ihrer Teams Entscheidungen treffen. Hier geht es um Vertrauen – die Mitarbeiter sollen ihrem Delegierten oder anderen Teams oder Gruppen, die für andere Bereiche im Unternehmen zuständig sind, vertrauen können. Im Gegenzug haben sie die Gewissheit, dass sie sich nicht selbst um alles kümmern müssen, was in Ihrem Unternehmen vor sich geht – in dem Wissen, dass sie letztlich immer eine Möglichkeit haben, einen Einwand gegen eine vergangene Entscheidung, eine bestehende Vereinbarung oder eine Aktivität vorzubringen.

Sociocracy 3.0 (S3) in a Nutshell

Sociocracy 3.0 (S3) ist eine soziale Technologie für die Entwicklung von agilen und belastbaren Organisationen jeder Größe, von kleinen Start-ups bis hin zu großen internationalen Organisationen. S3 ist:

• Flexibel: anpassungsfähige, unabhängige und sich gegenseitig verstärkende Muster, die Sie bei allen Aspekten der Zusammenarbeit unterstützen
• Prinzipien-basiert: ein kohärenter Weg für das Wachsen organisatorischer Integrität und die Entwicklung einer agilen Denkweise
• Frei: Sociocracy 3.0 ist frei, und lizenziert unter einer Creative Commons Free Culture license

Erfahre mehr über S3 unter: https://sociocracy30.org/

Wo wir gerade stehen und was die nächsten Schritte sind

Wir haben es geschafft, drei verantwortliche Teams zu bilden. Ein Product Team und zwei Customer Solution Teams. Der erste Rückblick auf diese Teams zeigt, dass unser Ansatz, Teams um Kunden ODER Produkte herum zu bilden, funktioniert. Die Autonomie erlaubt es unseren Teams, den bestmöglichen Weg für ihre Arbeitsweise zu finden und sich als Team zu verbessern.

Wir haben inzwischen für die meisten Bereiche von VSHN klare Domain Descriptions . Das hilft bereits anderen Teams, die nicht direkt von den laufenden Teamveränderungen betroffen sind, indem geklärt wird, wer für was zuständig ist.

Unser Alignment Framework gibt uns bereits Klarheit darüber, was VSHN eigentlich ist, was unsere Ziele sind und wie wir Funktionen und Produkte für die Produktentwicklung sowie Treiber für organisatorische Verbesserungen priorisieren.

Wir haben einen Weg gefunden, das Consent Decision Making (von Tension, Driver über Decision Making und Review von Agreements) auf eine größtenteils asynchrone und schriftliche Weise zu implementieren, was in der heutigen, fast vollständig “remote-work“ geprägten Welt wichtig ist. Wir nennen dies den VSHN Improvement Process.

Als Nebeneffekt werden wir die Begriffe Squad und Chapters los, die aus dem Spotify-„Modell“ stammen (There Is No Spotify Model).

Nächste Schritte

• Die verbleibenden alten Tech-Teams in das neue Modell der Solution Teams bringen.
• Unsere Delegate Circles sollen besser funktionieren.
• Den VSHN Improvement Process vereinfachen, um mehr ein Hilfsmittel zu sein als ein formaler Prozess.
• Sociocracy 3.0 Interne Lerngruppen und Ausbildungen – wir müssen das S3-Wissen verbreiten.
• S3 Facilitators, die mit gutem Beispiel vorangehen können. Es ist wichtig, dass VSHNeers andere VSHNeers in ihrem täglichen Arbeitsleben und bei der Entscheidungsfindung anleiten können.

Zusammenfassung – Unsere Erfahrung

Veränderung ist schwer. Aber insgesamt glauben wir bisher, dass wir auf dem richtigen Weg sind. Wir verstehen, warum wir diese Veränderungen vornehmen, gemeinsam als VSHN und unter Beibehaltung eines starken Kundenfokus.

Wir haben gelernt, dass Organisationen in zwei Bereiche unterteilt werden können. Da gibt es das System und da sind die Menschen im System. Die Menschen brauchen das System, um ihren Sinn zu erkennen, um zu wissen, wofür sie verantwortlich sind, was von ihnen erwartet wird und wo die Grenzen und Einschränkungen sind. Ohne dass die Menschen ihren Platz finden und sich dafür engagieren, dass das System funktioniert, kann das System nicht funktionieren. Wir haben uns in den letzten Monaten sehr auf die neuen Strukturen konzentriert. Jetzt müssen wir uns vermehrt darauf konzentrieren, kontinuierlich in die Menschen zu investieren, damit sie sich im System entfalten können.

Was uns an S3 wirklich gefällt, ist der iterative Ansatz. Inkrementelle Veränderungen, Experimentieren und Flexibilität kombiniert mit Consent Entscheidungsfindung – all diese Muster bilden aus unserer Sicht eine bessere Organisation. Auf der anderen Seite können sich Menschen durch inkrementelle Änderungen zwischen der alten und der neuen Welt verlohren fühlen – wir haben gelernt, dass dies ein Risiko darstellt, Menschen zu verwirren und Prozesse, die früher funktionierten, zu gefährden – es ist wichtig, die Balance zu finden zwischen kleinen, inkrementellen Änderungen und nicht den Überblick zu verlieren, wo wir hinwollen.

Was denken Sie darüber? Was sind Ihre Erfahrungen? Wir würden uns freuen, Ihre Geschichten über organisatorische Veränderungen zu hören.