Emails profesionales en inglés para developers: plantillas

Las guías de emails profesionales en inglés te enseñan a escribir 'Dear Mrs. Price' y a despedirte con 'Sincerely', como si fueras a mandar una carta a un banco en 1995. Pero el correo que te pone a dudar es otro: avisar de que el deploy se ha caído, escalar un blocker que te tiene parado o responder a un recruiter sin sonar a plantilla pasada por un traductor. Ese mensaje lo relees cinco veces antes de darle a enviar, y aun así no sabes si suenas profesional o si parece que lo ha escrito Google Translate.

Aquí no hay teoría de business English. Hay plantillas para los seis correos que un developer manda en el día a día, la decisión de cuándo va a email y cuándo a Slack, y la lista de calcos del español que te delatan en cuanto el receptor los lee. Copia, adapta y envía.

Email o Slack: cuándo usar cada uno (y por qué el registro cambia)

Antes de escribir nada, decide el canal. No es lo mismo soltar un blocker en un DM de Slack que mandarlo por email a tres stakeholders, y el error más común es tratar los dos canales igual. Slack es para lo rápido, lo conversacional, lo que se resuelve en cinco mensajes —con su propio dialecto de expresiones como LGTM, PTAL o heads up. El email es para lo que necesita estructura, rastro y, normalmente, una decisión de alguien que no está en tu canal.

La regla práctica que uso: si el mensaje es largo, asíncrono y quieres que quede constancia, va a email. Si esperas respuesta en los próximos minutos y es entre tú y una o dos personas del equipo, Slack. El mismo blocker cambia de forma según el canal.

¿Cuándo toca dar el salto de chat a email? En el momento en que necesitas que algo quede por escrito y nadie pueda decir luego que no se enteró, o cuando metes en la conversación a alguien ajeno a tu equipo. También cuando hay una decisión formal de por medio —de esas que tendrás que releer con calma dentro de un mes para acordarte de por qué se tomó. Si mueves el hilo de Slack al correo, dilo en voz alta para que nadie se pierda:

En un equipo distribuido nadie espera que estés conectado a su hora. Lo que sí esperan es que tu email se entienda a la primera, sin tener que responderte pidiendo contexto. Eso significa más estructura y un punto más de registro que un DM: el receptor puede estar leyéndote ocho horas después y en otro huso horario.

El esqueleto de un email que se lee en 10 segundos

El receptor abre tu correo entre dos reuniones. Si en diez segundos no sabe qué le pides, lo cierra y vuelve "luego" — y luego no llega. Un buen email de trabajo se entiende de un vistazo: subject claro, primera línea al grano, una idea por párrafo y una petición explícita al final.

Empieza por el subject, porque mucha gente decide si abrir el correo solo con eso. Etiqueta la intención entre corchetes y resume el qué:

[Action needed] Prod deploy blocked — need DB access
[FYI] Staging back up, no action required
[Decision needed] Drop Node 16 support in the next release?

La primera línea no se gasta en cortesías. Di a qué vienes:

• "Quick update on the payments migration:"
• "I'm reaching out about the access request from yesterday."
• "Following up on the PR I opened Monday."

Y sáltate el "I hope this email finds you well". Es la cortesía vacía con la que abre la mitad de las guías de business English, no aporta nada y le roba la primera línea al motivo real del correo. El receptor quiere saber a qué vienes, no que le desees buen día.

Después, una idea por párrafo. El muro de texto donde el contexto, el problema y la petición van todos pegados obliga al receptor a releer para encontrar qué le pides. Sepáralo. Y cierra siempre con un CTA explícito: qué quieres, de quién y para cuándo.

Fíjate en el cierre de la versión buena: "Could you grant access by EOD today?" es una petición concreta con plazo. "It would be good if someone could maybe look at it" no compromete a nadie, así que no lo hace nadie.

Plantillas de emails profesionales en inglés por situación real (copia, adapta y envía)

Estas son las seis que realmente acabas escribiendo. Cópialas, cambia los datos y envía.

Status update / report de avance

Estructura el avance en tres estados —done, in progress, blocked— y di si llegas a la fecha o no. La honestidad sobre un retraso vale más que un "todo bien" que se desmonta el viernes.

Subject: [Update] Payments migration — on track for Friday

Quick update:
- Done: schema migration + tests on staging
- In progress: backfill script (~70%)
- Blocked: prod DB access (raised with infra)

