Ha llegado un día importante para Red Hat, la comunidad rusa de código abierto y todos los involucrados: fue publicado en ruso. . Ella cuenta detallada y vívidamente cómo nosotros en Red Hat damos el camino a las mejores ideas y a las personas más talentosas, y también cómo no perderse en el caos y unir a millones de personas en todo el mundo.
Este libro también trata sobre la vida y la práctica. Contiene muchos consejos para cualquiera que quiera aprender cómo construir una empresa utilizando el modelo de organización abierta y gestionarla de forma eficaz. A continuación se muestran algunos de los principios más importantes que figuran en el libro y de los que puede tomar nota ahora mismo.
El historial laboral de Jim en la empresa es notable. Muestra que no hay fanfarria en el mundo del código abierto, pero hay un nuevo enfoque de liderazgo:
“Después de hablar con el reclutador, le expresé interés en una entrevista y me preguntó si me importaría volar a la sede de Red Hat en Raleigh, Carolina del Norte, el domingo. Pensé que el domingo era un día extraño para reunirnos. Pero como todavía iba a volar a Nueva York el lunes, en general estaba en camino y acepté. Abordé un avión desde Atlanta y aterricé en el aeropuerto de Raleigh Durham. Desde allí tomé un taxi que me dejó frente al edificio Red Hat en el campus de la Universidad de Carolina del Norte. Era domingo a las 9:30 am y no había nadie alrededor. Las luces estaban apagadas y al revisar encontré que las puertas estaban cerradas. Al principio pensé que me estaban engañando. Cuando me di vuelta para volver al taxi, vi que ya se había ido. Muy pronto empezó a llover, no tenía paraguas.
Justo cuando estaba a punto de ir a algún lugar para tomar un taxi, Matthew Shulick, más tarde presidente de la junta directiva y director ejecutivo de Red Hat, se detuvo en su auto. "Hola", saludó. “¿Quieres tomar un café?” Parecía una forma inusual de comenzar una entrevista, pero sabía que definitivamente necesitaba tomar un poco de café. Al final pensé que me resultaría más fácil coger un taxi hasta el aeropuerto.
Los domingos por la mañana son bastante tranquilos en Carolina del Norte. 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 funcionaba y se podía tomar café recién hecho allí. Nos sentamos en una mesa y empezamos a hablar.
Después de unos treinta minutos me di cuenta de que me gustaba cómo iban las cosas; La entrevista no fue tradicional, pero la conversación en sí resultó muy interesante. En lugar de discutir los puntos más finos de la estrategia corporativa de Red Hat o su imagen en Wall Street (algo para lo que me había preparado), Matthew Shulick preguntó más sobre mis esperanzas, sueños y metas. Ahora tengo claro que Shulik estaba evaluando si yo encajaría en la subcultura y el estilo de gestión de la empresa.
Cuando terminamos, Shulick dijo que quería presentarme al asesor general de la empresa, Michael Cunningham, y sugirió que me reuniera con él para almorzar temprano. Estuve de acuerdo y nos preparamos para partir. Entonces mi interlocutor descubrió que no llevaba consigo su cartera. "Ups", dijo. - No tengo dinero. ¿Y tú?" Esto me tomó por sorpresa, pero respondí que tenía dinero y que no me importaba pagar el café.
Unos minutos más tarde, Shulik me dejó en un pequeño restaurante mexicano, donde conocí a Michael Cunningham. Pero nuevamente no siguió ninguna entrevista tradicional o reunión de negocios, sino que tuvo lugar otra conversación interesante. Cuando estábamos a punto de pagar la cuenta, resultó que la máquina de tarjetas de crédito del restaurante estaba rota y solo podíamos aceptar efectivo. Cunningham se volvió hacia mí y me preguntó si estaba dispuesto a pagar, porque no llevaba dinero en efectivo. Como iba a Nueva York, tenía mucho dinero en efectivo, así que pagué el almuerzo.
Cunningham se ofreció a llevarme al aeropuerto y fuimos en su coche. Después de unos minutos, preguntó: “¿Te importa si paro y pongo gasolina? Iremos a toda máquina." "No hay problema", respondí. Tan pronto como escuché el sonido rítmico de la bomba, alguien golpeó la ventana. Era Cunningham. "Oye, aquí no aceptan tarjetas de crédito", dijo. "¿Me prestas algo de dinero?" Empecé a preguntarme si esto era realmente una entrevista o algún tipo de estafa.
Al día siguiente, mientras estaba en Nueva York, hablé de esta entrevista con mi esposa en Red Hat. Le dije que la conversación fue muy interesante, pero que no estaba seguro de si estas personas hablaban en serio acerca de contratarme: ¿tal vez solo querían comida y gasolina gratis? Al recordar esa reunión de hoy, entiendo que Shulick y Cunningham eran simplemente personas abiertas y me trataban como a cualquier otra persona con la que podían tomar un café, almorzar o cargar gasolina. Sí, es gracioso y hasta gracioso que ambos terminaran sin dinero. Pero para ellos no se trataba de dinero. Ellos, al igual que el mundo del código abierto, no creían en desplegar alfombras rojas ni en intentar convencer a los demás de que todo era perfecto. Sólo intentaban conocerme mejor, no intentaban impresionarme ni señalar nuestras diferencias. Querían saber quién era yo.
Mi primera entrevista en Red Hat me mostró claramente que el trabajo aquí era diferente. Esta empresa no tenía una jerarquía tradicional ni un trato especial para los directivos, al menos en la forma habitual en la mayoría de las demás empresas. Con el tiempo, también aprendí que Red Hat cree en el principio de la meritocracia: siempre vale la pena intentar implementar la mejor idea, independientemente de si proviene de la alta dirección o de un pasante de verano. En otras palabras, mi primera experiencia en Red Hat me presentó cómo será el futuro del liderazgo”.
Consejos para cultivar la meritocracia
La meritocracia es el valor central de la comunidad de código abierto. No nos importa qué nivel de la pirámide ocupes, lo principal es qué tan buenas sean tus ideas. Esto es lo que sugiere Jim:
- Nunca diga: "Eso es lo que quiere el jefe" y no confíe en la jerarquía. Esto puede ayudarle a corto plazo, pero no es así como se construye una meritocracia.
- Reconocer públicamente los éxitos y contribuciones importantes. Este podría ser un simple correo electrónico de agradecimiento con copia de todo el equipo.
- Considere: ¿su autoridad es una función de su posición en la jerarquía (o del acceso a información privilegiada), o es el resultado del respeto que se ha ganado? Si es el primero, empieza a trabajar en el segundo.
- Solicite comentarios y recopile ideas sobre un tema específico. Debes reaccionar ante todo, probar solo lo mejor. Pero no se limite a tomar las mejores ideas y seguir adelante con ellas: aproveche cada oportunidad para fortalecer el espíritu de meritocracia, dando crédito a todos los que lo merecen.
- Reconoce a un miembro ejemplar de tu equipo ofreciéndole un encargo interesante, aunque no sea en su campo de trabajo habitual.
Deja que tus estrellas de rock sigan su pasión
Entusiasmo y participación son dos palabras muy importantes en una organización abierta. Se repiten constantemente en el libro. Pero no se puede conseguir que personas creativas y apasionadas trabajen duro, ¿verdad? De lo contrario, simplemente no obtendrás todo lo que su talento tiene para ofrecer. En Red Hat, los obstáculos para sus propios proyectos se nivelan al máximo:
“Para impulsar la innovación, las empresas prueban muchas cosas. El enfoque de Google es interesante. Desde que Google se hizo conocido en todos los hogares en 2004, los ejecutivos e ideólogos del negocio de Internet han intentado desentrañar el principal secreto de la empresa para repetir su impresionante éxito. Uno de los programas más famosos, pero actualmente cerrado, consistía en que a todos los empleados de Google se les pedía que dedicaran el 20 por ciento de su tiempo a hacer casi cualquier cosa que quisieran. La idea era que si los empleados perseguían sus propios proyectos e ideas que les apasionaran fuera del trabajo, comenzarían a innovar. Así surgieron exitosos proyectos de terceros: GoogleSuggest, AdSense for Content y Orkut; todos ellos provienen 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 la "innovación". En lugar de darles a las personas tiempo dedicado a educarse, nos aseguramos de que los empleados se ganen el derecho de dedicar su tiempo a aprender cosas nuevas. Sinceramente, muchas personas disponen de muy poco tiempo, pero también hay quienes pueden dedicar casi toda su jornada laboral a la innovación.
El caso más típico es algo así: alguien trabaja en un proyecto paralelo (si explicó su importancia a los gerentes, directamente en el lugar de trabajo, o fuera del horario laboral, por iniciativa propia), y luego este trabajo puede ocupar todo sus horas actuales”.
Más que una lluvia de ideas
“Digresión lírica. Alex Fakeney Osborne es el inventor del método de lluvia de ideas, cuya continuación hoy es el método sinéctico. Es curioso que esta idea surgiera durante la Segunda Guerra Mundial, cuando Osborne comandaba uno de los barcos de un convoy de carga estadounidense que estaba en peligro de ser atacado con torpedos por un submarino alemán. Entonces el capitán recordó la técnica a la que recurrían los piratas de la Edad Media: si la tripulación se metía en problemas, todos los marineros se reunían en cubierta para, por turnos, sugerir una forma de solucionar el problema. Hubo muchas ideas, incluidas algunas absurdas a primera vista: por ejemplo, la idea de soplar un torpedo con todo el equipo. Pero con el chorro de la bomba de barco, disponible en todos los barcos, es muy posible frenar un torpedo o incluso cambiar su rumbo. Como resultado, Osborne incluso patentó un invento: se monta una hélice adicional en el costado del barco, que impulsa un chorro de agua a lo largo del costado, y el torpedo se desliza a lo largo”.
Nuestro Jim repite constantemente que no es tan fácil trabajar en una organización abierta. Incluso la dirección lo entiende, ya que nadie se ahorra la necesidad de defender su opinión. Pero este es exactamente el enfoque necesario para lograr excelentes resultados:
“Los foros y salas de chat en línea [de código abierto] a menudo están llenos de discusiones animadas y, a veces, enconadas sobre todo, desde cómo corregir mejor un error de software hasta qué nuevas funciones deben considerarse en la próxima actualización. Por regla general, esta es la primera fase de las discusiones, durante la cual se presentan y acumulan nuevas ideas, pero siempre hay una siguiente ronda: el análisis crítico. Aunque cualquiera puede participar en estos debates, una persona debe estar preparada para defender su posición con todas sus fuerzas. Las ideas impopulares serán, en el mejor de los casos, rechazadas y, en el peor, ridiculizadas.
Incluso Linus Torvalds, el creador del sistema operativo Linux, expresa su desacuerdo con los cambios de código propuestos. Un día, Linus y David Howells, uno de los principales desarrolladores de Red Hat, entablaron un acalorado debate sobre los méritos de un cambio de código que Red Hat había solicitado y que ayudaría a brindar seguridad a nuestros clientes. En respuesta a la petición de Howells, Torvalds escribió: “Francamente, esto es [palabra no imprimible] idiota. Todo parece girar en torno a estas estúpidas interfaces, y por razones completamente estúpidas. ¿Por qué deberíamos hacer ésto? Ya no me gusta el analizador X.509 existente. Se están creando interfaces estúpidas y complejas y ahora habrá 11. – Linus 9”.
Dejando a un lado los detalles técnicos, Torvalds continuó escribiendo con el mismo espíritu en el siguiente mensaje, y de tal manera que no me atrevo a citar. Esta disputa fue tan ruidosa que incluso llegó a las páginas de The Wall Street Journal. […]
Este debate muestra que la mayoría de las empresas que producen software privativo y no libre no tienen un debate abierto sobre en qué nuevas características o cambios podrían estar trabajando. Cuando el producto está listo, la empresa simplemente lo envía a los clientes y sigue adelante. 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 amainan. Esto, por supuesto, hace que todo el proceso sea mucho más complicado y requiera más tiempo”.
Libertad anticipada, la liberación a menudo
No podemos predecir el futuro, así que sólo tenemos que intentarlo:
"Trabajamos según el principio de" lanzamiento temprano, actualizaciones frecuentes ". El problema clave de cualquier proyecto de software es el riesgo de errores o fallas en el código fuente. Obviamente, cuantos más cambios y actualizaciones se recopilen en una versión (versión) de software, mayor será la probabilidad de que haya errores en esta versión. Los desarrolladores de software de código abierto se han dado cuenta de que al lanzar versiones de software de forma rápida y frecuente, se reduce el riesgo de problemas graves con cualquier programa; después de todo, no lanzamos todas las actualizaciones al mercado a la vez, sino una a la vez para cada versión. Con el tiempo, nos dimos cuenta de que este enfoque no sólo reduce los errores, sino que también conduce a soluciones más interesantes. Resulta que realizar pequeñas mejoras continuamente genera más innovación a largo plazo. Quizás no haya nada sorprendente aquí. Uno de los principios clave de los procesos de fabricación modernos, como kaizen a o lean b, es centrarse en cambios y actualizaciones pequeños e incrementales.
[…] Es posible que gran parte de lo que trabajamos no tenga éxito. Pero en lugar de pasar mucho tiempo preguntándonos qué funcionará y qué no, preferimos realizar pequeños experimentos. Las ideas más populares conducirán al éxito y aquellas que no funcionen desaparecerán por sí solas. De esta forma podemos probar muchas cosas en lugar de una sola, sin mucho riesgo para la empresa.
Esta es una forma racional de asignar recursos. Por ejemplo, la gente suele preguntarme cómo elegimos qué proyectos de código abierto comercializar. Si bien a veces iniciamos proyectos, la mayoría de las veces simplemente nos lanzamos a los existentes. Un pequeño grupo de ingenieros (a veces solo una persona) comienza a contribuir a uno de los proyectos de la comunidad de código abierto. Si el proyecto tiene éxito y tiene demanda entre nuestros clientes, comenzamos a dedicarle más tiempo y esfuerzo. De lo contrario, los desarrolladores pasan a un nuevo proyecto. Para cuando decidamos comercializar la propuesta, es posible que el proyecto haya crecido hasta tal punto que la solución sea obvia. Varios proyectos, incluidos los que no son de software, surgen naturalmente en Red Hat hasta que queda claro para todos que ahora alguien tendrá que trabajar en esto a tiempo completo”.
Aquí hay otra cita del libro:
“Me di cuenta de que para desempeñar este papel, los líderes del mañana deben tener características que simplemente se pasan por alto en las organizaciones convencionales. Para liderar eficazmente una organización abierta, un líder debe tener las siguientes cualidades.
- Fuerza personal y confianza. Los líderes comunes utilizan el poder posicional (su posición) para lograr el éxito. Pero en una meritocracia, los líderes deben ganarse el respeto. Y esto sólo es posible si no tienen miedo de admitir que no tienen todas las respuestas. Deben estar dispuestos a discutir problemas y tomar decisiones rápidamente para encontrar las mejores soluciones con su equipo.
- Paciencia. Los medios rara vez cuentan historias sobre cuán “paciente” es un líder. Pero realmente debe tener paciencia. Cuando trabajas para obtener el mejor esfuerzo y los mejores resultados de tu equipo, tienes conversaciones durante horas y repites las cosas una y otra vez hasta que se hace bien, debes tener paciencia.
- Alto EQ (inteligencia emocional). Con demasiada frecuencia promovemos la inteligencia de los líderes centrándonos en su coeficiente intelectual, cuando lo que realmente hay que tener en cuenta es su coeficiente de inteligencia emocional o puntuación de coeficiente intelectual. Ser la persona más inteligente entre otras no es suficiente si no eres capaz de trabajar con esas personas. Cuando trabajas con comunidades de empleados comprometidos como Red Hat, y no tienes la capacidad de dar órdenes a nadie, tu capacidad de escuchar, procesar analíticamente y no tomar las cosas como algo personal se vuelve increíblemente valiosa.
- Mentalidad diferente. Los líderes que provenían de organizaciones tradicionales fueron educados con el espíritu del quid pro quo (en latín, “quid pro quo”), según el cual cada acción debería recibir un retorno adecuado. Pero cuando buscas invertir en la construcción de una comunidad en particular, debes pensar a largo plazo. Es como intentar construir un ecosistema delicadamente equilibrado, donde cualquier paso en falso puede crear un desequilibrio y provocar pérdidas a largo plazo que quizás no notes de inmediato. Los líderes deben deshacerse de la mentalidad que les exige lograr resultados hoy, a cualquier costo, y comenzar a hacer negocios de una manera que les permita obtener mayores beneficios invirtiendo en el futuro”.
y porque es importante
Red Hat vive y opera según principios que son muy diferentes de los de una organización jerárquica tradicional. Y funciona, nos hace exitosos comercialmente y humanamente felices. Tradujimos este libro con la esperanza de difundir los principios de la organización abierta entre las empresas rusas, entre las personas que quieren y pueden vivir de otra manera.
, ¡intentalo!
Fuente: habr.com