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 del software de código abierto. Sin saberlo, quizás, la gente que te trajo Linux son virtuosos practicantes de nuevos principios de trabajo que producen equipos energizados y reducen los costos. Tampoco están solos.

En cualquier medida, Linux es un producto muy competitivo. Se estima que hay más servidores ejecutan en Linux que en cualquier otro sistema operativo. Ha superado a UNIX como oferta comercial. Y sus ventajas van más allá del coste 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, coinciden en que el éxito del producto es inseparable de su modo de producción distintivo. Concretamente, Linux es la creación de una comunidad esencialmente voluntaria y autoorganizada de miles de programadores y empresas. La mayoría de los líderes venderían a sus abuelas por trabajadores que colaboran de forma tan eficiente, sin fricciones y de manera creativa 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, es decir, cualquier otra clasificada constantemente entre las organizaciones con mejor desempeño del mundo. El fabricante de automóviles ha sido durante mucho tiempo líder en calidad y producción ajustada, y el éxito del híbrido Prius ha establecido su reputación como innovador. Hemos descubierto 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 Toyota (TPS) debe parte de su cacareada capacidad de respuesta a los rasgos de código abierto. De hecho, la propia Toyota está evolucionando hacia un híbrido entre una jerarquía convencional y una red autoorganizada similar a Linux.

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

Toyota es notablemente similar a Linux en la forma en que combina características clave de los mercados y las jerarquías. Al igual que los mercados, las comunidades Toyota y Linux pueden autoorganizarse, pero a diferencia de los mercados, no utilizan efectivo ni contratos en coyunturas críticas. 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) y no están encorsetados por funciones y responsabilidades específicas y predefinidas. Al igual que las jerarquías, los miembros comparten un propósito común, pero ese propósito emana de la motivación propia y no de los incentivos o sanciones externos que las jerarquías generalmente imponen. En este sentido, 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 difíciles. Creemos que esas lecciones pueden mejorar significativamente la forma en que se trabaja en la mayoría de las organizaciones.

martes, 2 de diciembre de 2003

Cerca de la medianoche, Andrea Barisani, administrador de sistemas del 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 los datos entre las computadoras. Se trataba de un ataque grave: cualquier penetración de rsync podía comprometer archivos en miles de servidores en todo el mundo.

