« Organisation ouverte » : comment ne pas se perdre dans le chaos et fédérer des millions de personnes

Un jour important est arrivé pour Red Hat, la communauté open source russe et toutes les personnes impliquées - il a été publié en russe Le livre de Jim Whitehurst, The Open Organization: Passion That Gets Results. Elle raconte en détail et de manière vivante comment nous, chez Red Hat, donnons le chemin aux meilleures idées et aux personnes les plus talentueuses, et aussi comment ne pas se perdre dans le chaos et unir des millions de personnes à travers le monde.

Ce livre parle aussi de la vie et de la pratique. Il contient de nombreux conseils pour tous ceux qui souhaitent apprendre à créer une entreprise en utilisant le modèle d'organisation ouverte et à la gérer efficacement. Vous trouverez ci-dessous quelques-uns des principes les plus importants énoncés dans le livre et dont vous pouvez prendre note dès maintenant.

L'expérience professionnelle de Jim au sein de l'entreprise est remarquable. Cela montre qu’il n’y a pas de fanfare dans le monde open source, mais qu’il existe une nouvelle approche du leadership :

« Après avoir parlé avec le recruteur, j'ai exprimé mon intérêt pour un entretien et il m'a demandé si cela me dérangerait de me rendre au siège de Red Hat à Raleigh, en Caroline du Nord, dimanche. Je pensais que dimanche était un jour étrange pour se rencontrer. Mais comme j'allais encore prendre l'avion pour New York lundi, en général c'était en route, et j'ai accepté. Je suis monté à bord d'un avion en provenance d'Atlanta et j'ai atterri à l'aéroport de Raleigh Durham. De là, j'ai pris un taxi qui m'a déposé devant le bâtiment Red Hat sur le campus de l'Université de Caroline du Nord. C'était dimanche, 9h30, et il n'y avait personne. Les lumières étaient éteintes et après vérification, j'ai découvert que les portes étaient verrouillées. Au début, je pensais que j'étais dupe. Alors que je me retournais pour remonter dans le taxi, j'ai vu qu'il était déjà parti. Très vite, il s’est mis à pleuvoir, je n’avais pas de parapluie.

Juste au moment où j'étais sur le point d'aller quelque part prendre un taxi, Matthew Shulick, plus tard président du conseil d'administration et PDG de Red Hat, s'est arrêté dans sa voiture. « Salut », salua-t-il. « Voudriez-vous prendre un café ? » Cela semblait être une façon inhabituelle de commencer une interview, mais je savais que j'avais absolument besoin de prendre un café. En fin de compte, j'ai pensé qu'il serait plus facile pour moi de prendre un taxi pour l'aéroport.

Les dimanches matins sont plutôt calmes en Caroline du Nord. Il nous a fallu un certain temps pour trouver un café ouvert avant midi. Le café n'était pas le meilleur de la ville ni le plus propre, mais il fonctionnait et on pouvait y boire du café fraîchement moulu. Nous nous sommes assis à une table et avons commencé à parler.

Au bout d'une trentaine de minutes, j'ai réalisé que j'aimais la façon dont les choses se déroulaient ; L'entretien n'était pas traditionnel, mais la conversation elle-même s'est avérée très intéressante. Au lieu de discuter des subtilités de la stratégie d'entreprise de Red Hat ou de son image à Wall Street – ce à quoi je m'étais préparé – Matthew Shulick m'a demandé davantage sur mes espoirs, mes rêves et mes objectifs. Il est désormais clair pour moi que Shulik évaluait si je correspondrais à la sous-culture et au style de gestion de l'entreprise.

Après avoir terminé, Shulick m'a dit qu'il voulait me présenter à l'avocat général de l'entreprise, Michael Cunningham, et m'a suggéré de le rencontrer maintenant pour un déjeuner tôt. J'ai accepté et nous nous sommes préparés à partir. Puis mon interlocuteur a découvert qu’il n’avait pas son portefeuille sur lui. "Oups," dit-il. - Je n'ai pas d'argent. Et toi?" Cela m’a surpris, mais j’ai répondu que j’avais de l’argent et que cela ne me dérangeait pas de payer pour le café.

