Escribiste el RFC. Está bien pensado, las opciones están documentadas, el trade-off es claro. Pero en la reunión donde lo presentas en inglés, algo se pierde: terminas explicando el historial completo de cómo llegaste a la decisión antes de decir cuál es la decisión — y para cuando llegas al punto, la sala ya está en otra conversación.
El problema no es el análisis. Es el orden en que lo cuentas en inglés.
El error más común: contar la historia en vez de pedir la decisión
Cuando un Tech Lead latinoamericano prepara un RFC, suele estructurar la presentación de forma cronológica: primero el contexto completo, luego cómo investigó las opciones, luego los detalles técnicos de cada una, y al final — si llega — la recomendación.
En español, ese orden se siente riguroso y respetuoso con la audiencia. En inglés, frente a un equipo americano, se lee distinto: como si no supieras todavía qué recomendar, o como si necesitaras convencerte a ti mismo mientras hablas.
Los RFCs que sí generan una decisión en la reunión invierten el orden: la recomendación va casi al principio, no al final.
El framework en 4 pasos: Problem → Options → Recommendation → Ask
Paso 1: El problema en una oración
Antes de cualquier detalle, nombra el problema que el RFC resuelve.
- "We need to decide how we handle schema migrations across services — right now it's manual and it's caused two incidents this quarter."
- "This RFC is about picking a caching layer before we hit the traffic increase in Q4."
Una oración. Sin historial de cómo llegaste ahí todavía.
Paso 2: Las opciones, de forma objetiva
Presenta 2-3 opciones reales, sin sesgo visible todavía.
"We looked at three approaches: keep the current manual process, adopt [tool], or build something in-house."
Para cada una, una línea de trade-off — no un párrafo:
- "Option A is zero effort but doesn't scale past [X]."
- "Option B solves it but adds a new dependency we'd need to maintain."
- "Option C gives us full control but costs [N] weeks we don't have right now."
Paso 3: Tu recomendación — directa, no oculta
Este es el paso que más se salta o se diluye. Dilo explícitamente:
"My recommendation is Option B." "Given the timeline, I'd go with Option A now and revisit Option C next quarter."
No: "I think maybe Option B could work, but I'm open to other ideas." Esa frase no es humildad — es ambigüedad, y en inglés se procesa como falta de convicción.
Paso 4: El Ask — qué necesitas de ellos
Cierra con la acción concreta que buscas en esa reunión.
"I need a decision by Friday so we can start next sprint." "I'm looking for objections — if there are none, we move forward with this." "I need someone from the platform team to confirm this doesn't conflict with their roadmap."
Sin este paso, un RFC bien escrito puede terminar en una reunión que "quedó en nada" — todos estuvieron de acuerdo con todo y nadie decidió nada.
Ejemplos de diálogo real
Situación: Elegir entre dos librerías para manejo de estado
Versión que diluye la recomendación:
"So we've been looking at this for a couple of weeks, there are a lot of factors to consider, both libraries have pros and cons, it kind of depends on what we prioritize as a team..."
Versión con el framework:
"We need to standardize state management before the new team joins next month. We compared Library A and Library B — A has better docs but a smaller community, B is more established but heavier. My recommendation is B, given team size. I need a thumbs up or a blocker by Wednesday."
Situación: Proponer deprecar un servicio interno
Versión que genera dudas:
"I'm not sure if this is the right call, but I was thinking maybe we could look into deprecating the old notification service at some point, if that makes sense for everyone."
Versión con el framework:
"The notification service costs us two incidents a quarter and nobody owns it. I recommend we deprecate it and migrate to [replacement] over the next sprint. I need the on-call team to confirm there's no hidden dependency before we start."
Situación: RFC que genera desacuerdo
Cuando alguien objeta, no defiendas el proceso completo — vuelve al trade-off puntual:
"That's a fair point on Option B's cost. Given that, does the timeline change your read on the recommendation, or is it a blocker either way?"
Esto mantiene la conversación en la decisión, no en re-litigar todo el análisis.
Qué practicar esta semana
Toma el próximo RFC o design doc que necesites presentar y estructura la introducción — antes de escribir una sola línea de detalle técnico — con estas cuatro frases:
- "We need to decide [problem]."
- "We looked at [N] options: ..."
- "My recommendation is [option], because [one reason]."
- "I need [specific ask] by [date]."
Si puedes decir las cuatro en menos de 30 segundos, tu RFC está listo para generar una decisión — no una discusión sin fin.
El Commit Method incluye situaciones de presentar recomendaciones técnicas en inglés — RFCs, design reviews, decisiones de arquitectura — donde practicas este framework en audio hasta que sale sin pensar.