Los datos les daban la razón. Al principio.

Lo que nos dijeron

Nos dijeron que un ingeniero tenía un rendimiento por debajo de lo esperado.

Las preocupaciones venían del liderazgo de producto y de ingeniería.

Se describía a este ingeniero como alguien que tardaba demasiado en entregar, cuestionaba las decisiones con excesiva frecuencia y perjudicaba la armonía del equipo.

La organización estaba considerando sacar a este ingeniero del equipo.

La evidencia parecía clara.

Desde que se asignaba el trabajo en GitHub hasta que se abría un pull request, este ingeniero solía tardar más de lo que habríamos esperado para la propia implementación.

Según esa medida, el ingeniero realmente era más lento.

Lo que observamos

GitHub mostraba el tiempo transcurrido.

No mostraba qué hacía el ingeniero durante ese tiempo.

Así que seguimos el trabajo hasta Slack.

Al recibir una solicitud, el ingeniero preguntaba con frecuencia por qué existía una especificación concreta, qué problema pretendía resolver, o si una implementación distinta lograría mejor el mismo objetivo.

No eran objeciones aleatorias.

Eran intentos de comprender el contexto del requisito o de proponer una alternativa antes de que comenzara la implementación.

El product owner solía tratar esas preguntas y propuestas como innecesarias.

Cuando se rechazaba una propuesta, el ingeniero comenzaba la implementación de inmediato.

Cuando una pregunta o propuesta no recibía respuesta, el ingeniero no esperaba indefinidamente.

Después de tres días hábiles, el ingeniero indicaba que no había recibido respuesta y que la implementación avanzaría según la solicitud original.

Solo entonces comenzaba el trabajo de codificación.

El patrón

La organización medía todo el tiempo entre la asignación y la entrega como tiempo de ejecución de ingeniería.

Pero una parte importante de ese tiempo se empleaba antes de la implementación.

El ingeniero intentaba aclarar la intención, cuestionar suposiciones o proponer una alternativa.

Esas actividades no se contaban como trabajo útil.

Se interpretaban como retraso.

Esa interpretación también moldeaba la reputación del ingeniero.

Hacer preguntas parecía resistencia.

Proponer alternativas parecía negarse a seguir instrucciones.

Esperar una decisión de producto sin respuesta parecía una implementación lenta.

El mismo comportamiento se usaba, por tanto, como evidencia para varios juicios negativos sobre esa persona.

Entonces encontramos otra señal

Algunas de las propuestas rechazadas o ignoradas del ingeniero no desaparecieron.

Después de que se lanzara la implementación original, el product owner a veces solicitaba la misma idea en un sprint posterior.

La propuesta que antes se había considerado innecesaria podía volver más tarde como un requisito oficial.

Eso importaba.

Mostraba que las preguntas y propuestas alternativas del ingeniero no eran mera obstrucción.

Al menos algunas de ellas identificaban mejoras que la organización de producto acabaría queriendo de todos modos.

Nuestra hipótesis

El ingeniero no sufría, principalmente, un problema de capacidad.

La organización había creado un entorno en el que un solo tipo de comportamiento de ingeniería se recompensaba por encima de todos los demás:

Ejecutar la instrucción tal como se dio.

Cuestionar la especificación generaba retraso.

Sugerir una alternativa generaba fricción.

Esperar una aclaración aumentaba el lead time medido.

Desde esa perspectiva, un ingeniero que intentaba mejorar el trabajo antes de implementarlo podía parecer menos productivo que uno que simplemente empezaba a programar de inmediato.

El sistema no se limitaba a medir la velocidad de entrega.

Estaba recompensando indirectamente la obediencia a las instrucciones.

Por qué el diagnóstico original parecía convincente

El juicio original no se basaba en datos imaginarios.

El tiempo transcurrido realmente era mayor.

Eso fue lo que hizo interesante el caso.

Una única fuente de evidencia respaldaba la conclusión de la organización.

Si nos hubiéramos detenido en GitHub, habríamos podido llegar a la misma conclusión.

Pero la métrica solo respondía a una pregunta:

¿Cuánto tiempo pasó entre la asignación y la entrega?

No respondía:

• ¿Cuándo comenzó realmente la implementación?
• ¿Qué ocurrió antes de la implementación?
• ¿Quién esperaba a quién?
• ¿Qué decisiones estaban sin resolver?
• ¿Qué valor se estaba creando fuera del propio código?

Lo que mostró la evidencia

El ingeniero era más lento si solo medíamos el tiempo de entrega transcurrido.

Pero ese número combinaba varios tipos distintos de actividad en una sola métrica.

Al separar la implementación de la aclaración, la propuesta, la decisión y el tiempo de espera, el significado de ese número cambió.

La organización había interpretado un patrón de interacción a nivel de sistema como un problema de rendimiento individual.

Sacar al ingeniero del equipo no habría corregido ese patrón.

Solo habría eliminado a la persona cuyo comportamiento hacía visible el patrón.

Los datos no estaban equivocados. La interpretación era incompleta.

La perspectiva de Pulsar

No empezamos decidiendo si una persona es buena o mala en su trabajo.

Seguimos el trabajo.

En este caso, GitHub mostraba que la entrega tardaba más.

Slack mostraba por qué.

Decisiones de producto posteriores mostraron que parte del comportamiento supuestamente innecesario había estado identificando valor real.

Ninguna de esas observaciones, por sí sola, contaba toda la historia.

Juntas, cambiaron el diagnóstico.

No evaluamos a las personas a partir de una sola señal. Investigamos el sistema que produjo esa señal.