Si no sabés programar, ¿cómo evaluás si el que programa lo hace bien? Es la pregunta que todo gerente, founder o product owner se hace en algún momento. Y la respuesta no está en revisar código — está en observar señales que cualquiera puede leer, sin importar su conocimiento técnico. Hay patrones que distinguen a un buen desarrollador de uno que solo parece ocupado.
Las señales de alerta
Un desarrollador que siempre dice «ya casi está» pero nunca entrega. Uno que te propone reescribir todo cada tres meses. Uno que no puede explicarte con palabras simples qué está haciendo y por qué. Uno que evita las reuniones de planificación o que nunca te pregunta sobre el negocio. Ninguna de estas señales es definitiva, pero juntas arman un cuadro. Un buen desarrollador no solo construye — comunica, pregunta y anticipa.
Qué métricas mirar sin entender código
No necesitás leer una línea de código para medir calidad. Mirá la frecuencia de deploys: si el equipo despliega poco pero con muchos cambios, hay riesgo. Mirá la cantidad de bugs que llegan después de cada release: si siempre hay sorpresas, algo falla en el proceso. Mirá si el equipo estima bien o si siempre se pasan del tiempo prometido. Mirá si hay tests automatizados y si se ejecutan antes de cada deploy. Estas son métricas que cualquier gerente puede trackear.
La conversación que tenés que tener
La mejor forma de saber si tu desarrollador está bien no es espiar — es preguntar. «¿Qué te está dificultando?» «¿Qué cambiarías de la arquitectura actual?» «¿Qué necesitás de mi parte?» Un buen desarrollador tiene respuestas honestas y específicas. Un mediocre dice que todo está bien o que necesita más tiempo. La diferencia entre un equipo técnico saludable y uno disfuncional se mide en la calidad de estas conversaciones, no en las horas de trabajo.
El mejor indicador no es técnico — es cultural. Un equipo que pregunta, que cuestiona, que propone es un equipo que está haciendo su trabajo. Un equipo que solo ejecuta sin entender el por qué está construyendo sobre arena.