Reglas de colaboración

los esfuerzos del grupo extraordinarias no tienen que ser milagrosos o accidental. Un entorno diseñado para productos baratos, las transacciones abundantes colaboraciones que da rienda suelta a romper las barreras organizativas.
Reglas de colaboración
Reglas de colaboración

Los líderes corporativos que buscan crecimiento, aprendizaje e innovación pueden encontrar la respuesta en un lugar sorprendente: la comunidad de software de código abierto. Sin saberlo, tal vez, las personas que te trajeron Linux son virtuosos practicantes de nuevos principios de trabajo que producen equipos energizados y menores costos. Tampoco están solos.

En cualquier medida, Linux es un producto altamente competitivo. Se estima que más servidores se ejecutan en Linux que en cualquier otro sistema operativo. Ha abrumado a UNIX como una oferta comercial. Y sus ventajas van más allá del costo y la calidad a la velocidad con la que se mejora y mejora. Mientras los partidarios debaten sus limitaciones técnicas y el tratamiento de la propiedad intelectual, están de acuerdo en que el éxito del producto es inseparable de su modo distintivo de producción. Específicamente, Linux es la creación de una comunidad esencialmente voluntaria y autoorganizativa de miles de programadores y empresas. La mayoría de los líderes vendían a sus abuelas por mano de obra que colaboran tan eficientemente, sin fricciones y creativamente como los autodenominados «hackers» de Linux.

Pero Linux es software, y el software es un poco raro. Toyota, sin embargo, es una empresa como cualquier otra, cualquier otra constantemente clasificada entre las organizaciones de mayor rendimiento del mundo, es decir. El fabricante de automóviles ha sido durante mucho tiempo un líder en calidad y producción magra, y el éxito del híbrido Prius ha establecido su reputación como un innovador. Hemos encontrado que los métodos de gestión de Toyota se asemejan, en varios de sus fundamentos, al funcionamiento de la comunidad Linux; el Sistema de Producción de Toyota (TPS) debe parte de su vanagada capacidad de respuesta a rasgos de código abierto. De hecho, Toyota mismo está evolucionando hacia un híbrido entre una jerarquía convencional y una red autoorganizativa similar a Linux.

(A lo largo de este artículo, usamos el término «Linux» como abreviatura para la comunidad de software de código libre/abierto que desarrolló y continúa perfeccionando el sistema operativo y otros programas de código abierto. Utilizamos «Toyota» como abreviatura para el Sistema de Producción de Toyota, que comprende a Toyota y sus proveedores directos de «nivel uno» en la industria automotriz en Japón y los Estados Unidos.)

Toyota es notablemente similar a Linux en la forma en que combina características clave de ambos mercados y jerarquías. Al igual que los mercados, las comunidades Toyota y Linux pueden organizarse por sí mismas, pero a diferencia de los mercados, no usan efectivo o contratos en momentos críticos. Al igual que las jerarquías, Toyota y Linux disfrutan de bajos costos de transacción, pero a diferencia de las jerarquías, sus miembros pueden pertenecer a muchas organizaciones diferentes (o a ninguna en absoluto) y no están corsetados por roles y responsabilidades específicos y predefinidos. Y al igual que las jerarquías, los miembros comparten un propósito común, pero ese propósito proviene de la automotivación más que de los incentivos externos o sanciones que generalmente imponen las jerarquías. En estos aspectos, Toyota y Linux representan lo mejor de ambos mundos. Un análisis de sus características comunes sugiere cómo las organizaciones de alto rendimiento siguen siendo productivas e inventivas incluso en condiciones agotadoras. Creemos que esas lecciones pueden mejorar significativamente la forma en que se realiza el trabajo en la mayoría de las organizaciones.

Martes, Diciembre 2, 2003

Cerca de medianoche, Andrea Barisani, administrador del sistema en el departamento de física de la Universidad de Trieste, descubrió que un atacante había golpeado el servidor Gentoo Linux de su institución. Rastreó la brecha hasta un punto vulnerable en el kernel de Linux y otro en rsync, un mecanismo de transferencia de archivos que replica automáticamente datos entre computadoras. Este fue un ataque serio: cualquier penetración de rsync podría comprometer archivos en miles de servidores en todo el mundo.

