„Offene Organisation“: Wie man im Chaos nicht untergeht und Millionen zusammenbringt

Ein wichtiger Tag für Red Hat, die russische Open-Source-Community und alle Beteiligten – das Buch von Jim Whitehurst „Offene Organisation: Leidenschaft, die Früchte trägt“, ist auf Russisch erschienen.Es beschreibt ausführlich und lebendig, wie wir bei Red Hat die besten Ideen und die talentiertesten Menschen fördern und wie wir es schaffen, nicht im Chaos unterzugehen und Millionen von Menschen auf der ganzen Welt zu vereinen.

Außerdem handelt dieses Buch von Leben und Praxis. Es enthält viele Ratschläge für alle, die lernen möchten, ein Unternehmen im Modell der offenen Organisation aufzubauen und es effektiv zu führen. Im Folgenden finden Sie einige der wichtigsten Prinzipien aus dem Buch, die Sie bereits jetzt in Betracht ziehen können.

Die Geschichte von Jims Einstellung zur Firma 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 Recruiter hatte ich Interesse an einem Vorstellungsgespräch bekundet, und er fragte, ob es mir etwas ausmachen würde, am Sonntag nach Raleigh, North Carolina, zum Headquarters von Red Hat zu fliegen. Ich fand, dass Sonntag ein seltsamer Tag für ein Treffen ist. Aber da ich ohnehin am Montag nach New York fliegen wollte, war es für mich mehr oder weniger auf dem Weg, und ich stimmte zu. Ich nahm den Flug von Atlanta und landete am Raleigh-Durham Flughafen. Von dort nahm ich ein Taxi, das mich vor das Gebäude von Red Hat auf dem Gelände der University of North Carolina brachte. Es war Sonntag, es war 9:30 Uhr morgens und niemand war in der Nähe. Das Licht war aus, und ich stellte fest, dass die Türen abgeschlossen waren. Zunächst dachte ich, man macht 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 dachte, ich würde irgendwo hingehen, um ein Taxi zu schnappen, kam Matthew Szulik, später Vorsitzender des Vorstands und CEO von Red Hat, mit seinem Auto vorbei. „Hallo“, begrüßte er mich. „Möchten Sie einen Kaffee trinken?“ Ich fand das einen ungewöhnlichen Beginn des Vorstellungsgesprächs, aber ich wusste, dass ich definitiv einen Kaffee brauchte. Schließlich dachte ich, es würde mir später leichter fallen, ein Taxi zum Flughafen zu bekommen.

Am Sonntagmorgen ist es in North Carolina recht ruhig. Wir brauchten eine Weile, um einfach ein Café zu finden, das vor Mittag öffnete. Das Café stellte sich als nicht das beste und auch nicht das sauberste in der Stadt heraus, aber es hatte geöffnet und man konnte frischen Kaffee genießen. Wir setzten uns an einen Tisch und begannen das Gespräch.

Nach etwa dreißig Minuten oder so wurde mir klar, dass mir gefiel, wie alles verlief; das Interview war nicht traditionell, aber das Gespräch selbst war sehr interessant. Anstatt die Feinheiten der Unternehmensstrategie von Red Hat oder ihr Image an der Wall Street zu besprechen – also das, wofür ich mich vorbereitet hatte – fragte Matthew Shulik mehr nach meinen Hoffnungen, Träumen und Zielen. Jetzt ist mir klar, dass Shulik bewertete, ob ich zur Subkultur und zum Führungsstil des Unternehmens passe.

Nachdem wir fertig waren, teilte Shulik mit, dass er mich mit dem Hauptrechtsberater des Unternehmens, Michael Cunningham, bekannt machen wollte, und schlug vor, ihn sofort bei einem frühen Lunch zu treffen. Ich stimmte zu, und wir machten uns bereit zu gehen. Dann stellte mein Gesprächspartner fest, dass er seine Brieftasche nicht dabei hatte. "Ups", sagte er. "Ich habe kein Geld. Und du?" Das traf mich etwas unvorbereitet, aber ich antwortete, dass ich Geld habe und nichts dagegen habe, für den Kaffee zu bezahlen.

