Ha llegado un día importante para Red Hat, la comunidad de código abierto en Rusia y todos los involucrados: se ha publicado en ruso . Este libro narra de manera detallada y vívida cómo en Red Hat permitimos que las mejores ideas y las personas más talentosas avancen, además de cómo no perderse en el caos y unir a millones de personas en todo el mundo.
Además, este libro trata sobre la vida y la práctica. Contiene muchos consejos para aquellos que quieren aprender a construir una empresa siguiendo el modelo de una organización abierta y liderarla de manera efectiva. A continuación, se presentan algunos de los principios más importantes mencionados en el libro que puedes tomar en cuenta desde ahora.
La historia de cómo Jim fue contratado en la compañía es notable. Muestra que en el mundo del código abierto no hay fanfarrias, pero sí un nuevo enfoque de liderazgo:
«Después de hablar con el reclutador, expresé mi interés en una entrevista, y él preguntó si me importaría volar el domingo a la sede de Red Hat en la ciudad de Raleigh, Carolina del Norte. Pensé que un domingo era un día extraño para una reunión. Pero como de todos modos tenía planeado volar el lunes a Nueva York, era más o menos en el camino, así que acepté. Tomé un avión de Atlanta y aterrizé en el aeropuerto de Raleigh-Durham. Desde allí tomé un taxi que me dejó frente al edificio de Red Hat en el campus de la Universidad de Carolina del Norte. Era domingo, eran las 9:30 de la mañana, y no había nadie por los alrededores. Las luces estaban apagadas, y al comprobarlo, descubrí que las puertas estaban cerradas. Primero pensé que estaban bromeando conmigo. Al girar para regresar al taxi, vi que ya se había ido. Muy pronto empezó a llover, y no tenía paraguas.
Justo cuando me preparaba para ir a buscar un taxi, Matthew Szulik, quien más tarde sería presidente del consejo de administración y director ejecutivo de Red Hat, se acercó en su coche. «Hola», saludó. «¿Quieres tomar un café?» Me pareció un comienzo inusual para una entrevista, pero sabía que definitivamente necesitaba un café. Al final, pensé, sería más fácil conseguir un taxi hacia el aeropuerto.
El domingo por la mañana en Carolina del Norte es bastante tranquilo. Nos tomó un tiempo encontrar una cafetería que abriera antes del mediodía. La cafetería no era la mejor de la ciudad ni la más limpia, pero estaba abierta y se podía tomar café recién hecho. Nos sentamos en una mesa y comenzamos a charlar.
Al cabo de unos treinta minutos más o menos, me di cuenta de que me gustaba cómo iban las cosas; la entrevista no fue tradicional, pero la conversación resultó muy interesante. En lugar de discutir los pormenores de la estrategia corporativa de Red Hat o su imagen en Wall Street, es decir, cosas para las que me había preparado, Matthew Shulik preguntaba más sobre mis esperanzas, sueños y objetivos. Ahora entiendo que Shulik estaba evaluando si encajaría en la subcultura y el estilo de gestión de la empresa.
Después de que terminamos, Shulik mencionó que quería presentarme al consejero general de la empresa, Michael Cunningham, y propuso reunirme con él justo ahora, durante un almuerzo temprano. Acepté, y nos preparábamos para irnos. Entonces mi compañero se dio cuenta de que no tenía su billetera. "Ups", dijo. "No tengo dinero. ¿Y tú?" Esto me tomó por sorpresa, pero respondí que tenía dinero y que no me importaba pagar por el café.
Unos minutos después, Shulik me dejó en una pequeña taquería mexicana, donde conocí a Michael Cunningham. Pero nuevamente no hubo una entrevista tradicional ni una reunión de negocios, sino que se dio otra conversación interesante. Cuando estábamos a punto de pagar la cuenta, descubrimos que la máquina para el pago con tarjeta en el restaurante estaba rota, y solo aceptaban efectivo. Cunningham se volvió hacia mí y preguntó si estaba dispuesto a pagar, porque no tenía efectivo. Como iba a Nueva York, tenía bastante efectivo, así que pagué el almuerzo.
Cunningham me ofreció darme un paseo hasta el aeropuerto, y así nos fuimos en su coche. A los pocos minutos, preguntó: «¿Te importa si me detengo a repostar? Iremos a toda velocidad». – «No hay problema», respondí. Tan pronto como escuché el golpeteo rítmico de la bomba, alguien golpeó la ventana. Era Cunningham. «Eh, aquí no aceptan tarjetas de crédito», me informó. – «¿Puedo pedirte algo de dinero prestado?» Comencé a preguntarme si realmente era una entrevista o alguna clase de estafa.
Al día siguiente, en Nueva York, discutí con mi esposa sobre esta entrevista en Red Hat. Le conté que la conversación había sido muy interesante, pero no estaba seguro de si estas personas realmente tenían la intención de contratarme: ¿quizás solo necesitaban comida gratis y gasolina? Recordando hoy aquella reunión, me doy cuenta de que Shulik y Cunningham simplemente eran personas abiertas y me trataban como a cualquiera con quien podían tomarse un café, almorzar o llenar gasolina. Sí, es curioso e incluso gracioso que ambos se encontraran sin dinero. Pero para ellos no se trataba de dinero. Al igual que el mundo del código abierto, no creían en alfombras rojas ni en tratar de impresionar al entrevistado asegurando que todo era perfecto. Solo querían conocerme mejor, sin tratar de causar una buena impresión o señalar nuestras diferencias. Querían saber quién era yo realmente.
Mi primera entrevista en Red Hat me mostró claramente que el trabajo aquí tiene un carácter diferente. En esta empresa no había una jerarquía tradicional ni un trato especial para los líderes, al menos no en la forma en que se observa en la mayoría de las otras empresas. Con el tiempo, también descubrí que Red Hat cree en el principio de meritocracia: siempre vale la pena intentar llevar a cabo la mejor de las ideas, sin importar si proviene de la alta dirección o de un pasante tomado para trabajar en verano. En otras palabras, mi primera impresión de Red Hat me introdujo en cómo se ve el futuro del liderazgo.
Consejos para cultivar la meritocracia
La meritocracia es el valor principal de la comunidad del código abierto. No importa qué nivel de la pirámide ocupes, lo que cuenta es qué tan buenas son tus ideas. Esto es lo que propone Jim:
- Nunca digas: «Así lo quiere el jefe» y no te apoyes en la jerarquía. Esto puede ayudarte a corto plazo, pero no construirás una meritocracia de esa manera.
- Reconoce públicamente los logros y las contribuciones importantes al esfuerzo común. Esto puede ser un simple correo electrónico de agradecimiento, con todo el equipo en copia.
- Piensa: ¿tu autoridad depende de tu posición en la jerarquía (o del acceso a información privilegiada) o es el resultado del respeto que has ganado? Si es lo primero, comienza a trabajar en lo segundo.
- Pide retroalimentación y reúne ideas sobre un tema específico. Deberías reaccionar a todas ellas, pero solo implementar las mejores. Sin embargo, no solo tomes las mejores ideas y sigue adelante: utiliza cualquier oportunidad para fortalecer el espíritu de meritocracia, reconociendo a todos los que lo merecen.
- Destaca a un miembro ejemplar de tu equipo ofreciéndole una tarea interesante, incluso si no está relacionada con su área habitual.
Deja que tus 'rockstars' sigan su pasión.
Entusiasmo y compromiso son dos palabras muy importantes en una organización abierta. En el libro, se repiten constantemente. Pero no puedes hacer que personas creativas y apasionadas trabajen ‘de 9 a 5’, ¿verdad? De lo contrario, no obtendrás todo lo que su talento puede ofrecer. En Red Hat, los obstáculos para los proyectos personales se minimizan al máximo:
«Para gestionar la innovación, las empresas prueban muchas cosas. Es interesante el enfoque de Google. Desde que Google se hizo famoso en cada hogar en 2004, líderes y pensadores en el negocio de Internet han intentado desentrañar el secreto principal de la empresa para replicar su impresionante éxito. Uno de los programas más conocidos, aunque actualmente cerrado, consistía en que se le ofrecía a todos los empleados de Google dedicar el 20% de su tiempo laboral prácticamente a lo que desearan. La idea era que, si los empleados comenzaban a desarrollar sus propios proyectos e ideas que les apasionaban además de su trabajo, empezarían a crear innovaciones. Así surgieron proyectos externos exitosos: GoogleSuggest, AdSense for Content y Orkut; todos ellos nacieron de este experimento del 20 por ciento – ¡una lista impresionante! […]
En Red Hat adoptamos un enfoque menos formal. No tenemos una política establecida sobre cuánto tiempo debe dedicar cada uno de nuestros empleados a las "innovaciones". En lugar de asignar tiempo específico para la autoformación, hacemos que los empleados ganen el derecho a dedicar su tiempo a lo nuevo. Siendo sinceros, muchos tienen muy poco tiempo para ello, aunque también hay quienes pueden dedicar prácticamente toda su jornada laboral a la innovación.
El caso más típico se presenta así: alguien trabaja en un proyecto externo (si se ha explicado a los gerentes su importancia – directamente en el lugar de trabajo; o en su tiempo libre – por iniciativa propia), y después este trabajo puede ocupar todas sus horas de presencia.
Más que una lluvia de ideas
"Una digresión lírica. Alex F. Osborn – inventor del método de 'tormenta de ideas', del cual hoy en día es continuación el método de sinéctica. Curiosamente, esta idea surgió durante la Segunda Guerra Mundial, cuando Osborn comandaba uno de los barcos de un convoy de carga estadounidense que estaba bajo amenaza de ataque por torpedos de un submarino alemán. En ese momento, el capitán recordó un recurso utilizado por los piratas medievales: si la tripulación se encontraba en problemas, todos los marineros se reunían en la cubierta para proponer, por turnos, maneras de resolver el problema. Se generaron muchas ideas, incluso algunas que a primera vista parecían absurdas: por ejemplo, la idea de soplar sobre el torpedo con todo el equipo. Pero con el chorro de la bomba del barco, que se encuentra en cada nave, se puede frenar el torpedo o incluso cambiar su rumbo. Como resultado, Osborn patentó incluso el invento: se instala un tornillo adicional en el costado del barco que impulsa un chorro de agua a lo largo de la borda, mientras el torpedo se desliza cerca."
Nuestro Jim repite constantemente que no es tan fácil trabajar en una organización abierta. Incluso la gerencia enfrenta dificultades, ya que nadie se libra de la necesidad de defender su punto de vista. Pero este es precisamente el enfoque necesario para lograr resultados excelentes:
Los foros en línea [de desarrolladores de código abierto] y los chats a menudo están llenos de discusiones animadas, y a veces mordaces, sobre todo: desde cómo corregir mejor un error en el software hasta qué nuevas funciones deben considerarse en la próxima actualización. Por lo general, esta es la primera fase de las discusiones, donde se generan y acumulan nuevas ideas, pero siempre hay una siguiente ronda: el análisis crítico. Aunque cualquiera puede participar en estas disputas, una persona necesita estar lista para defender su posición con todas sus fuerzas. Las ideas impopulares serán rechazadas en el mejor de los casos, y en el peor, ridiculizadas.
Incluso Linus Torvalds, el creador del sistema operativo Linux, expresa su desacuerdo con los cambios propuestos en el código. En una ocasión, Linus y David Howells, uno de los principales desarrolladores de Red Hat, tuvieron un acalorado intercambio sobre los beneficios de modificar el código, tal como lo pidió la empresa Red Hat, lo que ayudaría a garantizar la seguridad de nuestros clientes. En respuesta a la solicitud de Howells, Torvalds escribió: "Francamente, esto es [palabra inapropiada] una idiotez. Todo parece girar en torno a estas interfaces estúpidas, y por razones completamente idiotas. ¿Por qué deberíamos hacerlo así? Ya no me gusta el analizador existente X.509. Se están creando interfaces increíblemente complejas, y ahora tendrán 11. – Linus 9."
Dejando de lado los detalles técnicos, Torvalds continuó escribiendo en el mismo tono en su siguiente mensaje, algo que no me atreveré a citar. Esta disputa fue tan ruidosa que incluso apareció en las páginas de The Wall Street Journal. […]
Esta disputa muestra que en la mayoría de las empresas que producen programas propietarios, no hay debates abiertos sobre qué nuevas características o cambios pueden estar trabajando. Cuando el producto está listo, la empresa simplemente lo envía a los clientes y avanza. Al mismo tiempo, en el caso de Linux, las discusiones sobre qué cambios son necesarios y, lo más importante, por qué son necesarios, no cesan. Esto, por supuesto, hace que todo el proceso sea mucho más desordenado y laborioso.
Lanza temprano, lanza a menudo
No podemos predecir el futuro, así que simplemente debemos intentarlo:
«Actuamos bajo el principio de ‘lanzamiento temprano, actualizaciones frecuentes’. El problema clave de cualquier proyecto de software es el riesgo de errores o fallos en el código fuente. Es evidente que cuanto más cambios y actualizaciones se acumulen en una misma versión de software, mayor será la probabilidad de que haya fallos en esa versión. Los desarrolladores de software de código abierto se dieron cuenta de que con un lanzamiento rápido y frecuente de versiones se reduce el riesgo de problemas serios con cualquier software; pues no lanzamos todas las actualizaciones a la vez, sino en partes para cada versión. Con el tiempo, hemos notado que este enfoque no solo reduce el número de errores, sino que también conduce a soluciones más interesantes. Resulta que la constante introducción de pequeñas mejoras, al final, genera más innovación. Quizás no haya nada sorprendente en ello. Uno de los principios clave de los procesos de producción modernos, como kaizen a o lean b, es el enfoque en pequeños y graduales cambios y actualizaciones.
[…] Mucho de lo que estamos trabajando puede no tener éxito. Pero en lugar de pasar mucho tiempo romviéndonos la cabeza sobre qué funcionará y qué no, preferimos realizar pequeños experimentos. Las ideas más demandadas llevarán al éxito, mientras que aquellas que no funcionen se desvanecerán por sí solas. De este modo, podemos probar muchas cosas, en lugar de solo una, y sin un gran riesgo para la empresa.
Esta es una forma racional de distribuir recursos. Por ejemplo, la gente a menudo me pregunta cómo elegimos qué proyectos de código abierto deben ser comercializados. Aunque a veces iniciamos proyectos, más a menudo simplemente nos unimos a los existentes. Un pequeño grupo de ingenieros, a veces incluso una sola persona, comienza a contribuir a uno de los proyectos de la comunidad de código abierto. Si el proyecto es exitoso y es demandado por nuestros clientes, comenzamos a dedicarle más tiempo y esfuerzo. Si no, los desarrolladores pasan a un nuevo proyecto. Para cuando decidimos comercializar la oferta, el proyecto puede haber crecido hasta el punto en que la decisión es obvia. Proyectos diversos, incluidos aquellos no relacionados con el software, surgen naturalmente en toda la empresa Red Hat, hasta que todos se dan cuenta de que ahora alguien tendrá que trabajar en ello de manera constante.
Aquí hay otra cita del libro:
«Me di cuenta de que para cumplir con tal rol, los líderes del mañana deben diferenciarse con características que las organizaciones convencionales simplemente ignoran. Para dirigir efectivamente una organización abierta, un líder debe poseer las siguientes cualidades.
- Fuerza personal y confianza. Los líderes convencionales utilizan el poder posicional —su cargo— para tener éxito. Pero en una meritocracia, los líderes deben ganarse el respeto. Y esto solo es posible si no temen reconocer que no tienen respuestas para todas las preguntas. Deben estar dispuestos a discutir problemas y tomar decisiones rápidamente para encontrar las mejores soluciones junto con su equipo.
- Paciencia. Los medios rara vez cuentan historias sobre cuán "paciente" es un líder. Pero realmente debe ser paciente. Cuando trabajas para obtener el máximo esfuerzo y resultados de tu equipo, durante horas manteniendo un diálogo y repitiendo algo una y otra vez hasta que todo se realice correctamente, necesitas tener paciencia.
- Alto EQ (inteligencia emocional). Con demasiada frecuencia, promovemos las capacidades intelectuales de los líderes al centrarnos en su CI, cuando en realidad es crucial considerar su coeficiente de inteligencia emocional, o evaluación de EQ. Ser la persona más inteligente entre otros no es suficiente si no puedes trabajar con esas personas. Cuando trabajas con comunidades de empleados comprometidos, como en Red Hat, y no tienes la opción de ordenar a nadie, tu capacidad para escuchar, procesar analíticamente y no tomarte todo de manera personal se vuelve increíblemente valiosa.
- Otra mentalidad. Los líderes que provienen de organizaciones tradicionales fueron criados bajo el principio del quid pro quo, según el cual cada acción debe recibir una compensación adecuada. Pero cuando planeas invertir en la creación de una comunidad específica, debes pensar a largo plazo. Es como intentar construir un ecosistema delicadamente equilibrado, donde cualquier paso en falso puede crear un desequilibrio y causar pérdidas a largo plazo que puede que no notes de inmediato. Los líderes deben deshacerse de ese tipo de mentalidad que exige resultados hoy mismo a cualquier costo y comenzar un enfoque que les permita obtener mayores beneficios al invertir en el futuro.
Y por qué es importante
Red Hat vive y opera según principios que difieren mucho de los de una organización tradicional con jerarquías. Y esto funciona, nos hace exitosos comercialmente y humanos felices. Hemos traducido este libro con la esperanza de difundir los principios de la organización abierta entre las empresas rusas, entre las personas que desean y pueden vivir de otra manera.
, ¡inténtalo!
Fuente: habr.com
