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

Ein wichtiger Tag ist für Red Hat, die russische Open-Source-Community und alle Beteiligten gekommen – es wurde auf Russisch veröffentlicht Jim Whitehursts Buch „The Open Organization: Passion That Gets Results“.. Sie erzählt ausführlich und anschaulich, wie wir bei Red Hat den besten Ideen und den talentiertesten Menschen den Weg weisen und wie man sich nicht im Chaos verliert und Millionen von Menschen auf der ganzen Welt vereint.

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

Auch in diesem Buch geht es um Leben und Praxis. Es enthält viele Ratschläge für alle, die lernen möchten, wie man ein Unternehmen mithilfe des offenen Organisationsmodells aufbaut und effektiv führt. Im Folgenden finden Sie einige der wichtigsten Grundsätze des Buches, die Sie jetzt zur Kenntnis nehmen können.

Jims Beschäftigungsgeschichte im Unternehmen ist bemerkenswert. Es zeigt, dass es in der Open-Source-Welt keine Fanfare gibt, sondern einen neuen Führungsansatz:

„Nachdem ich mit dem Personalvermittler gesprochen hatte, bekundete ich Interesse an einem Vorstellungsgespräch und er fragte, ob es mir etwas ausmachen würde, am Sonntag zum Hauptsitz von Red Hat in Raleigh, North Carolina, zu fliegen. Ich dachte, Sonntag wäre ein seltsamer Tag für ein Treffen. Aber da ich am Montag noch nach New York fliegen wollte, lag es im Allgemeinen auf dem Weg und ich stimmte zu. Ich stieg von Atlanta aus in ein Flugzeug und landete am Flughafen Raleigh Durham. Von dort nahm ich ein Taxi, das mich vor dem Red Hat-Gebäude auf dem Campus der University of North Carolina absetzte. Es war Sonntag, 9:30 Uhr, und niemand war da. Das Licht war ausgeschaltet und als ich nachsah, stellte ich fest, dass die Türen verschlossen waren. Zuerst dachte ich, ich würde getäuscht. Als ich mich umdrehte, um wieder ins Taxi zu steigen, sah ich, dass es bereits abgefahren war. Sehr bald begann es zu regnen, ich hatte keinen Regenschirm.

Gerade als ich irgendwohin wollte, um ein Taxi zu nehmen, hielt Matthew Shulick, der spätere Vorstandsvorsitzende und CEO von Red Hat, in seinem Auto vor. „Hallo“, grüßte er. „Möchten Sie einen Kaffee trinken?“ Das schien eine ungewöhnliche Art zu sein, ein Vorstellungsgespräch zu beginnen, aber ich wusste, dass ich unbedingt einen Kaffee brauchte. Letztendlich dachte ich, dass es für mich einfacher wäre, ein Taxi zum Flughafen zu nehmen.

Der Sonntagmorgen ist in North Carolina ziemlich ruhig. Es dauerte eine Weile, bis wir ein Café fanden, das vor Mittag öffnete. Das Café war nicht das beste in der Stadt und nicht das sauberste, aber es funktionierte und man konnte dort frisch gebrühten Kaffee trinken. Wir setzten uns an einen Tisch und begannen zu reden.

Nach ungefähr dreißig Minuten wurde mir klar, dass mir der Lauf der Dinge gefiel; Das Interview war nicht traditionell, aber das Gespräch selbst erwies sich als sehr interessant. Anstatt die Feinheiten der Unternehmensstrategie von Red Hat oder sein Image an der Wall Street zu diskutieren – worauf ich mich vorbereitet hatte – fragte Matthew Shulick mehr nach meinen Hoffnungen, Träumen und Zielen. Jetzt ist mir klar, dass Shulik prüfte, ob ich zur Subkultur und zum Führungsstil des Unternehmens passen würde.

Nachdem wir fertig waren, sagte Shulick, dass er mich dem Chefsyndikus des Unternehmens, Michael Cunningham, vorstellen wollte, und schlug vor, dass ich mich jetzt zu einem frühen Mittagessen mit ihm treffe. Ich stimmte zu und wir machten uns bereit zu gehen. Dann stellte mein Gesprächspartner fest, dass er sein Portemonnaie nicht dabei hatte. „Ups“, sagte er. - Ich habe kein Geld. Und bei Ihnen?" Das überraschte mich, aber ich antwortete, dass ich Geld hätte und es mir nichts ausmache, den Kaffee zu bezahlen.

