„Offene Organisation“: Wie man sich im Chaos nicht verliert und Millionen vereint.

Ein wichtiger Tag für Red Hat, die russische Open-Source-Community und alle Beteiligten – auf Russisch ist erschienen das Buch von Jim Whitehurst „Die offene Organisation: Leidenschaft, die Früchte trägt“. Es erzählt detailliert und lebendig, wie wir bei Red Hat den besten Ideen und den talentiertesten Menschen eine Chance geben, und darüber, wie man im Chaos nicht verloren geht und Millionen von Menschen weltweit vereint.

Außerdem handelt dieses Buch von Leben und Praxis. Es enthält zahlreiche Ratschläge für alle, die lernen möchten, ein Unternehmen nach dem Modell einer offenen Organisation aufzubauen und es effektiv zu führen. Im Folgenden finden Sie einige der wichtigsten Grundsätze aus dem Buch, die Sie schon jetzt berücksichtigen können.

Die Geschichte von Jims Einstellung zu dem Unternehmen ist bemerkenswert. Sie zeigt, dass es in der Welt des Open Source keine Fanfaren gibt, sondern einen neuen Ansatz für Führung:

Nach einem Gespräch mit dem Rekrutierer zeigte ich Interesse an einem Interview, und er fragte mich, ob ich etwas dagegen hätte, am Sonntag zum Hauptsitz von Red Hat in Raleigh, North Carolina zu fliegen. Ich dachte, Sonntag sei ein merkwürdiger Tag für ein Treffen. Aber da ich ohnehin am Montag nach New York fliegen wollte, war es für mich im Grunde genommen auf dem Weg, und ich stimmte zu. Ich nahm einen Flug von Atlanta und landete am Flughafen Raleigh-Durham. Dort nahm ich ein Taxi, das mich vor dem Gebäude von Red Hat auf dem Campus der University of North Carolina absetzte. Es war Sonntag, es war 9:30 Uhr morgens und niemand war in der Nähe. Das Licht war aus, und als ich nachschaute, stellte ich fest, dass die Türen verschlossen waren. Zuerst dachte ich, man machte sich über mich lustig. Als ich mich umdrehte, um ins Taxi zurückzukehren, sah ich, dass es bereits weggefahren war. Bald darauf begann es zu regnen, und ich hatte keinen Regenschirm.

Gerade als ich mich auf den Weg machen wollte, um ein Taxi zu bekommen, fuhr Matthew Schullik, der spätere Vorstandsvorsitzende und Geschäftsführer von Red Hat, mit seinem Auto vor. „Hallo“, sagte er. „Möchten Sie einen Kaffee trinken?“ Mir erschien das als ein ungewöhnlicher Beginn des Interviews, aber ich wusste definitiv, dass ich einen Kaffee brauchte. Ich dachte bei mir, dass es mir später leichter fallen würde, ein Taxi zum Flughafen zu bekommen.

Sonntagmorgen in North Carolina ist recht ruhig. Es dauerte eine Weile, bis wir ein Café fanden, das vor Mittag öffnete. Das Café war nicht das beste der Stadt und auch nicht das sauberste, aber es hatte geöffnet, und wir konnten frischen Kaffee bekommen. Wir setzten uns an einen Tisch und begannen unser Gespräch.

Nach etwa dreißig Minuten wurde mir klar, dass mir der Verlauf des Gesprächs gefiel. Das Interview war nicht traditionell, aber der Dialog war äußerst interessant. Anstatt die Feinheiten der Unternehmensstrategie von Red Hat oder deren Image an der Wall Street zu besprechen – also das, wozu ich mich vorbereitet hatte – stellte Matthew Shulik eher Fragen zu meinen Hoffnungen, Träumen und Zielen. Jetzt verstehe ich, dass Shulik beurteilen wollte, ob ich zur Subkultur und dem Führungsstil des Unternehmens passen würde.

Nachdem wir fertig waren, teilte Shulik mir mit, dass er mich mit dem General Counsel des Unternehmens, Michael Cunningham, bekannt machen wollte, und schlug vor, ihn sofort beim frühen Mittagessen zu treffen. Ich stimmte zu und wir machten uns bereit zu gehen. Dann bemerkte mein Gesprächspartner, dass er sein Portemonnaie nicht dabei hatte. „Ups“, sagte er. „Ich habe kein Geld. Und Sie?“ Das überraschte mich, aber ich antwortete, dass ich Geld dabei habe und bereit bin, für den Kaffee zu bezahlen.

