Product Engineering: cuando un developer empoderado supera a un equipo de cuatro

Un equipo de cuatro personas trabajó durante tres meses para automatizar el 50% de un proceso operativo crítico. Al final del trimestre, habían logrado automatizar el 10%. No por falta de talento, no por falta de presupuesto, no por falta de herramientas. El equipo tenía todo lo que la ortodoxia de gestión de proyectos prescribe: un Product Manager dedicado, tres desarrolladores competentes, ceremonias ágiles, un backlog priorizado y stakeholders disponibles. Y sin embargo, el resultado fue una fracción de lo prometido.

La empresa — una compañía de servicios financieros en Latinoamérica con operaciones en varios países — decidió cambiar de estrategia. En lugar de agregar personas o extender el plazo, hicieron algo que la mayoría de las organizaciones consideraría contraintuitivo: redujeron el equipo a una sola persona. Un desarrollador. Pero no cualquier desarrollador ejecutando tickets — un ingeniero al que le entregaron ownership completo del problema de negocio. Le dieron acceso directo a los stakeholders operativos, libertad para tomar decisiones arquitecturales y, paradójicamente, una meta más ambiciosa: 70% de automatización en lugar del 50% original.

Seis semanas después, ese desarrollador había superado la meta. La mitad del tiempo, un tercio de las personas, y un objetivo 40% más agresivo. Los números son suficientemente dramáticos como para merecer una explicación que vaya más allá de la anécdota.

El modelo tradicional: por qué cuatro personas no pudieron con el 50%

Para entender por qué el equipo de cuatro falló, hay que examinar la estructura en la que operaban, no su competencia individual. El modelo era el que predomina en la mayoría de las organizaciones de tecnología: un Product Manager recibía los requerimientos del negocio, los traducía en historias de usuario, las priorizaba en un backlog y las distribuía a los desarrolladores en sprints de dos semanas. Los desarrolladores construían lo que se les pedía, lo entregaban para revisión y pasaban al siguiente ticket. El ciclo se repetía cada dos semanas con una retrospectiva donde todos coincidían en que “había que mejorar la comunicación.”

Este modelo tiene una premisa implícita que rara vez se examina: que el entendimiento del problema y la construcción de la solución pueden separarse limpiamente en dos funciones distintas. El Product Manager entiende el negocio, el desarrollador entiende la tecnología, y la interfaz entre ambos son documentos — historias de usuario, criterios de aceptación, diagramas de flujo. La teoría dice que esta separación permite especialización y eficiencia. La práctica dice algo diferente.

Cuando un desarrollador recibe un ticket que dice “automatizar la validación de documentos según las reglas de compliance,” lo que recibe es una abstracción de un problema que alguien más entendió parcialmente, tradujo a un formato estandarizado y descontextualizó para que cupiera en un sprint. El desarrollador no sabe por qué esas reglas de compliance existen, no conoce los casos borde que el equipo operativo maneja intuitivamente cada día, no entiende qué pasa cuando la automatización falla y un humano tiene que intervenir. Construye lo que el ticket dice, no lo que el problema necesita. Y cuando lo que construye no resuelve el problema real, el ciclo se repite: feedback del negocio al PM, el PM reescribe el ticket, el desarrollador reconstruye. Cada iteración de este ciclo consume entre una y dos semanas.

En el caso de la empresa de servicios financieros, el proceso que intentaban automatizar tenía más de cuarenta variaciones operativas que el equipo de negocio conocía pero que nunca habían sido documentadas formalmente. El Product Manager, por más competente que fuera, no podía capturar toda esa complejidad en historias de usuario. Cada sprint revelaba nuevas variaciones que nadie había anticipado, lo que generaba retrabajo y erosionaba tanto la velocidad como la moral del equipo. Los desarrolladores sentían que construían sobre arena — cada entrega era parcialmente incorrecta no por errores de código sino por errores de entendimiento.

Frederick Brooks, en “The Mythical Man-Month” (1975), articuló una observación que medio siglo después sigue siendo ignorada con notable consistencia: agregar personas a un proyecto de software atrasado lo atrasa más. La razón es matemática antes que organizacional. Los canales de comunicación en un equipo crecen de forma cuadrática con el número de integrantes. Un equipo de cuatro personas tiene seis canales de comunicación bilateral. Si agregamos un quinto miembro para “acelerar,” pasamos a diez canales. El overhead de coordinación — reuniones, documentación, alineación, resolución de ambigüedades — consume una proporción creciente del tiempo disponible. En el equipo de esta empresa, las ceremonias ágiles, las reuniones de refinamiento, las sesiones de alineación con stakeholders y las code reviews consumían, según estimaciones internas, entre el 35% y el 40% del tiempo semanal de cada desarrollador. Menos del 65% del tiempo se dedicaba a construir. Y de ese tiempo de construcción, una porción significativa se dedicaba a reconstruir lo que ya se había entregado porque los requerimientos no capturaban la realidad del problema.

