Un jour important est venu pour Red Hat, la communauté open source russe et toutes les personnes impliquées - en russe,
le livre de Jim Whitehurst, Une organisation ouverte: la passion porte ses fruits, a été publié . Elle raconte en détail et de manière vivante comment, chez Red Hat, nous donnons le meilleur des idées et des personnes les plus talentueuses, et comment ne pas se perdre dans le chaos et rallier des millions de personnes à travers le monde.
Et ce livre parle 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 donnés dans le livre, dont vous pouvez prendre note dès maintenant.
(Vidéo disponible avec sous-titres russes)
L'histoire de l'emploi de Jim est remarquable. Cela montre que dans le monde open source, il n'y a pas de fanfare, mais il y a une nouvelle approche du leadership:
«Après avoir parlé avec le recruteur, j'ai exprimé mon intérêt pour l'entretien et il m'a demandé si cela ne me dérangerait pas d'aller dimanche au siège de Red Hat à Raleigh, en Caroline du Nord. Je pensais que dimanche était une journée étrange à rencontrer. Mais comme j'allais prendre l'avion pour New York lundi de toute façon, j'étais en route et j'ai accepté. Je suis monté dans un avion 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 la société Red Hat sur le campus de l'Université de Caroline du Nord. C'était dimanche, à 9 h 30, et personne n'était près. La lumière a été éteinte et après vérification, j'ai constaté que les portes étaient verrouillées. Au début, j'ai décidé que j'étais dupe. En me retournant vers le taxi, je vis qu'il était déjà parti. Il a commencé à pleuvoir très vite, je n'avais pas de parapluie.
Dès que j'étais sur le point d'aller quelque part pour prendre un taxi, Matthew Schulick, plus tard président du conseil d'administration et PDG de Red Hat, s'est arrêté dans sa voiture. "Salut," dit-il. "Voulez-vous du café?" Cela m'a semblé un début inhabituel de l'interview, mais j'ai réalisé que j'avais vraiment besoin de boire du café. En fin de compte, je pensais, alors il sera plus facile pour moi de prendre un taxi pour l'aéroport.
Le dimanche en Caroline du Nord est assez calme le matin. Il nous a fallu un certain temps pour trouver un café qui ouvrirait avant midi. Le café n'était pas le meilleur de la ville et pas le plus propre, mais cela fonctionnait et là, on pouvait boire du café fraîchement moulu. Nous nous sommes assis à une table et avons commencé une conversation.
Une trentaine de minutes plus tard, j'ai réalisé que j'aime la façon dont tout se passe; l'entretien n'était pas traditionnel, mais la conversation elle-même était 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 faire ce pour quoi je me suis préparé - Matthew Shulick a demandé plus sur mes espoirs, mes rêves et mes objectifs. Je comprends maintenant que Shulik évaluait si je serais en accord avec le style de sous-culture et de gestion de l'entreprise.
Après avoir terminé, Shulik a annoncé qu'il souhaitait me présenter à l'avocat général de l'entreprise, Michael Cunningham, et a proposé de le rencontrer dès maintenant, à un déjeuner matinal. J'ai accepté et nous étions sur le point de partir. Puis mon interlocuteur a découvert qu'il n'avait pas de portefeuille avec lui. "Oups," dit-il. "Je n'ai pas d'argent." Et toi? Cela m'a pris par surprise, 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 entrevue traditionnelle ou réunion d'affaires n'a suivi, mais une autre conversation intéressante a eu lieu. Lorsque nous allions payer la facture, il s'est avéré que la machine de paiement par carte de crédit était tombée en panne dans le restaurant, et seuls les espèces pouvaient être acceptées de notre part. Cunningham s'est tourné vers moi et m'a demandé si j'étais prêt à payer parce qu'il n'avait pas d'argent comptant avec lui. Depuis que j'allais à New York, j'avais beaucoup d'argent, alors j'ai payé pour le déjeuner.
Cunningham m'a proposé de me conduire à l'aéroport et nous avons conduit dans sa voiture. Quelques minutes plus tard, il a demandé: «Ça vous dérange si je m'arrête et que je fais le plein? Nous allons nous précipiter à toute vitesse. » "Pas de problème," répondis-je. Dès que j'ai entendu le coup rythmé de la pompe, il y a eu un coup à la fenêtre. C'était Cunningham. "Hé, ils n'acceptent pas les cartes de crédit ici", a-t-il dit. "Puis-je emprunter de l'argent?" J'ai commencé à me demander s'il s'agissait vraiment d'une interview ou d'une sorte d'escroquerie.
Le lendemain, à New York, j'ai discuté avec ma femme de cette interview avec Red Hat. Je lui ai dit que la conversation était très intéressante, mais je ne sais pas si ces personnes ont sérieusement l'intention de m'engager: peut-être avaient-elles juste besoin de nourriture et d'essence gratuites? En me souvenant de cette réunion d'aujourd'hui, je comprends que Shulik et Cunningham n'étaient que des gens ouverts et me traitaient comme toute 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. Comme le monde autour de l'open source, ils ne croyaient pas au roulement du tapis rouge ni à la tentative de convaincre l'autre personne que tout était parfait. Ils ont simplement cherché à mieux me connaître, plutôt que d'essayer d'impressionner ou de souligner nos différences. Ils voulaient savoir qui j'étais.
Ma première interview chez Red Hat m'a clairement montré que le travail ici est différent. Cette entreprise n'a pas observé une hiérarchie traditionnelle et un régime spécial pour les dirigeants, du moins sous la forme acceptée dans la plupart des autres sociétés. Au fil du temps, j'ai également appris que Red Hat croit au principe de la méritocratie: il vaut toujours la peine d'essayer de traduire le meilleur des idées, que ce soit de la haute direction ou d'un stagiaire embauché 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 de culture de la méritocratie
La méritocratie est une valeur fondamentale de la communauté open source. Peu importe le niveau de la pyramide que vous occupez, l'essentiel est de savoir si vos idées sont bonnes. Voici ce que Jim propose:
- 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 la méritocratie ne peut pas être construite comme ça.
- Reconnaître publiquement les succès et les contributions importantes à la cause commune. Il peut s'agir d'un simple e-mail de remerciement, dont une copie représente toute l'équipe.
- Réfléchissez: votre autorité dépend-elle de votre position dans la hiérarchie (ou de l'accès à des informations privilégiées) ou est-ce le résultat du respect que vous avez mérité? Si le premier - commencez à travailler sur le second.
- Demandez des commentaires et collectez des idées sur un sujet spécifique. Devrait répondre à tout, tester - seulement le meilleur. Mais ne prenez pas seulement les meilleures idées et continuez avec elles - saisissez chaque occasion pour renforcer l'esprit de la méritocratie, en rendant hommage à tous ceux qui le méritent.
- Marquez le membre exemplaire de votre équipe en lui proposant une mission intéressante, même si elle ne fait pas partie de son domaine d'activité 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 répétés constamment. Mais vous ne pouvez pas faire travailler des gens enthousiastes et créatifs, non? Sinon, ne recevez pas tout ce que leur talent peut offrir. Dans Red Hat, les obstacles à vos propres projets sont levés autant que possible:
«Les entreprises essaient beaucoup pour stimuler l'innovation. L'approche de Google est intéressante. Depuis que Google a commencé à être connu dans tous les foyers depuis 2004, les dirigeants et les idéologues du secteur Internet ont tenté de percer le secret principal de l'entreprise afin de répéter son impressionnant succès. L'un des programmes les plus connus, mais actuellement fermés, était que tous les employés de Google étaient invités à consacrer 20% de leur temps de travail à presque tout ce qu'ils voulaient. L'idée était la suivante: si les employés commencent à mettre en œuvre leurs propres projets et idées qui les passionnent en plus du travail, ils commenceront à créer des innovations. C'est ainsi que les projets tiers réussis ont vu le jour: GoogleSuggest, AdSense for Content et Orkut; ils sont tous issus de cette expérience avec 20% - une liste impressionnante! [...]
Chez Red Hat, nous adoptons une approche moins formelle. Nous n'avons pas de politique établie concernant le temps que chacun de nos employés devrait consacrer à «l'innovation». Au lieu de donner aux gens du temps séparé pour l'auto-éducation, nous faisons en sorte que les employés gagnent le droit de passer leur temps sur de nouvelles choses. Franchement, beaucoup ont beaucoup de temps, mais il y a ceux qui peuvent passer presque toute la journée de travail sur l'innovation.
Le cas le plus typique ressemble à ceci: quelqu'un travaille sur un projet tiers (s'il a expliqué à ses gestionnaires l'importance de celui-ci sur le lieu de travail; ou après les heures de sa propre initiative), et plus tard, ce travail peut prendre toutes ses heures de bureau. "
Plus qu'un remue-méninges
«Digression lyrique. Alex Fakney Osbourne est l'inventeur de la méthode de brainstorming, dont la continuation est aujourd'hui la méthode synectique. Il est curieux que cette idée ait vu le jour pendant la Seconde Guerre mondiale, quand Osborne commandait l'un des navires de la caravane américaine, qui était en danger d'une torpille par un sous-marin allemand. Puis le capitaine se souvient de l'astuce à laquelle les pirates du Moyen Âge ont recours: si l'équipe était en difficulté, tous les marins se rassemblaient sur le pont pour proposer alternativement un moyen de résoudre le problème. Il y avait beaucoup d'idées, y compris absurdes à première vue: par exemple, l'idée de souffler une torpille dans toute l'équipe. Mais avec un jet de pompe de navire, disponible sur tous les navires, il est tout à fait possible de ralentir la torpille ou même de changer de cap. En conséquence, Osborne a même breveté l'invention: une vis supplémentaire est montée à bord du navire, qui entraîne un jet d'eau sur le côté, et la torpille glisse à proximité. "
Notre Jim répète constamment que dans une organisation ouverte, il n'est pas si facile de travailler. Même la direction s'en rend compte, car personne n'est épargné de la nécessité de défendre son opinion. Mais une telle approche est nécessaire pour obtenir un excellent résultat:
«Les forums en ligne [de développeurs open source] et les chats sont souvent remplis de discussions animées et parfois mordantes sur tout - de la meilleure façon de corriger un bogue dans le logiciel, et de se terminer par les 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 le cycle suivant a toujours lieu - une analyse critique. Bien que chacun puisse participer à ces différends, une personne doit être prête à défendre sa position de toutes ses forces. Les idées impopulaires sont rejetées au mieux et au pire ridiculisées.
Même Linus Torvalds, créateur du système d'exploitation Linux, n'est pas d'accord avec les modifications proposées au code. Un jour, Linus et David Howells, l'un des principaux développeurs de Red Hat, ont entamé un débat houleux sur les avantages des changements de code demandés par Red Hat, ce qui contribuerait à assurer la sécurité de nos clients. En réponse à la demande de Howells, Torvalds a écrit: «Franchement, ce [mot non imprimable] est une idiotie. Tout semble tourner autour de ces interfaces stupides, et pour des raisons complètement idiotes. Pourquoi devrions-nous faire cela? Je n'aime plus l'analyseur X.509 existant. Les interfaces idiotes complexes sont en cours de création, et maintenant il y en aura 11. - Linus 9 ”.
Laissant de côté les détails techniques, Torvalds dans le prochain post a continué à écrire dans la même veine - et telle que je ne risquerais pas de citer. Ce débat a tonné si fort qu'il a même été diffusé dans les pages du Wall Street Journal. [...]
Ce débat montre que dans la plupart des entreprises qui produisent des logiciels propriétaires exclusifs, il n'y a pas de débat ouvert sur les nouvelles fonctionnalités ou modifications sur lesquelles ils peuvent travailler. Lorsque le produit est prêt, l'entreprise l'envoie simplement aux clients et passe à autre chose. En même temps, dans le cas de Linux, les discussions sur exactement quels changements sont nécessaires et, surtout, pourquoi ils sont nécessaires, ne disparaissent pas. Bien entendu, cela rend le processus beaucoup plus compliqué et prend plus de temps. "
Relâchez tôt, relâchez souvent
Nous ne pouvons pas prévoir l'avenir, nous devons donc simplement essayer:
«Nous agissons selon le principe du« lancement précoce, mises à jour fréquentes ». Le problème clé de tout projet logiciel est le risque d'erreurs ou de bugs dans le code source. De toute évidence, plus il y a de changements et de mises à jour dans une version (version) du logiciel, plus il y a de chances qu'il y ait des bogues dans cette version. Les développeurs de logiciels open source ont réalisé: avec la sortie rapide et fréquente des versions logicielles, le risque de problèmes graves avec n'importe quel programme est réduit - car nous n'apportons pas toutes les mises à jour sur le marché, mais en portions pour chaque version. Au fil du temps, nous avons remarqué que cette approche non seulement réduit le nombre d'erreurs, mais conduit également à des solutions plus intéressantes. Il s'avère que des améliorations mineures en continu créent en fin de compte plus d'innovation. 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 modifications et des mises à jour petites et progressives.
[...] Une grande partie de ce sur quoi nous travaillons peut ne pas réussir. Mais au lieu de perdre beaucoup de temps à creuser la tête sur ce qui fonctionne et ce qui ne fonctionne pas, nous préférons faire de petites expériences. Les idées les plus populaires mèneront au succès et celles qui ne fonctionnent pas disparaîtront d'elles-mêmes. Ainsi, nous pouvons essayer beaucoup, et pas seulement une chose, et sans trop de risques pour l'entreprise.
Il s'agit d'une façon rationnelle d'allouer des ressources. Par exemple, les gens me demandent souvent comment nous choisissons lequel des projets open source doit être commercialisé. Bien que nous lancions parfois des projets, nous nous connectons le plus souvent à des projets existants. Un petit groupe d'ingénieurs - et parfois même une seule personne - commence à contribuer à l'un des projets communautaires 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 pourrait croître à un point tel que la solution est évidente. Une grande variété de projets, y compris ceux qui ne sont pas liés aux logiciels, surgissent naturellement dans Red Hat, jusqu'à ce qu'il devienne clair pour tout le monde que maintenant quelqu'un devra travailler avec lui tout le temps. »
Voici une autre citation du livre:
«J'ai réalisé que pour remplir ce rôle, les dirigeants de demain devraient avoir des caractéristiques qui ne sont tout simplement pas prises en compte dans les organisations ordinaires. Pour gérer efficacement une organisation ouverte, le leader doit posséder les qualités suivantes.
- Force et confiance personnelles. Les chefs ordinaires utilisent le pouvoir positionnel - leur position - pour réussir. Mais avec la 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 de réponses à toutes les questions. Ils doivent être prêts à discuter des problèmes et à prendre des décisions rapides afin de trouver les meilleures solutions avec leur équipe.
- Patience. Les médias racontent rarement des histoires sur la «patience» du leader. Mais il doit vraiment être patient. Lorsque vous travaillez pour obtenir le maximum d'efforts et de résultats de votre équipe, passez des heures à parler et à répéter quelque chose encore et encore jusqu'à ce que tout soit fait correctement - vous devez être patient.
- EQ élevé (intelligence émotionnelle). Trop souvent, nous annonçons les capacités intellectuelles des cadres en nous concentrant sur leur QI, alors qu'en réalité leur rapport d'intelligence émotionnelle, ou EQ, doit être pris en compte. Être la personne la plus intelligente parmi d'autres ne suffit pas si vous n'êtes pas en mesure de travailler avec ces personnes. Lorsque vous travaillez avec des communautés d'employés impliqués, comme dans Red Hat, et que vous n'avez pas la possibilité de commander quelqu'un, votre capacité d'écoute, de traitement analytique et de ne pas tout prendre sur votre propre compte devient extrêmement précieuse.
- Une autre mentalité. Les dirigeants issus d'organisations traditionnelles ont été élevés dans un esprit de contrepartie (lat. «Service pour service»), selon lequel chaque action devrait recevoir un retour adéquat. Mais lorsque vous allez investir dans la création d'une certaine communauté, vous devez penser à long terme. C'est comme une tentative de construire un écosystème finement équilibré, où tout mauvais mouvement peut créer un déséquilibre et conduire à des pertes à long terme que vous ne remarquerez peut-être pas tout de suite. Les gestionnaires doivent se débarrasser du type de pensée qui les oblige à obtenir des résultats aujourd'hui et à tout prix, et commencer à faire des affaires de telle manière qu'il sera possible d'obtenir de grands avantages en investissant dans l'avenir. »
Et pourquoi est-ce important
Red Hat vit et travaille sur des principes très différents d'une organisation hiérarchique traditionnelle. Et cela fonctionne, cela nous rend commercialement prospères et humainement heureux. Nous avons traduit ce livre dans l'espoir de diffuser les principes de l'organisation ouverte parmi les entreprises russes, parmi les personnes qui veulent et peuvent vivre différemment.
Lisez , essayez-le!