Lo sabíamos antes de empezar.

Lo que nos dijeron

Una empresa nos pidió ayuda para mejorar su organización de desarrollo de software.

Antes de que comenzara el proyecto, nos reunimos con el CEO y el responsable de desarrollo para hablar de dónde podíamos ayudar.

También nos dijeron que los accesos y permisos necesarios para el trabajo se concederían de inmediato.

Sobre el papel, no había ningún problema de acceso.

Pero durante esa misma conversación, observamos algo que nos hizo dudar de esa predicción — no porque pensáramos que alguien mentía, sino porque su comportamiento apuntaba en una dirección distinta.

Lo que observamos

El CEO propuso primero incorporarnos a un proyecto existente que necesitaba mejoras.

El responsable de desarrollo explicó por qué eso no funcionaría: el proyecto ya tenía una fecha de lanzamiento fija.

El CEO propuso otro proyecto. Este no tenía fecha de lanzamiento fija.

De nuevo, el responsable de desarrollo explicó por qué no funcionaría: había demasiadas partes interesadas involucradas como para que alguien externo entrara y asumiera la responsabilidad.

Ambas objeciones, por separado, podrían haber sido perfectamente razonables.

Entonces el CEO probó una tercera opción: en lugar de asignarnos un proyecto, quizá podríamos ayudar a mejorar la productividad del equipo de desarrollo.

Esta vez, la respuesta fue positiva.

Eso sonaba prometedor.

Así que hicimos una pregunta.

¿Existía un enfoque de desarrollo compartido en toda la organización, o cada ingeniero era libre de decidir cómo trabajar?

La respuesta fue que a los ingenieros se les daba, de forma intencionada, la libertad de elegir sus propios métodos.

Entonces le hicimos al responsable de desarrollo una pregunta hipotética:

¿Si alguien pudiera mostrarle una forma distinta de trabajar que lo hiciera diez veces más productivo, la adoptaría?

La respuesta fue no.

Esa respuesta importaba.

Pero el patrón importaba más.

El patrón

Cada vez que el CEO proponía una forma de que contribuyéramos, el responsable de desarrollo explicaba por qué no podía funcionar.

• El proyecto A no podía funcionar.
• El proyecto B no podía funcionar.
• Mejorar las prácticas de desarrollo sonó aceptable al principio — pero el responsable de desarrollo dijo entonces, de forma explícita, que ni siquiera una forma de trabajar drásticamente más productiva se adoptaría si venía de otra persona.

Había otra señal.

No se propuso ninguna alternativa.

La conversación era, en apariencia, sobre encontrar una forma de que ayudáramos. Sin embargo, una persona explicaba una y otra vez por qué cada camino propuesto era imposible, sin sugerir nunca uno que sí lo fuera.

Las objeciones individuales eran datos.

El patrón entre ellas era evidencia de algo mayor.

Nuestra hipótesis

El problema no era el proyecto A.

No era el proyecto B.

Y no era la forma concreta de mejora de productividad que se estaba discutiendo.

Nuestra hipótesis era que la organización de desarrollo, en realidad, no aceptaba la intervención externa.

Si esa hipótesis era correcta, el problema no terminaría al decidir qué trabajo debíamos hacer.

Una vez comenzado el proyecto, la misma resistencia aparecería en todo lo necesario para realizar ese trabajo — incluido el acceso a sistemas, información y permisos.

Así, antes de que comenzara el proyecto, predijimos que obtener el acceso necesario para trabajar de forma efectiva se convertiría en un problema.

Por qué seguimos adelante de todos modos

En circunstancias normales, esto habría sido motivo para rechazar el proyecto.

Esa era nuestra intención.

Pero las decisiones de negocio las toman personas, no algoritmos de optimización.

El proyecto había llegado a través de alguien a quien le debíamos mucho. Dada esa relación y las circunstancias, rechazarlo no era, en la práctica, una opción.

Así que seguimos adelante a pesar del riesgo que habíamos identificado.

Lo que mostró la evidencia

Una vez que comenzó el proyecto, los accesos y permisos que se suponía se concederían de inmediato se convirtieron en un obstáculo importante.

La predicción se confirmó.

Pero esto no era un ejercicio de detección de mentiras.

No necesitábamos determinar si alguien había hecho a sabiendas una afirmación falsa. Es posible que creyeran sinceramente que el acceso necesario podría proporcionarse de inmediato.

Para nuestro propósito, la intención era irrelevante.

La afirmación era un dato.

El comportamiento que observamos durante esa misma conversación era otro.

Cuando esos datos apuntaban en direcciones distintas, formulamos una hipótesis sobre lo que realmente ocurriría — y esperamos a que la evidencia observable la confirmara o la refutara.

Lo que decía la gente era un dato. Cómo se comportaba mientras lo decía era otro.

La perspectiva de Pulsar

La mayor parte de lo que hacemos ocurre después de que un problema ya ha aparecido. Este caso fue distinto.

Formulamos una hipótesis sobre un problema que aún no había ocurrido, basándonos únicamente en cómo se hablaron dos personas en una sola reunión.

La predicción podría haber sido errónea. No estaba garantizada en el momento en que la formulamos.

Lo que lo hizo posible fue tratar la señal de comportamiento como evidencia por derecho propio, y no como una nota al pie de lo que se dijo.

Una hipótesis que se confirma después no es suerte. Es lo que ocurre cuando se trata el comportamiento como un dato antes de tener que hacerlo.