Nach wenigen Minuten setzte Shulik mich in einem kleinen mexikanischen Imbiss ab, wo ich Michael Cunningham traf. Aber erneut gab es kein traditionelles Interview oder Geschäftstreffen, stattdessen fand ein weiteres interessantes Gespräch statt. Als wir die Rechnung begleichen wollten, stellte sich heraus: Im Restaurant war das Kartenlesegerät defekt, und sie konnten nur Bargeld annehmen. Cunningham drehte sich zu mir und fragte, ob ich bereit sei zu zahlen, da er kein Bargeld dabei hatte. Da ich nach New York wollte und viel Bargeld dabei hatte, bezahlte ich das Mittagessen.

Cunningham bot mir an, mich zum Flughafen zu fahren, und wir fuhren mit seinem Auto. Nach ein paar Minuten fragte er: „Haben Sie etwas dagegen, wenn ich anhalte und tanke? Wir müssen schnell weiter.“ – „Kein Problem“, antwortete ich. Sobald ich das rhythmische Geräusch der Pumpe hörte, klopfte es an das Fenster. Es war Cunningham. „Hey, hier werden keine Kreditkarten akzeptiert“, sagte er. „Kann ich mir etwas Geld leihen?“ Ich begann mich zu fragen, ob das Interview wirklich ernst gemeint oder vielleicht eine Art Betrug war.

Am nächsten Tag, während 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 mir nicht sicher war, ob die Leute es ernst meinten, mich einzustellen: Vielleicht brauchten sie einfach nur kostenloses Essen und Benzin? Wenn ich heute an dieses Treffen zurückdenke, verstehe ich, dass Shulik und Cunningham einfach offene Menschen waren und mich wie jeden anderen behandelten, mit dem sie Kaffee trinken, zu Mittag essen oder tanken konnten. Ja, es ist lustig und sogar komisch, dass beide kein Geld hatten. Aber für sie ging es nicht um Geld. Sie glaubten, genauso wie die Welt des Open Source, nicht an das Ausrollen roter Teppiche oder daran, den Gesprächspartner zu überzeugen, dass alles perfekt sei. Sie wollten mich einfach besser kennenlernen und nicht beeindrucken oder auf unsere Unterschiede hinweisen. Sie wollten wissen, wer ich bin.

Mein erstes Interview bei Red Hat zeigte mir deutlich, dass die Arbeit hier eine andere Art hat. In diesem Unternehmen gab es keine traditionelle Hierarchie und keinen speziellen Status für Führungskräfte, zumindest nicht in der Form, wie es in den meisten anderen Firmen üblich ist. Im Laufe der Zeit erfuhr ich auch, dass Red Hat an das Meritokratie-Prinzip glaubt: Es lohnt sich immer, die beste Idee zu verwirklichen, egal ob sie vom oberen Management oder von einem Praktikanten stammt, der für den Sommer eingestellt wurde. Mit anderen Worten, mein erster Eindruck von Red Hat vermittelte mir, wie die Zukunft der Führung aussieht.

Tipps zur Förderung von Meritokratie

Meritokratie ist der zentrale Wert der Open-Source-Community. Uns ist es egal, welche Stufe der Pyramide du einnimmt, entscheidend sind die Qualität deiner Ideen. Das schlägt Jim vor:

• Sagen Sie niemals: „So will der Chef“ – und verlassen Sie sich nicht auf die Hierarchie. Das mag Ihnen kurzfristig helfen, aber so bauen Sie keine Meritokratie auf.
• Erkennen Sie öffentlich Erfolge und wichtige Beiträge zum gemeinsamen Ziel an. Das kann eine einfache Dankes-E-Mail sein, in der das gesamte Team in CC gesetzt ist.
• Überlegen Sie: Hängt Ihre Autorität von Ihrer Position in der Hierarchie (oder vom Zugang zu privilegierten Informationen) ab oder ist sie das Resultat des Respekts, den Sie sich erarbeitet haben? Wenn es das erste ist, fangen Sie an, am zweiten zu arbeiten.
• Bitten Sie um Feedback und sammeln Sie Ideen zu einem bestimmten Thema. Auf alles sollten Sie reagieren, das Beste sollten Sie testen. Nehmen Sie nicht einfach die besten Ideen und machen Sie damit weiter – nutzen Sie jede Gelegenheit, um den Geist der Meritokratie zu stärken, indem Sie allen, die es verdienen, die gebührende Anerkennung zollen.
• Heben Sie ein vorbildliches Teammitglied hervor, indem Sie eine interessante Aufgabe vorschlagen, auch wenn sie nicht in seinem gewohnten Aufgabenbereich liegt.

