- Al igual que el estudio según el cual, durante la Segunda Guerra Mundial, solo entre el 15% y el 20% de los soldados realmente dispararon, en las organizaciones la mayor parte de los resultados reales también la produce una minoría
- La industria tecnológica presentó la “colaboración” como solución a este problema, pero en la práctica lo que se consolidó fue una estructura donde solo aumentan las herramientas de coordinación y casi no salen entregables
- Cuanto más crece el grupo, más se disparan los costos de comunicación y de coordinación, y se repite el fenómeno de difusión de responsabilidad en el que las reuniones generan más reuniones
- La transparencia se confunde con avance, y la visibilidad se confunde con responsabilidad, de modo que la cultura de colaboración diluye la responsabilidad individual
- En la práctica, la mayor parte del trabajo complejo y de alta calidad la realizan individuos o grupos pequeños con autoridad y responsabilidad claras, y la colaboración solo funciona como el lenguaje que lo maquilla
- Lo que de verdad se necesita no es infraestructura de colaboración, sino juicio autónomo y responsabilidad personal (ownership), y las organizaciones deben cambiar hacia una dirección que confíe en ello
La ilusión llamada colaboración
- La colaboración (collaboration) suele considerarse un símbolo de productividad en las organizaciones modernas, pero en realidad funciona como una estructura de evasión de responsabilidades e ineficiencia
- Según el estudio de S.L.A. Marshall durante la Segunda Guerra Mundial, solo entre el 15% y el 20% de los soldados realmente dispararon en combate
- De forma similar al patrón que IBM encontró en los años 60, según el cual “el 80% del uso proviene del 20% de las funciones”, una minoría de integrantes produce la mayoría de los resultados
- El resto solo aporta “soporte estructural (structural support)”, y dentro de las organizaciones reaparece una y otra vez un desequilibrio en el esfuerzo
- Para resolver este problema, la industria tecnológica terminó siguiendo el concepto de “colaboración” casi como si fuera una religión
- Aparecieron innumerables herramientas de colaboración como Notion, ClickUp, Slack, Jira, Monday y Teams, pero aumentó más la actividad (activity) que el producto o resultado (output)
- La transparencia y la visibilidad se malinterpretan como si fueran avance o responsabilidad, y “estar incluido en un hilo” se equipara con “hacerse dueño del resultado”
- Como consecuencia, la colaboración se degrada en una simulación de participación más que en resultados reales
- La difusión de responsabilidad (diffusion of responsibility) es un fenómeno observado desde hace mucho tiempo
- En 1913, el efecto Ringelmann mostró que, a medida que aumenta el tamaño del grupo, disminuye la proporción de esfuerzo individual
- Frederick Brooks, a partir del caso de IBM System/360 en 1975, formuló la ley de que agregar gente a un proyecto retrasado lo retrasa aún más
- A medida que aumenta el personal, los costos de comunicación y coordinación crecen de forma exponencial, y se produce un círculo vicioso en el que las reuniones generan más reuniones
- La industria de la colaboración ha invertido enormes recursos para ocultar este problema estructural, pero el trabajo real de alta calidad lo siguen haciendo unos pocos individuos o equipos pequeños
- Dostoevsky escribió Los hermanos Karamázov solo, y la Apollo Guidance Computer fue desarrollada por un equipo pequeño del MIT bajo un sistema de responsabilidades claras
- Los logros reales surgen de autoridad clara y responsabilidad personal, y la colaboración solo opera como el lenguaje que envuelve ese resultado
- En cambio, las organizaciones modernas solo han construido una compleja infraestructura de colaboración para la gestión social (social management), mientras que el trabajo real queda relegado
- La verdadera propiedad o responsabilidad (ownership) existe cuando una persona toma decisiones por sí misma y asume las consecuencias
- Sin embargo, en un entorno donde la colaboración se ha vuelto norma cultural, tomar decisiones en solitario se considera una conducta poco colaborativa
- La ideología de la colaboración ha hecho que la responsabilidad y la iniciativa se sientan como actos antisociales, debilitando así el mecanismo central de la producción
- Reuniones, documentos, retrospectivas, kickoffs y demás se repiten sin fin, pero al final solo queda un exceso de coordinación sin conexión con la ejecución real
La necesidad de volver a la responsabilidad individual
- La mayoría de los proyectos se ha convertido en una estructura donde el tiempo de coordinación > tiempo de ejecución, y cuando fallan, la solución termina siendo “más colaboración”
- Pero la verdadera pregunta es: qué estamos construyendo realmente y quién es responsable de ello
- Para cualquier trabajo, debe haber una sola persona como responsable final, aunque la estructura colaborativa oculte su existencia
- Hace falta recuperar la confianza en el individuo
- No es necesario que toda la organización supervise cada responsabilidad
- En lugar de una cultura de gestión excesiva y obsesionada con métricas, cada persona debería gestionar su propio trabajo y ser evaluada por sus resultados
- Cuando haya fallas, debe existir una estructura que atribuya con claridad esa responsabilidad a una persona concreta
- Debemos abandonar la ilusión del esfuerzo colectivo y volver a un entorno donde se pueda identificar a quien realmente actúa
- Volver a una estructura simple en la que cada quien gestione su propio trabajo y sea evaluado por los resultados
- Cuando dejemos atrás la cálida pero costosa ficción llamada “colaboración”, podremos ver con claridad quién es realmente quien aprieta el gatillo
20 comentarios
Parece simplemente una declaración larga de "no sé colaborar". No es que nunca pase que el concepto de colaboración termine siendo un obstáculo dentro de una organización grande, pero incluso eso es un fenómeno que ocurre por no saber colaborar bien, no un problema de la colaboración en sí.
Parece que la personalidad del autor deja mucho que desear.
jajajajajajajajajajaja ay, me estallé de la risa jajaja
"Durante la Segunda Guerra Mundial, solo entre el 15% y el 20% de los soldados realmente dispararon sus armas"
Los estudios y artículos posteriores que analizaron y refutaron de frente la afirmación de Marshall sobre la "tasa de disparo del 15% al 20%" han sido tratados con bastante peso en el campo de la historia militar. A partir de la década de 1980, varios historiadores y especialistas militares rastrearon los registros de investigación de Marshall y llegaron a la conclusión de que esa cifra fue, en la práctica, fabricada o gravemente exagerada.
Robert Engen (2010) analizó encuestas y registros de combate de oficiales de infantería del ejército canadiense durante la Segunda Guerra Mundial, que combatieron en condiciones similares a las del ejército estadounidense. Demostró que la tasa real de disparo del ejército canadiense fue abrumadoramente más alta que el 15% al 20% afirmado por Marshall, y refutó su tesis señalando que era un grave error de generalización aplicarla a todas las fuerzas aliadas occidentales.
Desde el primer párrafo me pareció que había algo raro, así que lo busqué y parece que es un dato mal difundido. Lo que dicen en los comentarios de Hacker News de abajo también va en esa línea.
Opiniones de Hacker News
En mis más de 30 años haciendo este trabajo, lo que he visto es que la “fecha límite (date)” siempre se considera más importante que el entregable
En la práctica, cumplir esa fecha casi siempre es imposible, pero la organización la sigue usando como el único indicador
Casi nunca se toma en cuenta que el desarrollo de software es, por naturaleza, una actividad impredecible
Cuando apareció por primera vez el Manifiesto Ágil había esperanza, pero pronto se deformó en una gestión de “dime exactamente cuánto va a tardar cada etapa”
Que algo se retrase un poco se perdona, pero si pides más dinero te odian para siempre
Agile solo funciona bien cuando hay un buen Product Owner que tiene asegurado un presupuesto adecuado y autoridad para decidir
El equipo entrega solo lo que sea posible dentro del plazo y, conforme se acerca la fecha límite, va recortando funcionalidades
Es una forma de garantizar la entrega en sí, más que el contenido del resultado
Si la fecha es tan importante, ¿no valdría la pena probar también este enfoque?
Cuanto más pequeña es la organización, más probable es que haya partes interesadas reales, pero en las grandes organizaciones el desempeño y la carrera profesional están separados
Yo trabajo en hardware y defino mi meta de fin de año como “tener algo demostrable con código escrito directamente por mí”
Dicen “esto tomará unas semanas” y en realidad lo implementan en 30 segundos
Creo que el autor fue demasiado tajante
Tal vez tenga un trauma por haber trabajado en un equipo donde la colaboración era un desastre
Pero sin duda existen equipos bien gestionados, y un grupo puede lograr más que un individuo
Las pirámides, el kernel de Linux y AWS no los hizo una sola persona
Mientras más crece el equipo, mayor es el overhead de comunicación, y gran parte de eso viene del deseo de visibilidad de la gerencia
Los buenos equipos se comunican bien internamente, pero la gerencia también necesita cierto nivel de visibilidad
Al final, la combinación de buen equipo + buen gerente es indispensable
La mayoría de las organizaciones no colaboran bien, pero esconden ese fracaso detrás de la palabra colaboración
Aun así, la afirmación de que “solo los equipos pequeños trabajan” es exagerada
Casos como la construcción de las pirámides se parecen más a una cadena de mando estricta que a la colaboración en el sentido moderno
El programa de computadoras del Apolo lo hizo un equipo pequeño, pero para llegar a la Luna hizo falta mucha más cooperación
Hay demasiada evidencia de que la colaboración sí funciona en la práctica
Una sola persona no puede hacer una superproducción como Assassin’s Creed, y un comité no puede hacer un juego como Stardew Valley
Son capacidades de naturaleza distinta
Yo también me identifico con la experiencia del autor
Después de que me despidieran de una startup, me fui a una gran empresa, y al principio el trabajo en equipo funcionaba bien y rendíamos mucho
Pero luego apareció un coach Agile y empezó a empujar su propia agenda con la “colaboración” como pretexto
Durante 8 meses siguieron talleres inútiles y luchas de poder, y al final un equipo competente terminó arrastrado por uno ineficaz
El problema es una cultura donde no se despide a la gente incompetente
La colaboración real solo es posible cuando la gente deja el ego de lado, escucha y trabaja
Trabajando solo puedes hacer más cosas, pero hay más riesgo de definir mal el problema
La colaboración ayuda a evitar eso al aportar perspectivas distintas
La gente que no trabaja termina estorbando a la que sí trabaja
Hace poco leí el artículo de McEntire “The Organizational Physics of Multi-Agent AI” y me pareció interesante
Incluso los agentes de IA reproducen tal cual la ineficiencia política de las organizaciones humanas
Al final, si la organización es mala, uno termina haciendo puro “trabajo sobre el trabajo (work about work)”
Los equipos pequeños y responsables son mucho más agradables, pero es difícil replicarlos
También toco este tema en mi blog, Where to Cut
Se siente que la orquestación solo funciona bien cuando los roles y la estructura están claros
Si cambias personas o mueves equipos, aparece un costo de cambio de contexto que rompe la cohesión del equipo
En el original no me quedaba claro qué quería decir
Una cultura donde no se reconoce a quienes sí producen resultados termina pudriendo a la organización
El 20% que carga con más peso solo quiere ser reconocido
Si no se le da eso, la empresa se vacía rápidamente
No me interesa el elogio de alguien que ni siquiera sabe qué hago
Este texto puede ampliarse más allá de las organizaciones hacia el significado social de la “autoría y la agencia”
El trabajo complejo y de alta calidad al final surge de la responsabilidad clara de individuos o equipos pequeños
Como Dostoievski o el equipo de cómputo del Apolo
En cambio, la utopía colaborativa de “todos contribuyen pero nadie recibe recompensa” está lejos de la realidad
Los seres humanos sienten más motivación por las obras creativas que llevan su nombre
Las cadenas de suministro complejas son otra forma de colaboración
La afirmación de que “el 80% de los soldados no disparó su arma” me pareció dudosa, así que la busqué, y resultó ser un dato refutado desde hace mucho
Incluso en un artículo de 2011 dicen que su base es débil
Si vemos la relación tooth-to-tail del ejército de EE. UU., el personal de combate real está en torno al 4~10%
Así que la confusión numérica podría ser la causa
Pero también dice que la tasa de PTSD aumentó en la misma medida
Todo el texto se siente como un intento incoherente de forzar ejemplos militares como modelo para el trabajo de oficina
Pero hay una buena noticia para el autor: tú también puedes convertirte en un creador individual
Como Notch o el desarrollador de Stardew Valley
En vez de quejarte, simplemente ponte a hacer algo tú mismo
eso de que el 80% no disparó siga siendo un dato interesante
El autor no consideró en absoluto el diseño de incentivos para el desempeño
Como dice Munger, “si ves los incentivos, ves los resultados”
Más importante que la dificultad de colaborar es crear una estructura que recompense a quien rinde y castigue al free rider
Y ni siquiera son tan grandes
Si se pudiera, ya estaríamos viviendo en una utopía
Además de que la premisa de la primera línea ya no coincide con los hechos, también me parece extraño relacionar el problema de disparar un arma en la guerra (donde se mezclan cuestiones como que puedes matar a una persona, el nivel de entrenamiento de los soldados en tiempo de guerra, etc.) con el problema de la colaboración en desarrollo. ¿Es un texto que demuestra lo importante que es cómo empieza un artículo...?
Viendo las reacciones, de verdad parece que hay mucha gente viviendo engañada, tal como dice este texto.
Incluso si
1 + 1 = 1.1, por muy productiva que sea una sola persona, no puede generar un resultado mayor que 1,000 personas ineficientes.El desarrollo de software tiene tanto un lado de artesanía hecha a mano como un lado de producto manufacturado en fábrica.
Una minoría inteligente lo organiza bien para que hasta los tontos puedan entenderlo y moverse bien. Los tontos se engañan pensando que eso significa que están colaborando jajaja
Es cierto que la colaboración en general fracasa, pero todos los grandes logros, incluido el nacimiento de la vida, surgieron de la colaboración.
A menos que seas un genio verdaderamente extraordinario, por muy bueno que seas no puedes trabajar solo. Aunque el 80% restante haga apenas de porristas, con que te animen al lado ya cuentan como medio aporte, y como los cracks hacen el trabajo de 2 o 3 personas, así es como la empresa sigue funcionando. Si trabajas solo, ni siquiera sientes que te reconocen, y no aguantas la soledad.
Me identifica mucho.
Sobre todo cuando, más que el resultado, solo se alargan interminablemente las actividades por la visibilidad y la transparencia que ocurren en las herramientas de colaboración...
Cuando veo a los planificadores que dejan notas de todo y para todo solo para quitarse responsabilidad, como desarrollador me da una crisis existencial.
Parece un estudiante de secundaria que acaba de descubrir la hipocresía y las falsas formalidades de los adultos, y empieza a indignarse. Por alguna razón, siento que al autor le gustaría Holden Caulfield de El guardián entre el centeno...
Dependiendo del tamaño del proyecto, puede que haya casos en los que una sola persona lidere de forma proactiva y eso sea más importante que la contribución de todo el equipo... pero según el tamaño, también puede que no sea así.
¿No será esto..?
Es la regla de las dos pizzas.
La colaboración no sirve para nada
Siento que ya había visto antes un título exactamente igual...
Creo que ni siquiera se verificaron los datos presentados en la primera línea.
Cuanto más grande es la organización, más siento que lo que dice este autor es acertado.
Y mientras más pequeña es la organización, parece que la dirección que plantea este autor ya es una realidad jajaja
Creo que, en el momento actual en que las AI TOOLs ya son una realidad, este es un texto bastante realista y con criterio sobre cómo maximizar la capacidad individual.
De ahora en adelante, todo irá exigiendo cada vez más ligereza y mayor velocidad, así que la colaboración basada en ideas anticuadas que hemos venido practicando hasta ahora probablemente se reinicie. Sin embargo, para desarrollar soluciones de nivel enterprise, la colaboración es indispensable.