Quelques minutes plus tard, Shulik m'a déposé dans un petit restaurant mexicain, où j'ai rencontré Michael Cunningham. Mais encore une fois, aucune interview ou réunion d’affaires traditionnelle n’a suivi, mais une autre conversation intéressante a eu lieu. Alors que nous étions sur le point de payer la facture, il s'est avéré que le distributeur de carte de crédit du restaurant était en panne et que nous ne pouvions accepter que des espèces. Cunningham s'est tourné vers moi et m'a demandé si j'étais prêt à payer, car il n'avait pas d'argent liquide sur lui. Comme j'allais à New York, j'avais beaucoup d'argent, alors j'ai payé le déjeuner.

Cunningham m'a proposé de me conduire à l'aéroport et nous sommes allés dans sa voiture. Après quelques minutes, il a demandé : « Cela vous dérange-t-il si je m'arrête et prends de l'essence ? Nous allons y aller à toute vapeur." "Pas de problème," répondis-je. Dès que j'ai entendu le bruit rythmé de la pompe, on a frappé à la fenêtre. C'était Cunningham. "Hé, ils n'acceptent pas les cartes de crédit ici", a-t-il déclaré. "Puis-je emprunter de l'argent?" J'ai commencé à me demander s'il s'agissait vraiment d'une interview ou d'une sorte d'arnaque.

Le lendemain, alors que j'étais à New York, j'ai discuté de cette interview avec ma femme chez Red Hat. Je lui ai dit que la conversation était très intéressante, mais je n'étais pas sûr que ces gens voulaient vraiment m'embaucher : peut-être voulaient-ils juste de la nourriture et de l'essence gratuites ? En me souvenant de cette réunion d'aujourd'hui, je comprends que Shulick et Cunningham étaient simplement des gens ouverts et me traitaient comme n'importe quelle autre personne avec qui ils pouvaient prendre un café, déjeuner ou faire le plein d'essence. Oui, c'est drôle et même drôle qu'ils se retrouvent tous les deux sans argent. Mais pour eux, ce n’était pas une question d’argent. Tout comme le monde open source, ils ne croyaient pas à l’importance de dérouler le tapis rouge ou d’essayer de convaincre les autres que tout était parfait. Ils essayaient simplement de mieux me connaître, sans essayer de m'impressionner ou de souligner nos différences. Ils voulaient savoir qui j'étais.

Mon premier entretien chez Red Hat m'a clairement montré que le travail ici était différent. Cette entreprise n'avait pas de hiérarchie traditionnelle ni de traitement spécial pour les dirigeants, du moins sous la forme habituelle dans la plupart des autres entreprises. Au fil du temps, j'ai également appris que Red Hat croit au principe de méritocratie : il vaut toujours la peine d'essayer de mettre en œuvre la meilleure idée, qu'elle vienne de la haute direction ou d'un stagiaire d'été. En d’autres termes, ma première expérience chez Red Hat m’a fait découvrir à quoi ressemble l’avenir du leadership.

Conseils pour cultiver la méritocratie

La méritocratie est la valeur fondamentale de la communauté open source. Peu importe le niveau de la pyramide que vous occupez, l’essentiel est la qualité de vos idées. Voici ce que Jim suggère :