Ein paar Minuten später setzte Shulik mich an einem kleinen mexikanischen Restaurant ab, wo ich Michael Cunningham traf. Aber auch hier folgte kein traditionelles Vorstellungsgespräch oder Geschäftstreffen, sondern es fand ein weiteres interessantes Gespräch statt. Als wir die Rechnung bezahlen wollten, stellte sich heraus, dass der Kreditkartenautomat des Restaurants kaputt war und wir nur Bargeld akzeptieren konnten. Cunningham drehte sich zu mir um und fragte, ob ich bereit sei zu zahlen, da er kein Bargeld bei sich hatte. Da ich nach New York wollte, hatte ich viel Bargeld, also bezahlte ich das Mittagessen.

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

Am nächsten Tag, als ich in New York war, besprach ich dieses Interview mit meiner Frau bei Red Hat. Ich sagte ihr, dass das Gespräch sehr interessant sei, aber ich war mir nicht sicher, ob diese Leute es ernst meinten, mich einzustellen: Vielleicht wollten sie nur kostenloses Essen und Benzin? Wenn ich mich an das heutige Treffen erinnere, verstehe ich, dass Shulick und Cunningham einfach offene Menschen waren und mich wie jeden anderen Menschen behandelten, mit dem sie Kaffee trinken, zu Mittag essen oder tanken konnten. Ja, es ist lustig und sogar lustig, dass beide ohne Geld dastanden. Doch ums Geld ging es ihnen nicht. Wie die Open-Source-Welt glaubten sie nicht daran, rote Teppiche auszurollen oder andere davon zu überzeugen, dass alles perfekt sei. Sie versuchten nur, mich besser kennenzulernen, nicht zu beeindrucken oder unsere Unterschiede aufzuzeigen. Sie wollten wissen, wer ich war.

Mein erstes Vorstellungsgespräch bei Red Hat hat mir deutlich gezeigt, dass die Arbeit hier anders ist. In diesem Unternehmen gab es keine traditionelle Hierarchie und Sonderbehandlung der Führungskräfte, zumindest nicht in der Form, wie sie in den meisten anderen Unternehmen üblich ist. Mit der Zeit habe ich auch gelernt, dass Red Hat an das Prinzip der Meritokratie glaubt: Es lohnt sich immer, die beste Idee umzusetzen, unabhängig davon, ob sie von der Geschäftsleitung oder von einem Ferienpraktikanten kommt. Mit anderen Worten: Meine erste Erfahrung bei Red Hat hat mir gezeigt, wie die Zukunft der Führung aussieht.“

Tipps zur Pflege der Leistungsgesellschaft

Meritokratie ist der Grundwert der Open-Source-Community. Für uns spielt es keine Rolle, auf welcher Ebene der Pyramide Sie sich befinden, Hauptsache, wie gut Ihre Ideen sind. Hier ist, was Jim vorschlägt:

  • Sagen Sie niemals: „Das will der Chef“ und verlassen Sie sich nicht auf die Hierarchie. Das mag Ihnen kurzfristig helfen, aber so bauen Sie keine Leistungsgesellschaft auf.
  • Würdigen Sie Erfolge und wichtige Beiträge öffentlich. Dies könnte eine einfache Dankes-E-Mail mit der Kopie an das gesamte Team sein.
  • Bedenken Sie: Ist Ihre Autorität eine Funktion Ihrer Position in der Hierarchie (oder Ihres Zugangs zu vertraulichen Informationen) oder ist sie ein Ergebnis des Respekts, den Sie verdient haben? Wenn das erste der Fall ist, beginnen Sie mit der Arbeit am zweiten.
  • Bitten Sie um Feedback und sammeln Sie Ideen zu einem bestimmten Thema. Man sollte auf alles reagieren, nur das Beste testen. Aber nehmen Sie nicht einfach die besten Ideen und setzen Sie sie fort – nutzen Sie jede Gelegenheit, um den Geist der Leistungsgesellschaft zu stärken und jedem Anerkennung zu zollen, der es verdient.
  • Erkennen Sie ein vorbildliches Mitglied Ihres Teams an, indem Sie ihm eine interessante Aufgabe anbieten, auch wenn diese nicht zu seinem üblichen Arbeitsgebiet gehört.