Still on track for Friday, assuming access lands today.
If it slips, I'll flag it tomorrow morning.

Escalar un blocker

Avisa pronto y di exactamente qué te frena y qué necesitas para arrancar de nuevo. No es quejarse, es dar visibilidad. Yo aprendí esto por las malas: una vez mandé un blocker como DM de Slack a una sola persona, esa persona estaba desconectada, y la cosa no salió a la luz hasta que reventó el deploy. Por correo y con la gente correcta en copia, eso no pasa.

I'm blocked on the release: I don't have prod DB access and
can't run the migration. This is blocking Friday's deploy, so
flagging early. Could infra grant access today, or point me to
who can?

Pedir acceso o credenciales

Pide el acceso y di para qué lo necesitas. El "para qué" acelera la aprobación porque el otro no tiene que preguntártelo.

Could you grant me read access to the staging analytics DB? I
need it to validate the migration before Friday's deploy. Happy
to follow whatever access process you have.

Avisar de un incidente en producción

Sé factual y rápido. Qué pasa, desde cuándo, qué estás haciendo y cuándo darás la próxima actualización. Nada de adornos.

Subject: [Incident] Elevated 5xx errors in prod since ~14:00 UTC

We're seeing elevated 500s on the payments API since around
14:00 UTC. Investigating now — looks related to today's deploy.
I'll send an update in 30 minutes, sooner if anything changes.

Follow-up de un PR parado

El recordatorio educado existe en inglés y tiene fórmulas propias. "Gentle nudge" y "PTAL" (please take a look) son estándar y no suenan a que estás presionando. Y si el PR se te queda parado a menudo, a veces el cuello de botella está en cómo lo presentaste: una buena descripción de pull request en inglés te ahorra la mitad de los follow-ups.

Gentle nudge on this PR — it's blocking the next deploy. PTAL
when you get a sec. Happy to walk through it on a quick call if
that's faster.

Declinar o reprogramar una reunión

Di que no puedes, propón alternativa y no te disculpes tres veces. Una vez basta.

I won't be able to make the 3pm — conflict with the incident
review. Could we move it to tomorrow morning? I'm free 9–11 UTC.

Este vocabulario solo se te queda si lo repasas; meterlo en tarjetas de repaso espaciado evita que se te olvide justo el día que tienes que escribir el email a contrarreloj.

Responder a un recruiter o hiring manager sin quemarte

Te escribe un recruiter por LinkedIn o por email y tienes que contestar en inglés según tu interés real, sin sonar desesperado ni cortar de malas. Hay tres situaciones y cada una tiene su plantilla.

Si te interesa, muéstralo sin alfombra roja:

Thanks for reaching out — this sounds interesting. I'd be happy
to learn more. What does the team and tech stack look like?

Si no estás buscando pero no quieres cerrar puertas:

Thanks for thinking of me. I'm not actively looking right now,
but I'd be glad to stay in touch in case timing changes.

Si quieres datos antes de gastar una llamada —y haces bien en pedirlos—:

Before we set up a call, could you share the tech stack, whether
it's remote, and the salary range? That'll help me see if it's a
fit on both sides.

A mí me ha pasado quemar una llamada entera para enterarme al final de que el rango salarial no daba ni de lejos; desde entonces lo pregunto en el primer mensaje. El error clásico aquí es el inglés de carta antigua. "I am writing to enquire about the position" suena a 1990, y "Dear Sir/Madam" a un recruiter que firma con su nombre en el email es casi cómico. Te escribe una persona; respóndele como a una persona. Y si la cosa avanza, el primer email solo abre la puerta: las preguntas reales de una entrevista técnica en inglés son otro mundo, y soltarte en caliente —cuando el recruiter responde y toca seguir la conversación— se entrena mejor hablando con un tutor que releyendo plantillas.

Saludos y despedidas que no suenan a robot ni a carta antigua

El entorno tech es más informal de lo que enseñan los cursos. "Dear Mr. Smith" es casi siempre exagerado: lo reservas para un cliente externo formal, un tema legal o un primer contacto en frío con alguien que no conoces de nada. Para el día a día interno, la escala normal es esta:

• Lo habitual en tech: "Hi [name]," / "Hi team," / "Hey [name],"
• Formal en serio (raro): "Dear Mr. Smith," — cliente externo, legal, cold outreach

Con los cierres pasa lo mismo. "Sincerely" y "Yours faithfully" suenan a carta de instituto. En tech lo normal es corto y cálido:

Errores típicos del hispanohablante que te delatan en un email

Hay un grupo de calcos y falsos amigos que hacen que tu email suene traducido aunque la gramática esté perfecta. Estos son los que más veo.

Los falsos amigos primero, porque cambian el significado:

"Actually" no es "actualmente" (eso es currently). "Eventually" no es "eventualmente" sino "al final, con el tiempo"; si quieres decir "puede que", usa possibly. "Assist" no es asistir a una reunión (eso es attend), y "sensible" en inglés significa "sensato", no "sensible" —para datos delicados es sensitive.

Y luego los calcos directos del español, esas frases que traduces literal y que no le saldrían a ningún nativo:

• "I have a doubt" → "I have a question" (en inglés doubt es duda en el sentido de desconfianza).
• "Greetings," como saludo → suena a email de spam; usa "Hi [name],".
• Abusar de "Please find attached" → con "I've attached the logs" sobra.
• "Sorry to bother you" en cada frase → una disculpa basta; el exceso te hace parecer inseguro.

Sobre las contracciones: en un email de trabajo normal, "I'm" y "we'll" están perfectas. El "I am" y "we will" acartonados solo tienen sentido en un correo legal o muy formal. Escribir sin contracciones no te hace más profesional, te hace sonar como un manual de instrucciones.

Cuándo NO aplica

Estas plantillas resuelven el correo interno de un equipo tech moderno. Hay contextos donde el registro relajado juega en tu contra:

• Sector regulado o cliente externo formal (banca, legal, administración, sanidad): ahí sí esperan la estructura completa, el "Dear Mr. Smith" y el cierre formal. Soltar un "Hey, quick one" a un abogado de la contraparte resta credibilidad.
• Culturas corporativas muy jerárquicas (parte de Japón, Corea, algunas empresas alemanas tradicionales): el tuteo directo y el "Cheers" pueden leerse como falta de respeto antes que como cercanía. Observa primero cómo escriben ellos y copia el registro.
• Documentos contractuales o legales: contracciones, abreviaturas tipo EOD y emojis no pintan nada. Ahí la rigidez es una característica, no un defecto.
• Cuando el problema es de fondo, no de forma: si fallas en gramática básica —tiempos verbales, preposiciones, concordancia— las plantillas tapan el síntoma pero no curan la causa. Eso se arregla practicando, no copiando.
• Comunicación de crisis con clientes afectados: un incidente que toca a usuarios externos necesita un tono medido y, a menudo, una plantilla aprobada por la empresa. El "flagging early, looks related to today's deploy" es perfecto para tu equipo, no para un comunicado público.

Preguntas frecuentes

¿Es de mala educación ser informal en un email de trabajo en inglés? No, al contrario: en la mayoría de equipos tech lo formal de más suena raro y distante. La frase "Hi Sara, quick question about the API" es totalmente correcta y normal en el día a día. Reserva el registro formal solo para clientes externos, temas legales o un primer contacto en frío.

¿Tengo que poner 'Dear' siempre? No. "Dear" es para contextos formales (legal, cliente, cold outreach). Para el día a día con tu equipo, "Hi [name]," o "Hi team," es lo estándar. "Dear" con un compañero suena a que pasa algo grave.

¿Cómo pido algo sin sonar exigente ni demasiado servil? Usa una pregunta con could y añade el motivo: "Could you review this PR today? It's blocking the deploy." Es directo pero educado. Evita tanto el "Do this now" como el "I would be eternally grateful if you could possibly…".

¿Qué pongo en el subject si es urgente? Etiqueta la urgencia y di el qué: "[Action needed] Prod deploy blocked" o "[Urgent] Payments API down". La etiqueta entre corchetes hace que se entienda sin abrir el correo, que es justo lo que necesitas cuando es urgente.

¿Está mal usar contracciones (I'm, we'll) en un email profesional? No. En un email de trabajo normal son perfectamente profesionales y suenan naturales. El inglés sin contracciones solo es necesario en documentos legales o muy formales; en el resto te hace sonar rígido.

Dominar estos emails profesionales en inglés no es cuestión de memorizar fórmulas de cortesía, sino de saber qué situación tienes delante y mandar el mensaje sin releerlo cinco veces. Con las seis plantillas y los calcos controlados, ya tienes el 90% de tu bandeja resuelto; si quieres seguir engordando el repertorio, hay más frases hechas de inglés técnico para el resto de tu día a día.