Inglés para trabajo remoto: qué necesitas en un equipo internacional

En una oficina puedes salir del paso señalando una pantalla o preguntándole al de al lado en voz baja. En remoto y en inglés no tienes esa red: tu daily escrita y tu PR son toda tu presencia en el equipo, y cada palabra que tecleas queda registrada. Nadie te ve resolver un bug en quince minutos; ven el mensaje con el que lo explicaste. Este post va de eso — del inglés para trabajo remoto en las situaciones concretas donde te pone a prueba de verdad, con las frases exactas que puedes copiar en tu próxima daily, en un thread de Slack o en el traspaso de fin de jornada.

Qué nivel de inglés para trabajo remoto necesitas de verdad (y por qué el certificado importa poco)

La respuesta que vas a encontrar en todas partes es "necesitas un B2, mejor un C1". Es una respuesta de academia, no de equipo de trabajo. Un certificado mide que sabes elegir entre cuatro opciones en un examen de gramática y escribir una redacción sobre el cambio climático. Nada de eso aparece en un sprint. Lo que aparece es: entender un audio de Loom de tu tech lead a las once de la noche, leer un thread de GitHub con tres opiniones cruzadas y escribir un mensaje en el que pides acceso a un repo sin sonar como un bot.

En remoto hay dos competencias que de verdad usas a diario, y casi nunca son las que mide el examen: comprensión (leer y escuchar) y escritura clara. El speaking, que es lo que más miedo te da, es la tercera en importancia — y muchos días ni la usas, porque el equipo trabaja con solape horario mínimo. La mayoría de equipos distribuidos funcionan con tres o cuatro horas de coincidencia al día; el resto es asíncrono.

El mito que más daño hace es "tengo que hablar como un nativo". No. Necesitas que te entiendan y entender tú. Y lo que más va a doler al principio no es hablar: es el listening. El primer mes me costó muchísimo más entender a un compañero con un acento cerrado, hablando rápido en una call sin subtítulos, que hacerme entender yo. Mi acento marcado era un problema menor al lado de descifrar el suyo a toda velocidad.

En remoto el inglés escrito pesa más que el hablado

En un equipo async-first tu reputación técnica se construye por escrito. Los standups son mensajes en un canal, las decisiones se documentan en un doc o en el PR, las demos van grabadas. La gente con la que trabajas puede pasar semanas sin oírte la voz — pero lee tu descripción de PR, tu mensaje de Slack y tu comentario en Jira todos los días. Esos textos eres tú para ellos. Un buen PR description con contexto, capturas y el "por qué" del cambio te posiciona como alguien serio aunque tu pronunciación cojee.

El problema es que el hispanohablante arrastra unos cuantos vicios al escribir en inglés, y casi todos vienen de traducir literal. El clásico es "I have a doubt" cuando quieres decir "tengo una duda" — en inglés eso suena a que dudas de la honestidad de alguien; lo natural es "I have a question". Otro es meter "actually" en cada frase pensando que significa "actualmente" (significa "en realidad", y abusar de él suena correctivo). Y el tercero, el más común: frases kilométricas calcadas del español, con tres subordinadas, donde el inglés pide cortar en seco.

Cada una de las grandes piezas escritas del trabajo remoto tiene sus propias reglas de tono y formato: el mensaje de Slack con sus expresiones propias, la descripción de PR en inglés y el comentario de code review sin sonar brusco. No los reexplico aquí porque cada uno da para un post entero; lo que sí quiero que te lleves es la idea de fondo: escribir claro y corto no es opcional en remoto, es la mitad de tu trabajo.

El standup escrito, en tres líneas

En async el daily casi nunca es una call: lo escribes en un canal antes de empezar. La estructura es la de siempre —ayer, hoy, bloqueos— pero aquí es donde el hispanohablante se delata: lo calca del español en un párrafo lleno de gerundios. En inglés van tres líneas, verbo en pasado simple, y el blocker arriba si de verdad te frena. Si lo que te frena es explicar un fallo concreto, hay toda una técnica para describir un bug en el standup sin trabarte.