Barisani despertó a algunos colegas, que lo pusieron en contacto con Mike Warfield, un investigador senior de Internet Security Systems en Atlanta, y con Andrew «Tridge» Tridgell, un conocido programador Linux en Australia en cuya tesis doctoral rsync se basó. Dirigieron el mensaje de Barisani (hecho anónimo por razones de seguridad) a otro australiano, Martin Pool, que trabajaba para Hewlett-Packard en Canberra y había sido líder en el desarrollo de rsync. Aunque Pool ya no era responsable de rsync (nadie lo era), inmediatamente golpeó los teléfonos y el correo electrónico, primero cuestionó a Warfield y Dave Dykstra (otro contribuyente temprano al desarrollo de rsync, que estaba basado en California) acerca de las vulnerabilidades y luego ayudó a Barisani a rastrear el fallo línea por línea.

Por la mañana, hora de Trieste, Pool y Barisani habían encontrado la ubicación exacta de la brecha. Pool contactó con el actual grupo de desarrollo rsync, mientras Barisani se conectó con la afiliación floja de aficionados y profesionales que empaquetan Gentoo Linux, y publicó un aviso de alerta temprana al sitio Gentoo. Pool y Paul «Rusty» Russell (un compañero Canberran que trabaja para IBM) trabajaron durante la noche australiana para escribir un parche, y dentro de cinco horas los usuarios desarrolladores de Gentoo comenzaron a probar la primera versión. Mientras tanto, Tridge elaboró una descripción de la vulnerabilidad y su solución, asegurándose (a instancias de Pool) de acreditar a Barisani y Warfield por sus esfuerzos entre bastidores. El jueves por la tarde, hora de Canberra, el anuncio y el parche fueron publicados en el sitio web de rsync y así distribuidos a los usuarios de Linux de todo el mundo.

Unos días después de la emergencia, después de haber dormido, Barisani se ofreció a colaborar con Warfield en la creación de un sistema de servidores deliberadamente vulnerables para atraer al cracker del sistema a revelarse a sí mismo.

Nadie autorizó ni dirigió este esfuerzo. Nadie —aficionado o profesional— fue pagado por participar o habría sido sancionado por no hacerlo. El trabajo de nadie dependía de detener el ataque. Nadie se reprimió por miedo a la responsabilidad legal. De hecho, la comunidad de usuarios más amplia se mantuvo informada de todos los acontecimientos. Sin embargo, a pesar de la necesidad de la máxima seguridad, un grupo de unas 20 personas, casi ninguna de las cuales se había encontrado alguna vez, empleadas por una docena de empresas diferentes, que vivían en tantas zonas horarias y se alejaban de sus descripciones de trabajo, logró en aproximadamente 29 horas lo que podría haber llevado a colegas en cubículos adyacentes semanas o meses.

Es tentador descartar esto como un ejemplo de extrañeza de los hacker, admirable, sí, pero nada que ver con negocios reales. Considere, sin embargo, otra historia.

Sábado, Febrero 1, 1997

A las 4:18 de la mañana, se produjo un incendio en la planta número 1 de Kariya de Aisin Seiki, un importante proveedor japonés de piezas de automoción. En cuestión de minutos, el edificio y prácticamente toda la maquinaria especializada en su interior fueron destruidos. Kariya Número 1 produce el 99% de las válvulas de distribución de flujo de freno, o válvulas P, para las operaciones japonesas de Toyota, piezas requeridas por cada vehículo que Toyota construye. Y Toyota, fiel a sus principios justo a tiempo, tenía menos de un día de inventario. El sistema japonés de producción Toyota enfrentó la posibilidad de un cierre total de meses.

En pocas horas, los ingenieros de Aisin se reunieron con sus homólogos en Toyota y otros proveedores de nivel uno de Toyota. El grupo acordó improvisar la mayor producción posible. A medida que las noticias se difundieron a través de la red de proveedores, algunos de los niveles dos se ofrecieron voluntariamente para desempeñar funciones de liderazgo. Aisin envió planos de las válvulas a cualquier proveedor que los solicitara y distribuyó cualquier herramienta, materia prima y trabajo en proceso que pudiera ser rescatada. Los ingenieros de Aisin y Toyota ayudaron a las líneas de producción del jurado en 62 ubicaciones: talleres de máquinas sin usar, taller de prototipos de Toyota, incluso una instalación de máquinas de coser propiedad de Brother. Denso, el mayor proveedor de Toyota, se ofreció a gestionar la desordenada logística de las válvulas de envío a Aisin para su inspección y luego a las líneas de montaje estancadas de Toyota.

