Reglas de colaboración

Los líderes corporativos que buscan crecer, aprender e innovar pueden encontrar la respuesta en un lugar sorprendente: la comunidad del software de código abierto. Sin saberlo, quizás, los que le crearon Linux son virtuosos practicantes de nuevos principios de trabajo que producen equipos con energía y reducen los costes. Tampoco están solos. Desde cualquier punto de vista, Linux es un producto muy competitivo. Se estima que más servidores funcionan 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, hasta la velocidad con la que se mejora y mejora. Mientras los partisanos debaten sobre 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 de producción distintivo. En concreto, 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 una fuerza laboral que colaborara de manera tan eficiente, sin problemas y 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 que se sitúe constantemente entre las organizaciones con mejor desempeño del mundo. El fabricante de automóviles lleva mucho tiempo siendo líder en producción eficiente y de calidad, y el éxito del Prius híbrido le ha consolidado su reputación como innovador. Hemos descubierto que los métodos de gestión de Toyota se parecen, en varios de sus aspectos fundamentales, al funcionamiento de la comunidad Linux; el Sistema de Producción de Toyota (TPS) debe parte de su tan cacareada capacidad de respuesta a las características del 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 la de Linux. (A lo largo de este artículo, utilizamos el término «Linux» como forma abreviada de referirse a la comunidad de software libre/de código abierto que desarrolló y sigue perfeccionando el sistema operativo y otros programas de código abierto. Usamos «Toyota» como forma abreviada del Sistema de Producción de Toyota, que incluye a Toyota y sus proveedores directos («primer nivel» en el lenguaje automotriz) en Japón y los Estados Unidos.) Toyota se parece notablemente a Linux en la forma en que combina las características clave de los mercados y las jerarquías. Al igual que los mercados, las comunidades de Toyota y Linux pueden autoorganizarse, pero a diferencia de los mercados, no utilizan efectivo ni contratos en momentos críticos. Al igual que las jerarquías, Toyota y Linux disfrutan de costes de transacción bajos, 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. Y al igual que las jerarquías, los miembros comparten un propósito común, pero ese propósito emana de la automotivación y no de los incentivos o sanciones externos que las jerarquías suelen imponer. 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 ingeniosas incluso en condiciones agotadoras. 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 medianoche, Andrea Barisani, administradora de sistemas del departamento de física de la Universidad de Trieste, descubrió que un atacante había atacado el servidor Gentoo Linux de su institución. Rastreó la violación hasta un punto vulnerable del núcleo de Linux y otro de rsync, un mecanismo de transferencia de archivos que replica automáticamente los datos entre los ordenadores. Fue un ataque grave: cualquier penetración de rsync podría comprometer los archivos de miles de servidores de todo el mundo. Barisani despertó a algunos colegas, quienes lo pusieron en contacto con Mike Warfield, investigador sénior de Sistemas de Seguridad de Internet 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 (hecho anónimo por motivos 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 acudió al teléfono y al correo electrónico. Primero interrogó a Warfield y a Dave Dykstra (otro de los primeros colaboradores del desarrollo de rsync, que vivía en California) sobre 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 de rsync, mientras que Barisani se dio cuenta de la débil 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 canberrano que trabaja para IBM) se esforzaron entonces durante la noche australiana para escribir un parche y, en cinco horas, los desarrolladores de usuarios de Gentoo empezaron a probar la primera versión. Mientras tanto, Tridge elaboró una descripción de la vulnerabilidad y su solución, y se aseguró (a instancias de Pool) de dar crédito 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, tras recuperar el sueño, Barisani se ofreció como voluntario para colaborar con Warfield en la creación de un sistema de servidores deliberadamente vulnerables para atraer al descifrador del sistema para que se revelara. Nadie autorizó ni dirigió este esfuerzo. A nadie, aficionado o profesional, se le pagó por participar ni se le habría sancionado por no hacerlo. El trabajo de nadie consistía en detener el ataque. Nadie se puso manos a la obra por miedo a la responsabilidad legal. De hecho, la comunidad de usuarios en general estaba informada de todas las novedades. Sin embargo, a pesar de la necesidad de la máxima seguridad, un grupo de unas 20 personas, de las que casi ninguna se había conocido, empleadas en una docena de empresas diferentes, que vivían en otras zonas horarias y se alejaban de las descripciones de sus puestos, lograron en unas 29 horas lo que los colegas de cubículos adyacentes podrían haber llevado semanas o meses. Es tentador descartarlo como un ejemplo de rareza de un hacker; admirable, sí, pero nada que ver con los negocios reales. Sin embargo, considere 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 piezas de automóviles. En cuestión de minutos, el edificio y prácticamente toda la maquinaria especializada que había en su interior quedaron destruidos. El número 1 de Kariya produce el 99% del líquido de frenos (válvulas dosificadoras o válvulas P, para las operaciones de Toyota en Japón), piezas que se necesitan en todos los vehículos que fabrica Toyota. 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 de Toyota se enfrentaba a la posibilidad de un cierre total que durara 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 accedió a improvisar la mayor cantidad de producción posible. A medida que la noticia se difundió por la red de proveedores, algunos de segundo nivel se ofrecieron como voluntarios para desempeñar funciones de liderazgo. Aisin envió los planos de las válvulas a cualquier proveedor que los solicitara y distribuyó todas las herramientas, materias primas y piezas en proceso intactas que pudieran rescatarse. Los ingenieros de Aisin y Toyota ayudaron al jurado a montar líneas de producción en 62 ubicaciones: talleres de máquinas en desuso, el propio taller de prototipos de Toyota e incluso una planta 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 las válvulas a Aisin para su inspección y, luego, a las estancadas líneas de montaje de Toyota. Todo el mundo se sorprendió cuando un pequeño proveedor de electrodos de soldadura de segundo nivel, Kyoritsu Sangyo, fue el primero en entregar válvulas con calidad de producción a Toyota, 1000 de ellas, solo 85 horas después del incendio. Otros lo siguieron rápidamente y Toyota empezó 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 estar en plena producción. Seis meses después, Aisin distribuyó una guía de respuesta a emergencias que contenía las lecciones extraídas de la experiencia y recomendaba procedimientos para responder a este tipo de situaciones en el futuro. Ninguna persona u organización planificó este esfuerzo: más bien, las personas y las empresas intervinieron siempre que pudieron. Los competidores colaboraron. A nadie en ese momento se le pagó 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 en función de las ventas actuales al fabricante de automóviles, lo que lo alentó, pero no exigió, a hacer lo mismo con sus propios proveedores de nivel dos. Pocas comunidades parecen más diferentes que el mundo anarquista, hirsuto y con cafeína de los hackers y el mundo disciplinado, limpio y bebedor de té de la ingeniería automotriz japonesa. Pero los paralelismos entre estas historias son sorprendentes. En ambas, las personas se encontraron y asumieron funciones sin un plan ni una estructura de mando y control establecida. Una red humana extendida se organizó en horas y se «agrupó» contra una amenaza. Las personas, los equipos y las empresas trabajaban juntos sin contratos legales ni pagos negociados. Y a pesar de la falta de un palo autoritario o zanahoria financiera, esas personas trabajaban como el infierno para resolver el problema. Pocas comunidades parecen más diferentes que el mundo anarquista, hirsuto y con cafeína de los hackers y el mundo disciplinado, limpio y bebedor de té de la ingeniería automotriz japonesa. Bien, obviamente, 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 no fueron más que una intensificación 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 centro de las comunidades de Linux y Toyota hay reglas sobre tres cosas completamente diferentes: cómo las personas y los grupos pequeños trabajan juntos; 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. Tanto las comunidades de Linux como las de 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 tienen un enfoque de trabajo mucho más disciplinado y riguroso que otras comunidades de ingenieros. Ambos hacen hincapié en la granularidad: prestan atención a los pequeños detalles, eliminan los problemas en su origen y recortan cualquier cosa que parezca excesiva, ya sea obra, código o material. Los miembros de Linux, por ejemplo, comparten la obsesión por escribir un código mínimo, compilar los resultados de cada día antes de pasar al siguiente y eliminar los defectos de programación a medida que avanzan. Por su parte, los ingenieros de TPS son implacables a la hora de aplicar ciclos cortos de prueba y error, centrarse en una sola cosa a la vez y entrar y observar los procesos reales. Ambos grupos llevan esos principios a extremos aparentes. Los programadores de Linux reducen el código en busca no de la eficiencia computacional sino de la elegancia. Los ingenieros de Toyota rechazan los estampados para el capó del Lexus, aunque son impecables y cumplen totalmente con las especificaciones, porque el brillo, a sus ojos, carece de brillo. Comunicación granular y generalizada. En las comunidades de Linux y Toyota, la información sobre los problemas y las soluciones se comparte ampliamente, con frecuencia y en pequeños incrementos. La mayoría de las comunicaciones de los hackers de Linux no son entre personas, sino mediante publicaciones en servidores de listas abiertos y con capacidad de búsqueda. Cualquiera puede revisar el historial de versiones del código y los debates sobre el servidor de listas, no los resúmenes ejecutivos o los resúmenes, sino la propia actividad sin procesar. Y cada contribución al código es puesta a prueba por decenas de personas. Como dice una famosa metáfora mixta de código abierto: «Con mil ojos, todos los bichos son superficiales». La carga media al núcleo de Linux es de tan solo una docena de líneas de código. La versión alfa funcional se vuelve a compilar cada 24 horas, por lo que los hackers concilian sus esfuerzos casi de forma continua. Si alguien trabajara de forma aislada durante seis meses incluso en la contribución más brillante, probablemente la rechazarían por falta de compatibilidad con los esfuerzos de los demás. La filosofía de mejora continua de Toyota también incluye mil pequeñas colaboraciones. Los ingenieros de Toyota son famosos por «preguntar por qué cinco veces» para seguir una cadena de causas y efectos hasta la raíz del problema. No es un tópico insípido lo de pensar profundamente. De hecho, todo lo contrario. El mérito del precepto reside precisamente en su superficialidad. Decir que B causa A es simplista: todas las complejidades de las interacciones múltiples se reducen a una sola causa y efecto. Pero la cadena de pensamiento necesaria para descubrir que C causa B y D provoca C, lo lleva rápidamente a un nuevo dominio, probablemente el 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 sus porqués y por qué», 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 imponen esta disciplina. Cada reunión aborda un solo tema y apunta a un resultado específico, aunque eso signifique que las mismas personas se reúnan más de una vez al día. Las clases están escritas 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. Los líderes como conectores. En todos los niveles, los líderes de Linux y TPS desempeñan tres funciones fundamentales. Enseñan a los miembros de la comunidad —a menudo con el 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 las personas, por el mérito de estar muy bien conectados entre sí. Los principales programadores de Linux procesan más de 300 o 400 correos electrónicos al día. Fujio Cho, el presidente de Toyota, se las arregla mediante numerosas interacciones diarias similares que trascienden la cadena de mando normal. Ninguna de las dos comunidades trata el liderazgo como una disciplina distinta del hacer. Más bien, la credibilidad y, por lo tanto, la autoridad de los líderes se derivan de su competencia como profesionales. El contenido de las comunicaciones staccato de los líderes es menor acerca de trabajar que es trabajo. (Cuando el creador de Linux Linus Torvalds publica sus decenas de correos electrónicos diarios, escribe casi tanto en el lenguaje de programación C como en inglés.) En las comunidades de Linux y Toyota, liderar no se trata como una disciplina distinta de hacer. Más bien, la autoridad de los líderes se deriva de su competencia como profesionales. De vez en cuando, los líderes tienen que realizar actos de liderazgo tradicionales, como arbitrar conflictos. Sin embargo, esa es la excepción y se considera un pequeño fallo 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 gestiona sola. En Linux, las prioridades de desarrollo las decide no el CEO sino miles de hackers que votan con los pies para elegir en qué trabajar. Ese tipo de autogestión radical no ocurre en Toyota, excepto en caso 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 un amplio margen de maniobra para aprovechar los recursos, tomar decisiones de compra y perseguir las prioridades que se propongan. Construir redes humanas vibrantes Las empresas que sientan las bases para una colaboración de alto rendimiento deben seguir estos principios: Implemente una tecnología colaborativa generalizada. Manténgalo simple y abierto: «piezas pequeñas unidas holgadamente», en Manifiesto Cluetrain La feliz frase del coautor David Weinberger. Las herramientas deben funcionar juntas mediante estándares comunes y ser lo más compatibles posible con las del resto del mundo. Piense en las opciones, no en la integración, en la adaptabilidad, no en la eficiencia estática. Mantenga el trabajo visible. A menos que haya una buena razón para no hacerlo, dejar que todos vean el verdadero trabajo de todos. Deje que las personas aprendan a filtrar y clasificar por sí mismas. No resuma, resuma ni canalice. El forraje es bueno. Ponlo al alcance de todos. Cree comunidades de confianza. Cuando las personas confían unas en otras, es más probable que colaboren de forma libre y productiva. Cuando las personas confían en sus organizaciones, es más probable que den de sí mismas ahora en previsión de recompensas futuras. Y cuando las organizaciones confían unas en otras, es más probable que compartan la propiedad intelectual sin ahogarse con los legalismos. Piense de forma modular. La reingeniería consistía en pensar de forma lineal: gestionar el proceso de principio a fin en lugar de las funciones discretas. Ese enfoque fomenta la eficiencia centrada, 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 fino, mejor. Fomente el trabajo en equipo. Celebre los sacrificios que los equipos hacen por la empresa en general, incluidos los clientes y los proveedores. Elimine las métricas de rendimiento y las recompensas individualizadas que enfrentan a las personas unas contra otras. Las transacciones baratas entre los muchos impulsan más la innovación que los caros incentivos dirigidos a unos pocos. Recompense al grupo y el grupo lo recompensará a usted. En conjunto, estos tres principios generan 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 y directas de persona a persona; y cuando no hay enlaces, los líderes más conectados los crean según es necesario. Esto es disciplina, pero no la disciplina de la conformidad producida por los controles e incentivos. Más bien, se parece a la disciplina de la ciencia. Al igual que las comunidades científicas, estos sistemas se basan en procedimientos comunes, reglas comunes de comunicación y pruebas y objetivos comunes que se entienden con claridad. El comportamiento individual es rigurosamente cauteloso, pero los logros colectivos se caracterizan por una innovación continua y radical. Lo que saben y cómo lo saben Por lo tanto, en el centro de Linux y el Sistema de Producción de 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 de conocimientos compartido y herramientas disponibles en todo el mundo para difundir el conocimiento. Propiedad intelectual común. La licencia pública general con la que se publica Linux exige que todos los distribuidores pongan su código fuente a disposición gratuita para que otros puedan cambiarlo libremente. Este principio viral impide 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 desarrollador de usuarios, que corrige los defectos y añade funciones para su propio beneficio, y luego comparte esas mejoras con todos los demás. Esa función es imposible cuando el código propietario tiene una 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 plano) es propiedad intelectual de una persona, el conocimiento del proceso se comparte. Eso desglosa algunas distinciones entre las empresas. Los proveedores de Toyota comparten con regularidad amplias lecciones sobre la mejora de los 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 queda 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 la Asociación de Fabricantes de Automóviles de Bluegrass, que difunde las mejores prácticas entre todos los miembros. Tecnología simple y omnipresente. Aunque la información es el elemento vital de las comunidades de Linux y TPS, sus sistemas de circulación son sorprendentemente rudimentarios. Los desarrolladores de Linux producen software de última generación utilizando una tecnología de comunicación no más sofisticada que el correo electrónico y los servidores de listas, pero todo el mundo utiliza esas herramientas mundanas. De hecho, el valor que se da a la universalidad es tan grande que los correos electrónicos de texto sin formato, en lugar de formateados, son la norma, lo que garantiza que los mensajes aparezcan exactamente igual para todos los destinatarios. Toyota, cuyos productos también son de última generación, también prefiere una tecnología interna simple y generalizada. Una papelera kanban vacía indica la necesidad de reponer las piezas; un trozo de cinta adhesiva en el suelo de la línea de montaje indica 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 televisión. Y todo el mundo recibe la alerta. Incluso Ray Tanguay, director de Toyota Canadá, recibe llamadas 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 de cualquier parte de Norteamérica. El poder de la confianza y los aplausos Estas colaboraciones tan ricas y flexibles tienen consecuencias psicológicas positivas para los participantes y poderosas consecuencias competitivas para sus organizaciones. Esas consecuencias son un rico conocimiento común, la capacidad de organizar los equipos de forma modular, una motivación extraordinaria y altos niveles de confianza. Amplios conocimientos semánticos. Una disciplina de trabajo rigurosa, una propiedad intelectual común y un intercambio constante se combinan para distribuir el conocimiento de manera amplia y relativamente uniforme en las redes humanas. Ese conocimiento incluye no solo la información formal y sintáctica que se encuentra en las bases de datos, sino también el conocimiento ambiguo y semánticamente rico sobre el contenido y el proceso que es la moneda de cambio de la colaboración creativa. ¿Qué queremos decir con el brillo de una carrocería que no tiene suficiente brillo? ¿Qué debemos discutir exactamente con la empresa siderúrgica para corregir un problema tan mal definido? Este tipo de preguntas que no son fáciles de responder se discuten y resuelven continuamente en mil colaboraciones en equipos pequeños. El pensamiento matizado resultante y el vocabulario común más rico sobre estos temas se reflejan en la base de conocimientos, donde están disponibles para que toda la comunidad los perfeccione aún más. Formación de equipos modulares. La modularidad es un principio de diseño mediante el cual un proceso o producto complejo se divide en partes simples conectadas por normas estándar. En las disposiciones modulares de 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 varios experimentos paralelos y hacer muchas apuestas pequeñas en lugar de unas cuantas grandes. Los proveedores de Toyota se organizaron de esta manera para fabricar válvulas en P, que funcionaban en parte por dirección, pero principalmente ofreciéndose como voluntarios para hacer lo que cada uno sabía mejor. El grupo de Gentoo, los expertos en seguridad de Tridge y el círculo de exalumnos de rsync de Pool eran módulos preexistentes y superpuestos que mezclaban y combinaban funciones según las necesidades de emergencia. Cuando mapeamos los patrones de colaboración diaria a lo largo de todo el esfuerzo de desarrollo del núcleo de Linux, descubrimos que estos arreglos modulares son generalizados y, hasta cierto punto, encajan unos dentro de otros. Esto crea una especie de organigrama dinámico, un diagrama que nadie ha escrito, pero que permite a la comunidad expandirse y adaptarse sin caer en el caos. Motivación intrínseca. Las comunidades de Linux y TPS disocian el dinero de las transacciones clave. Sin embargo, a pesar de la debilidad de los incentivos financieros, tienen un nivel de motivación superior al que se encuentra en los entornos convencionales. Los psicólogos han descubierto constantemente que las zanahorias monetarias y los bastones de responsabilidad motivan a las personas a realizar tareas limitadas y específicas, pero en general desalientan a las personas a ir más allá de ellas. La admiración y los aplausos son estimulantes mucho más eficaces de un 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á creando algo para regalar al mundo, algo que represente ante millones de usuarios su filosofía de la informática, siempre lo convertirá en el mejor producto que pueda». Las zanahorias monetarias y las normas de responsabilidad motivan a las personas a realizar tareas limitadas y específicas. La admiración y los aplausos son estimulantes mucho más eficaces de un comportamiento que va más allá. Los psicólogos también hacen hincapié en 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 la defina el departamento de marketing ni los contadores, sino 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 de su vida profesional. El sistema de producción de Toyota no ofrece una autonomía tan extrema, por supuesto, y los empleados no trabajan gratis. Sin embargo, en comparación con sus homólogos del resto de la industria automotriz, los trabajadores del TPS disfrutan de menos controles, de un mayor fomento de la iniciativa individual, de menos indicadores relacionados con el rendimiento individual y de los aplausos de los compañeros más fuertes. El orgullo profesional y empresarial, no los honorarios de Toyota, fue la payoff para el equipo de Kyoritsu Sangyo cuando entregó el primer lote de válvulas P. Un trabajador subalterno de una línea de montaje siente el mismo orgullo cuando sus compañeros confían en él para experimentar con mejoras en los procesos 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. Al operar bajo un escrutinio constante (lo cual es un desafío pero no hostil), los trabajadores saben que su reputación está en riesgo y eso sirve como garantía de un buen comportamiento, el equivalente a contratos en un mercado o auditorías jerárquicas. De ahí la obsesión de la comunidad Linux por reconocer las contribuciones al código e incluir direcciones de correo electrónico personales en los campos de comentarios de los servidores de listas. 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 aproveche la ignorancia de la otra. Y con un vocabulario y una forma de trabajar comunes, se producen menos malentendidos. Esos factores aumentan la confianza, el capital social fundamental de estas comunidades. La confianza importaría menos si salir de estas redes no tuviera ningún coste o si las transacciones fueran de tamaños radicalmente diferentes (ya que eso tentaría a las personas o a las empresas a infringir las normas cuando se presentara una gran oportunidad). Pero tanto en la comunidad de Linux como en la de Toyota, entrar en el círculo íntimo es un privilegio ganado con esfuerzo, y ambas funcionan en muchas bolsas pequeñas. Y, por supuesto, cuando 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, por lo tanto, de restringirlo. Sin embargo, en una red densa, la información simplemente fluye alrededor del posible punto de estrangulamiento. En esas circunstancias, ser una fuente de información tiene más poder que un sumidero de información. En consecuencia, las personas se motivan para maximizar tanto la visibilidad de su trabajo como sus conexiones con quienes tienen una conexión amplia. Eso, a su vez, alimenta la densidad de información de la red. Transacciones baratas y muchas de ellas Hasta ahora hemos estado discutiendo el contenido de la obra. Pero los modelos TPS y Linux también cambian la economía del trabajo, al reducir los costes de transacción. Los bajos costes de transacción permiten a las organizaciones realizar más y más pequeñas transacciones (tanto internas como externas) y, por lo tanto, aumentan el ritmo y la flexibilidad típicos de las organizaciones de alto rendimiento. Explotando el 80% descuidado El famoso 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 costes de transacción, no se puede explorar la larga cola de esa curva (ese 80% de los generadores de valores inciertos). Así que en nombre del enfoque empresarial, se corta la cola, se segmenta o se rediseña para que deje de existir. Las innovaciones potencialmente rentables mueren con ello. Las organizaciones que reducen los costes de transacción pueden aceptar el 80% rechazado. Pueden responder a las débiles señales 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 automotrices estadounidenses preferían una investigación sobre la tecnología de pilas de combustible que hasta ahora no se había realizado. Mientras tanto, Toyota fabricaba el Prius. El híbrido ya está en su segunda generación y Toyota espera vender 300 000 en todo el mundo este año. Los bajos costes de transacción de Toyota y su afició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 —más que en la mente de unos pocos niños prodigio— donde nacen la mayoría de las verdaderas innovaciones. Por lo tanto, son los costes 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 cogemos a personas con un talento medio y hacemos que trabajen como equipos espectaculares». La red, en otras palabras, es la innovadora. Las fuentes clásicas de los costes de transacción son la vulnerabilidad mutua ante la incertidumbre, los conflictos de intereses 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 conllevan costes de transacción (aunque existen jerarquías para economizarlos, 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 costes de las transacciones en efectivo por sí solos representaron más de la mitad del PIB no gubernamental de los EE. UU. Gastamos más dinero en negociar y hacer cumplir las transacciones que en su cumplimiento. En las comunidades de Linux y Toyota, los acuerdos no se hacen cumplir 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 costes de transacción. Esto no es nuevo: los equipos de personas de todo el mundo en el lugar de trabajo convencional funcionan sobre la base de la confianza. La novedad es hasta qué punto la confianza puede extenderse, incluso a las personas que no se conocen, o incluso entre personas que tienen intereses contrapuestos. Aisin confió a sus proveedores rivales los planos de la válvula P. Los hackers de rsync intercambiaban información confidencial con personas que nunca habían conocido. Los proveedores de componentes de Toyota comparten sus conocimientos sobre los procesos a diario y confían en que Toyota no los utilizará para reducir los precios. Los hackers de Linux confían unos en otros para hacer modificaciones simultáneas y descoordinadas en el código base. Además, tener una propiedad en común —ya que hay ciertos tipos de propiedad intelectual en estas comunidades— reduce las apuestas monetarias entre los copropietarios. Los costes de transacción caen porque simplemente hay menos por lo que negociar. En la comunidad Linux, los costes de transacción se acercan a cero. Hewlett-Packard pagó a Martin Pool para que fuera ingeniero de Linux, pero eso no significa que hubiera que pagar a HP al margen por las tareas nocturnas de Pool en rsync. En la comunidad de Toyota, los costes de transacción, si bien no son cero, se han reducido radicalmente. Cuando la planta de Aisin Seiki fue destruida, Toyota y sus proveedores no se demandaron mutuamente ni concertaron contratos de suministro de emergencia. Simplemente siguieron con su 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 costes de transacción entre Toyota y sus proveedores de primer nivel son solo una octava parte de los de General Motors, una disparidad que atribuye a los diferentes niveles de confianza. Un modelo para muchos Reúna todos estos elementos y tendrá 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 costes de transacción. Los bajos costes de transacción, a su vez, permiten realizar muchas transacciones pequeñas, lo que crea una red autoorganizada y que se profundiza acumulativamente. Dar crédito a quien se debe La comunidad Linux utiliza un formato determinado, la «ficha de créditos», para reconocer las contribuciones de sus miembros. Si, por ejemplo, reconociéramos en el formato Linux las contribuciones de las personas que nos ayudaron a dar forma a nuestra forma de pensar para este artículo, quedaría así: n: Mark Blaxill correo electrónico: blaxill.mark@bcg.com d: Exploración de la economía del código abierto s: Boston Consulting Group No: Paul Carlile correo electrónico: carlile@bu.edu d: Discusión sobre los paralelismos entre Linux/Toyota s: Universidad de Boston n: Karim Lakhani correo electrónico: lakhani@mit.edu d: Discusión sobre los paralelismos entre Linux/Toyota d: Encuesta sobre piratas informáticos de código abierto o gratuito s: MIT Una vez que el sistema alcanza una masa crítica, se alimenta de sí mismo. Cuanto más grande 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 las personas, más fuertes serán los aplausos y más fuerte será la motivación. El éxito de Linux es una prueba del poder de ese círculo virtuoso. El éxito de Toyota demuestra que también es poderosa en las empresas convencionales que maximizan los beneficios. La comunidad Linux y el Sistema de Producción de Toyota son sorprendentemente diferentes. El hecho de que logren tanto de formas tan similares apunta a algunos principios que otros pueden seguir. La disciplina de la ciencia se adapta sorprendentemente 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 los equipos pequeños sino también en las comunidades muy grandes. En todas las cadenas de suministro, las organizaciones que pueden sustituir los contratos por la confianza ganan más con la colaboración de lo que pierden en poder de negociación. Los bajos costes de transacción permiten más innovación que los altos incentivos monetarios. Estos principios satisfacen las necesidades de crecimiento e innovación de las empresas de formas que los modelos organizativos tradicionales no lo hacen. Y quizás la eficacia de estas colaboraciones sugiera la aparición definitiva de algo completamente nuevo. No son mercados. No jerarquías. Pero una combinación poderosa de ambas cosas y una firma de la sociedad en red.

Reglas de colaboración

Partner Center