Tu ingeniero senior te escribe en Slack: "Hey, should I roll back the deploy or wait for the fix?" Tú estás en otra reunión. Respondes en dos minutos, pierdes el hilo de lo que estabas discutiendo, y la decisión termina siendo tuya — otra vez. No porque quisieras tomarla. Porque él te la entregó con una pregunta, y una pregunta bien hecha es difícil de no responder.
Esto se repite cinco veces por semana. No es el deploy. Es el patrón: tu equipo trae preguntas en inglés, tú traes respuestas, y cada respuesta refuerza que la decisión pasa por ti primero.
El error más común: confundir delegar con dar permiso
El Tech Lead que quiere delegar hace una cosa consistentemente mal: delega la tarea, pero conserva la decisión. Le dice a su reporte "you handle the rollback" y después agrega "just check with me before you do it." La frase suena a delegación. Funciona como supervisión.
El reporte lo nota. Si cada acción pasa por tu aprobación, da igual quién la ejecute — la decisión sigue siendo tuya. Y en inglés el patrón se vuelve más rígido todavía, porque el reporte que no domina el idioma evita la ambigüedad del todo: en vez de proponer, pregunta. Es más seguro preguntar mal que proponer mal.
El capitán de submarino L. David Marquet encontró la misma dinámica en el USS Santa Fe, un submarino nuclear con el peor desempeño de la flota del Pacífico. Sus oficiales no tomaban malas decisiones. No tomaban ninguna. Cada orden pasaba por él, así que cada error también. El problema no era competencia. Era que nadie más que él tenía permiso de decidir.
El framework: "I intend to..."
Marquet cambió una sola frase y con eso cambió quién decide. En vez de que un oficial preguntara "should I take the ship down to four hundred feet?", debía decir "Captain, I intend to take this ship down to four hundred feet." Marquet respondía "very well" — o pedía el dato que faltaba antes de confirmar. La decisión ya estaba tomada. Su rol era auditarla, no producirla.
Tres pasos para instalarlo con tu equipo:
1. Cambia la pregunta que aceptas. La próxima vez que alguien te escriba "should I...?", no respondas la pregunta. Responde: "What do you intend to do?" Lo obligas a convertir la pregunta en una propuesta antes de que tú intervengas.
2. Exige el criterio, no solo la acción. "I intend to roll back" sin contexto es una orden disfrazada de propuesta. "I intend to roll back — the error rate doubled in the last ten minutes and the fix isn't verified yet" te da lo que necesitas para confirmar en tres segundos sin pedir que te explique nada más.
3. Responde con "very well", no con la decisión mejorada. Si tu respuesta habitual es reescribir su plan, sigues decidiendo tú. Confirma cuando el criterio es sólido, aunque no sea exactamente como tú lo habrías hecho. La corrección que no cambia el resultado no vale el costo de enseñarle que su decisión no era suficiente.
Por qué "very well" funciona y "good job, but..." no
Marquet aprendió algo contraintuitivo en el proceso: no bastaba con pedir intenciones. Si cada "I intend to..." terminaba en una corrección tuya, el equipo aprendía la lección real — proponer no vale la pena, porque de todas formas vas a reescribir el plan. La autoridad que delegas se mide por cuántas veces confirmas sin tocar nada, no por cuántas veces escuchas una propuesta antes de cambiarla.
Esto exige dos condiciones que van antes de la frase. La primera es competencia: tu reporte necesita el conocimiento técnico para que su "I intend to..." valga algo — si no sabe leer un dashboard de error rate, pedirle que decida solo traslada el riesgo. La segunda es claridad: necesita entender qué estás optimizando (¿uptime sobre velocidad de fix? ¿comunicación con el cliente sobre resolución rápida?) para que su criterio coincida con el tuyo sin que tengas que corregirlo cada vez. Delegar sin esas dos cosas no es empoderamiento — es abandonar al equipo con la decisión y el riesgo, sin las herramientas para tomarla bien.
La frase se siente extraña la primera vez que la dices en inglés — "very well" suena más seco de lo que estás acostumbrado a decir en español, donde probablemente agregarías un "dale, perfecto" o un "sí, hazlo así". No necesita el suavizante. La brevedad es la señal: estás confirmando, no negociando. Si le agregas explicación cada vez, vuelves al patrón anterior — la decisión parece suya pero la justificación sigue siendo tuya.
Cómo se ve en inglés, en una conversación real
Reporte: "Hey, the payments service is throwing 500s intermittently — should I restart the pods?"
Tú: "What do you intend to do?"
Reporte: "I intend to restart the pods one at a time instead of all together — if it's a memory leak, restarting all of them at once risks a bigger outage window."
Tú: "Very well. Ping me if the error rate doesn't drop in five minutes."
La diferencia con el patrón anterior no es el resultado — probablemente ibas a aprobar el restart de todas formas. La diferencia es que tu reporte llegó con un criterio explícito, lo dijo en voz alta, y la próxima vez que algo falle intermitentemente no te va a preguntar. Va a decidir con el mismo razonamiento que ya confirmaste una vez.
Qué practicar esta semana
Elige una sola conversación recurrente con tu equipo donde siempre terminas decidiendo tú — un deploy, un rollback, una asignación de tarea. La próxima vez que te traigan la pregunta en inglés, no respondas la pregunta. Pide el intento: "What do you intend to do?" Confirma con "very well" si el criterio aguanta. El patrón se instala después de la tercera o cuarta vez, no la primera — la primera vez que lo hagas, probablemente te va a seguir preguntando por costumbre.