Y si no tienes bloqueos, escríbelo: "Blockers: none." Dejar el hueco en blanco hace que alguien acabe preguntando, y eso es justo el ida y vuelta que el async existe para evitar.

Sobrevivir a las reuniones cuando el solape horario es mínimo

Las pocas calls que tengas van a ir rápidas, sin subtítulos y sin que hayas podido prepararlo todo. Lo primero es aceptar que vas a perder frases, y que pedir que repitan no te hace quedar mal — te hace quedar como alguien que se preocupa por entender bien. La frase que más me ha salvado es simplemente avisar de que se cortó: "Sorry, you cut out — could you repeat the last part?". Le echas la culpa a la conexión, que la mitad de las veces es verdad, y nadie piensa que es tu inglés.

Cuando necesitas un segundo para ordenar la cabeza, gana tiempo con acción en vez de quedarte congelado. "Let me share my screen so it's easier to follow" te da diez segundos mientras compartes, y de paso la conversación pasa a apoyarse en algo visual, que es donde un dev juega con ventaja. Si quieres asegurarte de que has pillado un requisito antes de seguir, reformúlalo: "Just to make sure I got this right — you mean X, correct?".

Meter baza en una call con seis personas hablando rápido es otra historia. No esperes el silencio perfecto, porque no llega. Encadena al final de la frase de alguien con un "Can I add something here?" o "Building on what Marta said —". Y esa pausa incómoda, el "es que..." con el que en español rellenamos mientras pensamos, en inglés tiene su equivalente natural: no te quedes en silencio mortal, usa una muletilla limpia.

El handoff entre zonas horarias: pasar el testigo por escrito

Aquí es donde el inglés remoto se diferencia de verdad del de oficina. Cuando tu compañero entra a trabajar seis horas después de que tú te hayas ido, no puede girarse y preguntarte. Lo único que tiene es lo que dejaste escrito. Un handoff flojo le cuesta medio día esperando a que te conectes; uno bueno le deja seguir como si hubieras estado a su lado.

El mensaje de fin de jornada

El end-of-day update no es burocracia, es lo que mantiene el proyecto en movimiento mientras duermes. La plantilla que funciona es siempre la misma: dejas claro qué quedó cerrado y, sobre todo, qué necesitas de la otra persona cuando entre. Corto y escaneable.