Todo el mundo se sorprendió cuando un pequeño proveedor de electrodos de soldadura de nivel dos, Kyoritsu Sangyo, fue el primero en entregar válvulas de calidad de producción a Toyota, 1.000 de ellas, apenas 85 horas después del incendio. Otros siguieron rápidamente, y Toyota comenzó a reabrir las líneas de montaje el miércoles. Aproximadamente dos semanas después de la parada, toda la cadena de suministro volvió a su plena producción. Seis meses más tarde, Aisin distribuyó una guía de respuesta de emergencia que contenía lecciones extraídas de la experiencia y recomendaba procedimientos para responder a esas situaciones en el futuro.

Ninguna persona u organización planeó este esfuerzo: más bien, personas y empresas intervinieron donde pudieron. Los competidores colaboraron. En ese momento no se pagaba a nadie por contribuir. Meses después, Aisin compensó a las otras empresas por los costes directos de las válvulas que habían entregado. Toyota dio a cada proveedor de nivel uno un honorario basado en las ventas actuales al fabricante de automóviles, alentándoles —pero no requiriendo— a hacer lo mismo para sus propios niveles dos.

Pocas comunidades parecen más diferentes que el anarquista, con cafeína y hirsute mundo de los hackers y el mundo disciplinado, sorbo de té y limpio de la ingeniería automotriz japonesa. Pero los paralelismos entre estas historias son sorprendentes. En ambos, los individuos se encontraron unos a otros y entraron en funciones sin un plan o una estructura de mando y control establecida. Una extensa red humana se organizó en horas y se «pululaban» contra una amenaza. Personas, equipos y empresas trabajaron juntos sin contratos legales ni pagos negociados. Y a pesar de la falta de cualquier palo autoritario o zanahoria financiera, esas personas trabajaron como el infierno para resolver el problema.

Pocas comunidades parecen más diferentes que el anarquista, con cafeína y hirsute mundo de los hackers y el mundo disciplinado, sorbo de té y limpio de la ingeniería automotriz japonesa.

Obviamente, estas fueron respuestas de emergencia. Pero un vistazo a las operaciones diarias de la comunidad Linux y del Sistema de Producción Toyota revela que esas respuestas fueron simplemente intensificaciones de la forma en que la gente ya estaba trabajando.

Obsesión, interacción y un toque ligero

Las reglas de los mercados son sobre efectivo y contratos. Las reglas de las jerarquías tienen que ver con la autoridad y la rendición de cuentas. Pero en el núcleo de las comunidades Linux y Toyota hay reglas sobre tres cosas completamente diferentes: cómo los individuos y los grupos pequeños trabajan juntos; cómo y cuán ampliamente se comunican; y cómo los líderes los guían hacia un objetivo común.

Una disciplina laboral común.

Las comunidades Linux y Toyota están compuestas por ingenieros, por lo que los miembros tienen las mismas habilidades que sus colegas y hablan el mismo idioma. Pero estos grupos son mucho más disciplinados y rigurosos en su enfoque al trabajo que otras comunidades de ingeniería. Ambos enfatizan la granularidad: prestan atención a pequeños detalles, eliminan problemas en la fuente y recortan cualquier cosa que se asemeje a exceso, ya sea trabajo, código o material. Los miembros de Linux, por ejemplo, comparten una obsesión por escribir código mínimo, compilando la salida de cada día antes de pasar a la siguiente y extirpando flujos de programación a medida que avanzan. Por su parte, los ingenieros de TPS son implacables en aplicar ciclos cortos de prueba y error, centrándose en una sola cosa a la vez, y entrando y observando los procesos reales. Ambos grupos llevan esos principios a extremos aparentes. Los programadores de Linux se escaburan en el código en busca no de la eficiencia computacional sino de la elegancia. Los ingenieros de Toyota rechazan los estampados de la capucha Lexus, aunque impecable y totalmente dentro de las especificaciones, porque el brillo, para sus ojos, carece de brillo.

Comunicación granular generalizada.