Lassen Sie Ihre Rockstars ihrer Leidenschaft folgen

Begeisterung und Engagement sind zwei sehr wichtige Wörter in einer offenen Organisation. Sie werden im Buch ständig wiederholt. Aber leidenschaftliche kreative Menschen kann man doch nicht dazu bringen, hart zu arbeiten, oder? Andernfalls erhalten Sie einfach nicht alles, was ihr Talent zu bieten hat. Bei Red Hat werden Hürden für eigene Projekte weitestgehend eingeebnet:

„Um Innovationen voranzutreiben, probieren Unternehmen viele Dinge aus. Der Ansatz von Google ist interessant. Seit Google im Jahr 2004 in jedem Haushalt bekannt wurde, versuchen Führungskräfte und Ideologen der Internetbranche, das Hauptgeheimnis des Unternehmens zu lüften, um seinen beeindruckenden Erfolg zu wiederholen. Eines der bekanntesten, aber derzeit geschlossenen Programme bestand darin, dass alle Google-Mitarbeiter aufgefordert wurden, 20 Prozent ihrer Zeit damit zu verbringen, fast alles zu tun, was sie wollten. Die Idee war, dass Mitarbeiter, wenn sie ihre eigenen Projekte und Ideen verfolgen, die ihnen außerhalb der Arbeit am Herzen liegen, mit Innovationen beginnen würden. So entstanden erfolgreiche Drittprojekte: GoogleSuggest, AdSense for Content und Orkut; Sie alle kamen aus diesem 20-Prozent-Experiment – ​​eine beeindruckende Liste! […]

Bei Red Hat verfolgen wir einen weniger formellen Ansatz. Wir haben keine feste Richtlinie darüber, wie viel Zeit jeder unserer Mitarbeiter für „Innovation“ aufwenden sollte. Anstatt den Menschen die Zeit zu geben, sich weiterzubilden, stellen wir sicher, dass die Mitarbeiter das Recht haben, ihre Zeit damit zu verbringen, neue Dinge zu lernen. Ehrlich gesagt haben viele Menschen sehr wenig Zeit, aber es gibt auch solche, die fast ihren gesamten Arbeitstag mit Innovationen verbringen können.

Der typischste Fall sieht etwa so aus: Jemand arbeitet an einem Nebenprojekt (wenn er den Führungskräften dessen Bedeutung erklärt hat – direkt am Arbeitsplatz; oder außerhalb der Arbeitszeit – aus eigener Initiative), und später kann diese Arbeit alles in Anspruch nehmen seine gegenwärtigen Stunden.“

Mehr als Brainstorming

„Lyrische Exkursion. Alex Fakeney Osborne ist der Erfinder der Brainstorming-Methode, deren Fortsetzung heute die Synektik-Methode ist. Es ist merkwürdig, dass diese Idee während des Zweiten Weltkriegs entstand, als Osborne eines der Schiffe eines amerikanischen Frachtkonvois befehligte, das von einem Torpedoangriff eines deutschen U-Bootes bedroht war. Dann erinnerte sich der Kapitän an die Technik, auf die die Piraten des Mittelalters zurückgriffen: Wenn die Besatzung in Schwierigkeiten geriet, versammelten sich alle Seeleute an Deck, um abwechselnd einen Weg zur Lösung des Problems vorzuschlagen. Es gab viele Ideen, auch auf den ersten Blick absurde: zum Beispiel die Idee, mit der ganzen Mannschaft einen Torpedo abzublasen. Doch mit dem Strahl einer Schiffspumpe, der auf jedem Schiff vorhanden ist, ist es durchaus möglich, einen Torpedo abzubremsen oder sogar seinen Kurs zu ändern. Infolgedessen patentierte Osborne sogar eine Erfindung: An der Seite des Schiffes ist ein zusätzlicher Propeller angebracht, der einen Wasserstrahl an der Seite entlangtreibt und den Torpedo entlang gleitet.“