• Ne dites jamais : « C’est ce que veut le patron » et ne vous fiez pas à la hiérarchie. Cela peut vous aider à court terme, mais ce n’est pas ainsi qu’on construit une méritocratie.
• Reconnaître publiquement les réussites et les contributions importantes. Il peut s'agir d'un simple e-mail de remerciement avec toute l'équipe en copie.
• Considérez : votre autorité est-elle fonction de votre position dans la hiérarchie (ou de votre accès à des informations privilégiées), ou est-elle le résultat du respect que vous avez gagné ? Si c’est le premier, commencez à travailler sur le second.
• Demandez des commentaires et rassemblez des idées sur un sujet spécifique. Il faut réagir à tout, tester uniquement le meilleur. Mais ne vous contentez pas de prendre les meilleures idées et de les mettre en œuvre : saisissez chaque occasion pour renforcer l'esprit de méritocratie, en accordant du crédit à tous ceux qui le méritent.
• Reconnaissez un membre exemplaire de votre équipe en lui offrant une mission intéressante, même si elle ne relève pas de son domaine de travail habituel.

Laissez vos rock stars suivre leur passion

Enthousiasme et implication sont deux mots très importants dans une organisation ouverte. Ils sont répétés constamment dans le livre. Mais on ne peut pas amener des créatifs passionnés à travailler dur, n'est-ce pas ? Sinon, vous n’obtiendrez tout simplement pas tout ce que leur talent a à offrir. Chez Red Hat, les obstacles à leurs propres projets sont levés autant que possible :

« Pour stimuler l’innovation, les entreprises essaient beaucoup de choses. L'approche de Google est intéressante. Depuis que Google est devenu connu dans tous les foyers en 2004, les dirigeants et les idéologues du secteur Internet ont tenté de percer le principal secret de l'entreprise afin de répéter son succès impressionnant. L'un des programmes les plus connus, mais actuellement fermé, consistait à demander à tous les employés de Google de consacrer 20 % de leur temps à faire presque tout ce qu'ils voulaient. L’idée était que si les employés poursuivaient leurs propres projets et idées qui les passionnent en dehors du travail, ils commenceraient à innover. C'est ainsi qu'ont vu le jour des projets tiers à succès : GoogleSuggest, AdSense for Content et Orkut ; ils sont tous issus de cette expérience à 20 pour cent – ​​une liste impressionnante ! […]

Chez Red Hat, nous adoptons une approche moins formelle. Nous n'avons pas de politique définie concernant le temps que chacun de nos employés doit consacrer à « l'innovation ». Au lieu de donner aux gens du temps pour se former, nous veillons à ce que les employés aient le droit de consacrer leur temps à apprendre de nouvelles choses. Pour être honnête, beaucoup de gens disposent de très peu de temps, mais il y a aussi ceux qui peuvent consacrer presque toute leur journée de travail à l'innovation.

Le cas le plus typique ressemble à ceci : quelqu'un travaille sur un projet parallèle (s'il a expliqué son importance aux managers - directement sur le lieu de travail ; ou en dehors des heures de travail - de sa propre initiative), et plus tard ce travail peut prendre tout ses heures actuelles.

Plus qu'un brainstorming

« Digression lyrique. Alex Fakeney Osborne est l'inventeur de la méthode du brainstorming, dont la méthode synectique est aujourd'hui une continuation. Il est curieux que cette idée soit apparue pendant la Seconde Guerre mondiale, lorsqu'Osborne commandait l'un des navires d'un convoi de marchandises américain qui risquait d'être attaqué à la torpille par un sous-marin allemand. Le capitaine se souvint alors de la technique à laquelle recouraient les pirates du Moyen Âge : si l'équipage avait des ennuis, tous les marins se rassemblaient sur le pont pour proposer à tour de rôle une solution au problème. Il y avait beaucoup d'idées, y compris des absurdes à première vue : par exemple, l'idée de souffler sur une torpille avec toute l'équipe. Mais avec le jet d'une pompe de navire, disponible sur chaque navire, il est tout à fait possible de ralentir une torpille ou même de modifier sa trajectoire. En conséquence, Osborne a même breveté une invention : une hélice supplémentaire est montée sur le côté du navire, qui entraîne un courant d'eau le long du côté, et la torpille glisse le long du navire.

Notre Jim ne cesse de répéter qu'il n'est pas si facile de travailler dans une organisation ouverte. Même la direction comprend, puisque personne n'est épargné par la nécessité de défendre son opinion. Mais c’est exactement l’approche nécessaire pour obtenir d’excellents résultats :

