El sector de las TI en Ucrania hace tiempo que dejó de ser una historia local. Nuestros desarrolladores, especialistas en control de calidad, DevOps, diseñadores, analistas y gestores trabajan con clientes de EE. UU., Reino Unido, Europa y Escandinavia. Sabemos construir sistemas complejos, soportar la carga de trabajo, entender la arquitectura, cumplir con los plazos y encontrar soluciones donde otros solo ven un mensaje de error en rojo.
Pero en el mercado occidental, un código sólido ya no es suficiente.
El cliente no solo compra horas de desarrollo. Lo que compra es tranquilidad. Para él es importante saber que el equipo no se limita a «hacer algo en Jira», sino que realmente entiende el reto empresarial, es capaz de explicar los riesgos, proponer la mejor solución y señalar a tiempo: «Aquí es donde podemos perder tiempo, dinero o calidad».
Y es precisamente aquí donde el inglés deja de ser una «habilidad adicional». Se convierte en parte del peso profesional del especialista.
Durante mucho tiempo, en el mundo de la informática prevaleció la cómoda idea de que a un desarrollador le bastaba con saber leer la documentación. Algo así como: se abre Stack Overflow, se lee GitHub, los artículos técnicos se entienden de alguna manera. Así que todo va bien.
En realidad, eso es solo la punta del iceberg.
El desarrollo actual hace tiempo que dejó de parecerse a estar sentado en solitario en una habitación a oscuras con un café, código y un silencio heroico. Se trata de una comunicación constante: reuniones diarias, planificación, revisión de código, demostraciones, debate de requisitos, aclaración de detalles, llamadas con el cliente, análisis de problemas y defensa de soluciones técnicas.
Puedes leer perfectamente en inglés y, al mismo tiempo, quedarte en blanco cuando tienes que explicar rápidamente por qué una tarea no llevará dos días, sino una semana. Puedes entender la documentación, pero quedarte callado en una reunión cuando el cliente pregunta: «What are the risks here?»
Y en los negocios, el silencio rara vez se interpreta como modestia. Más a menudo se interpreta como falta de seguridad, falta de iniciativa o falta de comprensión de la situación.
Buenas noticias: no se espera de ti que hables como un locutor de la BBC. Los equipos occidentales llevan mucho tiempo acostumbrados a diferentes acentos, a distintos ritmos de habla y a una gramática imperfecta. En el sector internacional de las TI, lo importante es otra cosa: que se entienda lo que quieres decir.
El inglés profesional para TI no sirve para hablar con elegancia sobre el tiempo. Sirve para:
● explicar una solución técnica sin una introducción caótica de diez minutos;
● aclarar los requisitos antes de que el equipo se ponga a hacer lo que no debe;
● mencionar con calma un obstáculo;
● pedir más tiempo de forma argumentada;
● realizar una demostración;
● escribir un comentario claro en Jira;
● dar feedback en una revisión de código de manera que suene profesional, y no como un ataque.
Y aquí la diferencia entre «sé un poco de inglés» y «puedo trabajar en inglés» se hace muy patente.
Al inicio de la carrera, las habilidades técnicas pueden impulsar al especialista casi por sí solas. Los niveles Junior y Middle suelen crecer gracias al código, la rapidez de aprendizaje y la atención al detalle.
Pero a partir de ahí empieza otro juego.
Para pasar al nivel de Senior, Tech Lead, Solution Architect o Engineering Manager, ya no basta con limitarse a realizar bien las tareas. Hay que explicar las soluciones, dirigir debates, trabajar con las partes interesadas, entender el contexto empresarial y asumir la responsabilidad de la comunicación.
Y es aquí donde el inglés suele convertirse en un techo invisible.
Una persona puede tener unos conocimientos técnicos muy sólidos, pero si no es capaz de presentar con seguridad su idea al cliente, es menos probable que la incluyan en las reuniones estratégicas. Si no puede explicar una solución arquitectónica, lo hará otra persona. Si se queda callada en las reuniones, su experiencia se queda dentro del equipo, en lugar de llegar a los ojos del cliente.
Como resultado, la carrera parece avanzar, pero más lentamente. No porque falte inteligencia, sino porque falta voz.
Para una empresa de TI, el nivel de inglés del equipo influye directamente en la confianza del cliente. Especialmente si la empresa quiere trabajar con el mercado occidental no como «mano de obra barata», sino como socio tecnológico.
Cuando solo el PM o el analista de negocio hablan inglés con soltura, se produce el efecto del «teléfono estropeado». El cliente explica la tarea al gestor, el gestor se la transmite al desarrollador, el desarrollador aclara algo a través del gestor, el cliente responde y la respuesta vuelve a pasar por varios filtros. En cada etapa se pierden matices.
Y los matices en el ámbito de las tecnologías de la información suelen salir caros.
Los clientes occidentales quieren trabajar con equipos en los que el ingeniero pueda plantear preguntas por sí mismo, explicar los riesgos y proponer alternativas. Esto crea una sensación de colaboración. El cliente no ve simplemente a unos ejecutores, sino a personas que piensan junto a él.
De ahí surge la confianza. Y de la confianza surgen contratos más largos, tareas más complejas y un pago más elevado.
Cuando un profesional de las tecnologías de la información decide mejorar su nivel de inglés, la primera opción obvia es apuntarse a un curso de inglés general. Y eso es mejor que nada. Pero hay un problema.
En un curso de inglés general puedes hablar de viajes, comida, aficiones, películas, ecología o unas hipotéticas vacaciones junto al mar. Esto es útil para adquirir una base general, pero no siempre se puede aplicar al trabajo.
Y en el mundo real de las tecnologías de la información hay que hablar de cosas completamente diferentes.
¿Cómo explicar que una tarea está bloqueada por depender de otro equipo? ¿Cómo decirle a un cliente que su idea es técnicamente viable, pero que su mantenimiento resultaría muy costoso? ¿Cómo hacer una demostración sin entrar en pánico? ¿Cómo mostrar tu desacuerdo con una decisión de forma diplomática? ¿Cómo describir un error para que se entienda sin necesidad de tres mensajes adicionales?
Por eso mismo, el inglés para TI debe basarse en situaciones de trabajo reales: daily stand-ups, Jira, Git, revisión de código, demostraciones, entrevistas técnicas, correspondencia, llamadas con el cliente, discusión de plazos, riesgos y prioridades.
Aquí no se aprende el idioma «en general», sino para una acción profesional concreta.
Puedes empezar sin necesidad de un plan heroico para una nueva vida a partir del lunes.
Traduce a inglés las interfaces de trabajo: IDE, gestor de tareas, teléfono y los servicios que utilizas a diario. Escribe los mensajes de commit en inglés. Formula las tareas en inglés, incluso si el equipo es ucraniano.
Ve las charlas técnicas en su versión original. Después de una reunión, intenta resumir brevemente en inglés lo que se ha debatido.
Y lo más importante: entrena no solo tus conocimientos, sino sobre todo tu reacción lingüística. Porque durante una llamada no hay tiempo para recordar toda la gramática del libro de texto. Allí hay que pensar, escuchar, responder y no perder el hilo de la conversación.
Hoy en día, el inglés en el sector de las tecnologías de la información no es un adorno en el currículum ni un punto que «será una ventaja». Es una herramienta de trabajo que influye en la carrera profesional del especialista, en la confianza del cliente y en las oportunidades de la empresa en el mercado occidental.
El código demuestra lo que eres capaz de hacer.
El inglés demuestra que se te puede confiar más.
Y es precisamente esta diferencia la que a menudo distingue a un simple buen profesional de un especialista al que se invita a participar en proyectos más complejos, a ocupar puestos de mayor responsabilidad y a formar parte de las conversaciones en las que se toman las decisiones importantes.