Lassen Sie Ihre „Rockstars“ ihrer Leidenschaft folgen.

Enthusiasmus und Engagement sind zwei sehr wichtige Wörter in einer offenen Organisation. In diesem Buch werden sie ständig wiederholt. Aber Sie können leidenschaftliche Kreativköpfe nicht dazu zwingen, „von Anfang bis Ende“ zu arbeiten, oder? Andernfalls erhalten Sie einfach nicht alles, was ihr Talent zu bieten hat. Bei Red Hat werden die Hindernisse für eigene Projekte so weit wie möglich abgebaut:

„Um Innovationen zu steuern, probieren Unternehmen vieles aus. Interessant ist der Ansatz von Google. Seit Google ab 2004 in jedem Haushalt bekannt wurde, haben Führungskräfte und Ideologen im Internetgeschäft versucht, das Geheimnis des Unternehmens zu entschlüsseln, um seinen beeindruckenden Erfolg zu wiederholen. Eines der bekanntesten, aber derzeit geschlossenen Programme bestand darin, dass allen Google-Mitarbeitern angeboten wurde, 20 Prozent ihrer Arbeitszeit praktisch für alles zu verwenden, was ihnen gefällt. Die Idee war folgende: Wenn die Mitarbeiter beginnen, ihre eigenen Projekte und Ideen, für die sie neben der Arbeit brennen, umzusetzen, werden sie Innovationen schaffen. So entstanden erfolgreiche Nebenprojekte: GoogleSuggest, AdSense for Content und Orkut; sie alle entstanden aus diesem 20-Prozent-Experiment – eine beeindruckende Liste! […]

Bei Red Hat verfolgen wir einen weniger formellen Ansatz. Es gibt keine festgelegte Richtlinie dafür, wie viel Zeit jeder Mitarbeiter für "Innovationen" aufwenden sollte. Anstatt den Mitarbeitern bestimmte Zeitfenster für Weiterbildung zuzuweisen, ermöglichen wir es ihnen, das Recht zu verdienen, ihre Zeit für Neues zu investieren. Um ehrlich zu sein, haben viele nur wenig Zeit dafür, während andere fast den ganzen Arbeitstag für Innovationen aufwenden können.

Der typischste Fall sieht etwa so aus: Jemand arbeitet an einem externen Projekt (wenn er den Managern seine Bedeutung erklärt hat – direkt am Arbeitsplatz; oder in seiner Freizeit – aus eigenem Antrieb), und später kann diese Arbeit all seine Anwesenheitsstunden beanspruchen.

Mehr als nur Brainstorming

"Ein lyrischer Einschub: Alex F. Osborn – der Erfinder der Methode des "Brainstorming", aus der heute die Methode der Synectics hervorgeht. Interessanterweise entstand diese Idee während des Zweiten Weltkriegs, als Osborn ein amerikanisches Frachtschiff kommandierte, das einer Torpedoangriff eines deutschen U-Boots ausgesetzt war. Damals erinnerte sich der Kapitän an eine Methode, die im Mittelalter von Piraten angewendet wurde: Wenn die Besatzung in Schwierigkeiten geriet, versammelten sich alle Matrosen an Deck, um abwechselnd Lösungsvorschläge zu unterbreiten. Es gab viele Ideen, darunter auch auf den ersten Blick absurde: Beispielsweise die Idee, dass die gesamte Crew auf den Torpedo bläst. Doch mit dem Strahl einer Schiffspumpe, die auf jedem Schiff vorhanden ist, lässt sich der Torpedo durchaus abbremsen oder sogar in seinem Kurs ändern. Infolgedessen patentierte Osborn sogar die Erfindung: Am Schiffsrumpf wird eine zusätzliche Schraube montiert, die einen Wasserstrahl entlang des Rumpfs erzeugt, während der Torpedo daran vorbeigleitet."

Unser Jim betont ständig, dass es in einer offenen Organisation nicht so einfach ist zu arbeiten. Selbst die Führungskräfte sind betroffen, da niemand von der Notwendigkeit befreit ist, seine Meinung zu verteidigen. Doch genau dieser Ansatz ist erforderlich, um hervorragende Ergebnisse zu erzielen:

Die Online-Foren [Entwickler von Open Source] und Chats sind oft mit lebhaften, manchmal sogar scharfen Diskussionen zu allen möglichen Themen gefüllt – von der besten Art, einen Softwarefehler zu beheben, bis hin zu den neuen Funktionen, die in einem kommenden Update berücksichtigt werden sollten. In der Regel ist dies die erste Phase der Diskussionen, in der neue Ideen aufgebracht und gesammelt werden, doch es folgt immer eine nächste Runde – die kritische Analyse. Obwohl jeder an diesen Streits teilnehmen kann, muss man bereit sein, seine Position vehement zu verteidigen. Unbeliebte Ideen werden bestenfalls abgelehnt, im schlimmsten Fall belächelt.

Selbst Linus Torvalds, der Schöpfer des Linux-Betriebssystems, äußert seine Meinungsverschiedenheiten zu den vorgeschlagenen Änderungen am Code. Einmal gerieten Linus und David Howells, einer der führenden Entwickler bei Red Hat, in eine hitzige Debatte über die Vorzüge der von Red Hat geforderten Codeänderung, die unseren Kunden Sicherheit bieten würde. Als Antwort auf Howells' Anfrage schrieb Torvalds: „Ehrlich gesagt, das ist [das unverzichtbare Wort] Idiotie. Es scheint alles um diese dummen Schnittstellen zu kreisen, und das aus völlig idiotischen Gründen. Warum sollten wir das tun? Ich mag den bestehenden X.509-Parser nicht. Es werden idiotisch komplexe Schnittstellen erstellt, und jetzt werden es 11 sein. – Linus 9.

Die technischen Details mal beiseite gelassen, fuhr Torvalds in der nächsten Nachricht im gleichen Sinne fort – so sehr, dass ich es nicht wage zu zitieren. Diese Debatte war so laut, dass sie sogar in die Seiten des Wall Street Journal gelangte. […]

Diese Debatte zeigt, dass es in den meisten Unternehmen, die proprietäre, nicht-freie Software entwickeln, keine offenen Debatten darüber gibt, an welchen neuen Features oder Änderungen gearbeitet werden könnte. Wenn das Produkt fertig ist, schickt das Unternehmen es einfach an die Kunden und macht weiter. Im Gegensatz dazu verhallen die Diskussionen darüber, welche Änderungen bei Linux notwendig sind und – was am wichtigsten ist – warum sie notwendig sind, nicht. Das macht den gesamten Prozess natürlich viel chaotischer und arbeitsintensiver.

Früh veröffentlichen, oft veröffentlichen

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

„Wir handeln nach dem Prinzip „früher Start, häufige Updates“. Das zentrale Problem jedes Softwareprojekts ist das Risiko von Fehlern oder Bugs im Quellcode. Offensichtlich gilt: Je mehr Änderungen und Updates in einer Softwareversion zusammenkommen, desto höher ist die Wahrscheinlichkeit, dass in dieser Version Bugs vorhanden sind. Entwickler von Open-Source-Software haben erkannt: Durch schnelle und häufige Releases wird das Risiko schwerwiegender Probleme mit einer Software verringert – denn wir bringen nicht alle Updates auf einmal auf den Markt, sondern in kleineren Portionen für jede Version. Im Laufe der Zeit haben wir festgestellt, dass dieser Ansatz nicht nur die Zahl der Fehler reduziert, sondern auch zu interessanteren Lösungen führt. Es stellt sich heraus, dass ständige kleine Verbesserungen letztlich mehr Innovationen schaffen. Möglicherweise ist da nichts Überraschendes. Eines der Schlüsselprinzipien moderner Produktionsprozesse, wie zum Beispiel Kaizen oder Lean, ist der Fokus auf kleine, schrittweise Veränderungen und Updates.

[…] Vieles von dem, woran wir arbeiten, kann auch keinen Erfolg bringen. Aber anstatt viel Zeit damit zu verbringen, zu überlegen, was funktionieren wird und was nicht, ziehen wir es vor, kleine Experimente durchzuführen. Die gefragtesten Ideen werden erfolgreich sein, während die, die nicht funktionieren, von selbst verblassen. So können wir vieles ausprobieren, anstatt uns nur auf etwas Bestimmtes zu konzentrieren, und das ganz ohne nennenswertes Risiko für das Unternehmen.