Tanto en las comunidades Linux como en Toyota, la información sobre problemas y soluciones se comparte ampliamente, con frecuencia y en pequeños incrementos. La mayoría de la comunicación de hacker de Linux no es entre individuos, sino mediante publicaciones para abrir Listservs que se pueden buscar. Cualquiera puede revisar el historial de versiones del código y los debates de Listserv, no resúmenes o resúmenes ejecutivos, sino la actividad sin procesar en sí. Y cada contribución de código es el estrés probado por decenas de personas. Como dice una famosa metáfora mixta de código abierto: «Con mil ojos, todos los insectos son superficiales». La carga mediana al núcleo Linux es de una docena de líneas de código. La versión alfa de trabajo se vuelve a compilar cada 24 horas, por lo que los hackers concilian sus esfuerzos casi continuamente. Si alguien trabajó en aislamiento durante seis meses incluso en la contribución más brillante, probablemente sería rechazado por falta de compatibilidad con los esfuerzos de los demás.

La filosofía Toyota de mejora continua también comprende mil pequeñas colaboraciones. Los ingenieros de Toyota son famosos perforados para «preguntar por qué cinco veces» para seguir una cadena de causas y efectos de vuelta a la raíz de un problema. Esto no es un cliché de pensar profundamente. Todo lo contrario, de hecho. El mérito del precepto está precisamente en su superficialidad. Decir que B causa A es simplista: todas las complejidades de múltiples interacciones se han reducido a una sola causa y efecto. Pero la cadena de pensamiento necesaria para descubrir que C causa B, y D causa C, rápidamente te lleva a un nuevo dominio, probablemente de otra persona. Así que en lugar de inventar soluciones complejas dentro de sus propios dominios, los ingenieros deben buscar soluciones simples más allá de ellos. «Hacer tu porqué-porqué-qué», como se conoce en la práctica, no se trata de profundidad en absoluto, se trata de amplitud.

Y al igual que con Linux, los protocolos de comunicación de Toyota hacen cumplir esta disciplina. Cada reunión aborda un solo tema y conduce hacia un resultado específico, incluso si eso significa que las mismas personas se reúnen más de una vez al día. Las lecciones se escriben en un formato estándar en una sola hoja de papel A3. Y todo el mundo aprende a elaborar estos informes, hasta el pliegue en el documento que muestra los puntos principales y oculta los detalles.

Líderes como conectores.

En todos los niveles, los líderes de Linux y TPS desempeñan tres funciones críticas. Instruyen a los miembros de la comunidad, a menudo por ejemplo, en las disciplinas que acabamos de describir. Ellos articulan objetivos claros y sencillos para cada proyecto en función de su visión estratégica. Y conectan a la gente, por mérito de estar muy bien conectados ellos mismos. Los principales programadores de Linux procesan más de 300 o 400 correos electrónicos diariamente. Fujio Cho, el presidente de Toyota, gestiona por igual numerosas interacciones diarias que trascienden la cadena normal de mando.

Ninguna comunidad trata el liderazgo como una disciplina distinta de hacer. Más bien, la credibilidad y, por lo tanto, la autoridad de los líderes se deriva de su competencia como practicantes. El contenido de las comunicaciones staccato de los líderes es menor sobre trabajo de lo que es trabajo. (Cuando Linus Torvalds, creador de Linux, escribe casi tanto en el lenguaje de programación C como en inglés).

En las comunidades Linux y Toyota, liderar no es tratado como una disciplina distinta de hacer. Más bien, la autoridad de los líderes deriva de su proï¬ciency como practicantes.

Ocasionalmente, los líderes tienen que llevar a cabo actos de liderazgo tradicionales, como el arbitraje de conflictos. Esa, sin embargo, es la excepción y se ve como una falla del sistema. La suposición predeterminada es que, en la medida de lo posible, los gerentes no se las arreglan en un sentido tradicional: la red humana se administra sola. En Linux, las prioridades de desarrollo no son decididas por un CEO, sino por miles de hackers que votan con sus pies eligiendo en qué trabajar. Ese tipo de autogestión radical no ocurre en Toyota, excepto en emergencias. Pero incluso en las operaciones diarias, un solo trabajador de producción que ve un problema de calidad puede detener la línea, y los equipos de proyecto tienen amplia latitud para aprovechar los recursos, tomar decisiones de compra y perseguir las prioridades que se establecen.

