Cada uno pone cabeza en lo que le toca

El consejo habitual sobre gestión es dar autonomía y no revisar el trabajo a medias. Yo estoy con ellos a diario, les pregunto si tienen dudas, y cuando están construyendo algo les pido que me lo enseñen antes de que esté terminado.

El reparto que busco es este: ellos ponen la cabeza en desarrollar y yo la pongo en hablar con negocio y aterrizarlo. Son dos trabajos distintos, y ninguno de los dos sale bien si te toca hacer el otro a la vez.

Filtrar es la mayor parte de mi trabajo

Un desarrollador que recibe una petición de negocio en crudo acaba haciendo de todo menos desarrollar. Reuniones para entender qué se pide de verdad. Prioridades que cambian a mitad y hay que reinterpretar. Decisiones que no le tocan, tomadas con información que no tiene.

Todo eso se queda en mí. Yo estoy en esas conversaciones, y mi trabajo es que al equipo le llegue ya aterrizado: esto es lo que hay que hacer y esta es la razón. Ellos se ocupan de la parte técnica, que es donde se manejan.

Eso es lo que hay debajo de estar encima: un paraguas.

Por qué pido ver las cosas pronto

Por lo mismo.

Como el contexto de negocio lo tengo yo, soy quien puede ver antes que algo se está desviando. Si lo miro a los tres días y digo que esta parte habrá que cambiarla, se corrige ahí mismo. Si espero al final, ya se ha construido encima.

Cuando me lo enseñan, lo que miro es si aquello se sigue pareciendo a lo que hacía falta. Esa información no llega entera a un ticket por bien escrito que esté.

Las cuatro preguntas

Lo que hago en la práctica es poco ceremonioso, y se resume en cuatro preguntas:

• ¿Cómo vas?
• ¿Necesitas algo?
• ¿Te has quedado atascado?
• Enséñame un poco lo que llevas.

Buena parte de las veces la respuesta es que va bien y ya está. Eso también sirve: alguien que lleva tres días con algo sin saber si va en la dirección correcta avanza más despacio que alguien que lo sabe.

El caso que más se repite no es que alguien se equivoque. Es que falta algo que en negocio se daba por hecho, y justo por eso nadie lo escribió.

Me lo enseñó funcionando. Hacía lo que ponía en el ticket y estaba bien resuelto. Al verlo en pantalla me di cuenta de que faltaba una condición que en las conversaciones de negocio se asumía tanto que a nadie se le había ocurrido decirla en voz alta, y a mí tampoco al escribir la tarea. Se corrigió ahí mismo, y fue pequeño porque lo vimos pronto.

Lo importante de ese caso es que él no había hecho nada mal. No tenía forma de saberlo: esa información no estaba escrita en ningún sitio, estaba en una reunión a la que no fue.

En lo técnico también me meto. Reviso y opino, y propongo cosas cuando veo una manera mejor. Pero ahí estoy aportando experiencia en un terreno donde ellos ya son buenos. Lo de negocio es lo que les quito de encima.

Cómo cambia esto al crecer

Con más gente el paraguas no lo sostiene una persona sola, y hay que repartirlo. Parte del trabajo pasa a ser que otros puedan sostener su propio trozo.

Repartirlo no es lo mismo que quitarlo. La ambigüedad no desaparece porque el equipo crezca, y hace falta que alguien la pare antes de que llegue al que está construyendo. Ese trabajo existe en cualquier tamaño de equipo; lo que cambia es entre cuántos se reparte.

Porque el error caro no es una línea mal escrita, que se arregla en una tarde. Es construir durante días algo que no era.