Nach ein paar Minuten ließ Michail mich in einer kleinen mexikanischen Cantina aussteigen, wo ich Michael Cunningham traf. Doch es gab kein traditionelles Vorstellungsgespräch oder Geschäftstreffen. Stattdessen fand ein weiteres interessantes Gespräch statt. Als wir die Rechnung begleichen wollten, stellte sich heraus, dass im Restaurant die Kreditkartenlesemaschine defekt war und sie nur Bargeld akzeptieren konnten. Cunningham wandte sich an mich und fragte, ob ich bereit sei zu zahlen, denn er hatte kein Bargeld dabei. Da ich nach New York reisen wollte und genug Bargeld hatte, bezahlte ich das Mittagessen.

Cunningham bot an, mich zum Flughafen zu bringen, und wir fuhren in seinem Auto. Nach ein paar Minuten fragte er: „Haben Sie etwas dagegen, wenn ich anhalte und tanken gehe? Wir können dann schnell weiterfahren.“ – „Kein Problem“, antwortete ich. Sobald ich das rhythmische Geräusch der Pumpe hörte, klopfte es ans Fenster. Es war Cunningham. „Hey, hier akzeptieren sie keine Kreditkarten“, sagte er. „Kann ich mir etwas Geld leihen?“ Ich begann mich zu fragen, ob dies wirklich ein Vorstellungsgespräch war oder ob es sich um einen Betrug handelte.

Am nächsten Tag, als ich in New York war, sprach ich mit meiner Frau über das Interview bei Red Hat. Ich erzählte ihr, dass das Gespräch sehr interessant war, aber ich war mir nicht sicher, ob diese Leute ernsthaft daran interessiert waren, mich einzustellen: vielleicht benötigten sie einfach nur kostenloses Essen und Benzin? Wenn ich heute an dieses Treffen zurückdenke, erkenne ich, dass Shulik und Cunningham einfach offene Menschen waren, die mich wie jeden anderen behandelten, mit dem man einen Kaffee trinken, zu Mittag essen oder tanken könnte. Ja, es ist lustig und sogar komisch, dass sie beide kein Geld hatten. Aber für sie ging es nicht um Geld. Sie glauben, ebenso wie die Welt rund um den Open Source, nicht an das Ausrollen roter Teppiche oder den Versuch, den Gesprächspartner davon zu überzeugen, dass alles perfekt ist. Sie wollten einfach nur mehr über mich erfahren und versuchten nicht, Eindruck zu schinden oder auf unsere Unterschiede hinzuweisen. Sie wollten wissen, wer ich bin.

Mein erstes Vorstellungsgespräch bei Red Hat hat mir deutlich gezeigt, dass die Arbeit hier eine ganz andere ist. In diesem Unternehmen gab es keine traditionelle Hierarchie und keinen speziellen Status für Vorgesetzte, zumindest nicht in der Form, wie man es von den meisten anderen Unternehmen kennt. Im Laufe der Zeit habe ich auch erfahren, dass Red Hat an das Prinzip der Meritokratie glaubt: Es ist immer lohnenswert, die beste Idee zu verfolgen, egal ob sie von der Unternehmensleitung oder von einem Praktikanten kommt. Mit anderen Worten, mein erster Eindruck von Red Hat hat mich mit der Zukunft der Führung vertraut gemacht.

Tipps zur Förderung von Meritokratie

Meritokratie ist der zentrale Wert der Open-Source-Community. Es spielt keine Rolle, welche Position du in der Hierarchie hast, entscheidend sind die Qualität deiner Ideen. Und das empfiehlt Jim:

• Sage niemals: „So will es der Chef“ – und verlasse dich nicht auf die Hierarchie. Das kann dir kurzfristig helfen, aber so baust du keine Meritokratie auf.
• Öffentlich Anerkennung für Erfolge und bedeutende Beiträge zur gemeinsamen Sache aussprechen. Dies kann eine einfache Dankes-E-Mail sein, in der das gesamte Team in Kopie ist.
• Überlegen Sie: Beruht Ihr Ansehen auf Ihrer Position in der Hierarchie (oder dem Zugang zu privilegierten Informationen), oder resultiert es aus dem Respekt, den Sie sich erarbeitet haben? Wenn es ersteres ist, beginnen Sie, an letzterem zu arbeiten.
• Bitten Sie um Feedback und sammeln Sie Ideen zu einem bestimmten Thema. Reagieren Sie auf alle Rückmeldungen, testen Sie nur die besten. Aber nehmen Sie nicht einfach die besten Ideen und machen Sie mit ihnen weiter – nutzen Sie jede Gelegenheit, um den Geist der Meritokratie zu stärken, indem Sie allen, die es verdienen, Anerkennung zollen.
• Heben Sie ein vorbildliches Teammitglied hervor, indem Sie ihm eine interessante Aufgabe anbieten, auch wenn sie nicht in seinem gewohnten Tätigkeitsbereich liegt.

