"Have you considered what happens if that service goes down during a deploy?"
Un principal engineer que nunca habías visto en el canal de Slack lo pregunta a los tres minutos de tu presentación. No es una duda genuina — es la primera de varias objeciones que la sala tiene preparadas. El inglés de reunión que usas en standups y 1-on-1s no está diseñado para esto.
El error más común: sobre-explicar o ceder demasiado rápido
Cuando un Tech Lead enfrenta una objeción dura en inglés dentro de un architecture review board, cae en uno de dos patrones. El primero es sobre-explicar — responder con tres minutos de contexto adicional que nadie pidió, con la esperanza de que la objeción quede resuelta por agotamiento. El segundo es ceder de inmediato — "yeah, that's a good point, we could probably change that" — sobre una decisión que sí tenía un análisis detrás, solo porque la pregunta llegó en inglés y no en el idioma en que la pensaste.
Ninguno de los dos convence a la sala. El primero suena inseguro. El segundo suena a que la arquitectura no tenía fundamento.
El framework en 4 pasos: Repetir → Reconocer → Defender → Cerrar
Paso 1: Repite la objeción en tus palabras
Antes de responder, confirma que entendiste exactamente lo que están cuestionando. Esto compra el segundo que necesitas para pensar en inglés, sin que se sienta como una pausa incómoda.
Di: "So the concern is that a deploy failure on that service could cascade — is that right?"
No digas: "Um, yeah, so..." mientras piensas la respuesta en voz alta.
Paso 2: Reconoce la parte válida de la pregunta
No toda objeción es un ataque. Reconocer lo que la pregunta tiene de razonable evita que la conversación se vuelva defensiva desde el primer segundo.
Di: "That's a real risk if we don't handle the retry logic correctly."
No digas: "That's not really an issue." Cerrar la pregunta de golpe casi siempre suena a que no la consideraste.
Paso 3: Defiende con el trade-off específico que ya evaluaste
Aquí está el punto que separa una defensa sólida de una improvisada: nombrar la alternativa que consideraste y por qué la descartaste.
Di: "We looked at a synchronous call there, but that adds a hard dependency during deploys — the async queue trades a few seconds of delay for not taking the whole flow down."
No digas: "I think it should be fine."
Paso 4: Cierra confirmando si la objeción quedó resuelta
Termina con una pregunta que verifica si avanzas o si necesitas seguir defendiendo el mismo punto.
Di: "Does that address the concern, or is there a failure mode I'm missing?"
Esta pregunta invita a la sala a decir exactamente qué falta, en vez de dejar que el silencio se interprete como que ganaste el punto sin haberlo ganado.
El orden importa tanto como el contenido. Defender antes de reconocer suena a que ignoraste la objeción. Reconocer sin cerrar deja la conversación abierta y te obliga a volver al mismo punto tres preguntas después.
Antes de entrar a la sala: escribe las objeciones que ya conoces
La mitad del trabajo pasa antes de la reunión. Cada Tech Lead que presentó una arquitectura una vez sabe qué preguntas va a recibir — el punto de falla, el costo de la migración, la razón por la que no eligió la opción más simple. Escribir esas tres o cuatro respuestas en inglés antes de la reunión, con el framework de los cuatro pasos ya aplicado, saca la mitad de la sala de la categoría "objeción que tengo que pensar en tiempo real" y la mueve a "objeción que ya practiqué".
Lo que queda para improvisar en inglés bajo presión son las dos o tres preguntas genuinamente nuevas — no las quince que la sala siempre hace.
Ejemplos de diálogo real
Escenario: objeción sobre un punto de falla
Principal Engineer: "Have you considered what happens if that service goes down during a deploy?"
"So the concern is a cascading failure during deploy — that's a real risk if we don't handle retries correctly. We looked at a synchronous call there, but that adds a hard dependency; the async queue trades a few seconds of delay for isolating the failure. Does that address it, or is there a failure mode I'm missing?"
Cuatro movimientos, sin pausa incómoda y sin cesión automática.
Escenario: la sala insiste después de la primera respuesta
Principal Engineer: "I still think the coupling here is risky."
"Fair — where specifically do you see the coupling? If it's the shared schema, that's intentional; if it's the deploy order, that's something we haven't locked down yet."
Pedir especificidad convierte una objeción general — difícil de responder en inglés bajo presión — en una pregunta concreta que sí puedes contestar con datos.
Escenario: dos personas de la sala discrepan entre sí
Principal Engineer A: "I'd rather see this synchronous — simpler failure modes."
Principal Engineer B: "Sync introduces the cascade risk we just talked about."
"Both trade-offs are real — sync is simpler to reason about, async avoids the cascade. Given that we've had two cascade incidents this quarter and zero complexity-related ones, I'd rather optimize for the failure mode we've actually seen."
Cuando la sala discrepa entre sí, la salida no es tomar partido — es nombrar ambos trade-offs y anclar la decisión en el dato que ya tienes, no en la opinión más reciente.
Qué practicar esta semana
Antes de tu próxima architecture review, prepara las cuatro frases para al menos dos objeciones que anticipes:
- "So the concern is [objeción], is that right?"
- "That's a real risk if [condición]."
- "We looked at [alternativa], but [razón del descarte]."
- "Does that address it, or is there [algo] I'm missing?"
Si puedes producir estas cuatro frases sin pensar el orden, la sala deja de sentir que está esperando a que te recuperes del inglés — y empieza a sentir que está frente a alguien que ya pensó cada objeción antes de que la hicieran.