Charla: Incentivos perversos, resultados previsibles. Cuando el sistema sabotea a los equipos

Hoy he tenido la oportunidad de participar en FredCon 25 con la charla “Incentivos perversos, resultados previsibles: Cuando el sistema sabotea a los equipos”. Quiero agradecer sinceramente a la organización por la invitación y por generar el espacio para debatir un tema que me importa muchísimo.

Sobre la charla

Exploro cómo la aplicación continuada del Taylorismo en el desarrollo de software y producto genera problemas sistémicos como:

• La trampa de la eficiencia de recursos.
• La desconexión del propósito.
• La trampa de la calidad diferida.

Cuando el sistema está mal diseñado, aparecen resultados previsibles pero indeseables: cuellos de botella crónicos, retrabajo constante, productos irrelevantes, fuga de talento y deuda técnica. Sucede porque se premian incentivos locales y la ocupación individual por encima del rendimiento global del sistema.

Idea clave: estos problemas no son fallos puntuales de los equipos, sino consecuencias inevitables de un sistema mal diseñado. La solución pasa por cambiar el sistema, promoviendo la colaboración, la responsabilidad compartida, la optimización global, la autonomía con propósito y el aprendizaje continuo para lograr impacto y velocidad sostenibles.

Slides

El vídeo aún no está disponible, pero ya puedes consultar las diapositivas. Incluyen bastantes notas con ejemplos y explicaciones adicionales que ayudan a seguir el hilo más allá de lo que se ve en pantalla.

Documento original con notas (Google Slides)

Abrir las slides en pestaña nueva

Gracias de nuevo a la organización de FredCon 25 y a todas las personas que asististeis. Ojalá este material sirva para abrir conversaciones sobre cómo diseñar sistemas que potencien a los equipos en lugar de sabotearlos.

Referencias de los conceptos principales

Resource Efficiency vs Flow Efficiency:

• The Efficiency Paradox  (18m) by Niklas Modig
• The resource utilization trap (5m) by Henrik Kniberg

WIP Limits:

• Multiple WIP vs One Piece Flow Example (7m) by Henrik Kniberg

General Processes / Team Work:

• Creating Value and Flow in Product Development (7m) by John Cutler
• Stop starting and start finishing (5m) by Jason Yip
• Making Work Visible: How to Unmask Capacity Killing WIP (29m) by Dominica DeGrandis

Systems Thinking and Quality:

• The Red Bead Experiment (14m) by W. Edwards Deming — A powerful demonstration that performance and quality depend on the system, not individual effort. A reminder that systemic issues require systemic fixes.

My premises about engineering leadership and people management

As with software development, I find it useful to write down the principles that guide how I think about leadership and people management. These are not universal truths, but they are the foundations I rely on when building and leading engineering teams. By making them explicit, I aim to create clarity, alignment, and a shared understanding of how I see leadership, collaboration, and growth.

1. People are not resources I don't believe in treating people as interchangeable units or "resources." People are creative, motivated, and responsible when given the right environment. My default stance is trust, not control. This aligns with Theory Y (Douglas McGregor): most people want to do good work if they are respected, trusted, and given meaningful challenges.
2. Empower teams with ownership Teams work best when they own the whole problem end-to-end, from idea to operation. Ownership gives autonomy and accountability, while purpose provides alignment. An empowered team doesn't just execute tasks but makes decisions and cares about outcomes.
3. Motivation is intrinsic The best results in knowledge work come from intrinsic motivation, not external rewards or pressure. As Daniel Pink highlights in Drive, autonomy, mastery, and purpose are the real drivers of excellence. My role as a leader is to foster these conditions, not to rely on carrots and sticks. 
4. Learning never stops Engineering and product work are constant processes of discovery. We optimize for fast feedback, safe experiments, and collective learning. Mistakes are not failures to hide but opportunities to grow. A learning culture is the foundation of adaptability. 
5. Enable experiments, eliminate waste, make quality inevitable My role as a leader is to create conditions for safe experimentation while relentlessly removing what doesn't add value. But more fundamentally, I must change the system so that working with quality becomes the most natural, simplest, and fastest path. This means building strong foundations, aligning incentives, and creating space for learning where teams ask "What's the worst that could happen?" with confidence. When quality is inevitable rather than heroic, we create virtuous cycles where technical excellence enables bold experiments and meaningful impact.

These are my personal premises about engineering leadership and people management. They are not universal truths, but the foundations I rely on when building and leading teams. I believe that making these principles explicit helps create clarity, alignment, and better collaboration.

References:

• Theory X and Theory Y
• Lean Software Delivery: Empowering the Team
• Drive: The Surprising Truth About What Motivates Us
• My premises about software development
• The Phrases That Power My Leadership