Lassen Sie Ihre "Rockstars" ihrer Leidenschaft folgen.

Enthusiasmus und Engagement – zwei sehr wichtige Begriffe in einer offenen Organisation. In dem Buch werden sie ständig wiederholt. Aber man kann leidenschaftliche kreative Menschen nicht dazu bringen, ständig "von Anfang bis Ende" zu arbeiten, oder? Andernfalls werden Sie einfach nicht alles erhalten, was ihr Talent zu bieten hat. Bei Red Hat werden Hindernisse für eigene Projekte weitgehend abgebaut:

Um Innovationen voranzutreiben, probieren Unternehmen viel aus. Besonders interessant ist der Ansatz von Google. Seit die Firma seit 2004 in jedem Haushalt bekannt ist, haben Führungskräfte und Ideologen im Internetgeschäft versucht, das Geheimnis des Unternehmens zu entschlüsseln, um seinen beeindruckenden Erfolg nachzuahmen. Eines der bekanntesten, aber derzeit eingestellten Programme bestand darin, dass allen Google-Mitarbeitern angeboten wurde, 20 Prozent ihrer Arbeitszeit praktisch für alles zu verwenden, was ihnen in den Sinn kommt. Die Idee dahinter war: Wenn die Mitarbeiter ihre eigenen Projekte und Ideen, die sie neben der Arbeit begeistern, umsetzen, würden sie Innovationen schaffen. So entstanden erfolgreiche Nebenprojekte: GoogleSuggest, AdSense for Content und Orkut; all diese entwickelten sich aus diesem 20-Prozent-Experiment – eine beeindruckende Liste! […]

Bei Red Hat verfolgen wir einen weniger formellen Ansatz. Es gibt keine festgelegte Richtlinie, wie viel Zeit jeder unserer Mitarbeiter für "Innovation" aufwenden sollte. Anstatt den Mitarbeitern feste Zeiten für Weiterbildung zuzuweisen, ermöglichen wir es ihnen, sich das Recht zu verdienen, ihre Zeit für Neues zu investieren. Um ehrlich zu sein, haben viele nicht viel Zeit dafür, aber es gibt auch Kollegen, die nahezu den ganzen Arbeitstag für Innovationen aufwenden können.

Ein typischer Fall sieht so aus: Jemand arbeitet an einem externen Projekt (wenn er den Managern die Bedeutung erklärt hat – entweder am Arbeitsplatz oder in seiner Freizeit – aus eigenem Antrieb), und später kann diese Arbeit den Großteil seiner Arbeitszeit in Anspruch nehmen.

Mehr als nur Brainstorming

«Eine lyrische Abweichung. Alex Faikni Osborn ist der Erfinder der Brainstorming-Methode, die heute durch die Synectics-Technik weitergeführt wird. Interessanterweise entstand diese Idee während des Zweiten Weltkriegs, als Osborn eines der Schiffe eines amerikanischen Konvois befehligte, das einer Torpedoattacke eines deutschen U-Bootes ausgesetzt war. Dabei erinnerte sich der Kapitän an eine Technik, die von Piraten im Mittelalter verwendet wurde: Wenn die Crew in Schwierigkeiten geriet, versammelten sich alle Matrosen an Deck, um abwechselnd Lösungsvorschläge zu unterbreiten. Es gab viele Ideen, darunter auch solche, die auf den ersten Blick absurd erschienen: zum Beispiel, die gesamte Crew auf die Torpedos zu pusten. Doch mit der Strömung einer Schiffsrakel, die an jedem Schiff vorhanden ist, könnte man die Torpedos durchaus abbremsen oder sogar ihre Richtung ändern. Infolgedessen ließ Osborn die Erfindung patentieren: An die Bordwand des Schiffs wurde ein zusätzlicher Propeller montiert, der einen Wasserstrahl entlang des Randes erzeugt, auf dem die Torpedos gleiten.»

Unser Jim betont immer wieder, dass es in einer offenen Organisation nicht ganz einfach ist, zu arbeiten. Selbst das Management hat darunter zu leiden, denn niemand ist von der Notwendigkeit befreit, seine Meinungen zu vertreten. Genau dieser Ansatz ist jedoch erforderlich, um herausragende Ergebnisse zu erzielen.

