Die Entdeckung eines evolutionären Algorithmus
– Brian Robertson (HolacracyOne)
Übersetzung: Dennis Wittrock; Originaltext: hier
Ich kämpfe oft damit, wie ich die Geschichte der Entwicklung von Holacracy auf eine Weise vermitteln kann, die sowohl ihren vielen Einflüssen als auch dem Ursprung ihrer Neuartigkeit Rechnung trägt. Die Herausforderung stammt zum Teil aus der schieren Anzahl der Einflüsse und der Tatsache, dass Holacracy aus einer kombinierten Suppe all dieser, statt durch die Erweiterung einer oder zwei Vorläufer erwachsen ist. Doch eine noch größere Herausforderung stammt aus der Natur von Holacracys Entwicklungsprozess selbst, und wie er sich von dem unterscheidet, was die Leute annehmen, inklusive mir.
Viele Methoden, denen mir begegnen, scheinen von jemandem erschaffen und verfeinert worden zu sein, der ein Bündel von Ideen oder Kernprinzipien genommen hat und ein System um sie herum konstruiert hat, um diese Prinzipien zu verkörpern und auszudrücken. So hat Holacracys Entwicklung in ihren frühen Jahren ebenfalls begonnen (vor der Verfassung). Doch an irgendeinem Punkt begann ich zu realisieren, dass Regeln und Methoden, die meinen Ideen und Prinzipien entsprangen, meiner ultimativen Suche nach einer besseren Art und Weise eine Firma zu organisieren in Wirklichkeit im Wege standen. So wie ich es heute formulieren würde, habe ich aus dem Verstand designt, statt einen stärker empirischen Designprozess freizusetzen, der durch echte Spannungen geleitet wird – wie der Leader, der versucht, ein Design auf seine Organisation anzuwenden, anstatt das Design in dem evolutionären Prozess emergieren zu lassen, den Holacracy der Organisation einflößt.
Das Gründungsteam von HolacracyOne auf unser ersten Speaking Tour in Europa 2008, zusammen mit unserem Gastgeber Dennis Wittrock (links)
Um mein ultimatives Ziel zu erreichen, musste ich meine Ideen darüber loslassen, wie das System aussehen würde und welche Prinzipien sich darin zeigen würden. Ich musste meine Antworten loslassen, um meiner Frage mehr Aufmerksamkeit schenken zu können. Und meine Frage war einfach: Im Kontext der Arbeit in einer Organisation – was steht der Wahrnehmung von etwas, das besser sein könnte, im Weg, und dem Handeln aus diesem Gewahrsein heraus, um einen Schritt nach vorne zu machen? Und dann: Wie können wir das grundlegende Systemdesign weiterentwickeln, um dieses Hindernis zu beseitigen? Ohne schon eine Antwort anzunehmen wurde es mein Job, einfach zu experimentieren – eine hypothetische Antwort zu geben, sie in der Realität zu testen, Feedback zu bekommen, und dann das System weiterzuentwickeln, während ich lernte, was funktioniert. Statt “meine Idee” aufzubauen, wie Firmen funktionieren “sollten”, suchte ich nach dem natürlichsten Weg ein System zu strukturieren, um individuelle Spannungen zu verarbeiten, um den Sinn und Zweck (Purpose) einer Organisation auszudrücken.
Die Holacracy Verfassung codiert das System, das aus dieser experimentellen und durch Evolution angetriebenen Reise entstanden ist. Und das Resultat überrascht mich fortwährend weiter – das ist nicht das System, das ich mir vorgestellt hätte, und ich kann Prinzipien daraus entnehmen, an die ich vorher niemals gedacht hätte, ihr sie überhaupt einzuflößen. Während ich also sicherlich eine zentrale Rolle in der Entdeckung und der Erfassung der Regeln von Holacracy gespielt habe, war der Prozess eher wie die Entdeckung von Grundregeln der Physik, mit Hilfe einer Menge von Experimenten.
Dieser Entdeckungsprozess ist auch ein fortdauernder – ich mache mir keine Illusionen, dass wir die natürlichste Weise der Organisation komplett verstehen und ich glaube, dass das ohnehin ein bewegliches Ziel ist, während Menschheit und Technologie weiter ko-evolvieren. Während ich dies schreibe, befindet sich Holacracy bei Version 4.0 – was bedeutet, dass die Holacracy Verfassung sich in Version 4.0 befindet – und ich habe keinen Zweifel, dass wir zukünftige Versionen sehen werden, während wir kontinuierlich die Regeln dieses Spiels im Lichte realer Spannungen, die aus der Anwendung von Holacracy entstehen, weiter evolvieren. In der Tat habe ich bereits viele Seiten nuancierter Notizen, die Spannungen von mir und anderen in Bezug auf die tatsächliche Anwendung der Kernregeln von Holacracy beschreiben, welche großartigen evolutionären Treibstoff für Holacracy v5.0 und darüber hinaus darstellen sollten.
Nachdem ich diesen ganzen Rahmen gespannt habe, werde ich nun ein wenig von Holacracys Vorgeschichte berichten, insbesondere aus den frühen Jahren vor Holacracy v1.0, was ich als den Launch der ersten Holacracy Verfassung in 2009 definiere. Mein Ziel ist dabei, ein Gefühl davon zu vermitteln, was dazu geführt hat und was sie beeinflusst hat, sowie die vielen Denker, Praktizierenden, Methoden und Modelle zu ehren, die Wasser auf die Mühlen von Holacracys Evolution waren und ultimativ zu dem beigetragen haben, was sie heute ist.
Die Suche nach dem Code
Es ist schwer zu sagen, wann genau meine Suche nach dem “Code” für Holacracy wirklich begann, doch weil ich irgendwo mit meiner Geschichte anfangen muss, wähle ich März 2001. Ich hatte gerade einen gut bezahlten Job verlassen und Ternary Software gegründet, ein Start-up, das ich in den nächsten sieben Jahren als ein Experimentierfeld für neue Organisationsmethoden nutzen würde. Wir durchliefen in diesen Jahren mehrere Iterationen der Erfassung des Sinn und Zwecks der Firma. Die meisten von ihnen waren Spielarten von “erschaffe das gesundest-mögliche System, in dem Menschen aufblühen”, was den Geist dieser Firma ziemlich gut abbildete, obwohl wir irgendwann die Worte fanden, die es für mich am besten erfassten: “Es muss einen besseren Weg geben – finde ihn, erschaffe ihn, lebe ihn.” Ich gründete diese Firma, weil ich hungrig war nach besseren Wegen der Zusammenarbeit und ich wollte ein Laboratorium haben, um sie zu finden.
In der Anfangszeit der Firma experimentierten meine Mitgründer und ich mit eher konventionellen Methoden eine postkonventionelle Firma zu führen. Wir entdeckten und erfassten unseren Sinn und Zweck (Purpose), wir definierten die Werte der Firma, wir konzentrierten uns unablässig darauf, unsere Kultur um diese Werte herum zu entwickeln, wir sahen uns nach jeder Gelegenheit um, um Menschen zu empowern, Menschen zu unterstützen, selber bewusstere Leader zu sein, und eine Atmosphäre des Lernens und der Entwicklung zu erzeugen. Ich verschlang jedes Buch, das ich darüber finden konnte, wie man eine bessere und mehr empowernde Firmenkultur aufbaut, und die Arbeit von Jim Collins, Peter Senge, Barry Oshry, Patrick Lencioni und mehreren anderen waren einflussreich in der Anfangszeit. Ich versuchte auch mein bestes, um die Lektionen zu integrieren, die ich von Linda Berens gelernt hatte, eine Leaderin in der Wissenschaft psychologischer Typenmodelle und der Nutzung der individuellen Unterschiede von Teammitgliedern – viele unserer Experimente wurden in Hinsicht auf das Kriterium geprüft, “integriert das die Kern-Stärken/-Energien, die von allen Typen von Menschen eingebracht werden, oder gibt es eine Voreingenommenheit für nur einen Teil davon?”
Nach ein paar Jahren hauptsächlich kultureller Experimente, wurde deutlich, dass wir uns auf auch auf die Ebene des Prozesses konzentrieren mussten – wir wuchsen recht schnell, und der Mangel an Klarheit in Fragen von Struktur, Prozess und Entscheidungsfindung wurde langsam schmerzhaft. Ich hatte die Agile Software Development Bewegung von Anbeginn an verfolgt und betrachtete sie als einen Riesensprung nach vorne, sowie als natürlichen Startpunkt für einen Softwarefirma auf der Suche nach neuen Wegen der Organisation. Entsprechend konzentrierten wir uns 2003 darauf, so viel wie möglich aus den Prinzipien und Praktiken des Agile Software Development in die Firma zu integrieren. Agile fordert selbstorganisierte Teams mit der Macht, Entscheidungen darüber zu treffen, wie sie zusammenarbeiten wollen, um Resultate zu liefern, weshalb wir die Firma als eine Sammlung selbstorganisierter Teams strukturierten und so gut wir konnten aus dem Weg gingen. Agile fordert adaptives Planen und Antworten auf Veränderungen anstelle von voraussagenden Planen und Kontrollmechanismen, und es bietet eine Menge konkreter Prozesse, um diese Prinzipien auf der Ebene der Softwareentwicklung umzusetzen, also übernahmen wir sie und passten sie auf unseren Kontext an. Agile fordert visuelle Projekt Boards und Informationstransparenz, was wir uns zu Herzen nahmen – unsere Wände bestanden teilweise vom Boden bis zur Decke aus Cork-Boards, vollgepackt mit nützlichen Projektdaten. Und Agile fordert einen Feedback-getriebenen, evolutionären Ansatz für Design und Lieferung, um Kunden mit einem kontinuierlichen und empirisch gegründeten Wertstrom zu versorgen, weshalb wir das auf der Prozessebene und in der Kultur integrierten.
Die Wirkung unseres tiefen Eintauchens in Agile Software Development ging weit über das schlichte “wie wir unsere Software bauen” hinaus – sie floss in unsere Kultur ein und gab uns auch eine Grundlage von Prinzipien und Praktiken für das Management der Firma. Die folgenden, mehreren Jahre taten wir unser Bestes, um dieses Paradigma in allem auszudrücken, was wir taten. Agile Prinzipien wurden unser Wegweiser und ein Maßstab für alle unsere zukünftigen Experimente, genauso wie die sich hochgradig überlappenden Prinzipien der Lean Bewegung. Letztendlich pflanzte Agile auch einen Samen der Wertschätzung für die unglaubliche Kraft und Befreiung, die durch Disziplin und Klarheit kommt und das wurde noch verstärkt und vertieft durch meine eigene Praxis von David Allens Getting Things Done Methode (“GTD”), die ebenfalls zu dieser Zeit begann. Die Suche nach tieferen Ebenen der Disziplin und Klarheit sollte ein bedeutsamer und fortwährender Antrieb für weitere Prozess-Experimente werden, und mein Verständnis ihrer Wichtigkeit und ihres Potenzials begann mit Erfahrung aus agilen Methoden. Die Arbeit vieler Praktizierender in diesem Umfeld war ebenfalls einflussreich während dieser gesamten Phase der Aufnahme und Anwendung agiler / Lean Prinzipien und Praktiken, inklusive der Schriften und Lehren von Kent Beck, Ken Schwaber, Jeff Sutherland, Mike Cohn, und Mary Poppendieck, neben anderen.
Parallel zu unserem Fokus auf agile Praktiken begann wir zusätzlich mit verschiedenen Gruppenmoderations- und Entscheidungsfindungsmethoden zu experimentieren, um mehr von der Selbstorganisation zu ermöglichen, die wir suchten. Wir begannen mit dem Facilitator’s Guide für partizipatorische Entscheidungsfindung von Sam Kaner, neben unseren eigenen, selbst entwickelten Ansätzen aus agilen Praktiken, zusammen mit einigen von Peter Senges Unterscheidungen. Diese frühen Experimente sollten ultimativ zu Holacracys integrativen Entscheidungsfindungsprozess führen, obwohl von diesen aus dort anzukommen noch eine lange Reise sein sollte – und es gab einige wirklich mühsame Meetings entlang des Weges. Eine besonders eindrückliche Erfahrung war der Versuch, Ende 2004 eine Firmen-Mission mithilfe eines strukturierten Konsensprozesses festzulegen. Obwohl er uns letztlich zu einem ansehnlichen Ergebnis brachte, war die Anstrengung, um dorthin zu gelangen, ziemlich intensiv. Das ließ mich hungrig danach, effizientere Prozesse zur Integration multipler Perspektiven zu finden, und einen Weg, um diejenigen herauszufiltern, die für den Sinn und Zweck (Purpose) der Organisation relevant sind, während er sie vor den persönlichen Wünschen und Egos schützt, die in jeder menschlichen Unternehmung eine Rolle spielen.
Als ein nächster Schritt in Richtung dieses Ziels googelte im Dezember 2004 einer meiner Mitgründer “kollaborative Entscheidungsfindungsmethoden”, in der Hoffnung, andere Prozesse zum Experimentieren zu finden. Durch diese Suche entdeckte er Soziokratie, eine Organisationssystem, das in den 1960er und 70er Jahren durch Gerard Endenburg entwickelt wurde, der in einer Elektrofirma, die er in den Niederlanden führte, mit alternativen Managementtechniken experimentierte. Es gab so viele Ähnlichkeiten zwischen Soziokratie und dem, was wir zu dieser Zeit bereits taten, plus einige interessante Ideen, die neu für uns waren. Unser Fokus auf selbstorganisierte Teams aus agilen Methoden tauchte auch in Soziokratie auf unter der Bezeichnung “Kreise” – das ist der Ursprung dessen, woher Holacracys Verwendung des Begriffes ursprünglich kam, obwohl die Definition, die in Holacracy verwendet wird, sich von der Bedeutung in der Soziokratie unterscheidet. Soziokratie war ebenfalls um die Prinzipien herum gebaut, die eine adaptivere Weise der Steuerung ermöglichen, wieder ähnlich dem, was wir den agilen Techniken entnommen hatten – tatsächlich tauchte dieselbe Steuerungsmetapher eines natürlich schwankenden Fahrrads, die ich ursprünglich in der Agile Community gefunden hatte, ebenfalls in einem der Bücher über Soziokratie auf. Während Soziokratie im Vergleich zu dem, was agile Methoden boten, einiges der Tiefe und der konkreten Umsetzung dieser Prinzipien vermissen ließ, bot es eine neue Idee, die ich noch nirgendwo anders gesehen hatte: das Konzept eines gewählten Rep Links, der an den Meetings des übergeordneten Kreises teilnimmt. Diese Idee erwies sich in unseren Experimenten als ziemlich nützlich und taucht bis heute in Holacracy auf. Und schließlich beinhaltete Soziokratie einen strukturierten Entscheidungsfindungsprozess, auf Grundlage auf der Erlangung von “Konsent”, was dem ähnelte, mit dem wir zu der Zeit bereits experimentierten, doch das effektiver erschien.
All das sah vielversprechend aus und ich freute mich, dass wir ein System gefunden hatten, das erfasste und ergänzte, was wir bereits taten, was wir zuvor einfach “The Ternary Way” genannt hatten. Im Januar 2005 machten wir unsere Experimente weiter, indem wir die restlichen Praktiken von Soziokratie übernahmen, wobei wir die Bücher von Endenburg als unseren Lehrer und Leitfaden benutzten. Diese Phase dauerte von 2005 bis 2006 hinein, wobei ich Soziokratie in vielerlei Hinsicht als einen großen Schritt nach vorne schätzen lernte, obwohl es letztlich auch nicht das war, wonach ich suchte. Ihre Konsent-basierte Schwelle für Entscheidungsfindung und der Mangel an Kriterien in Bezug darauf, welche Bedenken gültig waren, um sie in den Prozess zu bringen, ließ viel Raum für unbewusste Verschmelzung von persönlichen und organisationalen Interessen, und erlaubte dem alltäglichen Ego die organisationale Entscheidungsfindung zu infiltrieren und zu verlangsamen. Während Soziokratie einen inklusiven und gut strukturierten Entscheidungsfindungsprozess bot, sowie einen strukturellen Link, um Feedback in der Organisation nach oben zu bewegen, beließ sie uns in einem stark persönlichen Paradigma der Organisation um die Menschen herum statt der Organisation um die Arbeit herum, zumindest nicht in dem Maße, wie ich das von dem hochgradig pragmatischen Fokus unserer agilen Methoden her kannte. Soziokratie verlässt sich zudem auf eine konventionelle Management Hierarchie und Manager, die außerhalb der gelegentlich stattfindenden speziellen Meetings, in denen der Konsent Prozess für jede Entscheidung verwendet wird, die Macht innehaben. Während das ein Schritt in Richtung verteilter Befugnis für uns darstellte, war der Mangel einer “Sprache von Mustern” zur Definition darüber, wo die Befugnis für alltägliche operative Entscheidungen liegt, eine große Limitierung für das Erreichen wahrer organisationaler Klarheit, und verhinderte die Differenzierung von Mensch und Organisation, die wir suchten. Natürlich kannte ich auch keinen anderen Ansatz, der diese Probleme gelöst hätte, weshalb das weniger ein Fehler der Soziokratie, als vielmehr eine ungelöste Herausforderung war.
Insgesamt bot uns Soziokratie einige großartige Teile unseres Puzzles und einen guten nächsten Schritt, doch es war beschränkt auf eine Management Hierarchie, umhüllt von einem Konsens-ähnlichen Entscheidungsprozess für Gruppen. Je mehr ich in der Umgebung lebte und arbeitete, die sie erschuf, desto mehr glaubte ich, dass ich mein Ziel weder durch eine konventionelle Management Hierarchie, noch durch irgendetwas, das als konsens-ähnlich beschrieben werden konnte, erreichen würde. Ich suchte ein System, das mehr Autonomie, mehr Purpose-Orientierung und schnellere Entscheidungsfindung und Evolution erlaubte, als ich finden konnte – weder bei Top-Down Managern, die das Handeln vorschreiben, noch in einer Kultur und einem Prozess, der um eine “Tyrannei des Konsens” konstruiert war, wie ich die Nachteile von personenorientierten Methoden der Gruppenentscheidung schließlich nennen sollte, die ich bis dato erfahren hatte, einschließlich Soziokratie. Mit zunehmender Zeit und Praxis erkannte ich, dass wir ein umfassenderes organisationales Betriebssystem brauchen würden, welches es ermöglicht, rollenbasierte operationale Befugnisse und Erwartungen zu klären und zu verteilen. Ohne Befugnisse, die klar in Rollen anstelle einer Hierarchie von Menschen verteilt waren, konnten wir nur uns auf dasjenige berufen, “was der Chef entscheidet” oder “was die Gruppe entscheidet”, was ich gleichermaßen unbefriedigend fand. Ich erkannte zudem, dass wir einen weniger persönlichen Prozess brauchen würden, um diese Rollen zu definieren, mit hinreichend eingebauten Unterscheidungen, um sicher zu stellen, dass nur organisational relevante Perspektiven auf die Entscheidungsfindung einwirkten.
Und so, als wir damit anfingen, uns Veränderungen der Kernaspekte unseres Prozesses anzuschauen und signifikante neue Teile zu entwickeln, realisierte ich Anfang 2006, dass, was wir machten weiterhin “Soziokratie” zu nennen, irreführend und ungenau war und dass es das immer mehr werden würde, während wir unsere intendierten Veränderungen einführten. Wir brauchten einen Namen für das System, das wir entwickelten. Nach einigem Brainstorming landeten wir bei “Holacracy” als führenden Kandidaten und dann nahmen wir ihn einige Monate später formal an. Er erfasste den Geist dessen, wonach wir suchten – Governance der und durch die organisationale Holarchie; mithilfe der Menschen, doch nicht Governance der oder für die Menschen. Es hatte zudem den Vorteil ein komplett neu erfundenes Wort zu sein – es gab exakt null Google-Treffer für “Holacracy” als wir es benannten, was uns ein vollkommen unbeschriebenes Blatt gab, um zu beginnen, der Welt unsere intendierte Bedeutung dieses neuen Begriffes darzulegen, und was von dem Betriebssystem zu erwarten war, welches er kennzeichnete.
Unter diesem neu geprägten Namen experimentierten und entwickelten wir unser System den Rest des Jahres 2006 und mehrere weitere Jahre weiter, bevor wir die Version 1.0 der Holacracy Verfassung tauften. Die meisten unserer Versuche auf dieser Stufe konzentrierten sich auf zwei miteinander verwandte Fronten. Zuerst fingen wir damit an, eine Sprache von organisationalen Mustern zu erschaffen, um eine Struktur klarer Rollen mit klaren Erwartungen und Befugnissen zu erfassen, alles differenziert von den involvierten Menschen. Und als zweites begannen wir damit, die Regeln der moderierten Entscheidungsfindungsmethode, die wir verwendeten, weiterzuentwickeln, um diese organisationale Struktur zu generieren und zu evolvieren, so dass organisational relevanten Perspektiven, auf die Struktur einzuwirken konnten, jedoch ohne, dass das Ego oder persönliche Wünsche in die Quere kamen. Unsere Bemühungen, eine klare Sprache von Mustern für organisationale Struktueren zu erschaffen, waren durch mehrere Modelle beeinflusst, darunter Ken Wilbers integrale Theorie, welche einige großartige Erkenntnisse und Unterscheidungen in Bezug auf natürliche Holarchien bot, und Elliot Jaques Modell der erforderlichen Organisation, welches einige großartige Erkenntnisse und Unterscheidungen in Bezug auf Arten von Erwartungen und Strukturen in Organisationen bot. Irgendwann landeten wir bei einer initialen Version der Struktur, die man heute in Holacracy sieht, obwohl die Bedeutung jedes Elementes einer Rollendefinition nicht völlig geklärt war, bis die Verfassung entworfen war. Selbst danach tauchte insbesondere das Feld der “Domäne” und seine besondere Bedeutung für Befugnis erst wirklich in der Version 3.0 der Verfassung (unter dem Begriff “Umfang”) auf, und war nicht komplett ausgearbeitet bis zur Version 4.0. Ich bin nicht sicher, ob ich frühere Versionen von Holacracy wirklich als ein System verteilter Befugnis kategorisieren sollte, denn Domänen bilden die Grundlage von Holacracys System der Besitzrechte und das ist eine grundlegende Komponente für jegliche Gesellschaft, die die Autonomie ihrer Vertreter wirklich respektiert.
Zusätzlich zur Evolution der Struktur und Muster-Sprache von Holacracy geschah eine parallele Entwicklung in den Regeln der Entscheidungsfindung und der Prozesse für Governance. Diese Evolution wurde hauptsächlich durch meine eigenen Beobachtungen und Experimente in der Praxis angetrieben, da ich keine andere Arbeit fand, die mir viel Hilfe bot – es schien, dass ich eine Herausforderung anging, die auf subtile, doch bedeutsame Weise anders war, als dasjenige, worauf sich die meisten Entscheidungsmethoden konzentrierten. Schließlich entwickelte ich eine frühe Version von Holacracys integrativen Entscheidungsfindungsprozess. Er nutzte eine Reihe von mechanischen Schritten, die dem Konsent-Prozess der Soziokratie ähnlich waren, doch mit anderen Unterscheidungen und Regeln in jedem von ihnen, und einem anderen Stil der Moderation (Facilitation). Diese Regeln codierten Holacracys Fokus auf eine Spannung zur Zeit, die klare Unterscheidung zwischen Governance Ergebnissen und operativen Ergebnissen, sowie all die Regeln, um herauszufinden, welche Spannungen und Einwände für die Verarbeitung durch die Organisation jetzt relevant sind. Eine frühe Rohfassung dieses Prozesses tauchte dann irgendwann Jahre später in der ersten Holacracy Verfassung auf, obwohl es bis Version 3.0 dauerte, bis die Regeln in Bezug auf Einwände klar und detailliert genug wurden, um sie komplett zu erfassen und von einer lockereren Tradition der Moderation zu einem konkreten Satz testfähiger Regeln zu gelangen. Diese Regeln sollten in Verfassung 4.0 durch die Ergänzung der Regeln der Integration und der Regeln für gültige Vorschläge einen weiteren großen evolutionären Sprung erfahren, was einen evolutionär angetriebenen Entscheidungsprozess weiter zementierte, der zwar hochgradig integrativ, jedoch weniger persönlich ist, als alles andere, was mir bisher begegnet ist.
Für historische Exaktheit sollte ich erwähnen, dass die Experimente, die oben während der Stufe vor der Verfassung beschrieben worden sind, von 2006 bis 2008, in Wirklichkeit zwischen zwei Organisationen aufgeteilt waren. Die initialen Experimente geschahen bei Ternary Software, meiner Softwarefirma, wo das Experimentieren ursprünglich begann, und dann verlagerte es sich fast komplett hinüber zu HolacracyOne, einer neuen Organisation, die Anfang 2007 geformt wurde, um Holacracy weiter ausreifen zu lassen und es zur Nutzung für andere Organisation zu verpacken. Ende 2007 begann ich mich aus Ternary hinaus zu bewegen, um mich HolacracyOne in Vollzeit anzuschließen, um meine Bemühungen in einer Organisation fortzusetzen, die spezifisch dieser Arbeit gewidmet war. Für ihre Rolle in der Unterstützung der frühen Entwicklung Richtung Holacracy bei Ternary Software und dafür, dass sie mich in der Zwischenzeit (meistens) ausgehalten haben, bin ich insbesondere Anthony Moquin dankbar, welcher die Firma gemeinsam mit mir gegründet und aufgebaut hat und als entscheidender Denkpartner diente, und dann für meine andere Mitbegründerin und Frau Alexia Bowers, sowie unsere eher prozessfokussierten, agilen Software Entwickler Bill Schofield und Gareth Powell. Doch es ist schwierig nur ein paar Namen herauszugreifen – fast jeder in dieser Firma trug auf irgendeine Weise zu Holacracy bei. Sie waren allesamt großartige Sportskameraden, denn die Experimente, die letztendlich zu einem eleganten System führten waren selbst oftmals nicht elegant.
Tom Thomison (links) und ich bei einer Holacracy-Präsentation in Bremen, Deutschland, 2008
Glücklicherweise hatte mein neuer Businesspartner und Mitbegründer von HolacracyOne keinerlei Bedenken dabei, sich mit uns in den chaotischen Prozess des Experimentierens zu stürzen. Anfang 2007 gründeten Tom Thomison und ich die Firma und meine Frau Alexia kam ebenfalls dazu, um das initiale Team von HolacracyOne zu bilden und die Arbeit fortzusetzen, die wir in unserer Softwarefirma begonnen hatten. Tom war eine serieller Enterpreneur, dem ich ungefähr ein Jahr früher begegnet war, welcher ebenfalls an einem besseren Weg interessiert war, als Menschen zusammenzuarbeiten, und er agierte als nahezu perfekte Kontrastfigur für meine eigene Energie und meinen eigenen Fokus. Er hinterfragte Holacracy in einer Weise, wie niemand zuvor es getan hatte und zwang uns dazu, in mehreren entscheidenden Bereichen klarer mit ihren Regeln und Prozessen zu werden. Zudem half er mir dabei, mich auf dieselbe Weise persönlich von Holacracy zu differenzieren, wie Holacracy jetzt Gründern hilft, sich von ihren Organisationen zu differenzieren, was entscheidend für meine Fähigkeit war, sie objektiv genug in einem geschriebenen Code zu erfassen. Letztendlich war unsere Arbeitsbeziehung der primäre Impulsgeber für meinen Entwurf der Version 1.0 der Holacracy Verfassung im Mai 2009. Das zwang mich dazu, alles was wir bis zu diesem Punkt getan haben, in ein greifbares und objektiv testbares System und Regelset zusammenzuführen. Sogar trotz aller Schwächen und fehlenden Teile bedeutete das einen riesigen Meilenstein für uns und erlaubte dem System, viel leichter getestet und weiterentwickelt zu werden.
Es war an diesem Punkt in 2009 – nach der Geburt von Holacracy v1.0 und der Verfassung – als sich die Entwicklung von Holacracy wirklich beschleunigte. Über die nächsten Jahre würden wir eine Version 2.0, 2.1, 3.0 und 4.0 veröffentlichen, jede mit substanziellen Entwicklungen des Kernregelsets, getrieben durch Spannungen aus der Erfahrung in der Praxis in unserer Organisation und später mit den Organisationen unserer Kunden. Holacracys Tactical Meeting Struktur wurde ebenfalls formalisiert, erst als eine Zusatz-App für v2.0 und dann formal eingebettet in die Verfassung in v3.0 – einiges von Patrick Lencionis Arbeit stellte eine grundlegende Blaupause dar, die diese Meetingstruktur und einige ihrer Kern-Regeln inspirierte. Es war auch während dieser Phase, dass ich die Arbeiten von Nassim Taleb und Eric Beinhocker entdeckte, welche beide mein eigenes Verständnis der Bedeutung von Holacracy vertieften und wie man es erklärt, ebenso wie die Arbeit vieler anderer.
Ein weiterer Meilenstein, der in Version 3.0 erreicht wurde, war die tiefe Integration von Holacracys Befugnisstruktur mit den operativen Kernkonzepten und Einsichten aus David Allens Getting Things Done (GTD) Methode. Zu dieser Zeit war ich bereits seit mehreren Jahren selber ein GTD-Praktizierender, und die exquisite Klarheit und Reinheit, mit der David die Methode erfasste und vermittelte, waren eine riesige Inspiration und ein Wegweiser in meiner eigenen Arbeit lange vor diesem Punkt. GTD erschien auf tiefgründige Weise “natürlich” – eine unvermeidliche Entdeckung der effektivsten Weise die Welt zu prozessieren, zu organisieren, und auf sie zu antworten, unter den Gegebenheiten des menschlichen Geistes und Bewusstseins. Es war ein empirisch entdecktes System und Set von nützlichen Unterscheidungen, nicht bloß eine Kreation des Verstandes, die einem spezifischen mentalen Modell oder Wertesystem entsprang. Das war genau das, was ich versuchte mit Holacracy zu entdecken, und ich glaube es war eine disziplinierte GTD-Praxis, die mir den ersten Geschmack davon vermittelte, wie sich eine solche Methode anfühlt, und eine Messlatte, um Holacracys Entwicklung daran zu messen. Und als wir schließlich in v.3.0 der Verfassung die Brücke zwischen Holacracy und GTD komplett geschlagen hatten, war ich ziemlich ekstatisch.
David Allen und ich 2011 beim Conscious Capitalism CEO Summit, auf dem wir uns ein Jahr zuvor getroffen hatten
Es gab auch noch andere bedeutsame Veränderungen mit jeder sukzessiven Version, und während ich hier in diesem Text einige der größeren hervorgehoben haben, denke ich, dass die Gesamtsumme von Holacracys Mikro-Evolutionen mindestens so folgenreich war. Für jeden der größeren Sprünge machten wir Dutzende kleine Anpassungen im Regelset – um die Verarbeitung von Spannungen etwas effizienter fließen zu lassen, oder um eine Art von Spannung leichter adressieren zu können, oder um irgendein potentielles Problem, das wir gefunden hatten, welches gelegentlich die Arbeit lahmlegt oder Dinge verlangsamt, zu verhindern. Und solange wie es Unternehmen gibt, die Interesse an der Anwendung der Verfassung haben, werden kontinuierlich Spannungen in Bezug auf die Kernregeln von Holacracy auftauchen und ihre evolutionäre Reise weiter antreiben.
Und doch spüre ich auch eine große Veränderung in der Art und Weise wie diese Evolution geschieht. In vielerlei Hinsicht denke ich, dass Holacracy sowohl über mich als auch über HolacracyOne hinauswächst, und ich vermute, dass ihre weitere Evolution mehr und mehr durch ihre größere Community von Nutzern und durch die Spannungen, die sie spüren, angetrieben werden wird. Zum Glück schießt eine ziemlich erstaunliche Community wie Pilze aus dem Boden, um sie weiter zu tragen und unsere Rolle bei HolacracyOne in der Entwicklung von Holacracy und seiner Verfassung verändert sich von Quelle hin in Richtung Steward. Das ist eine neue Herausforderung, für die wir uns immer noch im Orientierungsprozess befinden, doch ich mache mir keine Sorgen – die Evolution hat ein Händchen dafür, genau dasjenige zu finden, was gebraucht wird, und ich heiße ihren exquisit schonungslosen Blick willkommen.
Brian J Robertson
Birchrunville, Pennsylvania
Juni 2014
Brian ist der Autor von Holacracy: Ein revolutionäres Management-System für eine volatile Welt