Hay un fenómeno que la literatura de ingeniería de software ha documentado extensamente pero que las organizaciones siguen tratando como excepcional: la pérdida de contexto en la cadena de traducción. Cuando el conocimiento pasa del usuario final al analista de negocio, del analista al Product Manager, del Product Manager al desarrollador, y del desarrollador al código, cada transición pierde información. No por negligencia — por la naturaleza misma de la traducción entre dominios cognitivos distintos. El operador que procesa documentos de compliance tiene un modelo mental rico, contextual y lleno de excepciones que ha construido durante años. Ese modelo mental no cabe en una historia de usuario de tres líneas con criterios de aceptación binarios.

El experimento: un developer, un problema, cero intermediarios

El cambio de estrategia no fue una decisión teórica sino pragmática. Después de tres meses con resultados decepcionantes, la dirección de tecnología propuso un experimento: asignar a un solo desarrollador senior la responsabilidad completa del problema de automatización. No la responsabilidad de ejecutar tickets — la responsabilidad de resolver el problema de negocio. La diferencia parece semántica pero es estructural.

Al desarrollador se le explicó el problema en términos de negocio, no de tecnología: “Este proceso operativo consume X horas-persona al mes, tiene una tasa de error de Y%, y cada error cuesta Z en retrabajo y riesgo regulatorio. Tu objetivo es automatizar el 70% de este proceso. Cómo lo hagas es tu decisión.” No hubo backlog predefinido, no hubo historias de usuario pre-escritas, no hubo un PM intermediando entre el desarrollador y la realidad operativa.

Lo primero que hizo el desarrollador fue sentarse durante una semana con el equipo operativo. No para “relevar requerimientos” en el sentido tradicional — para entender el trabajo. Observó cómo procesaban documentos, preguntó por qué hacían cada paso, identificó las decisiones que tomaban intuitivamente y que ningún documento formal capturaba. Construyó su propio modelo mental del problema antes de escribir una sola línea de código. Cuando finalmente empezó a construir, las decisiones arquitecturales reflejaban un entendimiento del dominio que ningún ticket podría haber transmitido.

El resultado fue un sistema que no solo automatizaba las tareas predecibles sino que manejaba elegantemente los casos borde que habían descarrilado al equipo anterior. El desarrollador, al entender por qué el proceso existía y no solo qué pasos tenía, podía tomar decisiones de diseño que un ejecutor de tickets jamás habría tomado. Cuando encontraba una variación operativa que no podía automatizar de forma confiable, la escalaba directamente al equipo operativo y juntos decidían si automatizarla parcialmente, crear una interfaz para intervención humana o dejarla fuera del alcance. Estas decisiones, que en el modelo anterior habrían requerido una reunión con el PM, un análisis de impacto, una repriorización del backlog y al menos un sprint de espera, se tomaban en horas.

Seis semanas después del inicio del experimento, el sistema estaba en producción automatizando más del 70% del proceso. Los operadores reportaban que la herramienta “entendía su trabajo” — una observación que ningún usuario había hecho sobre las entregas del equipo anterior. Y el desarrollador, lejos de estar agotado por la carga de trabajo, reportó los niveles más altos de motivación y satisfacción de su carrera en la empresa. No estaba ejecutando tickets — estaba resolviendo un problema que entendía profundamente y sobre el cual tenía autonomía real.

Por qué funcionó: la teoría detrás del resultado

Es tentador atribuir el resultado a un “desarrollador excepcional” y cerrar el análisis ahí. Pero esa explicación, además de ser intelectualmente perezosa, es peligrosa porque sugiere que el éxito no es replicable. La evidencia académica ofrece explicaciones más estructurales y, por lo tanto, más útiles.