« Les forums et les salons de discussion en ligne [open source] sont souvent remplis de discussions animées et parfois acrimonieuses sur tout, depuis la meilleure façon de corriger un bug logiciel jusqu'aux nouvelles fonctionnalités à prendre en compte dans la prochaine mise à jour. En règle générale, il s'agit de la première phase des discussions, au cours de laquelle de nouvelles idées sont avancées et accumulées, mais il y a toujours une étape suivante : l'analyse critique. Même si n’importe qui peut participer à ces débats, chacun doit être prêt à défendre sa position de toutes ses forces. Les idées impopulaires seront au mieux rejetées, au pire ridiculisées.

Même Linus Torvalds, le créateur du système d'exploitation Linux, exprime son désaccord avec les modifications proposées au code. Un jour, Linus et David Howells, l'un des principaux développeurs de Red Hat, se sont lancés dans un débat houleux sur les mérites d'un changement de code demandé par Red Hat et qui contribuerait à assurer la sécurité de nos clients. En réponse à la demande de Howells, Torvalds a écrit : « Franchement, c'est [un mot non imprimable] idiot. Tout semble tourner autour de ces interfaces stupides, et pour des raisons complètement stupides. Pourquoi devrions-nous faire cela ? Je n'aime plus l'analyseur X.509 existant. Des interfaces stupidement complexes sont créées, et il y en aura désormais 11. – Linus 9. »

Laissant de côté les détails techniques, Torvalds a continué à écrire dans le même esprit dans le message suivant - et de telle manière que je n'ose pas le citer. Cette controverse a été si bruyante qu’elle a même fait la une des pages du Wall Street Journal. […]

Ce débat montre que la plupart des entreprises qui produisent des logiciels propriétaires non libres n'ont pas de débat ouvert sur les nouvelles fonctionnalités ou les changements sur lesquels elles pourraient travailler. Lorsque le produit est prêt, l’entreprise l’expédie simplement aux clients et passe à autre chose. Dans le même temps, dans le cas de Linux, les discussions sur les changements nécessaires et, surtout, sur les raisons pour lesquelles ils sont nécessaires ne s'apaisent pas. Bien entendu, cela rend l’ensemble du processus beaucoup plus compliqué et prend beaucoup plus de temps.

Sortir tôt, sortir souvent

Nous ne pouvons pas prédire l'avenir, nous devons donc simplement essayer :

« Nous fonctionnons selon le principe d’un « lancement anticipé et de mises à jour fréquentes ». Le problème clé de tout projet logiciel est le risque d’erreurs ou de bugs dans le code source. Évidemment, plus les modifications et les mises à jour sont collectées dans une version (version) du logiciel, plus la probabilité qu'il y ait des bogues dans cette version est élevée. Les développeurs de logiciels open source ont réalisé qu'en publiant des versions de logiciels rapidement et fréquemment, le risque de problèmes graves avec n'importe quel programme est réduit - après tout, nous ne mettons pas toutes les mises à jour sur le marché en même temps, mais une à la fois pour chaque version. Au fil du temps, nous avons remarqué que cette approche non seulement réduit les erreurs, mais conduit également à des solutions plus intéressantes. Il s’avère qu’apporter continuellement de petites améliorations crée davantage d’innovation à long terme. Il n’y a peut-être rien de surprenant ici. L'un des principes clés des processus de fabrication modernes tels que le Kaizen A ou le Lean B est l'accent mis sur des changements et des mises à jour mineurs et progressifs.

[…] Une grande partie de ce sur quoi nous travaillons pourrait ne pas réussir. Mais au lieu de passer beaucoup de temps à nous demander ce qui fonctionnera et ce qui ne fonctionnera pas, nous préférons mener de petites expériences. Les idées les plus populaires mèneront au succès, et celles qui ne fonctionnent pas dépériront d’elles-mêmes. De cette façon, nous pouvons essayer plusieurs choses plutôt qu’une seule, sans trop de risques pour l’entreprise.

