Cómo lidero

Le doy al equipo metas concretas, buena documentación y tickets bien formados. Después el trabajo es suyo. Ordeno el sprint y nombro lo que se va a retrasar antes de empezar, para que el retraso sea un plan y no una sorpresa.

Cuando un lanzamiento está listo, el ingeniero que lo construyó lo ejecuta, no yo. Mi trabajo es despejar el camino. El suyo es recorrerlo.

Soy jugador-entrenador, y lo tomo literalmente. Llevo mis propios arreglos pequeños en todo el stack, los documento siempre igual, y cuando algo se rompe en producción me meto: pequeño, quirúrgico, rápido. Después devuelvo el cierre al equipo.

Seguir en el código mantiene mis revisiones honestas y mis estimaciones reales.

La retroalimentación llega en días, basada en el comportamiento real y el archivo real, registrada cuando ocurre para que nada dependa de mi memoria a la hora de la evaluación. Los elogios viajan. Las críticas no tienen audiencia.

Si tengo que dejar el mismo comentario dos veces, la tercera es una conversación directa, no otro comentario.

El buen trabajo que nadie vio es como si no hubiera pasado cuando se deciden las calificaciones. Así que pongo a mis reportes en el escenario: ellos presentan sus propios lanzamientos, se les nombra en los lanzamientos, y les enseño qué cuenta para el siguiente nivel.

Si no sé que pasó, no puedo defenderlo.

Un punto de control diario corto dentro de un día ya empezado. Viernes asíncrono. Los bloqueos se reportan en el momento en que aparecen, no se guardan para el standup.

Cuando una épica se desborda, recorto alcance para proteger una línea de meta en lugar de seguir todo tarde.

La palanca para crecer es una tarea de estiramiento con una definición clara de terminado: una épica multi-stack para quien demuestra responsabilidad más amplia, responsabilidad de lanzamiento de punta a punta para quien está listo para exceder, un módulo propio para quien es nuevo y necesita demostrar el nivel.

Yo defino el piso. Ellos lo estiman y lo ejecutan.