Stray, Moe y Hoda (2018), en su investigación sobre equipos ágiles autónomos, identificaron que la autonomía del equipo — definida como la capacidad de tomar decisiones sobre qué construir, cómo construirlo y cómo organizarse — es el factor más consistentemente asociado con el desempeño en contextos de desarrollo de software. Sin embargo, sus hallazgos también revelaron una paradoja: las organizaciones que adoptan frameworks ágiles frecuentemente eliminan la autonomía real en el proceso de implementación. Los sprints, los backlogs priorizados externamente, las estimaciones comprometidas y las ceremonias obligatorias crean una estructura que simula agilidad pero que en la práctica reduce la capacidad del equipo para responder a lo que aprende durante la ejecución. El equipo de cuatro personas en la empresa de servicios financieros operaba exactamente bajo este patrón: formalmente ágil, estructuralmente rígido.

Lo que el experimento hizo fue restaurar la autonomía real. El desarrollador no tenía que negociar prioridades con un PM ni justificar cambios de enfoque en una retrospectiva. Cuando descubría que su enfoque inicial no funcionaba para un subconjunto de casos, pivotaba inmediatamente. Cuando identificaba una oportunidad de automatización que nadie había contemplado, la implementaba sin pedir permiso. La velocidad no venía de trabajar más horas — venía de eliminar el tiempo muerto entre “descubrir algo” y “actuar en consecuencia.”

Brooks (1975) observó que la complejidad del software tiene dos componentes: la complejidad esencial del problema y la complejidad accidental introducida por las herramientas, procesos y estructuras organizacionales. En el equipo de cuatro, la complejidad accidental era enorme: la cadena de traducción de requerimientos, la coordinación entre desarrolladores, la sincronización con el PM, las dependencias entre tareas distribuidas en el backlog. Al reducir el equipo a una persona, toda la complejidad accidental de coordinación desapareció. No porque la coordinación fuera innecesaria, sino porque se internalizó: el desarrollador coordinaba consigo mismo, lo cual tiene un costo cognitivo pero cero costo organizacional.

El segundo factor explicativo es la motivación intrínseca. La psicología organizacional ha documentado extensamente que la autonomía, el dominio y el propósito son los tres pilares de la motivación en trabajo cognitivo complejo. El desarrollador del experimento tenía los tres: autonomía para decidir cómo resolver el problema, la oportunidad de desarrollar dominio tanto técnico como de negocio, y un propósito claro y tangible — resolver un problema real que afectaba a personas reales cuyo trabajo observaba diariamente. En contraste, los tres desarrolladores del equipo original tenían autonomía limitada al cómo técnico de cada ticket, dominio restringido al código sin contexto de negocio, y un propósito abstracto mediado por un backlog que alguien más definía. No es sorprendente que el desarrollador empoderado reportara niveles de motivación significativamente superiores. Lo notable es que esa motivación se tradujera directamente en velocidad y calidad de ejecución — un vínculo que frecuentemente se trata como intangible pero que en este caso fue cuantificable.

Hay un tercer factor que merece examinarse con cuidado: el rol de las herramientas de inteligencia artificial como multiplicador de capacidad individual. Tabarsi et al. (2025), en su investigación sobre cómo los modelos de lenguaje están transformando el desarrollo de software, documentaron un hallazgo particularmente relevante para este caso. Los desarrolladores que integran herramientas basadas en LLMs en su flujo de trabajo reportan ganancias sustanciales de productividad, pero no de la manera que la narrativa popular sugiere. El código generado por IA frecuentemente se descarta o se reescribe significativamente. La ganancia real está en el desplazamiento del esfuerzo cognitivo: los desarrolladores pasan menos tiempo escribiendo código rutinario y más tiempo evaluando, integrando y tomando decisiones de diseño. Es decir, las herramientas de IA amplifican exactamente las capacidades que el modelo de Product Engineering requiere — pensamiento de diseño, evaluación de alternativas, toma de decisiones arquitecturales — mientras automatizan las tareas que el modelo tradicional distribuía entre múltiples personas.

Tabarsi et al. (2025) también identificaron lo que denominaron la “paradoja productividad-calidad”: los desarrolladores producían más código más rápido, pero el código generado requería evaluación crítica rigurosa. Esta paradoja se resuelve cuando el desarrollador tiene un entendimiento profundo del dominio del problema, porque puede evaluar la calidad del código generado no solo en términos técnicos sino en términos de adecuación al problema de negocio. Un desarrollador que no entiende el dominio no puede distinguir entre código que funciona técnicamente y código que resuelve el problema real. Un developer empoderado con ownership del problema sí puede. Las herramientas de IA, en este contexto, no reemplazan al equipo de cuatro — potencian al individuo que entiende tanto el problema como la solución.