Unser Jim wiederholt immer wieder, dass es nicht so einfach ist, in einer offenen Organisation zu arbeiten. Sogar das Management versteht es, denn es bleibt niemandem erspart, seine Meinung zu verteidigen. Aber genau dieser Ansatz ist nötig, um hervorragende Ergebnisse zu erzielen:

„Online-[Open-Source]-Foren und Chatrooms sind oft voller lebhafter und manchmal erbitterter Diskussionen über alles, von der besten Behebung eines Softwarefehlers bis hin zu den neuen Funktionen, die beim nächsten Update berücksichtigt werden sollten. In der Regel ist dies die erste Diskussionsphase, in der neue Ideen vorgebracht und gesammelt werden, aber es gibt immer eine nächste Runde – die kritische Analyse. Obwohl jeder an diesen Debatten teilnehmen kann, muss man bereit sein, seine Position mit aller Kraft zu verteidigen. Unpopuläre Ideen werden im besten Fall abgelehnt, im schlimmsten Fall lächerlich gemacht.

Sogar Linus Torvalds, der Erfinder des Linux-Betriebssystems, äußert seine Ablehnung der vorgeschlagenen Codeänderungen. Eines Tages gerieten Linus und David Howells, einer der führenden Entwickler von Red Hat, in eine hitzige Debatte über die Vorzüge einer von Red Hat angeforderten Codeänderung, die dazu beitragen würde, unseren Kunden Sicherheit zu bieten. Als Antwort auf Howells' Anfrage schrieb Torvalds: „Ehrlich gesagt ist das [nicht druckbares Wort] idiotisch. Alles scheint sich um diese dummen Schnittstellen zu drehen, und das aus völlig dummen Gründen. Warum sollten wir das tun? Der vorhandene X.509-Parser gefällt mir nicht mehr. Es werden dumme komplexe Schnittstellen erstellt, und jetzt wird es 11 davon sein. – Linus 9.“

Abgesehen von technischen Details schrieb Torvalds in der nächsten Nachricht im gleichen Sinne weiter – und zwar auf eine Weise, die ich nicht zu zitieren wage. Dieser Streit war so laut, dass er es sogar auf die Seiten des Wall Street Journal schaffte. […]

Diese Debatte zeigt, dass die meisten Unternehmen, die proprietäre, unfreie Software produzieren, keine offene Debatte darüber führen, an welchen neuen Funktionen oder Änderungen sie möglicherweise arbeiten. Wenn das Produkt fertig ist, versendet das Unternehmen es einfach an die Kunden und macht weiter. Gleichzeitig ebben im Fall von Linux die Diskussionen darüber, welche Änderungen notwendig sind und – was am wichtigsten ist – warum sie notwendig sind, nicht ab. Das macht den gesamten Prozess natürlich viel chaotischer und zeitaufwändiger.“

Früh loslassen, oft loslassen

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. Je mehr Änderungen und Updates in einer Softwareversion (Version) gesammelt werden, desto höher ist natürlich die Wahrscheinlichkeit, dass in dieser Version Fehler auftreten. Entwickler von Open-Source-Software haben erkannt, dass durch die schnelle und häufige Veröffentlichung von Softwareversionen das Risiko schwerwiegender Probleme mit jedem Programm verringert wird – schließlich bringen wir nicht alle Updates auf einmal auf den Markt, sondern eins nach dem anderen für jede Version. Im Laufe der Zeit haben wir festgestellt, dass dieser Ansatz nicht nur Fehler reduziert, sondern auch zu interessanteren Lösungen führt. Es stellt sich heraus, dass kontinuierliche kleine Verbesserungen auf lange Sicht zu mehr Innovation führen. Vielleicht gibt es hier nichts Überraschendes. Eines der Schlüsselprinzipien moderner Herstellungsprozesse wie Kaizen A oder Lean B ist die Konzentration auf kleine und inkrementelle Änderungen und Aktualisierungen.

[…] Vieles von dem, woran wir arbeiten, könnte scheitern. Doch anstatt lange darüber nachzudenken, was funktioniert und was nicht, führen wir lieber kleine Experimente durch. Die populärsten Ideen werden zum Erfolg führen, und diejenigen, die nicht funktionieren, werden von selbst verkümmern. Auf diese Weise können wir viele Dinge ausprobieren und nicht nur eine Sache, ohne großes Risiko für das Unternehmen.