Dies ist eine rationale Art der Ressourcenverteilung. Zum Beispiel fragen mich die Leute oft, wie wir entscheiden, welche Open-Source-Projekte kommerzialisiert werden sollen. Während wir manchmal Projekte initiieren, schließen wir uns meistens bestehenden an. Eine kleine Gruppe von Ingenieuren – manchmal auch nur eine Person – beginnt, zu einem der Open-Source-Community-Projekte beizutragen. Wenn das Projekt erfolgreich ist und bei unseren Kunden gefragt ist, investieren wir mehr Zeit und Mühe dafür. Wenn nicht, wechseln die Entwickler zu einem neuen Projekt. Zu dem Zeitpunkt, an dem wir entscheiden, das Angebot zu kommerzialisieren, kann das Projekt so gewachsen sein, dass die Entscheidung offensichtlich ist. Die unterschiedlichsten Projekte, auch solche, die nichts mit Software zu tun haben, entstehen auf natürliche Weise im gesamten Unternehmen Red Hat, bis allen klar wird, dass nun jemand konstant damit arbeiten muss.

Hier ist ein weiteres Zitat aus dem Buch:

„Mir wurde klar, dass die künftigen Führer, um in einer solchen Rolle erfolgreich zu sein, Eigenschaften aufweisen müssen, die in normalen Organisationen oft nicht beachtet werden. Um effektiv in einer offenen Organisation zu führen, muss ein Leiter über folgende Eigenschaften verfügen.

• Persönliche Stärke und Selbstvertrauen. Gewöhnliche Führungskräfte nutzen die Macht ihrer Position – ihre Stellung – um erfolgreich zu sein. Aber in einer Meritokratie müssen die Führungskräfte den Respekt verdienen. Und das ist nur möglich, wenn sie keine Angst haben, zuzugeben, dass sie nicht auf alle Fragen eine Antwort haben. Sie sollten bereit sein, Probleme zu besprechen 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“ ein Führungskraft ist. Aber tatsächlich muss er geduldig sein. Wenn Sie daran arbeiten, das Beste aus Ihrem Team herauszuholen und Ergebnisse zu erzielen, stundenlang im Dialog sind und etwas immer wieder wiederholen, bis es richtig gemacht ist – dann müssen Sie geduldig sein.
• Hoher EQ (emotionaler Intelligenz). Zu oft preisen wir die intellektuellen Fähigkeiten von Führungskräften und konzentrieren uns auf ihren IQ, während wir in Wirklichkeit ihren emotionalen Intelligenzquotienten, oder EQ, berücksichtigen sollten. Der klügste Mensch unter anderen zu sein, reicht nicht aus, wenn man nicht mit diesen Menschen arbeiten kann. Wenn Sie mit Gemeinschaften engagierter Mitarbeiter arbeiten, wie bei Red Hat, und nicht die Möglichkeit haben, jemandem Befehle zu erteilen, wird Ihre Fähigkeit zuzuhören, analytisch zu denken und nicht alles persönlich zu nehmen, unglaublich wertvoll.
• Eine andere Mentalität. Führungskräfte, die aus traditionellen Organisationen kommen, wurden im Geiste von quid pro quo (lateinisch "eine Hand wäscht die andere") erzogen, wonach jede Handlung eine angemessene Gegenleistung erhalten muss. Aber wenn Sie in den Aufbau einer bestimmten Gemeinschaft investieren möchten, sollten Sie langfristig denken. Es ist wie der Versuch, ein fein abgestimmtes Ökosystem zu schaffen, in dem jeder Fehler ein Ungleichgewicht hervorrufen kann, das zu langfristigen Verlusten führt, die Sie möglicherweise nicht sofort bemerken. Führungskräfte müssen sich von der Denkweise verabschieden, die ihnen verlangt, sofort Ergebnisse zu erzielen, um jeden Preis, und ein Geschäft führen, das es ermöglicht, durch Investitionen in die Zukunft größere Gewinne zu erzielen.

Und warum ist das wichtig

Red Hat lebt und arbeitet nach Prinzipien, die sich stark von traditionellen Organisationen mit hierarchischer Struktur unterscheiden. Und es funktioniert, es macht uns kommerziell erfolgreich und menschlich glücklich. Wir haben dieses Buch übersetzt, in der Hoffnung, die Prinzipien offener Organisationen unter russischen Unternehmen zu verbreiten, unter Menschen, die anders leben wollen und können.

Lies, probiere es aus!

Quelle: habr.com