Online-Foren von [Open-Source-Entwicklern] und Chats sind oft voll von lebhaften und manchmal scharfen Diskussionen über alles – von der besten Vorgehensweise zur Behebung von Softwarefehlern bis hin zu neuen Funktionen, die im nächsten Update in Betracht gezogen werden sollten. In der Regel ist dies die erste Phase der Diskussion, in der neue Ideen geäußert und gesammelt werden, aber es folgt immer eine zweite Runde – die kritische Analyse. Jeder kann an diesen Debatten teilnehmen, aber man muss bereit sein, seine Position mit Nachdruck zu vertreten. Unpopuläre Ideen werden im besten Fall abgelehnt, im schlimmsten Fall lächerlich gemacht.

Selbst Linus Torvalds, der Schöpfer des Linux-Betriebssystems, äußert sein Unverständnis gegenüber den vorgeschlagenen Änderungen im Code. Einmal führten Linus und David Howells, einer der leitenden Entwickler von Red Hat, eine hitzige Debatte über die Vorteile einer von Red Hat geforderten Änderung im Code, die dazu beitragen würde, unseren Kunden Sicherheit zu gewährleisten. Als Antwort auf Howells Anfrage schrieb Torvalds: „Um ehrlich zu sein, ist das [unhöfliches Wort] Unsinn. Alles dreht sich um diese dummen Schnittstellen, und das aus völlig idiotischen Gründen. Warum sollten wir das tun? Mir gefällt der bestehende X.509-Parser schon jetzt nicht. Es werden unnötig komplexe Schnittstellen erstellt, und jetzt werden es 11 sein. – Linus 9“.

Ohne die technischen Details zu berücksichtigen, fuhr Torvalds in seiner nächsten Nachricht im gleichen Ton fort – und so, dass ich es nicht wagen würde, zu zitieren. Diese Auseinandersetzung war so laut, dass sie sogar auf die Seiten der The Wall Street Journal gelangte. […]

Dieser Disput zeigt, dass es in den meisten Unternehmen, die proprietäre Software entwickeln, keine offenen Debatten darüber gibt, an welchen neuen Funktionen oder Änderungen gearbeitet werden könnte. Wenn das Produkt fertig ist, wird es einfach an die Kunden verteilt und das Unternehmen geht weiter. Im Gegensatz dazu gehen die Diskussionen über die notwendigen Veränderungen bei Linux – und vor allem, warum sie notwendig sind – niemals zu Ende. Das macht den gesamten Prozess natürlich viel chaotischer und arbeitsintensiver.

Frühzeitig veröffentlichen, oft veröffentlichen

Wir können die Zukunft nicht vorhersagen, also müssen wir es einfach versuchen:

Wir arbeiten nach dem Prinzip "früher Start, häufige Updates". Das Hauptproblem jedes Softwareprojekts ist das Risiko von Fehlern oder Bugs im Quellcode. Offensichtlich ist, je mehr Änderungen und Updates in einer einzigen Version der Software zusammenkommen, desto höher ist die Wahrscheinlichkeit, dass diese Version Bugs enthält. Entwickler von Open-Source-Software haben erkannt: Durch schnelle und häufige Versionen wird das Risiko ernsthafter Probleme mit einer Software reduziert, da wir nicht alle Updates auf einmal herausbringen, sondern sie portioniert für jede Version bereitstellen. Im Laufe der Zeit haben wir festgestellt, dass dieser Ansatz nicht nur die Anzahl der Fehler verringert, sondern auch zu interessanteren Lösungen führt. Es scheint, dass ständige kleine Verbesserungen letztendlich mehr Innovationen schaffen. Das ist vielleicht nicht überraschend. Ein zentrales Prinzip moderner Produktionsprozesse, wie Kaizen oder Lean, besteht darin, sich auf kleine und schrittweise Veränderungen und Updates zu konzentrieren.

[…] Vieles, woran wir arbeiten, wird möglicherweise nicht erfolgreich sein. Anstatt jedoch viel Zeit damit zu verbringen, darüber nachzudenken, was funktioniert und was nicht, ziehen wir es vor, kleine Experimente durchzuführen. Die gefragtesten Ideen werden zum Erfolg führen, während die, die nicht funktionieren, von selbst verkümmern. Auf diese Weise können wir vieles ausprobieren, anstatt uns nur auf eine einzige Sache zu konzentrieren, und das ohne großes Risiko für das Unternehmen.