En conjunto, estos tres principios siembran un sistema de adaptación continua. Una y otra vez, las ideas se formulan en paquetes ajustados y probables; se comunican con una atenuación mínima a través de conexiones establecidas, directas, de persona a persona; y donde los enlaces están ausentes, los líderes ampliamente conectados los crean según sea necesario. Esta es la disciplina, pero no la disciplina de la conformidad producida por los controles y los incentivos. Más bien, se asemeja a la disciplina de la ciencia. Al igual que las comunidades científicas, estos sistemas se basan en procedimientos comunes, normas comunes para la comunicación y las pruebas, y objetivos comunes claramente entendidos. El comportamiento individual es rigurosamente cauteloso, pero el logro colectivo está marcado por una innovación continua y radical.

Lo que saben y cómo lo saben

En el corazón de Linux y el Sistema de Producción Toyota, entonces, hay un conjunto de prácticas de trabajo, comunicación y liderazgo que contribuyen a una nueva forma de colaboración. Esta colaboración también se basa en dos componentes de infraestructura: un conjunto compartido de conocimientos y herramientas universalmente disponibles para mover los conocimientos.

Propiedad Intelectual Común.

La Licencia Pública General bajo la cual se publica Linux requiere que todos los distribuidores pongan su código fuente libremente disponible para que otros puedan publicarlo libremente. Este principio viral evita que el código se almacene en productos patentados. Esa transparencia, a su vez, rompe la distinción entre productor y usuario. Un «cliente» sofisticado como Andrea Barisani es realmente un usuario desarrollador, que corrige defectos y agrega características para su propio beneficio, luego comparte esas mejoras con todos los demás. Tal función es imposible cuando el código de propiedad es licenciado por un proveedor comercial. Del mismo modo, la cadena de suministro de Toyota se basa en el principio de que si bien el conocimiento del producto (como un proyecto) es propiedad intelectual de alguien, el conocimiento del proceso se comparte. Esto rompe algunas distinciones entre empresas. Los proveedores de Toyota comparten regularmente extensas lecciones de mejora de procesos tanto vertical como lateralmente, incluso con sus competidores. En Japón, los proveedores son generalmente exclusivos de un solo OEM, por lo que el beneficio colectivo de esa información compartida permanece dentro de la cadena de suministro de Toyota. Pero incluso en los Estados Unidos, donde Toyota es sólo uno de los varios clientes para la mayoría de sus niveles, el fabricante de automóviles hace lo mismo a través de su Bluegrass Automotive Manufacturers Association, que difunde las mejores prácticas a todos los miembros.

Tecnología simple y omnipresente.

Aunque la información es la savia de las comunidades Linux y TPS, sus sistemas de circulación son sorprendentemente rudimentarios. Los desarrolladores de Linux producen software de última generación utilizando tecnología de comunicación no más sofisticada que el correo electrónico y los servidores de listas, pero esas herramientas mundanas son utilizadas por todos. De hecho, es tan grande el valor que se asigna a la universalidad que los correos electrónicos de texto sin formato, en lugar de formatear, son la norma, asegurando que los mensajes aparezcan exactamente iguales para todos los destinatarios. Toyota, cuyos productos son de última generación, también prefiere la tecnología interna simple y generalizada. Un contenedor kanban vacío indica la necesidad de reponer las piezas; una longitud de cinta adhesiva en el piso de la línea de montaje asigna los tiempos de finalización de las tareas en un vehículo en movimiento. Los problemas de control de calidad en la línea de montaje se anuncian a través de buscapersonas y monitores de TV. Y todos reciben la alerta. Incluso Ray Tanguay, jefe de Toyota Canadá, es llamado cada vez que se encuentra un defecto en el último envío de Lexus en el muelle de Long Beach, California, o en una bahía de servicio en cualquier lugar de América del Norte.

El poder de la confianza y el aplauso

Estas colaboraciones extremadamente ricas y flexibles tienen consecuencias psicológicas positivas para los participantes y poderosas competitivas para sus organizaciones. Esas consecuencias son un rico conocimiento común, la capacidad de organizar equipos modularmente, una motivación extraordinaria y altos niveles de confianza.

Rico conocimiento semántico.

