Ha llegado un día importante para Red Hat, la comunidad rusa de código abierto y todos los involucrados: en ruso,
se publicó el libro de Jim Whitehurst, Una organización abierta: la pasión trae fruta . Ella cuenta en detalle y vívidamente cómo en Red Hat damos las mejores ideas y las personas más talentosas, y cómo no perderse en el caos y reunir a millones de personas en todo el mundo.
Y este libro trata sobre la vida y la práctica. Tiene muchos consejos para todos los que quieran aprender cómo construir una empresa de acuerdo con el modelo de una organización abierta y administrarla de manera efectiva. A continuación se presentan algunos de los principios más importantes que se dan en el libro, que puede tomar nota en este momento.
(Video disponible con subtítulos en ruso)
El historial laboral de Jim es notable. Muestra que en el mundo del código abierto no hay fanfarria, pero hay un nuevo enfoque para el liderazgo:
“Después de hablar con el reclutador, expresé interés en la entrevista y me preguntó si no me importaría ir a la sede de Red Hat en Raleigh, Carolina del Norte, el domingo. Pensé que el domingo era un día extraño para conocer. Pero como iba a volar a Nueva York el lunes de todos modos, estaba en camino y acepté. Subí a un avión desde Atlanta y aterricé en el aeropuerto Raleigh Durham. Desde allí tomé un taxi que me dejó frente a la compañía Red Hat en el campus de la Universidad de Carolina del Norte. Era domingo a las 9:30 a.m. y no había nadie cerca. La luz se apagó y, después de revisar, descubrí que las puertas estaban cerradas. Al principio decidí que me estaban engañando. Al girar para regresar al taxi, vi que ya se había ido. Comenzó a llover muy pronto, no tenía paraguas.
Tan pronto como estaba a punto de ir a algún lugar para tomar un taxi, Matthew Schulick, luego presidente de la junta directiva y gerente general de Red Hat, se detuvo en su automóvil. "Hola", dijo. "¿Quieres un poco de café?" Me pareció un comienzo inusual de la entrevista, pero me di cuenta de que definitivamente necesitaba tomar café. En última instancia, pensé, entonces será más fácil para mí tomar un taxi al aeropuerto.
El domingo en Carolina del Norte es bastante tranquilo por la mañana. Nos llevó un tiempo encontrar una cafetería que abriera antes del mediodía. La cafetería no era la mejor de la ciudad y no era la más limpia, pero funcionaba y allí se podía tomar café recién hecho. Nos sentamos en una mesa y comenzamos una conversación.
Unos treinta minutos después, me di cuenta de que me gusta cómo va todo; la entrevista no fue tradicional, pero la conversación en sí fue muy interesante. En lugar de discutir las complejidades de la estrategia corporativa de Red Hat o su imagen en Wall Street, es decir, hacer lo que preparé, Matthew Shulick preguntó más sobre mis esperanzas, sueños y objetivos. Ahora entiendo que Shulik estaba evaluando si sería coherente con el estilo de subcultura y gestión de la empresa.
Cuando terminamos, Shulik anunció que quería presentarme al abogado general de la compañía, Michael Cunningham, y se ofreció a reunirse con él ahora, en un almuerzo temprano. Acepté y estábamos a punto de irnos. Entonces mi interlocutor descubrió que no tenía una billetera con él. "Vaya", dijo. "No tengo dinero". ¿Y tú? Me tomó por sorpresa, pero respondí que tengo dinero y no me importa pagar el café.
Unos minutos más tarde, Shulik me dejó en un pequeño restaurante mexicano donde me encontré con Michael Cunningham. Pero, de nuevo, no siguió una entrevista tradicional o una reunión de negocios, sino que tuvo lugar otra conversación interesante. Cuando íbamos a pagar la factura, resultó que la máquina para el pago con tarjeta de crédito se había averiado en el restaurante, y solo podíamos aceptar dinero en efectivo. Cunningham se volvió hacia mí y me preguntó si estaba dispuesto a pagar porque no tenía efectivo con él. Como iba a Nueva York, tenía mucho efectivo, así que pagué el almuerzo.
Cunningham se ofreció a llevarme al aeropuerto y conducimos en su automóvil. Unos minutos más tarde preguntó: "¿Te importa si me detengo y reposto? Saldremos corriendo a toda velocidad. "No hay problema", le respondí. Tan pronto como escuché el golpe rítmico de la bomba, hubo un golpe en la ventana. Fue Cunningham. "Oye, no aceptan tarjetas de crédito aquí", dijo. "¿Me prestas algo de dinero?" Comencé a preguntarme si esto es realmente una entrevista o algún tipo de estafa.
Al día siguiente, mientras estaba en Nueva York, discutí con mi esposa esta entrevista con Red Hat. Le dije que la conversación fue muy interesante, pero no estoy seguro de si estas personas realmente intentan contratarme: ¿tal vez solo necesitaban comida y gasolina gratis? Al recordar esa reunión de hoy, entiendo que Shulik y Cunningham eran personas abiertas y me trataron como a cualquier otra persona con la que pudieran tomar café, almorzar o recargar combustible. Sí, es divertido e incluso divertido que ambos terminaron sin dinero. Pero para ellos no se trataba de dinero. Ellos, como el mundo del código abierto, no creían en la alfombra roja rodante o en tratar de convencer a la otra persona de que todo era perfecto. Simplemente buscaban conocerme mejor, en lugar de tratar de impresionar o señalar nuestras diferencias. Querían saber quién era yo.
Mi primera entrevista en Red Hat me mostró claramente que el trabajo aquí es diferente. Esta compañía no observó una jerarquía tradicional y un régimen especial para los gerentes, al menos en la forma que se acepta en la mayoría de las otras compañías. Con el tiempo, también aprendí que Red Hat cree en el principio de la meritocracia: siempre vale la pena tratar de traducir las mejores ideas, ya sea de la alta gerencia o de un interno que ha sido contratado para un trabajo de verano. En otras palabras, mi primera impresión de Red Hat me presentó cómo es el futuro del liderazgo ”.
Consejos de cultivo de meritocracia
La meritocracia es un valor central de la comunidad de código abierto. No nos importa el nivel de la pirámide que ocupes, lo principal es cuán buenas son tus ideas. Esto es lo que ofrece Jim:
- Nunca diga: "Esto es lo que quiere el jefe", y no confíe en la jerarquía. Esto puede ayudarlo a corto plazo, pero la meritocracia no puede construirse así.
- Reconozca públicamente los éxitos y las contribuciones importantes a la causa común. Este puede ser un simple correo electrónico de agradecimiento, en una copia del cual está todo el equipo.
- Piense: ¿su autoridad depende de su posición en la jerarquía (o del acceso a información privilegiada) o es el resultado del respeto que se ganó? Si es el primero, comience a trabajar en el segundo.
- Solicite comentarios y recopile ideas sobre un tema específico. Debería responder a todo, probar, solo lo mejor. Pero no solo tome las mejores ideas y siga adelante con ellas: aproveche cada oportunidad para fortalecer el espíritu de la meritocracia, rindiendo homenaje a todos los que lo merecen.
- Marque el miembro ejemplar de su equipo, ofreciendo una tarea interesante, incluso si no pertenece a su campo de actividad habitual.
Deja que tus estrellas de rock sigan su pasión
El entusiasmo y el compromiso son dos palabras muy importantes en una organización abierta. En el libro se repiten constantemente. Pero no se puede lograr que personas creativas entusiastas trabajen una y otra vez, ¿verdad? De lo contrario, simplemente no obtenga todo lo que su talento puede ofrecer. En Red Hat, los obstáculos para sus propios proyectos se nivelan tanto como sea posible:
“Las empresas están intentando mucho impulsar la innovación. El enfoque de Google es interesante. Desde que Google comenzó a ser conocido en todos los hogares desde 2004, los ejecutivos e ideólogos en el negocio de Internet han tratado de desentrañar el secreto principal de la compañía para repetir su impresionante éxito. Uno de los programas más conocidos, pero actualmente cerrados, fue que todos los empleados de Google fueron invitados a pasar el 20 por ciento de su tiempo de trabajo en casi cualquier cosa que quisieran. La idea era esta: si los empleados comienzan a implementar sus propios proyectos e ideas que les apasionan además del trabajo, comenzarán a crear innovaciones. Así es como surgieron proyectos exitosos de terceros: GoogleSuggest, AdSense for Content y Orkut; todos vinieron de este experimento con un 20 por ciento, ¡una lista impresionante! [...]
Nosotros en Red Hat adoptamos un enfoque menos formal. No tenemos una política establecida con respecto a la cantidad de tiempo que cada uno de nuestros empleados debe dedicar a la "innovación". En lugar de dar a las personas un tiempo separado para la autoeducación, hacemos que los empleados se ganen el derecho de dedicar su tiempo a cosas nuevas. Francamente, muchos tienen bastante de este tiempo, pero hay quienes pueden pasar casi todo el día de trabajo en innovación.
El caso más típico se ve más o menos así: alguien está trabajando en un proyecto de un tercero (si les explicó a sus gerentes la importancia de hacerlo directamente en el lugar de trabajo; o después de horas por iniciativa propia), y más tarde este trabajo puede tomar todas sus horas de oficina ".
Más que una lluvia de ideas
"Digresión lírica. Alex Fakney Osbourne es el inventor del método de lluvia de ideas, una continuación del cual es hoy el método sinéctico. Es curioso que esta idea surgió durante la Segunda Guerra Mundial, cuando Osborne comandó una de las naves de la caravana de carga estadounidense, que estaba en peligro de un ataque de torpedos por un submarino alemán. Entonces el capitán recordó el truco al que recurrieron los piratas de la Edad Media: si el equipo estaba en problemas, todos los marineros se reunían en la cubierta para proponer alternativamente una forma de resolver el problema. Hubo muchas ideas, incluso absurdas a primera vista: por ejemplo, la idea de volar un torpedo como un equipo completo. Pero con un chorro de la bomba de un barco, que está disponible en cada barco, el torpedo se puede frenar por completo o incluso cambiar su curso. Como resultado, Osborne incluso patentó la invención: se monta un tornillo adicional a bordo del barco, que impulsa una corriente de agua a lo largo del costado, y el torpedo se desliza cerca ".
Nuestro Jim repite constantemente que en una organización abierta no es tan fácil trabajar. Incluso la gerencia lo entiende, porque nadie se salva de la necesidad de defender su opinión. Pero se necesita tal enfoque para lograr un resultado excelente:
“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 la mejor manera de corregir un error en el software, y hasta qué nuevas características deben considerarse en la próxima actualización. Como regla general, esta es la primera fase de las discusiones, durante la cual se presentan y acumulan nuevas ideas, pero la siguiente ronda siempre tiene lugar: un análisis crítico. Aunque todos pueden participar en estas disputas, una persona debe estar preparada para defender su posición con todas sus fuerzas. Las ideas impopulares son rechazadas en el mejor de los casos, y en el peor, ridiculizadas.
Incluso Linus Torvalds, creador del sistema operativo Linux, no está de acuerdo con los cambios propuestos al código. Un día, Linus y David Howells, uno de los principales desarrolladores de Red Hat, entraron en un acalorado debate sobre los beneficios del cambio de código solicitado por Red Hat, lo que ayudaría a garantizar la seguridad de nuestros clientes. En respuesta a la solicitud de Howells, Torvalds escribió: "Francamente, esta [palabra no imprimible] es idiotez. Todo parece girar en torno a estas interfaces estúpidas, y por razones completamente idiotas. ¿Por qué deberíamos hacer esto? Ya no me gusta el analizador X.509 existente. Se están creando las complejas interfaces idiotas, y ahora habrá 11. - Linus 9 ”.
Dejando a un lado los detalles técnicos, Torvalds en la siguiente publicación continuó escribiendo en la misma línea, y de tal manera que no me arriesgaría a citar. Este debate tronó tan fuerte que incluso llegó a las páginas de The Wall Street Journal. [...]
Este debate muestra que en la mayoría de las empresas que producen software propietario, no existe un debate abierto sobre las nuevas características o cambios en los que pueden trabajar. Cuando el producto está listo, la compañía simplemente lo envía a los clientes y continúa. Al mismo tiempo, en el caso de Linux, las discusiones sobre exactamente qué cambios son necesarios y, lo que es más importante, por qué son necesarios, no disminuyen. Esto, por supuesto, hace que todo el proceso sea mucho más complicado y lento ".
Suelte temprano, suelte a menudo
No podemos prever el futuro, así que solo tenemos que intentar:
"Actuamos según el principio de" lanzamiento temprano, actualizaciones frecuentes ". El problema clave de cualquier proyecto de software es el riesgo de errores o errores en el código fuente. Obviamente, cuantos más cambios y actualizaciones se recopilen en una versión (versión) del software, mayor será la probabilidad de que haya errores en esta versión. Los desarrolladores de software de código abierto se dieron cuenta: con el lanzamiento rápido y frecuente de versiones de software, se reduce el riesgo de problemas serios con cualquier programa, porque no traemos todas las actualizaciones al mercado de inmediato, sino en porciones para cada versión. Con el tiempo, notamos que este enfoque no solo reduce la cantidad de errores, sino que también conduce a soluciones más interesantes. Resulta que realizar mejoras menores en última instancia crea más innovación. 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 y graduales.
[...] Gran parte de lo que estamos trabajando puede no tener éxito. Pero en lugar de perder mucho tiempo haciendo estallar nuestro cerebro sobre lo que funciona y lo que no, preferimos hacer pequeños experimentos. Las ideas más populares conducirán al éxito, y las que no funcionen se marchitarán solas. Por lo tanto, podemos intentar mucho, y no solo una cosa, y sin mucho riesgo para la empresa.
Esta es una forma racional de asignar recursos. Por ejemplo, la gente a menudo me pregunta cómo elegimos cuál de los proyectos de código abierto debe comercializarse. Aunque a veces iniciamos proyectos, la mayoría de las veces solo nos conectamos con los existentes. Un pequeño grupo de ingenieros, y a veces incluso una sola persona, comienza a contribuir a uno de los proyectos comunitarios de código abierto. Si el proyecto tiene éxito y demanda entre nuestros clientes, comenzamos a dedicarle más tiempo y esfuerzo. Si no, los desarrolladores se están moviendo a un nuevo proyecto. Cuando decidamos comercializar la propuesta, el proyecto podría crecer hasta tal punto que la solución sea obvia. Una amplia variedad de proyectos, incluidos los que no están relacionados con el software, surgen naturalmente en Red Hat, hasta que queda claro para todos que ahora alguien tendrá que trabajar con él todo el tiempo ".
Aquí hay otra cita del libro:
“Me di cuenta de que para cumplir con este rol, los líderes del mañana deberían tener características a las que simplemente no se les presta atención en las organizaciones ordinarias. Para gestionar eficazmente una organización abierta, el líder debe poseer las siguientes cualidades.
- Fuerza personal y confianza. Los líderes ordinarios usan el poder posicional, su posición, para tener éxito. Pero con la meritocracia, los líderes deben ganarse el respeto. Y esto solo es posible si no tienen miedo de admitir que no tienen respuestas a todas las preguntas. Deben estar preparados para discutir problemas y tomar decisiones rápidas para encontrar las mejores soluciones junto con su equipo.
- Paciencia Los medios rara vez cuentan historias sobre cuán "paciente" es el líder. Pero realmente tiene que ser paciente. Cuando trabaje para obtener el máximo esfuerzo y resultados de su equipo, pase horas hablando y repitiendo algo una y otra vez hasta que todo se haga correctamente: debe ser paciente.
- Alto EQ (inteligencia emocional). Con demasiada frecuencia, publicitamos las capacidades intelectuales de los ejecutivos al centrarnos en su coeficiente intelectual, cuando en realidad su índice de inteligencia emocional, o EQ, debe tenerse en cuenta. Ser la persona más inteligente entre otros no es suficiente si no puede trabajar con estas personas. Cuando trabaja con comunidades de empleados involucrados, como en Red Hat, y no tiene la capacidad de ordenar a alguien, su capacidad de escuchar, procesar analíticamente y no tener todo en su propia cuenta se vuelve increíblemente valiosa.
- Otra mentalidad. Los líderes que provenían de organizaciones tradicionales fueron criados en el espíritu de quid pro quo (lat. "Servicio por servicio"), según el cual cada acción debería recibir un retorno adecuado. Pero cuando va a invertir en la creación de una determinada comunidad, debe pensar a largo plazo. Esto es como un intento de construir un ecosistema finamente equilibrado, donde cualquier paso incorrecto puede crear un desequilibrio y provocar pérdidas a largo plazo que puede que no note de inmediato. Los gerentes deben deshacerse del tipo de pensamiento que les exige lograr resultados hoy y a cualquier costo, y comenzar a hacer negocios de tal manera que puedan obtener grandes beneficios a través de inversiones en el futuro ".
¿Y por qué es esto importante?
Red Hat vive y trabaja en principios que son muy diferentes de una organización jerárquica tradicional. Y funciona, nos hace comercialmente exitosos y humanamente felices. Tradujimos este libro con la esperanza de difundir los principios de organización abierta entre las compañías rusas, entre las personas que quieren y pueden vivir de manera diferente.
¡Lee , pruébalo!