Il s’agit d’une manière rationnelle d’allouer les ressources. Par exemple, les gens me demandent souvent comment nous choisissons les projets open source à commercialiser. Même si nous lançons parfois des projets, le plus souvent nous nous contentons de nous lancer dans des projets existants. Un petit groupe d'ingénieurs (parfois une seule personne) commence à contribuer à l'un des projets de la communauté open source. Si le projet réussit et est demandé par nos clients, nous commençons à y consacrer plus de temps et d'efforts. Sinon, les développeurs passent à un nouveau projet. Au moment où nous décidons de commercialiser la proposition, le projet aura peut-être pris une telle ampleur que la solution sera évidente. Divers projets, y compris des projets non logiciels, surgissent naturellement au sein de Red Hat jusqu'à ce qu'il devienne clair pour tout le monde que désormais quelqu'un devra travailler dessus à plein temps.

Voici une autre citation du livre :

« J'ai réalisé que pour remplir ce rôle, les dirigeants de demain doivent avoir des caractéristiques qui sont tout simplement négligées dans les organisations conventionnelles. Pour diriger efficacement une organisation ouverte, un leader doit posséder les qualités suivantes.

• Force personnelle et confiance. Les dirigeants ordinaires utilisent le pouvoir de leur position – leur position – pour réussir. Mais dans une méritocratie, les dirigeants doivent gagner le respect. Et cela n’est possible que s’ils n’ont pas peur d’admettre qu’ils n’ont pas toutes les réponses. Ils doivent être disposés à discuter des problèmes et à prendre des décisions rapidement pour trouver les meilleures solutions avec leur équipe.
• Patience. Les médias racontent rarement à quel point un leader est « patient ». Mais il faut vraiment qu'il soit patient. Lorsque vous travaillez pour obtenir le meilleur effort et les meilleurs résultats de votre équipe, que vous discutez pendant des heures et que vous répétez les choses encore et encore jusqu'à ce que tout soit bien fait, vous devez être patient.
• QE élevé (intelligence émotionnelle). Trop souvent, on valorise l’intelligence des dirigeants en se focalisant sur leur QI, alors que ce qu’il faut réellement prendre en compte c’est leur quotient d’intelligence émotionnelle, ou score EQ. Être la personne la plus intelligente parmi les autres ne suffit pas si vous n’êtes pas capable de travailler avec ces personnes. Lorsque vous travaillez avec des communautés d'employés engagés comme Red Hat et que vous n'avez pas la possibilité de donner des ordres à qui que ce soit, votre capacité à écouter, à traiter de manière analytique et à ne pas prendre les choses personnellement devient extrêmement précieuse.
• Mentalité différente. Les dirigeants issus d’organisations traditionnelles ont été élevés dans l’esprit de quiproquo (du latin « quid pro quo »), selon lequel chaque action doit recevoir un retour adéquat. Mais lorsque vous envisagez d’investir dans la construction d’une communauté particulière, vous devez penser à long terme. C'est comme essayer de construire un écosystème délicatement équilibré, dans lequel tout faux pas peut créer un déséquilibre et entraîner des pertes à long terme que vous ne remarquerez peut-être pas tout de suite. Les dirigeants doivent se débarrasser de la mentalité qui les oblige à obtenir des résultats aujourd’hui, à tout prix, et commencer à faire des affaires d’une manière qui leur permet de récolter de plus grands bénéfices en investissant dans l’avenir. »

Et pourquoi est-ce important

Red Hat vit et fonctionne selon des principes très différents d'une organisation hiérarchique traditionnelle. Et ça marche, ça nous rend commercialement prospère et humainement heureux. Nous avons traduit ce livre dans l'espoir de diffuser les principes d'une organisation ouverte parmi les entreprises russes, parmi les personnes qui veulent et peuvent vivre différemment.

Lire, essayez-le !

Source: habr.com