Una disciplina de trabajo rigurosa, la propiedad intelectual común y el intercambio constante se combinan para distribuir el conocimiento de manera amplia y relativamente uniforme entre las redes humanas. Ese conocimiento incluye no sólo la información formal y sintáctica que se encuentra en las bases de datos, sino también el conocimiento semánticamente rico y ambiguo sobre el contenido y el proceso que es la moneda de la colaboración creativa. ¿Qué queremos decir con el brillo de un estampado corporal con brillo insuficiente? ¿Qué, precisamente, debemos discutir con la empresa siderúrgica para corregir un problema tan mal definido? Este tipo de preguntas que no son fáciles de responder se discute y resuelve continuamente en mil colaboraciones de pequeños equipos. El pensamiento matizado resultante y el vocabulario común más rico en estos asuntos se alimentan de nuevo en el fondo de conocimientos, donde están disponibles para su ulterior perfeccionamiento por parte de toda la comunidad.

Equipo modular.

La modularidad es un principio de diseño por el cual un proceso o producto complejo se divide en piezas simples conectadas por reglas estándar. En los arreglos modulares de los equipos, cada equipo se centra en tareas pequeñas y sencillas que juntas forman un todo más grande. La modularidad permite a una organización ejecutar múltiples experimentos paralelos, haciendo muchas apuestas pequeñas en lugar de unas pocas grandes. Los proveedores de Toyota se organizaron de esta manera para hacer válvulas P, operando en parte por dirección, pero principalmente por voluntarios para hacer lo que cada uno sabía mejor. El grupo Gentoo, los expertos en seguridad de Tridge y el círculo de antiguos alumnos rsync de Pool eran módulos preexistentes y superpuestos que mezclaban y combinaban roles según la emergencia requerida.

Cuando mapeamos los patrones de colaboración diaria a través de todo el esfuerzo de desarrollo del kernel de Linux, descubrimos que tales arreglos modulares son omnipresentes y, en cierta medida, se anidan unos dentro de otros. Esto crea una especie de organigrama dinámico, un gráfico que nadie escribió excepto uno que permite a la comunidad expandirse y adaptarse sin colapsar en el caos.

Motivación intrínseca.

Las comunidades Linux y TPS disocian el dinero de las transacciones clave. Sin embargo, a pesar de los débiles incentivos financieros, tienen un nivel de motivación superior al que se encuentra en los entornos convencionales. Zanahorias monetarias y palos de rendición de cuentas, los psicólogos han encontrado consistentemente, motivan a la gente a realizar tareas estrechas, específicas, pero generalmente desalientan a la gente de ir más allá de ellos. La admiración y el aplauso son estimulantes mucho más eficaces del comportamiento superior y más allá. «La reputación personal del desarrollador está unida a cada lanzamiento», explicó Linus Torvalds al columnista de tecnología Robert Cringely en 1998. «Si estás haciendo algo para regalar al mundo, algo que representa a millones de usuarios tu filosofía de informática, siempre lo convertirás en el mejor producto que puedas».

Las zanahorias monetarias y los palos de rendición de cuentas motivan a la gente a realizar tareas estrechas y específicas. La admiración y el aplauso son estimulantes mucho más eficaces del comportamiento superior y más allá.

Los psicólogos también enfatizan la importancia motivacional de la autonomía. Los programadores de Linux deciden por sí mismos cómo y dónde contribuir, y disfrutan de la satisfacción de producir algo cuya calidad no está definida por un departamento de marketing ni por contadores, sino por sus propios estándares exigentes. El coautor Bob Wolf y Karim Lakhani del MIT encuestaron a más de 800 usuarios desarrolladores, y más de la mitad dijeron que su trabajo de código abierto es el esfuerzo más valioso y creativo en su vida profesional.

El sistema de producción Toyota no ofrece una autonomía tan extrema, por supuesto, y los empleados no trabajan gratis. Pero en comparación con sus homólogos en el resto de la industria automotriz, los trabajadores de TPS disfrutan de menos controles, un mayor estímulo a la iniciativa individual, menos métricas asociadas al rendimiento individual y más aplausos de pares. El orgullo profesional y corporativo, no el honorario de Toyota, fue la payoff para el equipo de Kyoritsu Sangyo cuando entregó el primer lote de válvulas P. Ese mismo orgullo lo siente un trabajador junior de la línea de montaje cuando sus compañeros confían en él para experimentar con mejoras de proceso y detener la línea si algo sale mal.

Altos niveles de confianza.