Barisani despertó a algunos colegas, que lo pusieron en contacto con Mike Warfield, investigador senior de Internet Security Systems en Atlanta, y con Andrew «Tridge» Tridgell, un conocido programador de Linux en Australia en cuya tesis doctoral se basó rsync. Dirigieron el mensaje de Barisani (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 cuestionando a Warfield y Dave Dykstra (otro de los primeros colaboradores del desarrollo de rsync, que tenía su sede en California) sobre las vulnerabilidades y luego ayudando a Barisani a rastrear la falla 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 se puso en contacto con el actual grupo de desarrollo de rsync, mientras que Barisani se conectó con la floja afiliación de aficionados y profesionales que empaquetan Gentoo Linux, y publicó un aviso de alerta temprana en el sitio de Gentoo. Pool y Paul «Rusty» Russell (un compañero de Canberran que trabaja para IBM) trabajaron durante toda la noche australiana para escribir un parche, y en cinco horas los desarrolladores usuarios 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 instar 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 se publicaron en el sitio web de rsync y, por lo tanto, se distribuyeron 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ó como voluntario para colaborar con Warfield en la configuración de un sistema de servidores deliberadamente vulnerables para atraer al cracker del sistema para que se revelara.

Nadie autorizó ni dirigió este esfuerzo. A nadie, aficionado o profesional, se le pagó por participar o se le habría sancionado por no hacerlo. El trabajo de nadie se basaba en detener el ataque. Nadie se calmó por temor a la responsabilidad legal. De hecho, la comunidad de usuarios en general se mantuvo informada de todos los desarrollos. 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 conocido, empleadas por una docena de empresas diferentes, que vivían en tantas zonas horarias y se alejaban de sus descripciones laborales, lograron en unas 29 horas lo que podría haber llevado a los colegas de los cubículos adyacentes semanas o meses.

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

Sábado, 1 de febrero de 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 repuestos automotrices. En cuestión de minutos, el edificio y prácticamente toda la maquinaria especializada del interior fueron destruidos. Kariya Number 1 produce el 99% del líquido de frenos (válvulas dosificadoras o válvulas P) para las operaciones japonesas de Toyota, piezas requeridas por todos los vehículos que Toyota fabrica. Y Toyota, fiel a sus principios de «justo a tiempo», tenía menos de un día de inventario. El sistema de producción japonés Toyota se enfrentó a la posibilidad de un cierre total que duró meses.

En cuestión de horas, los ingenieros de Aisin se reunieron con sus homólogos de Toyota y otros proveedores de primer nivel de Toyota. El grupo acordó improvisar la mayor producción posible. A medida que se difundieron las noticias a través de la red de proveedores, algunos de los niveles dos se ofrecieron voluntariamente para desempeñar funciones Aisin envió planos para las válvulas a cualquier proveedor que los solicitara y distribuyó las herramientas, las materias primas y el trabajo en proceso que no habían sido dañados. Los ingenieros de Aisin y Toyota ayudaron a construir líneas de producción en 62 ubicaciones: talleres de máquinas sin usar, el propio taller de prototipos de Toyota e incluso una instalación de máquinas de coser propiedad de Brother. Denso, el mayor proveedor de Toyota, se ofreció como voluntario para gestionar la complicada logística del envío de válvulas a Aisin para su inspección y luego para las líneas de montaje estancadas de Toyota.

Todos se sorprendieron cuando un pequeño proveedor de electrodos de soldadura, Kyoritsu Sangyo, fue el primero en entregar válvulas de calidad de producción a Toyota, 1.000 de ellas, solo 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 interrupción, toda la cadena de suministro volvió a su plena producción. Seis meses después, Aisin distribuyó una guía de respuesta a emergencias que contenía lecciones extraídas de la experiencia y recomendaba procedimientos para responder a tales situaciones en el futuro.

Ningún individuo u organización planeó este esfuerzo: más bien, las personas y las empresas intervino donde podían. Colaboraron los competidores. En ese momento no se pagaba a nadie por contribuir. Meses después, Aisin compensó a las demás empresas por los costes directos de las válvulas que habían entregado. Toyota otorgó a cada proveedor de primer nivel un honorario basado en las ventas actuales al fabricante de automóviles, alentándolos, pero no exigiéndoles, que hicieran lo mismo para sus propios niveles dos.

Pocas comunidades parecen ser más diferentes que el mundo anárquico, cargado de cafeína e hirsuto de los hackers y el disciplinado mundo de la ingeniería automotriz japonesa. Pero los paralelismos entre estas historias son sorprendentes. En ambos casos, los individuos se encontraban entre sí y asumían roles sin un plan ni una estructura de mando y control establecida. Una extensa red humana se organizó en horas y «se abalanó» contra una amenaza. Las personas, los equipos y las 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 demonio para resolver el problema.

Pocas comunidades parecen ser más diferentes que el mundo anárquico, cargado de cafeína e hirsuto de los hackers y el disciplinado mundo de la ingeniería automotriz japonesa.

Obviamente, estas fueron respuestas de emergencia. Pero un vistazo a las operaciones cotidianas de la comunidad Linux y del Sistema de Producción Toyota revela que esas respuestas no eran más que intensificaciones de la forma en que la gente ya trabajaba.

Obsesión, interacción y un toque ligero

Las reglas de los mercados tienen que ver con el efectivo y los contratos. Las reglas de las jerarquías tienen que ver con la autoridad y la responsabilidad. Pero en el núcleo de las comunidades de Linux y Toyota hay reglas sobre tres cosas completamente diferentes: cómo trabajan juntas las personas y los grupos pequeños; cómo y con qué amplitud 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 de trabajo que otras comunidades de ingenieros. Ambos enfatizan la granularidad: prestan atención a los pequeños detalles, eliminan los problemas en la fuente y recortan todo lo que se parezca al exceso, ya sea trabajo, código o material. Los miembros de Linux, por ejemplo, comparten una obsesión por escribir código mínimo, compilar la salida de cada día antes de pasar al siguiente y extirpar los errores de programación a medida que avanzan. Por su parte, los ingenieros de TPS son implacables en la aplicación de ciclos cortos de ensayo y error, se centran en una sola cosa a la vez y se adentran y observan los procesos reales. Ambos grupos llevan esos principios a extremos aparentes. Los programadores de Linux se desvanecen en el código en busca no de la eficiencia computacional sino de la elegancia. Los ingenieros de Toyota rechazan los estampados de la capota Lexus, aunque impecables y totalmente dentro de las especificaciones, porque el brillo, a sus ojos, carece de brillo.

Comunicación granular y generalizada.

Tanto en la comunidad de Linux como en la Toyota, la información sobre problemas y soluciones se comparte ampliamente, con frecuencia y en pequeños incrementos. La mayoría de las comunicaciones de hacker de Linux no se dan entre individuos, sino mediante publicaciones en Listservs abiertos y con capacidad de búsqueda. Cualquiera puede revisar el historial de versiones del código y los debates de Listserv, no los resúmenes ejecutivos ni los resúmenes, sino la propia actividad sin procesar. Y cada contribución del código es sometida a pruebas de estrés por decenas de personas. Como dice una famosa metáfora mixta de código abierto: «Con mil ojos, todos los insectos son superficiales». La mediana de carga en el kernel de Linux es de una docena de líneas de código. La versión alfa funcional se recompila cada 24 horas, por lo que los hackers concilian sus esfuerzos casi continuamente. Si alguien trabajara aislado durante seis meses incluso con la contribución más brillante, probablemente sería rechazada por falta de compatibilidad con los esfuerzos de los demás.

La filosofía de mejora continua de Toyota también comprende mil pequeñas colaboraciones. Los ingenieros de Toyota son conocidos por «preguntar por qué cinco veces» para seguir una cadena de causas y efectos hasta la raíz del problema. Este no es un tópico insípido de pensar profundamente. Al contrario, de hecho. El mérito del precepto radica precisamente en su superficialidad. Decir que B causa A es simplista: todas las complejidades de las interacciones múltiples se reducen a una única causa y efecto. Pero la cadena de pensamiento necesaria para descubrir que C causa B, y D causa C, te lleva rápidamente a un nuevo dominio, probablemente de otra persona, así que en lugar de idear soluciones complejas dentro de sus propios dominios, los ingenieros deben buscar soluciones simples más allá de ellas. «Hacer tus porques-porqués», como se conoce a la práctica, no tiene nada que ver con la profundidad, sino con la amplitud.

Y al igual que con Linux, los protocolos de comunicación de Toyota refuerzan 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 formato estándar en una sola hoja de papel A3. Y todo el mundo aprende a elaborar estos informes, hasta el pliegue del 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 fundamentales. Instruyen a los miembros de la comunidad, a menudo por ejemplo, en las disciplinas que acabamos de describir. 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 al día. Fujio Cho, presidente de Toyota, logra mediante numerosas interacciones diarias similares que trascienden la cadena de mando normal.

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

En las comunidades Linux y Toyota, el liderazgo no se trata como una disciplina distinta de hacer. Más bien, la autoridad de los líderes deriva de su competencia como practicantes.

Ocasionalmente, los líderes tienen que llevar a cabo actos de liderazgo tradicionales, como arbitraje de conflictos. Sin embargo, esa es la excepción y se considera como una falla del sistema. La suposición por defecto es que, en la medida de lo posible, los gerentes no gestionan en el sentido tradicional: la red humana se administra sola. En Linux, las prioridades de desarrollo no las decide un CEO sino miles de hackers que votan con sus pies eligiendo en qué trabajar. Ese tipo de autogestión radical no ocurre en Toyota, excepto en casos de emergencia. 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 una amplia libertad para aprovechar los recursos, tomar decisiones de compra y perseguir las prioridades que se fijan por sí mismos.

Creación de redes humanas vibrantes

Las empresas que sientan las bases para una colaboración de alto rendimiento deben seguir estos principios:

Implemente tecnología colaborativa generalizada.

Manténgalo sencillo y abierto: «piezas pequeñas unidas libremente», en Manifiesto Cluetrain frase feliz del coautor David Weinberger. Las herramientas deben funcionar juntas a través de estándares comunes y ser lo más compatibles posible con las del resto del mundo. Piense en opciones, no en integración, en adaptabilidad, en eficiencia estática

Mantén el trabajo visible.

A menos que haya una buena razón para no hacerlo, deja que todos vean el trabajo real de todos. Deja que la gente aprenda a filtrar y ordenar por sí misma. No abstraer, resumir ni canalizar. El forraje está bueno. Ponlo al alcance de todos.

Construye comunidades de confianza.

Cuando las personas confían mutuamente, es más probable que colaboren libre y productivamente. Cuando las personas confían en sus organizaciones, es más probable que se entreguen a sí mismas ahora en previsión de una recompensa futura. Y cuando las organizaciones confían entre sí, es más probable que compartan la propiedad intelectual sin ahogarse con los legalismos.

Piensa de forma modular.

La reingeniería consistía en pensar de forma lineal: gestionar el proceso de extremo a extremo en lugar de las funciones discretas. Este enfoque fomenta la eficiencia focalizada pero inhibe la variedad y la adaptabilidad. La modularidad es lo contrario: sacrificar la eficiencia estática por el valor recombinante de las opciones. Piense tanto en equipos modulares como en procesos. Cuanto más, mejor.

Fomente el equipo.

Celebra los sacrificios que los equipos hacen por la empresa en general, incluidos clientes y proveedores. Desmantele las métricas de rendimiento individualizadas y las recompensas que enfrentan a las personas entre sí. Entre los muchos, las transacciones baratas alimentan más la innovación que los costosos incentivos dirigidos a unos pocos. Recompensa al grupo y el grupo te recompensará.

En conjunto, estos tres principios siembran un sistema que se adapta continuamente. Una y otra vez, las ideas se formulan en paquetes ajustados y comprobables; se comunican con una atenuación mínima a través de conexiones establecidas, directas y de persona a persona; y cuando no hay enlaces, los líderes practicantes ampliamente conectados las crean según sea necesario. Esto es disciplina, pero no la disciplina de conformidad producida por los controles e 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, reglas comunes para la comunicación y las pruebas y objetivos comunes que se entienden claramente. El comportamiento individual es rigurosamente cauteloso, pero el logro colectivo se caracteriza por una innovación continua y radical.

Qué saben y cómo lo saben

En el corazón de Linux y del Sistema de Producción Toyota, 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 disponibles universalmente para trasladar el conocimiento.

Propiedad intelectual común.

La Licencia Pública General bajo la que se publica Linux exige que todos los distribuidores pongan su código fuente a disposición de forma gratuita para que otros puedan modificarlo libremente. Este principio viral evita que el código se guarde 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 fallas y añade funciones para su propio beneficio, y luego comparte esas mejoras con todos los demás. Esta función es imposible cuando el código de propiedad se licencia de 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 de los procesos se comparte. Esto rompe algunas distinciones entre empresas. Los proveedores de Toyota comparten regularmente amplias lecciones de mejora de procesos tanto vertical como lateralmente, incluso con sus competidores. En Japón, los proveedores suelen ser exclusivos de un solo OEM, por lo que el beneficio colectivo de esa información compartida se mantiene dentro de la cadena de suministro de Toyota. Pero incluso en los Estados Unidos, donde Toyota es solo uno de los varios clientes de la mayoría de sus niveles, el fabricante de automóviles hace lo mismo a través de su Asociación de Fabricantes de Automoción de Bluegrass, que difunde las mejores prácticas a todos los miembros.

Tecnología simple y omnipresente.

Aunque la información es el elemento vital 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 ListServi, pero todos usan esas herramientas mundanas. De hecho, tan grande es el valor que se le da a la universalidad que los correos electrónicos de texto sin formato, en lugar de con formato, son la norma, lo que garantiza que los mensajes aparezcan exactamente iguales para todos los destinatarios. Toyota, cuyos productos también son de última generación, también prefiere una tecnología interna simple y omnipresente. Un contenedor kanban vacío indica la necesidad de reponer las piezas; un trozo de cinta adhesiva en el piso de la línea de montaje permite el tiempo 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, director 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 un área de servicio en cualquier parte de Norteamérica.

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 de forma modular, una motivación extraordinaria y altos niveles de confianza.

Conocimiento semántico enriquecido.

Una disciplina laboral rigurosa, una propiedad intelectual común y un intercambio constante se combinan para distribuir el conocimiento de manera amplia y relativamente uniforme entre las redes humanas. Ese conocimiento incluye no solo la información sintáctica formal que se encuentra en las bases de datos, sino también el conocimiento ambiguo y semánticamente rico sobre contenido y proceso que es la moneda de la colaboración creativa. ¿Qué queremos decir con el brillo de un estampado corporal que no tiene suficiente brillo? ¿Qué debemos discutir precisamente con la empresa siderúrgica para corregir un problema tan mal definido? Este tipo de pregunta sin respuesta fácil se discute y resuelve continuamente en mil colaboraciones de equipos pequeños. El pensamiento matizado resultante y un vocabulario común más rico sobre tales asuntos se vuelven a introducir en el fondo de conocimientos, donde están disponibles para que toda la comunidad los perfeccione aún más.

Teaming modular.

La modularidad es un principio de diseño mediante el cual un proceso o producto complejo se divide en partes 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 realizar múltiples experimentos paralelos, haciendo muchas apuestas pequeñas en lugar de unas cuantas grandes. Los proveedores de Toyota se organizaron de esta manera para fabricar válvulas P, operando en parte por dirección pero principalmente ofreciéndose como voluntarios para hacer lo que cada uno sabía mejor. El grupo Gentoo, los expertos en seguridad de Tridge y el círculo de ex alumnos de rsync de Pool eran módulos preexistentes y superpuestos que mezclaban y combinaban roles según lo requiriera la emergencia.

Cuando mapeamos los patrones de colaboración diaria en todo el esfuerzo de desarrollo del kernel de Linux, descubrimos que tales arreglos modulares son omnipresentes y, hasta cierto punto, encajan entre sí. Esto crea una especie de organigrama dinámico, un gráfico que nadie escribió sino que permite a la comunidad expandirse y adaptarse sin caer 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. Los psicólogos han encontrado consistentemente que las zanahorias monetarias y los palos de responsabilidad motivan a las personas a realizar tareas estrechas y específicas, pero generalmente desalientan a las personas a ir más allá de ellas. La admiración y el aplauso son estimulantes mucho más efectivos del comportamiento que va más allá. «La reputación personal del desarrollador está ligada a cada lanzamiento», explicó Linus Torvalds al columnista de tecnología Robert Cringely en 1998. «Si estás creando algo para regalar al mundo, algo que representa para millones de usuarios tu filosofía informática, siempre lo convertirás en el mejor producto posible».

Las zanahorias monetarias y los bastones de responsabilidad motivan a las personas a realizar tareas estrechas y específicas. La admiración y el aplauso son estimulantes mucho más efectivos del comportamiento que va más allá.

Los psicólogos también destacan 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 dijo que su trabajo de código abierto es el esfuerzo más valioso y creativo de 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 contrapartes 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 sus compañeros. 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. Ese mismo orgullo lo siente un trabajador junior de la línea de ensamblaje cuando sus compañeros confían en él para experimentar con mejoras de procesos y para 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, lo cual es difícil pero no hostil, los trabajadores saben que su reputación está en riesgo y eso sirve como garante de un buen comportamiento, el equivalente a los contratos en un mercado o a las auditorías jerárquicas. De ahí la obsesión de la comunidad de Linux por reconocer las 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 las personas actúen de manera oportunista. Con la misma información disponible para todos, hay menos posibilidades de que una parte explote la ignorancia de otra. Y con un vocabulario y una forma de trabajar comunes, se producen menos malentendidos. Esos factores generan confianza, capital social fundamental de estas comunidades.

La confianza importaría menos si no hubiera costo alguno 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 de Linux como en la Toyota, la entrada al círculo íntimo es un privilegio que tanto se ha ganado con esfuerzo, y ambas operan en muchas pequeñas bolsas.

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 se deriva de controlar o negociar el flujo de información y, a menudo, por lo tanto, de restringirlo. Sin embargo, en una red densa, la información simplemente fluye alrededor del posible estrangulador. En esas circunstancias, hay más poder en ser una fuente de información que en un sumidero de información. En consecuencia, los individuos están motivados a maximizar tanto la visibilidad de su trabajo como sus conexiones con aquellos que están ampliamente conectados. Esto, a su vez, alimenta la densidad de información de la red.

Transacciones baratas y muchas de ellas

Hasta el momento hemos estado discutiendo 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 más y menos transacciones, tanto internas como externas, y así aumentar el ritmo y la flexibilidad típicos de las organizaciones de alto rendimiento.

Explotación de los descuidados 80%

El principio de Pareto dicta que las empresas obtienen el 80% de su valor de solo el 20% de sus productos, clientes o ideas. Debido a los altos costos de transacción, no se puede explorar la larga cola de esa curva (el 80% de los generadores de valor inciertos). Así que en nombre del enfoque de la empresa, la cola se corta, se segmenta o se rediseña para que desaparezca. Las innovaciones potencialmente rentables mueren con ello.

Las organizaciones que reducen los costos de transacción pueden aceptar el 80% rechazado. Pueden responder a las señales débiles del mercado, aprovechar segmentos pequeños y experimentar con combinaciones de tecnologías poco probables. Pueden hacer cien apuestas pequeñas en lugar de unas cuantas grandes.

Por ejemplo, Detroit consideraba que los vehículos híbridos eran un producto intermedio poco interesante: los ejecutivos de automóviles estadounidenses prefirieron una investigación hasta el momento incompleta sobre la tecnología de pilas de combustible. Mientras tanto, Toyota estaba construyendo el Prius. El híbrido se encuentra ahora en su segunda generación y Toyota espera vender 300.000 en todo el mundo este año. Los bajos costos de transacción de Toyota y su inclinación por las colaboraciones a pequeña escala le ayudaron a mantener abiertas 80 opciones discretas para el motor híbrido hasta solo seis meses antes de entregar el diseño final. Los fabricantes de automóviles convencionales habrían tenido que congelar esas variables de diseño al menos dos años antes.

Es en los intersticios de la red humana, en lugar de en la mente de unos pocos wunderkinder, donde nacen la mayoría de las innovaciones reales. Por lo tanto, son los costos de transacción los que limitan la innovación al limitar las oportunidades de compartir ideas, habilidades y prejuicios diferentes y contradictorios.

«La gente de Detroit tiene mucho más talento que la gente de Toyota», comenta el presidente de Toyota, Fujio Cho, con excesiva modestia. «Pero tomamos a personas con talento promedio y las hacemos trabajar como equipos espectaculares». En otras palabras, la red es la innovadora.

Las fuentes clásicas de los costos de transacción son la vulnerabilidad mutua frente a la incertidumbre, los intereses contradictorios y el acceso desigual a la información. Gastamos dinero en efectivo 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 economizar en ellos, como han argumentado Ronald Coase y Oliver Williamson). Utilizando una metodología desarrollada por J.J. Wallis y Douglass North, calculamos que en el año 2000, los costos de las transacciones en efectivo representaron por sí solos más de la mitad del PIB estadounidense no gubernamental. Gastamos más dinero negociando y ejecutando transacciones que en cumplirlas.

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