Product Engineering vs Product Management tradicional

La distinción entre Product Engineering y Product Management tradicional no es un rebranding ni una moda de consultoría. Es una diferencia estructural en cómo se organiza la creación de valor.

En el modelo de Product Management tradicional, existe una separación funcional entre quien define qué construir y quien lo construye. El Product Manager es el “dueño” del producto en el sentido de que decide la dirección, prioriza las funcionalidades y representa la voz del cliente y del negocio. El desarrollador es un ejecutor especializado que traduce esas decisiones en código. La interfaz entre ambos son artefactos documentales: roadmaps, PRDs, historias de usuario, criterios de aceptación. Este modelo asume que el conocimiento del problema y el conocimiento de la solución son dominios separados que pueden coordinarse a través de documentos y reuniones.

En el modelo de Product Engineering, esa separación se disuelve. El ingeniero no recibe requerimientos — investiga el problema. No ejecuta un backlog — define su propia secuencia de trabajo basada en lo que aprende. No traduce historias de usuario en código — traduce entendimiento del negocio en sistemas. La tecnología y el negocio convergen en una misma persona, y esa convergencia elimina la pérdida de información que caracteriza al modelo tradicional.

Esto no significa que el Product Manager desaparezca como rol. Significa que su función cambia. En lugar de ser un intermediario entre el negocio y la tecnología, se convierte en un facilitador que asegura que los ingenieros tengan acceso al contexto que necesitan, que las decisiones de producto se tomen con datos y que la visión estratégica sea coherente. El PM en un modelo de Product Engineering trabaja sobre el sistema — eliminando obstáculos, creando conexiones, alineando incentivos — en lugar de trabajar dentro del sistema como un nodo obligatorio en la cadena de valor.

La diferencia se manifiesta en la velocidad de aprendizaje. En el modelo tradicional, cada ciclo de aprendizaje requiere múltiples transferencias de información: el usuario reporta un problema al PM, el PM lo analiza, crea un ticket, el ticket se prioriza, un desarrollador lo toma, construye una solución, la entrega, el PM la valida, el usuario la prueba y proporciona feedback. Este ciclo tiene una latencia mínima de una a dos semanas incluso en equipos bien gestionados. En el modelo de Product Engineering, el ciclo es: el ingeniero observa el problema, construye una solución, la prueba con el usuario, itera. La latencia se mide en horas, no en semanas.

La empresa de servicios financieros experimentó esta diferencia de forma cuantificable. Durante los tres meses del modelo tradicional, el equipo completó aproximadamente doce ciclos de sprint, cada uno produciendo incrementos parciales que frecuentemente requerían retrabajo. Durante las seis semanas del modelo de Product Engineering, el desarrollador completó un número incontable de ciclos de iteración — algunos de minutos, otros de días — cada uno informado por contacto directo con la realidad operativa. La granularidad del aprendizaje era incomparablemente mayor, y cada iteración acumulaba entendimiento en lugar de consumirlo en overhead de coordinación.

Las condiciones para que funcione

Sería irresponsable presentar este caso como una receta universal. El modelo de Product Engineering no funciona por arte de magia, y no es apropiado para todos los contextos. Funciona bajo condiciones específicas que la organización debe crear deliberadamente.

La primera condición es acceso directo a los stakeholders y usuarios finales. El desarrollador en el caso de la empresa de servicios financieros no tuvo éxito porque era un genio aislado — tuvo éxito porque pasó una semana entendiendo el problema de primera mano y mantuvo comunicación constante con el equipo operativo durante todo el desarrollo. Si la organización interpone capas de intermediación entre el ingeniero y la realidad del problema — “no puedes hablar con los usuarios directamente, pasa por el PM” — el modelo colapsa. La ventaja fundamental del Product Engineering es la eliminación de la cadena de traducción, y cualquier estructura que la reintroduzca anula esa ventaja.

La segunda condición es seguridad psicológica para experimentar y fallar. El desarrollador tomó decisiones arquitecturales que, en el modelo tradicional, habrían requerido aprobación de un comité técnico. Algunas de esas decisiones resultaron incorrectas y tuvo que revertirlas. En una organización donde equivocarse tiene consecuencias políticas, ningún desarrollador asumiría ese riesgo. Preferiría pedir permiso, esperar aprobación y documentar cada decisión para protegerse. Esa protección tiene un costo: semanas de latencia en cada decisión significativa. La seguridad psicológica no es un concepto blando de recursos humanos — es un prerrequisito operativo para la velocidad de ejecución.

