C'est un jour important pour Red Hat, la communauté open source russe et tous ceux qui y participent – le livre de Jim Whitehurst "L'organisation ouverte : Une passion qui porte ses fruits" est sorti en russe. Ce livre parle aussi de la vie et de la pratique. Il contient de nombreux conseils pour tous ceux qui souhaitent apprendre à construire une entreprise selon le modèle d'une organisation ouverte et à la gérer efficacement. Voici quelques-uns des principes les plus importants présentés dans le livre que vous pouvez prendre en note dès maintenant.
L'histoire du recrutement de Jim dans l'entreprise est remarquable. Elle montre qu'il n'y a pas de fanfare dans le monde du code ouvert, mais un nouvel abord du leadership :
« Après une conversation avec le recruteur, j'ai exprimé mon intérêt pour un entretien, et il a demandé si cela me dérangerait de me rendre à la siège de Red Hat à Raleigh, en Caroline du Nord, un dimanche. J'ai pensé que c'était un jour étrange pour une réunion. Mais comme j'avais déjà prévu de voler à New York le lundi, cela faisait en fait un détour de mon chemin, et j'ai accepté. J'ai pris l'avion d'Atlanta et je suis arrivé à l'aéroport de Raleigh-Durham. De là, j'ai pris un taxi qui m'a déposé devant le bâtiment de Red Hat sur le campus de l'Université de Caroline du Nord. C'était un dimanche, il était 9h30 du matin et il n'y avait personne aux alentours. Les lumières étaient éteintes, et en vérifiant, j'ai découvert que les portes étaient verrouillées. Au début, je pensais que c'était une blague. En me retournant pour revenir au taxi, j'ai vu qu'il était déjà parti. Très vite, il a commencé à pleuvoir et je n'avais pas de parapluie.
Alors que je m'apprêtais à aller quelque part pour attraper un taxi, Matthew Szulik, qui deviendra plus tard le président du conseil d'administration et le PDG de Red Hat, est arrivé avec sa voiture. « Bonjour, » a-t-il dit. « Voulez-vous prendre un café ? » Cela m'a paru une manière inhabituelle de commencer un entretien, mais je savais que j'avais définitivement besoin d'un café. Au final, je me suis dit que ce serait plus facile de prendre un taxi pour l'aéroport par la suite.
Alors que je m'apprêtais à partir quelque part pour prendre un taxi, Matthew Shulik, le futur président du conseil d'administration et directeur général de Red Hat, s'est arrêté avec sa voiture. « Bonjour, » a-t-il dit. « Voulez-vous prendre un café ? » Cela m'a semblé être un début inhabituel d'entretien, mais je réalisais que j'avais vraiment besoin d'un café. Au fond, pensais-je, il sera plus facile de prendre un taxi pour l'aéroport après ça.
Le dimanche en Caroline du Nord, les matins sont assez calmes. Il nous a fallu un certain temps pour trouver un café qui ouvre avant midi. Le café ne s'est pas avéré être le meilleur de la ville et n'était pas très propre, mais il fonctionnait et on pouvait y boire un café fraîchement préparé. Nous nous sommes assis à une table et avons commencé notre conversation.
Après environ trente 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 s'est révélé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 - c'est-à-dire de ce pour quoi j'étais préparé - Matthew Shulik posait davantage de questions sur mes espoirs, mes rêves et mes objectifs. Maintenant, je comprends que Shulik évaluait si je correspondais à la sous-culture et au style de gestion de l'entreprise.
Après que nous ayons terminé, Shulik a signalé qu'il voulait me présenter au conseiller juridique principal de l'entreprise, Michael Cunningham, et a proposé de le rencontrer tout de suite, pour un déjeuner précoce. J'ai accepté, et nous nous sommes préparés à partir. Puis, mon interlocuteur a découvert qu'il n'avait pas de portefeuille avec lui. « Oups, a-t-il dit. J'ai pas d'argent. Et vous ? » 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é.
Après quelques minutes, Shulik m'a déposé dans un petit restaurant mexicain où j'ai rencontré Michael Cunningham. Mais il n'y a encore eu ni entretien traditionnel ni réunion d'affaires, juste une autre conversation intéressante. Lorsque nous nous sommes préparés à régler l'addition, il s'est avéré que la machine à cartes de crédit du restaurant était en panne, et ils n'acceptaient 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. Étant donné que j'allais à New York, j'avais beaucoup d'argent liquide, donc j'ai payé le déjeuner.
Cunningham a proposé de me conduire à l'aéroport, et nous sommes partis avec sa voiture. Après quelques minutes, il a demandé : « Ça ne vous dérange pas si je m'arrête faire le plein ? On va y aller à toute vitesse. » – « Pas de problème, » ai-je répondu. À peine avais-je entendu le bruit rythmique de la pompe, qu'il y eut un coup frappé à la fenêtre. C'était Cunningham. « Hé, ils n'acceptent pas les cartes de crédit ici, » m'a-t-il dit. – « Puis-je emprunter un peu d'argent ? » Je commençais à me demander si cette entrevue était réellement authentique ou si c'était une sorte d'escroquerie.
Le lendemain, alors que j'étais à New York, j'ai discuté avec ma femme de cet entretien chez Red Hat. Je lui ai expliqué que la conversation avait été très intéressante, mais je n'étais pas sûr que ces gens aient vraiment l'intention de m'embaucher : peut-être avaient-ils juste besoin de nourriture gratuite et d'essence ? En repensant à cette rencontre aujourd'hui, je réalise que Shulik et Cunningham étaient simplement des gens ouverts et m'ont traité comme n'importe quelle autre personne avec qui ils auraient pu prendre un café, déjeuner ou faire le plein. Oui, c'est drôle et même comique qu'ils se soient tous les deux retrouvés sans argent. Mais pour eux, ce n'était pas une question d'argent. Comme le monde qui entoure le code ouvert, ils ne croyaient pas aux tapis rouges ou aux tentatives de convaincre l'interviewé que tout est parfait. Ils cherchaient juste à mieux me connaître, sans essayer de faire bonne impression ou de souligner nos différences. Ils voulaient savoir qui j'étais vraiment.
Mon premier entretien chez Red Hat m'a clairement montré que le travail ici est différent. Dans cette entreprise, il n'y avait pas d'hiérarchie traditionnelle ni de régime particulier pour les dirigeants, du moins pas sous la forme habituelle à laquelle la plupart des autres entreprises sont habituées. Avec le temps, j'ai également appris que Red Hat croit au principe de méritocratie : il vaut toujours la peine d'essayer de réaliser la meilleure des idées, qu'elle provienne de la direction supérieure ou d'un stagiaire engagé pour un emploi d'été. En d'autres termes, ma première impression de 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é du code ouvert. Peu importe à quel niveau de la pyramide tu te trouves, l'important est la qualité de tes idées. Voici ce que propose Jim :
- Ne dites jamais : « C'est ce que veut le patron » – et ne comptez pas sur l'ordre hiérarchique. Cela peut vous aider à court terme, mais on ne construit pas une méritocratie de cette manière.
- Reconnaissez publiquement les succès et les contributions importantes au projet commun. Cela peut être un simple e-mail de remerciement, avec toute l'équipe en copie.
- Pensez-y : votre autorité dépend-elle de votre position dans la hiérarchie (ou de l'accès à des informations privilégiées) ou est-elle le résultat du respect que vous avez gagné ? Si c'est la première option, commencez à travailler sur la seconde.
- Demandez des retours et recueillez des idées sur un sujet spécifique. Vous devez réagir à tout, et tester uniquement le meilleur. Mais ne vous contentez pas de prendre les meilleures idées et d'avancer avec elles : saisissez chaque occasion de renforcer l'esprit de méritocratie en rendant hommage à ceux qui le méritent.
- Saluez un membre exemplaire de votre équipe en lui confiant une tâche intéressante, même si elle n'est pas liée à son domaine d'expertise habituel.
Laissez vos « rock stars » suivre leur passion.
L'enthousiasme et l'engagement sont deux mots très importants dans une organisation ouverte. Dans le livre, ils sont constamment répétés. Mais vous ne pouvez pas forcer des personnes créatives et passionnées à travailler « de A à Z », n'est-ce pas ? Sinon, vous ne profiterez tout simplement pas de tout ce que leur talent peut offrir. Chez Red Hat, les obstacles aux projets personnels sont minimisés au maximum :
« Pour gérer l'innovation, les entreprises essaient beaucoup de choses. L'approche de Google est intéressante. Depuis que Google, à partir de 2004, s'est fait connaître dans chaque foyer, les dirigeants et les idéologues du secteur Internet ont tenté de percer le secret de l'entreprise pour reproduire son succès impressionnant. L'un des programmes les plus connus, mais actuellement fermé, consistait à offrir à tous les employés de Google d'utiliser 20 % de leur temps de travail pour faire à peu près tout ce qui leur plaisait. L'idée était la suivante : si les employés commencent à réaliser leurs propres projets et idées qui les passionnent en dehors du travail, ils commenceront à innover. C'est ainsi que des projets tiers ont vu le jour : Google Suggest, AdSense for Content et Orkut ; tous sont issus de cette expérience des 20 pour cent – une liste impressionnante ! [...]
Chez Red Hat, nous adoptons une approche moins formelle. Nous n’avons pas de politique établie concernant le temps que chaque employé doit consacrer à l'« innovation ». Au lieu de réserver des moments spécifiques à l'auto-formation, nous permettons à nos employés de gagner le droit de consacrer leur temps à de nouvelles initiatives. Pour être franc, beaucoup d’entre eux n’ont pas beaucoup de ce temps, mais il y en a aussi qui peuvent passer presque toute leur journée de travail sur l'innovation.
Le cas le plus typique ressemble à ceci : quelqu'un travaille sur un projet secondaire (s'il a expliqué aux managers son importance – directement sur le lieu de travail ; ou pendant son temps libre – de son propre chef), et plus tard, ce travail peut occuper toutes ses heures de présence.
Plus qu'un brainstorming
« Une parenthèse lyrique. Alex Faïknie Osborne est l'inventeur de la méthode du « brainstorming », dont le successeur aujourd'hui est la méthode de la synectique. Il est intéressant de noter que cette idée a vu le jour pendant la Seconde Guerre mondiale, alors qu'Osborne commandait l'un des navires d'un convoi commercial américain menacé d'attaque par torpilles d'un sous-marin allemand. À ce moment-là, le capitaine se souvint d'une technique utilisée par les pirates du Moyen Âge : si l'équipage se trouvait en difficulté, tous les marins se rassemblaient sur le pont pour proposer tour à tour une solution au problème. Il y avait énormément d'idées, y compris certaines qui semblaient absurdes au premier abord : par exemple, l'idée de souffler sur la torpille avec toute l'équipe. Mais avec le jet de la pompe du navire, qui se trouve sur chaque bateau, il était possible de ralentir la torpille ou même de changer sa trajectoire. En conséquence, Osborne a même breveté l'invention : un additional hélice est montée sur le flanc du navire, qui propulse un jet d'eau le long de la coque, et la torpille glisse à côté. »
Notre Jim répète constamment que dans une organisation ouverte, il n'est pas si facile de travailler. Même la direction en fait l'expérience, car personne n'est exempté de la nécessité de défendre son point de vue. Mais c'est justement cette approche qui est nécessaire pour obtenir un excellent résultat :
Les forums en ligne [des développeurs open source] et les chats sont souvent remplis de discussions animées, parfois même acerbes, sur tout – allant de la meilleure manière de corriger un bug logiciel à la question des nouvelles fonctionnalités à envisager pour la prochaine mise à jour. En général, cela constitue la première phase des discussions, où de nouvelles idées sont avancées et accumulées, mais il y a toujours une prochaine étape – une analyse critique. Bien que tout le monde puisse participer à ces débats, il est nécessaire d'être prêt à défendre sa position avec vigueur. Les idées impopulaires sont, au mieux, rejetées, et 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 dans le code. Une fois, Linus et David Howells, l'un des principaux développeurs de Red Hat, ont eu une vive polémique sur les avantages d'une modification du code, demandée par Red Hat, qui aiderait à assurer la sécurité de nos clients. En réponse à la demande d'Howells, Torvalds a écrit : « Franchement, c'est [un mot inapproprié] de l'idiotie. Tout semble tourner autour de ces interfaces stupides, et pour des raisons complètement idiotes. Pourquoi devrions-nous faire cela ? Je n'aime déjà pas le parseur X.509 existant. On crée des interfaces compliquées et idiotes, et maintenant il y en aura 11. – Linus 9 ».
En laissant de côté les détails techniques, Torvalds a continué dans le même esprit dans son message suivant – et des choses que je n'oserais pas citer. Ce débat a été si retentissant qu'il est même apparu dans les pages de The Wall Street Journal. […]
Ce débat montre qu'il n'existe pas de débats ouverts dans la plupart des entreprises qui développent des programmes propriétaires et non libres sur les nouvelles fonctionnalités ou modifications sur lesquelles elles pourraient travailler. Une fois le produit prêt, l'entreprise l'envoie simplement à ses clients et passe à autre chose. En revanche, dans le cas de Linux, les discussions sur les changements nécessaires et – surtout – pourquoi ils sont nécessaires ne cessent jamais. Cela rend effectivement le processus beaucoup plus chaotique et laborieux.
Sortir tôt, sortir souvent
Nous ne pouvons pas prévoir l'avenir, alors nous devons juste essayer :
«Nous agissons sur le principe du «lancement précoce, mises à jour fréquentes». Le risque principal dans tout projet logiciel est celui des erreurs ou des bugs dans le code source. Il est évident que plus il y a de changements et de mises à jour regroupés dans une seule version d’un logiciel, plus la probabilité d’y rencontrer des bugs est élevée. Les développeurs de logiciels open source ont compris que des versions fréquentes et rapides réduisent le risque de rencontrer des problèmes graves avec un logiciel donné – car nous ne mettons pas tout en œuvre avec chaque mise à jour, mais plutôt par petites portions avec chaque version. Avec le temps, nous avons remarqué que cette approche non seulement réduit le nombre d'erreurs, mais mène également à des solutions plus intéressantes. Il s'avère que l'ajout constant de petites améliorations crée finalement plus d'innovations. Cela ne devrait pas être surprenant. Un des principes clés des processus de production modernes, tels que le kaizen ou le lean, est l'accent mis sur des changements et mises à jour petits et progressifs.
[…] Beaucoup de ce sur quoi nous travaillons peut ne pas réussir. Mais au lieu de perdre beaucoup de temps à hésiter sur ce qui fonctionnera ou non, nous préférons mener de petites expérimentations. Les idées les plus demandées mèneront au succès, tandis que celles qui ne fonctionneront pas disparaîtront d'elles-mêmes. De cette manière, nous pouvons essayer beaucoup de choses, au lieu de nous cantonner à une seule option, et ce, sans risque important pour l'entreprise.
C'est une méthode rationnelle de répartition des ressources. Par exemple, les gens me demandent souvent comment nous choisissons quels projets open source commercialiser. Bien que nous lancions parfois des projets, nous nous connectons le plus souvent à des projets existants. Un petit groupe d'ingénieurs - ou parfois une seule personne - commence à contribuer à l'un des projets de la communauté open source. Si le projet est réussi et 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 l'offre, le projet peut avoir tellement évolué que la décision est évidente. Des projets de toutes sortes, y compris ceux qui ne sont pas liés au logiciel, émergent naturellement dans toute l'entreprise Red Hat, jusqu'à ce que tout le monde réalise qu'il est désormais nécessaire que quelqu'un travaille en permanence dessus.
Voici une autre citation du livre :
« J'ai réalisé que pour correspondre à un tel rôle, les dirigeants de demain doivent posséder des caractéristiques auxquelles on ne prête généralement pas attention dans les organisations classiques. Pour diriger efficacement une organisation ouverte, un dirigeant doit posséder les qualités suivantes.
- Force personnelle et confiance. Les dirigeants classiques utilisent le pouvoir fonctionnel - 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 de reconnaître qu'ils n'ont pas toutes les réponses. Ils doivent être prêts à discuter des problèmes et à prendre des décisions rapidement pour trouver les meilleures solutions avec leur équipe.
- Patience. Les médias parlent rarement des histoires sur la manière dont un dirigeant est « patient ». Pourtant, il doit réellement faire preuve de patience. Lorsque vous travaillez pour obtenir le maximum d'efforts et de résultats de votre équipe, que vous passez des heures à dialoguer et à répéter quelque chose encore et encore jusqu'à ce que tout soit bien fait, vous devez faire preuve de patience.
- Élevé EQ (intelligence émotionnelle). Trop souvent, nous faisons la promotion des capacités intellectuelles des dirigeants en nous concentrant sur leur QI, alors qu'il est en réalité nécessaire de prendre en compte leur quotient d'intelligence émotionnelle, ou évaluation EQ. Être la personne la plus intelligente parmi les autres n'est pas suffisant si vous n'êtes pas capable de travailler avec ces personnes. Lorsque vous travaillez avec des communautés d'employés engagés, comme chez Red Hat, et que vous n'avez pas la possibilité d'ordonner à quiconque, votre capacité à écouter, à traiter analytiquement et à ne pas tout prendre pour vous devient incroyablement précieuse.
- Un autre état d'esprit. Les dirigeants issus d'organisations traditionnelles ont été élevés dans l'esprit du quid pro quo (lat. «une faveur pour une faveur»), selon lequel chaque action doit avoir un retour adéquat. Cependant, lorsque vous envisagez d'investir dans la création d'une certaine communauté, vous devez penser à long terme. C'est comme essayer de construire un écosystème délicatement équilibré, où le moindre 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 ce type de pensée exigeant des résultats immédiats et à tout prix, et adopter une gestion qui permettra d'en tirer un plus grand profit grâce à des investissements pour l'avenir.
Et pourquoi c'est important
Red Hat vit et travaille selon des principes fortement différents de ceux d'une organisation traditionnelle à hiérarchie stricte. Et cela fonctionne, cela nous rend commercialement prospères et humainement heureux. Nous avons traduit ce livre dans l'espoir de diffuser les principes d'une organisation ouverte parmi les entreprises russes, parmi des personnes qui souhaitent et peuvent vivre différemment.
, essayez !
Source : habr.com