Lo nuevo es cuán amplia puede extenderse la confianza, incluso a las personas que no se conocen, o incluso entre aquellos que tienen intereses contrapuestos. Aisin confió en sus proveedores rivales los planos de las válvulas P. Los hackers de rsync intercambiaron información confidencial con personas que nunca habían conocido. Los proveedores de componentes de Toyota comparten diariamente conocimientos sobre los procesos, confiando en que Toyota no lo utilizará para batir los precios. Los hackers de Linux confían unos en otros para hacer modificaciones descoordinadas y simultáneas en el código base.

Además, la tenencia de bienes en común, ya que 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 acercan a cero. Hewlett-Packard pagó a Martin Pool para ser ingeniero de Linux, pero no se dedujó que a HP se le deba pagar al margen por las labores nocturnas de Pool en rsync. En la comunidad Toyota, los costos de transacción, aunque no son cero, se han reducido radicalmente. Cuando la planta de Aisin Seiki fue destruida, Toyota y sus proveedores no se demandaron ni improvisaron contratos de suministro de emergencia. Simplemente siguieron adelante con el trabajo, 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 primer nivel son apenas 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 autoorganizada crea las condiciones para una 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, lo que crea una red autoorganizada y que se profundiza acumulativamente.

Dar crédito donde se debe el crédito