Das ist eine intelligente Art der Ressourcenverteilung. Oft werde ich gefragt, wie wir entscheiden, welche Open-Source-Projekte kommerzialisiert werden sollen. Zwar initiieren wir manchmal Projekte, meist schließen wir uns jedoch bestehenden an. Eine kleine Gruppe von Ingenieuren – manchmal sogar nur eine Person – beginnt, zu einem der Community-Projekte beizutragen. Wenn das Projekt erfolgreich ist und bei unseren Kunden Anklang findet, investieren wir mehr Zeit und Mühe darin. Ist das nicht der Fall, wechseln die Entwickler zu einem neuen Projekt. Zu dem Zeitpunkt, wenn wir entscheiden, das Angebot zu kommerzialisieren, kann das Projekt so weit gewachsen sein, dass die Entscheidung offensichtlich ist. Unterschiedlichste Projekte, einschließlich solcher, die nichts mit Software zu tun haben, entstehen ganz natürlich innerhalb des gesamten Unternehmens Red Hat, bis allen klar wird, dass jemand jetzt ständig damit arbeiten muss.

Hier ist noch ein Zitat aus dem Buch:

Ich habe erkannt, dass zukünftige Führungskräfte, um dieser Rolle gerecht zu werden, Eigenschaften besitzen müssen, die in herkömmlichen Organisationen oft übersehen werden. Um eine offene Organisation effektiv zu leiten, sollte ein Führer folgende Qualitäten mitbringen.

• Persönliche Stärke und Selbstvertrauen. Übliche Führungskräfte nutzen ihre Macht – ihre Position – um Erfolg zu haben. Doch in einer Meritokratie müssen Führungskräfte den Respekt verdienen. Dies ist nur möglich, wenn sie keine Angst haben, einzugestehen, dass sie nicht auf alle Fragen Antworten haben. Sie müssen bereit sein, Probleme zu diskutieren und schnell Entscheidungen zu treffen, um gemeinsam mit ihrem Team die besten Lösungen zu finden.
• Geduld. Die Medien berichten selten darüber, wie "geduldig" eine Führungskraft ist. Doch tatsächlich ist Geduld unerlässlich. Wenn man versucht, das Beste aus seinem Team herauszuholen, Stunden mit ihnen spricht und Dinge wiederholt, bis alles richtig gemacht ist, braucht man Geduld.
• Hohes EQ (emotionale Intelligenz). Zu oft bewerben wir die intellektuellen Fähigkeiten von Führungskräften und konzentrieren uns auf ihr IQ, während wir in der Realität ihren emotionalen Intelligenzquotienten, oder EQ, berücksichtigen sollten. Der intelligenteste Mensch im Raum zu sein, reicht nicht aus, wenn Sie nicht in der Lage sind, mit diesen Menschen zu arbeiten. Wenn Sie mit Gemeinschaften von engagierten Mitarbeitern arbeiten, wie bei Red Hat, und keine Autorität haben, jemandem zu befehlen, wird Ihre Fähigkeit zuzuhören, analytisch zu denken und nicht alles persönlich zu nehmen, unglaublich wertvoll.
• Ein anderer Denkansatz. Führungskräfte, die aus traditionellen Organisationen stammen, wurden im Geiste von quid pro quo (lat. „Gegenseitigkeit“) erzogen, wobei jede Handlung eine angemessene Rückgabe erwarten sollte. Doch wenn Sie in den Aufbau einer bestimmten Gemeinschaft investieren wollen, sollten Sie langfristig denken. Es ist wie der Versuch, ein fein abgestimmtes Ökosystem zu schaffen, in dem jeder falsche Schritt ein Ungleichgewicht verursachen und langfristige Verluste zur Folge haben kann, die nicht sofort erkennbar sind. Führungskräfte müssen sich von der Denkweise lösen, die von ihnen verlangt, heute und um jeden Preis Ergebnisse zu erzielen, und stattdessen eine Geschäftspraxis pflegen, die durch Investitionen in die Zukunft einen größeren Nutzen verspricht.

Und warum ist das wichtig?

Red Hat lebt nach Prinzipien, die sich stark von traditionellen hierarchischen Organisationsmodellen unterscheiden. Und es funktioniert, es macht uns kommerziell erfolgreich und menschlich glücklich. Wir haben dieses Buch übersetzt, in der Hoffnung, die Prinzipien der offenen Organisation in deutschen Unternehmen zu verbreiten, und bei Menschen, die anders leben wollen und können.

Lesen Sie, probieren Sie es aus!

Quelle: habr.com