EOD update 🌙
✅ Done: merged the auth refactor (PR #214), staging looks good.
🚧 In progress: migrating the user table — schema is ready, data
   backfill script is half-written (see branch feat/user-migration).
🙏 Need from you: review PR #214 when you start, and confirm whether
   we keep the legacy `role` column. I'm offline now, will catch up
   on the thread in my morning.

Dos frases para abrir o cerrar el traspaso conviene tenerlas siempre a mano: "Handing this over — full context is in the thread" y "I'll be offline by the time you read this, but here's exactly where I left it." Sobrecomunicar por escrito no es ser pesado; en remoto es justo lo que se espera de ti. El que escribe de más rara vez molesta. El que escribe de menos bloquea a medio equipo.

Dejar un blocker bien documentado

Un blocker mal escrito es el "it doesn't work" que todos hemos mandado alguna vez. No le sirve a nadie, y encima te obliga a un ida y vuelta de tres mensajes para sacar la información que deberías haber dado de entrada. Uno bien escrito responde cuatro cosas: qué falla, dónde, qué has probado y qué necesitas.

Las situaciones que más te van a doler (y cómo salir airoso)

Hay un puñado de momentos de fricción que se repiten en cualquier equipo internacional. La buena noticia es que son predecibles, así que puedes llevar las frases preparadas. Aquí tienes las que más vas a usar, con cuándo soltarlas:

El punto crítico de casi todas es el tono. En español somos directos y no pasa nada; traducido literal al inglés, esa misma frase suena agresiva. "I think you are wrong" es correcto gramaticalmente y un puñetazo en la mesa culturalmente. Lo mismo dicho con "I might be missing something, but..." abre la puerta a la conversación en vez de cerrarla. No es ser falso ni blando — es entender que en un thread escrito, sin tono de voz ni cara, la otra persona solo tiene tus palabras para interpretar la intención.

Cómo montar una rutina para llegar listo (sin gastarte 3000€)

No necesitas una academia ni un curso carísimo. Necesitas constancia diaria y, sobre todo, practicar el inglés exacto de tu trabajo, no el de un libro de texto. Entré en su día a un entorno internacional con el inglés al límite y lo que movió la aguja no fue ningún método mágico: fue apretar todos los días con los threads y los mensajes que me iba a tocar usar en el trabajo.

Una rutina realista que cabe en treinta minutos al día:

• Lee threads de proyectos de verdad. Issues de GitHub de proyectos open source serios, conversaciones de Slack de comunidades de devs. Te acostumbras al registro de un equipo que envía a producción, no al de un examen.
• Escribe tu daily aunque nadie lo lea. Tres líneas: qué hiciste ayer, qué harás hoy, qué te bloquea. Hazlo en inglés. El día que toque de verdad, ya no improvisas. Si quieres más material de este registro, tienes el resto de posts sobre el inglés de la daily para ir cogiendo soltura.
• Grábate dos minutos explicando una tarea técnica. Escúchalo. Vas a odiar tu voz y vas a detectar exactamente dónde se te traba la pronunciación. Es incómodo y funciona. Si prefieres practicar el ida y vuelta en directo, conversar con un tutor de IA sobre tu daily o un code review te da la presión de la call sin el ridículo delante de tu equipo.

Es lo que me habría venido bien hace unos años, peleándome con las reuniones sin nadie que me dijera qué frases funcionaban de verdad.

Cuándo NO te aplica esto

• Si tu equipo remoto trabaja en español o tienes solape horario completo con compañeros hispanohablantes, gran parte de la presión async-first desaparece y este post te sobra a medias.
• Si entras a un puesto muy senior donde tu inglés ya está rodado: ahí lo tuyo es pulir matices de tono en negociaciones, no sobrevivir a la primera daily.
• Si tu trabajo es casi todo síncrono por videollamada —algunos equipos pequeños siguen así—, vuelve a pesar el speaking y el listening en tiempo real más que el texto.
• Si el equipo tiene un canal de traducción o un PM bilingüe que hace de puente, la urgencia de tu inglés escrito baja bastante los primeros meses.

Sé honesto con qué tipo de equipo tienes delante antes de decidir dónde meter las horas.

Preguntas frecuentes

¿Qué nivel de inglés piden de verdad para un trabajo remoto de developer? Un nivel que te permita entender threads y audios sin perderte y escribir mensajes claros — en la práctica, un B2 funcional. El certificado importa poco: nadie te pide el título, te ponen a leer un PR y responder en Slack. Prioriza comprensión y escritura sobre conversación pulida.

¿Puedo trabajar en remoto en inglés si me defiendo mejor escribiendo que hablando? Sí, y de hecho juegas con ventaja. En un equipo async-first la mayor parte de la comunicación es escrita, así que un buen inglés escrito te cubre el 70% del día. El speaking lo irás soltando en las pocas calls que tengas, y como hay poco solape horario, tendrás menos exposición de la que temes.

¿Cómo sobrevivo a las reuniones si entiendo poco al principio? Pide que repitan sin complejos ("Sorry, you cut out — could you repeat that?"), comparte pantalla para apoyarte en lo visual y reformula los requisitos para confirmar que entendiste ("Just to make sure — you mean X?"). Grabar las calls (si el equipo lo permite) y revisarlas después acelera muchísimo el listening.

¿Cuánto tardo en defenderme en un equipo internacional? Con práctica diaria enfocada en el inglés real de tu trabajo, en unos meses pasas de sufrir cada daily a funcionar con soltura. El inglés para trabajo remoto no es cuestión de años ni de un curso caro — es constancia bestia con el material que de verdad vas a usar. La curva es incómoda al principio y luego se acelera.