La comunidad Linux utiliza un formato concreto, un «archivo de crédito», para reconocer las contribuciones de sus miembros. Si, por ejemplo, reconociéramos en el formato Linux las contribuciones de personas que ayudaron a dar forma a nuestra forma de pensar para este artículo, así es como se vería:

En: Mark Blaxill

e: blaxill.mark@bcg.com

d: Exploración de la economía del código abierto

s: Boston Consulting Group

En: Paul Carlile

e: carlile@bu.edu

d: Discusión de paralelos Linux/Toyota

s: Universidad de Boston

En: Karim Lakhani

e: lakhani@mit.edu

d: Discusión de paralelos Linux/Toyota

d: Encuesta de hackers de código abierto y gratuito

s: MIT

Una vez que el sistema alcanza la masa crítica, se alimenta de sí mismo. Cuanto mayor sea el sistema, más ampliamente se compartirán los conocimientos, 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 prueba del poder de ese círculo virtuoso. El éxito de Toyota es una prueba de que también es potente en 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 manera semejante 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 solo en equipos pequeños sino también en comunidades muy grandes.
• En todas las cadenas de suministro, las organizaciones que pueden sustituir la confianza por los contratos ganan más con 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 incentivos monetarios elevados.

Estos principios atienden las necesidades de crecimiento e innovación de las empresas de una manera que los modelos organizacionales tradicionales no lo hacen. Y tal vez la eficacia de estas colaboraciones sugiera el surgimiento definitivo de algo totalmente nuevo. No mercados. No jerarquías. Pero una poderosa combinación de ambas cosas y una firma de la sociedad en red.

— Escrito por Philip Evans Philip Evans Bob Wolf