La tercera condición es profundidad técnica y de dominio. No cualquier desarrollador puede operar en este modelo. Se requiere alguien con la madurez técnica para tomar decisiones arquitecturales sin supervisión constante, y con la curiosidad y capacidad de aprendizaje para adquirir rápidamente conocimiento de un dominio que no es el suyo. En el caso analizado, el desarrollador seleccionado tenía cinco años de experiencia en la empresa y conocimiento previo del área de compliance, lo que aceleró significativamente la curva de aprendizaje del dominio. Este no es un modelo para desarrolladores junior ni para ingenieros que prefieren recibir especificaciones detalladas.

La cuarta condición es la disponibilidad de herramientas de IA como multiplicador de fuerza. Una persona no puede replicar la producción de código de cuatro personas a través de puro esfuerzo. Lo que habilita la ecuación es que las herramientas de generación de código, depuración asistida y prototipado rápido basadas en LLMs permiten que un individuo con entendimiento profundo del problema produzca a una velocidad que hace una década habría sido imposible. Tabarsi et al. (2025) documentaron que el uso de LLMs es particularmente efectivo en las fases de implementación y depuración, precisamente las fases donde la producción individual se beneficia más de la amplificación. Pero, y esto es crucial, esa amplificación solo genera valor cuando quien la usa puede evaluar críticamente el output — lo cual requiere, de nuevo, entendimiento profundo del dominio.

La quinta condición, quizás la más difícil de crear, es voluntad organizacional para tolerar la opacidad temporal. Cuando un equipo de cuatro trabaja con un backlog visible, un burndown chart y demos cada dos semanas, la organización tiene visibilidad constante del progreso. Cuando un individuo trabaja con autonomía total, la visibilidad es menor y la confianza requerida es mayor. La dirección de la empresa de servicios financieros aceptó este trade-off conscientemente, pero no todas las organizaciones tienen la madurez para hacerlo. La necesidad de control visible frecuentemente supera la prioridad de resultados, especialmente en organizaciones donde la gestión se evalúa por procesos más que por outcomes.

Lo que esto implica para las organizaciones

El caso de la empresa de servicios financieros no es una historia sobre desarrollo de software. Es una historia sobre cómo las organizaciones estructuran la creación de valor y cómo esa estructura determina los resultados más que el talento individual o las herramientas disponibles.

La mayoría de las organizaciones están diseñadas para gestionar complejidad a través de especialización y coordinación. Se crean roles especializados — analistas de negocio, Product Managers, arquitectos, desarrolladores, testers, DevOps — y se establecen procesos para coordinar su trabajo. Este diseño organizacional tiene sentido en contextos de alta estabilidad y alta escala, donde la eficiencia de la especialización supera el costo de la coordinación. Pero en contextos de alta incertidumbre y cambio rápido — que es donde opera la mayoría de las iniciativas de transformación digital — el costo de coordinación supera la eficiencia de la especialización. Los equipos pasan más tiempo alineándose sobre qué construir que construyendo.

Lo que el modelo de Product Engineering propone no es eliminar la especialización sino rediseñar la unidad mínima de creación de valor. En lugar de un equipo donde cada persona aporta una especialidad parcial y la coordinación las integra, la unidad es un individuo o un equipo muy pequeño que integra múltiples capacidades en sí mismo. El “full-stack” no es solo una descripción técnica — es una postura organizacional donde la persona que construye es la misma que entiende el problema, toma decisiones de producto y es responsable del resultado.

Esto tiene implicaciones profundas para el diseño organizacional. Si el modelo de Product Engineering produce mejores resultados en contextos de incertidumbre, entonces la organización necesita invertir en crear las condiciones que lo habilitan en lugar de optimizar los procesos del modelo tradicional. Esto significa invertir en el desarrollo de ingenieros con capacidad de pensamiento de producto, no solo habilidad técnica. Significa crear canales directos entre los constructores y los usuarios, en lugar de agregar más capas de intermediación. Significa redefinir el rol del management como creador de contexto y removedor de obstáculos, no como controlador de tareas y asignador de trabajo.

También tiene implicaciones para la gestión del talento. En el modelo tradicional, un desarrollador es relativamente intercambiable — cualquier ingeniero competente puede tomar un ticket del backlog y ejecutarlo. En el modelo de Product Engineering, la persona que lleva tres meses entendiendo un dominio y construyendo sobre ese entendimiento no es reemplazable por otra persona con las mismas habilidades técnicas. El conocimiento de dominio acumulado es un activo estratégico, no un detalle operativo. Esto cambia radicalmente cómo se piensa sobre retención, compensación y desarrollo profesional de los ingenieros.