Dies ist eine rationale Möglichkeit, Ressourcen zuzuweisen. Ich werde zum Beispiel oft gefragt, wie wir auswählen, welche Open-Source-Projekte wir kommerzialisieren. Während wir manchmal Projekte initiieren, stürzen wir uns in den meisten Fällen einfach in bestehende Projekte. Eine kleine Gruppe von Ingenieuren – manchmal nur eine Person – beginnt, zu einem der Projekte der Open-Source-Community beizutragen. Wenn das Projekt erfolgreich ist und bei unseren Kunden gefragt ist, beginnen wir, mehr Zeit und Mühe dafür aufzuwenden. Wenn nicht, gehen die Entwickler zu einem neuen Projekt über. Bis wir uns für die Kommerzialisierung des Vorschlags entscheiden, ist das Projekt möglicherweise so weit gewachsen, dass die Lösung offensichtlich ist. Bei Red Hat entstehen natürlich verschiedene Projekte, auch solche, die nicht mit Software zu tun haben, bis jedem klar wird, dass jetzt jemand Vollzeit daran arbeiten muss.“

Hier noch ein Zitat aus dem Buch:

„Mir wurde klar, dass die Führungskräfte von morgen Eigenschaften haben müssen, die in herkömmlichen Organisationen einfach übersehen werden, um dieser Rolle gerecht zu werden. Um eine offene Organisation effektiv zu führen, muss eine Führungskraft über die folgenden Eigenschaften verfügen.

  • Persönliche Stärke und Selbstvertrauen. Gewöhnliche Führungskräfte nutzen ihre Positionsmacht – ihre Position –, um Erfolg zu haben. Aber in einer Leistungsgesellschaft müssen sich Führungskräfte Respekt verdienen. Und das ist nur möglich, wenn sie keine Angst haben zuzugeben, dass sie nicht alle Antworten haben. Sie müssen bereit sein, Probleme zu diskutieren und schnell Entscheidungen zu treffen, um mit ihrem Team die besten Lösungen zu finden.
  • Geduld. Die Medien erzählen selten Geschichten darüber, wie „geduldig“ eine Führungskraft ist. Aber er muss wirklich geduldig sein. Wenn Sie daran arbeiten, von Ihrem Team die bestmöglichen Leistungen und Ergebnisse zu erzielen, indem Sie stundenlang Gespräche führen und Dinge immer und immer wieder wiederholen, bis es richtig gemacht ist, müssen Sie geduldig sein.
  • Hoher EQ (emotionale Intelligenz). Allzu oft fördern wir die Intelligenz von Führungskräften, indem wir uns auf ihren IQ konzentrieren, obwohl eigentlich ihr emotionaler Intelligenzquotient oder EQ-Score berücksichtigt werden muss. Es reicht nicht aus, der klügste Mensch unter anderen zu sein, wenn man nicht in der Lage ist, mit diesen Menschen zusammenzuarbeiten. Wenn Sie mit Communities engagierter Mitarbeiter wie Red Hat zusammenarbeiten und nicht die Möglichkeit haben, jemanden herumzukommandieren, wird Ihre Fähigkeit, zuzuhören, analytisch zu verarbeiten und Dinge nicht persönlich zu nehmen, unglaublich wertvoll.
  • Andere Mentalität. Führungskräfte, die aus traditionellen Organisationen kamen, wurden im Geiste des quid pro quo (lateinisch für „quid pro quo“) erzogen, wonach jede Aktion eine angemessene Gegenleistung erhalten sollte. Wenn Sie jedoch in den Aufbau einer bestimmten Community investieren möchten, müssen Sie langfristig denken. Es ist, als würde man versuchen, ein fein ausbalanciertes Ökosystem aufzubauen, in dem jeder falsche Schritt ein Ungleichgewicht erzeugen und zu langfristigen Verlusten führen kann, die man vielleicht nicht sofort bemerkt. Führungskräfte müssen sich von der Denkweise befreien, die von ihnen verlangt, heute um jeden Preis Ergebnisse zu erzielen, und ihre Geschäfte so zu gestalten, dass sie durch Investitionen in die Zukunft größere Vorteile erzielen können.“

Und warum ist es wichtig

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

Lesen, Versuch es!

Source: habr.com

Kommentar hinzufügen