Cuando la información fluye libremente, la reputación, más que la reciprocidad, se convierte en la base de la confianza. Operando bajo un escrutinio constante —que es desafiante pero no hostil —los trabajadores saben que su reputación está en riesgo, y eso sirve como garante de buen comportamiento, equivalente a contratos en un mercado o auditorías en una jerarquía. De ahí la obsesión en la comunidad Linux por reconocer contribuciones de código e incluir direcciones de correo electrónico personales en los campos de comentarios de Listservs. De ahí el generoso crédito público otorgado a Barisani y Warfield. De ahí la celebración colectiva de los heroicos esfuerzos de Kyoritsu Sangyo.

Con su reputación en juego, es menos probable que la gente actúe de manera oportunista. Con la misma información disponible para todos, hay menos posibilidades de que una parte aproveche la ignorancia de otra. Y con un vocabulario común y una forma de trabajar, se producen menos malentendidos. Estos factores impulsan la confianza, capital social fundamental de estas comunidades.

La confianza importaría menos si no hubiera ningún costo para salir de estas redes o si las transacciones fueran de tamaños radicalmente diferentes (ya que eso tentaría a personas o empresas a romper las reglas cuando surgiera una gran oportunidad). Pero tanto en las comunidades Linux como en Toyota, la entrada al círculo interno es un privilegio ganado con mucho esfuerzo, y ambas operan en muchos intercambios pequeños.

Y, por supuesto, donde la confianza es la moneda, la reputación es una fuente de poder. En una red dispersa, como la mayoría de los mercados y jerarquías, el poder deriva del control o la intermediación del flujo de información y, por lo tanto, de su restricción. Sin embargo, en una red densa, la información simplemente fluye alrededor del posible punto de estrangulación. En esas circunstancias, hay más poder en ser una fuente de información que un sumidero de información. En consecuencia, las personas están motivadas a maximizar tanto la visibilidad de su trabajo como sus conexiones con aquellos que están conectados ampliamente. Eso, a su vez, alimenta la densidad de información de la red.

Transacciones baratas y muchas de ellas

Hasta ahora hemos estado debatiendo el contenido del trabajo. Pero los modelos TPS y Linux también cambian la economía del trabajo, al reducir los costos de transacción. Los bajos costos de transacción hacen que sea rentable para las organizaciones realizar transacciones más pequeñas, tanto internas como externas, y así aumentar el ritmo y la flexibilidad típicos de las organizaciones de alto rendimiento.

Las fuentes clásicas de los costos de transacción son la vulnerabilidad mutua ante la incertidumbre, los intereses conflictivos y el acceso desigual a la información. Gastamos dinero en negociación, supervisión y restitución para reducir esas imperfecciones. Tanto los mercados como las jerarquías incurren en costos de transacción (aunque existen jerarquías para economizarlas, como han argumentado Ronald Coase y Oliver Williamson). Utilizando una metodología desarrollada por J.J. Wallis y Douglass North, estimamos que en el año 2000, los costos de transacción en efectivo representaron por sí solos más de la mitad del PIB no gubernamental de los Estados Unidos. Gastamos más dinero en negociar y hacer cumplir transacciones que en cumplirlas.

En las comunidades Linux y Toyota, los acuerdos se aplican no por la sanción de un contrato legal, ni por la autoridad de un jefe, sino por la confianza mutua, reduciendo drásticamente los costos de transacción. Esto no es nuevo: Equipos de personas de todo el lugar de trabajo convencional operan sobre la base de la confianza.

Lo nuevo es cómo se puede extender la confianza, incluso a personas que no se conocen, o incluso entre aquellos que tienen intereses en competencia. Aisin confió en sus proveedores rivales los planos de la válvula P. Los hackers de rsync intercambiaron información confidencial con personas que nunca habían conocido. Los proveedores de componentes de Toyota comparten el conocimiento del proceso diariamente, confiando en que Toyota no lo usará para bajar los precios. Los hackers de Linux confían unos en otros para realizar emendaciones no coordinadas y simultáneas en la base de código.