Hay una dimensión adicional que las organizaciones suelen pasar por alto: la velocidad compuesta. En el modelo tradicional, el conocimiento de dominio se distribuye entre roles y se pierde parcialmente en cada transición. Cuando un PM deja el equipo, se lleva consigo una porción significativa del entendimiento del problema. Cuando un desarrollador rota a otro proyecto, el conocimiento técnico contextualizado — por qué esta decisión arquitectural y no otra, qué alternativas se evaluaron, qué restricciones de dominio informaron el diseño — se evapora. En el modelo de Product Engineering, el conocimiento de dominio y el conocimiento técnico se acumulan en la misma persona, creando un efecto de interés compuesto: cada semana de trabajo aumenta la capacidad de la siguiente semana porque el entendimiento se profundiza en lugar de diluirse. El desarrollador en la semana seis del experimento era radicalmente más efectivo que en la semana uno, no porque hubiera mejorado técnicamente sino porque su modelo mental del problema era incomparablemente más rico.

La resistencia organizacional a este modelo es predecible y comprensible. Los Product Managers perciben una amenaza existencial a su rol. Los gerentes de proyecto pierden la visibilidad granular que justifica su existencia. Los procesos de estimación y planificación trimestral se vuelven menos predecibles. Las métricas tradicionales — velocity, story points completados, tickets cerrados — pierden relevancia cuando el trabajo no se estructura en tickets. La organización completa tiene que reaprender cómo evalúa el progreso, y esa transición es incómoda.

Pero la incomodidad de la transición no es argumento contra el cambio cuando la alternativa es la ineficiencia sistémica del modelo actual. La empresa de servicios financieros gastó tres meses de cuatro salarios para obtener un 10% de automatización. Luego gastó seis semanas de un salario para obtener más del 70%. La diferencia no es marginal — es de un orden de magnitud. Y esa diferencia no se explica por talento individual excepcional sino por una estructura que permitía al talento existente expresarse sin las restricciones de un modelo de coordinación que consumía más energía que la que generaba.

Stray, Moe y Hoda (2018) concluyeron su investigación observando que el principal desafío para la implementación de equipos autónomos no es técnico ni metodológico — es cultural. Las organizaciones que genuinamente empoderan a sus equipos necesitan aceptar que el control centralizado y la optimización local son incompatibles con la autonomía y la optimización global. No se puede tener un equipo “empoderado” que requiere aprobación para cada decisión técnica, que trabaja sobre un backlog definido externamente y que es evaluado por métricas de producción en lugar de métricas de impacto.

La pregunta que este caso plantea no es técnica. No es sobre qué herramientas usar, qué framework ágil implementar ni cuántos desarrolladores contratar. La pregunta es organizacional y, en última instancia, filosófica: cuando su organización diseña cómo se crea valor, el diseño resultante empodera a quienes construyen para entender y resolver problemas de negocio, o los reduce a ejecutores de especificaciones que alguien más escribió. Si la respuesta honesta es lo segundo, entonces los resultados que obtiene — independientemente de cuántas personas asigne, cuánto presupuesto apruebe o cuántas ceremonias ágiles implemente — serán consistentemente inferiores a lo que el mismo talento podría producir bajo una estructura diferente.

La empresa de servicios financieros no descubrió un hack de productividad. Descubrió, de forma empírica y algo accidental, lo que la evidencia académica lleva décadas señalando: que la estructura organizacional es la variable independiente más poderosa en la ecuación de creación de valor en software, y que la mayoría de las organizaciones optimizan las variables equivocadas.

La pregunta para quien lee esto no es si el caso es replicable. Es si su organización está diseñada para empoderar a quienes construyen, o para gestionarlos.

Referencias

Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley. DOI: 10.1145/800027.808439
Stray, V., Moe, N. B., & Hoda, R. (2018). Autonomous agile teams: challenges and future directions for research. Proceedings of the 19th International Conference on Agile Software Development (XP 2018). DOI: 10.1145/3234152.3234182. ArXiv: 1810.02765
Tabarsi, B. T., Reichert, H., Limke, A., Kuttal, S., & Barnes, T. (2025). LLMs’ Reshaping of People, Processes, Products, and Society in Software Development: A Comprehensive Exploration with Early Adopters. ArXiv: 2503.05012