Por otra parte, la posesión de la propiedad en común —como ciertos tipos de propiedad intelectual se mantienen dentro de estas comunidades— reduce las apuestas monetarias entre los copropietarios. Los costos de transacción caen porque simplemente hay menos que negociar. En la comunidad Linux, los costos de transacción se aproximan a cero. Hewlett-Packard pagó a Martin Pool para ser ingeniero de Linux, pero no se sigue que HP necesitara ser pagado en el margen por las labores nocturnas de Pool en rsync. En la comunidad Toyota, los costos de transacción, aunque no cero, se han reducido radicalmente. Cuando la planta de Aisin Seiki fue destruida, Toyota y sus proveedores no se demandaron ni se juntaron contratos de suministro de emergencia. Simplemente se pusieron a trabajar, confiando en que eventualmente se haría una restitución justa. Jeffrey Dyer, profesor de estrategia en la Universidad Brigham Young, estima que los costos de transacción entre Toyota y sus proveedores de nivel uno son sólo una octava parte de los de General Motors, una disparidad que atribuye a diferentes niveles de confianza.

Un modelo para muchos

Reúne todos estos elementos y tendrás un círculo virtuoso. Una red densa y autoorganizativa crea las condiciones para la confianza a gran escala. La confianza a gran escala reduce los costos de transacción. Los bajos costos de transacción, a su vez, permiten muchas transacciones pequeñas, que crean una red autoorganizada y que se profundiza acumulativamente.

Una vez que el sistema alcanza la masa crítica, se alimenta de sí mismo. Cuanto más grande es el sistema, más ampliamente se comparten el conocimiento, el idioma y el estilo de trabajo. Cuanto mayor sea el capital reputacional de los individuos, más fuertes serán los aplausos y más fuerte será la motivación. El éxito de Linux es evidencia del poder de ese círculo virtuoso. El éxito de Toyota es evidencia de que también es poderoso en las empresas convencionales que maximizan los beneficios.

La comunidad Linux y el sistema de producción Toyota son sorprendentemente diferentes. El hecho de que logren tanto de maneras similares apunta a algunos principios que otros pueden seguir.

  • La disciplina de la ciencia es sorprendentemente adaptable a la organización del trabajo corporativo e incluso intercorporativo.
  • En algunas circunstancias, la confianza es un sustituto viable de los contratos de mercado y de la autoridad jerárquica, no sólo en equipos pequeños sino también en comunidades muy grandes.
  • A través de las cadenas de suministro, las organizaciones que pueden sustituir la confianza por los contratos ganan más de la colaboración de lo que pierden en poder de negociación.
  • Los bajos costos de transacción compran más innovación que los altos incentivos monetarios.

Estos principios sirven a la necesidad de crecimiento e innovación de las empresas de manera que los modelos organizacionales tradicionales no lo hacen. Y tal vez la efectividad de estas colaboraciones sugiere el surgimiento final de algo completamente nuevo. No mercados. No jerarquías. Pero una poderosa combinación de ambos y una firma de la sociedad en red.

A version of this article appeared in the
July–August 2005 issue of
Harvard Business Review.


Philip Evans Bob Wolf
Via HBR.org

Related Posts
Maximizing Your Return on People

El caso de los denunciantes deliberados

Cuando Ken Deaver, CEO de Fairway eléctrico, me ascendió a vicepresidente de la división nuclear, que estaba en la cima del mundo. Ahora, sólo un mes más tarde, se siente como si el mundo está encima de mí. Estoy acostumbrado a tener un equipo para compartir los problemas, pero ahora estoy en mi propio. Por lo menos […]
Leer más
Seamos honestos sobre mentir

Poder, capricho y consecuencias

Los líderes consiguen a menudo a saltar “buen proceso” y simplemente actuar según sus caprichos. Tome el jefe en el antiguo lugar de trabajo de mi colega. Heredó un equipo y despidió al jefe de la unidad que tenía el mejor rendimiento y las ganancias y pérdidas de la mejor reputación como un administrador de la gente. Al preguntarle cómo se llegó a esa decisión, el jefe dijo que debía [...]
Leer más
Por qué cada empresa necesita un director de experiencia

Por qué cada empresa necesita un director de experiencia

Muchas empresas echan de menos que una gran experiencia de empleados lleve a una gran experiencia de cliente. Independientemente, cada función conduce a relaciones valiosas, con clientes y empleados, pero cuando CX y EX se gestionan juntos, crean una ventaja competitiva única y sostenible. Para ello, las empresas deben considerar la integración de las dos disciplinas e instalar un Chief Experience Officer para liderar el esfuerzo combinado en toda la organización. Un CXO profundiza cómo los empleados entienden a los clientes y cómo los líderes de la empresa entienden a los empleados, centralizando el valor en sus funciones centradas en las personas.

Leer más