Hay carreras profesionales que parecen dibujadas con regla: estudias, encuentras un puesto, te especializas y vas avanzando dentro de ese mismo camino. Y luego están las que se parecen bastante más a la vida real: pruebas, cambias, descubres cosas que no esperabas y, en algún momento, vuelves a un lugar que echabas de menos con una perspectiva completamente distinta.
La trayectoria de Ana García pertenece a este segundo grupo.
Ingeniera informática y desarrolladora de software, Ana comenzó su carrera profesional como backend developer. Por el camino descubrió el mundo de Developer Relations, se acercó a la creación de contenido, la comunicación, los eventos y el marketing, y terminó regresando a la ingeniería.
Pero volver a programar no ha significado volver al punto de partida.
Al contrario. Después de haber trabajado entre equipos técnicos, comunidades, comunicación y marketing, Ana vuelve a la ingeniería con una mochila bastante más llena. Y con una idea clara: una carrera profesional no tiene por qué ser completamente lineal para tener sentido.
De los tutoriales de YouTube a la ingeniería informática
Ana se define como “una chica a la que le encantan los retos”.
Desde pequeña estuvo rodeada de ordenadores y fue aprendiendo, principalmente a través de tutoriales de YouTube, todo aquello que despertaba su curiosidad. A esa inquietud tecnológica se sumaba otra habilidad que también acabaría teniendo mucho peso en su trayectoria: la facilidad para hablar en público y comunicarse con otras personas.
La combinación terminó llevándola a estudiar Ingeniería Informática.
“Juntas eso con una Ingeniería Informática… y sale algo parecido a mí.”
Su primera experiencia profesional llegó como backend developer. No hubo detrás una estrategia especialmente elaborada ni un plan de carrera a largo plazo.
“Empecé como backend developer porque fue lo que me interesó en el momento. No lo pensé demasiado, ya que era mi primera experiencia laboral.”
Y quizá ahí está una de las primeras lecciones de su historia: muchas veces el camino profesional empieza simplemente por probar algo que nos interesa.
Cuando una developer descubre el mundo de los DevRel
Durante sus primeros años como desarrolladora, Ana empezó a hacer cosas que iban más allá de programar.
Daba charlas, participaba con otros equipos, aportaba ideas para contenidos y se involucraba cada vez más en actividades relacionadas con la comunicación. Hasta que su empresa decidió acercarla al mundo de Developer Relations.
El pequeño detalle es que ella no sabía exactamente qué era DevRel.
“Yo no sabía qué era eso, pero desde fuera, creo que era evidente que ese puesto me quedaba como anillo al dedo.”
El cambio supuso entrar en un terreno completamente diferente. Ana empezó a trabajar entre desarrollo, documentación, contenido, eventos, comunidad y comunicación.
Y descubrió que muchas de las cosas que estaba haciendo no eran tan ajenas a su perfil como podía parecer.
“Yo acabé siendo DevRel sin saber lo que hacía, y cuando lo aprendí, me di cuenta de que llevaba años haciéndolo.”
La experiencia también le permitió descubrir algo que no había visto trabajando únicamente como developer: lo complicada que puede ser la comunicación dentro de una organización.
“Las cosas no son tan sencillas. La comunicación es clave en un proyecto. Se pierde mucho tiempo y dinero por problemas de comunicación, y estar en medio te da una perspectiva y una responsabilidad.”
Para Ana, programar correctamente puede aprenderse con tiempo, práctica y formación. Mejorar la comunicación, en cambio, es bastante más complejo.
“Programar bien puede llegar a aprenderlo cualquiera, pero ¿mejorar la comunicación? Eso es algo mucho más difícil.”
Y ahí aparece otro elemento que, según ella, tiene un peso enorme en cualquier equipo: el ego.
“El ego no es malo, todos lo tenemos, pero hay que saber cuándo aporta y cuándo no. Y aprender a gestionar los de los demás es importante.”
¿Qué hace realmente una persona de DevRel?
Desde fuera, Developer Relations puede parecer un concepto difícil de definir. Para Ana, la explicación más sencilla es que un DevRel vive entre dos mundos.
Por un lado están los equipos de desarrollo. Por otro, todos aquellos perfiles que necesitan entender el producto desde fuera del código, incluidos usuarios, comunidades y otros equipos de la organización.
El trabajo consiste muchas veces en hacer de traductor entre ambos lados.
“Un DevRel es una persona que vive entre dos mundos.”
Eso implica generar contenidos muy diferentes: documentación que pueda entenderse, charlas, vídeos, eventos, comunidad o materiales que ayuden a explicar un producto.
Durante su etapa como DevRel, Ana pudo comprobar precisamente esa variedad.
Un día podía estar trabajando con el equipo de documentación para preparar un borrador sobre una funcionalidad. Otro, escribiendo el guion de un vídeo. Después podía tocar edición, una reunión con marketing para preparar publicaciones o la organización de un evento externo.
“Era muy variado, y me gustaba.”
Esa variedad es también parte de la exigencia del rol. No existe una única habilidad que defina a un buen DevRel.
Para Ana, hay algo más difícil de enseñar que cualquier conocimiento técnico: la curiosidad, el interés y la paciencia.
“Hay cosas que no se aprenden.”
No significa que la formación no sea importante. Significa que, para ella, los mejores profesionales tienen algo genuino que hace que determinadas tareas les salgan de manera natural.
Como ese profesor que recuerdas años después porque se notaba que disfrutaba enseñando.
“Un ‘buen’ profesional, sea del tipo que sea, tiene que tener algo genuino que haga que ese puesto le salga natural.”
El DevRel como puente entre tecnología y negocio
Una de las ideas que más se repite cuando se habla de DevRel es la de “puente”. Y para Ana no es una metáfora especialmente exagerada.
Es algo que se experimenta en el día a día.
Un DevRel necesita entender suficientemente bien la parte técnica para poder trabajar con los desarrolladores, pero también tiene que ser capaz de explicar productos y funcionalidades a personas que no tienen ese mismo conocimiento.
Eso no significa que un DevRel tenga que saberlo todo.
De hecho, Ana considera que una de las habilidades fundamentales es precisamente reconocer cuándo no sabes algo.
“Sólo necesitas conocer bien el producto o los productos en los que estéis trabajando. Y tener la honestidad de admitir cuando no sabes algo, con la humildad de preguntar y aprender cuando toca.”
¿Puede alguien ser DevRel en su primer trabajo? Ana es un ejemplo de que sí.
Pero si alguien le pregunta si recomienda llegar a ese puesto directamente desde la universidad, su respuesta es algo más prudente.
Ella considera útil haber pasado antes unos años por desarrollo, no únicamente para adquirir conocimientos técnicos, sino para entender cómo funcionan realmente los equipos y procesos.
“No puedes ser puente entre cosas que no conoces.”
Entre DevRel y marketing: dos mundos que necesitan hablarse
Trabajar cerca de marketing también permitió a Ana entender mejor las diferencias entre ambos roles.
A veces se piensa que, eliminando la parte técnica, un DevRel y alguien de marketing hacen prácticamente lo mismo. Para Ana, esa simplificación es un error.
El equipo de marketing tiene conocimientos y responsabilidades que un DevRel no necesariamente tiene: estudiar públicos, diseñar campañas, definir estrategias o trabajar sobre objetivos de comunicación.
El DevRel puede participar y aportar ideas, pero normalmente trabaja dentro de esas estrategias y ayuda a cubrir una necesidad muy concreta: aportar conocimiento profundo sobre el producto y el mundo técnico.
Por eso el concepto de puente vuelve a aparecer.
“Cuando se define a este rol como un ‘puente’, es algo real que notas en todo momento cuando trabajas de ello. Estás entre dos mundos.”
Y Ana tiene una forma bastante más divertida de resumirlo:
“Una Hannah Montana, pero menos glamurosa.”
Lo que cambia cuando sales de tu zona de confort
Uno de los aprendizajes más interesantes de su experiencia llegó precisamente cuando dejó temporalmente de estar centrada en el desarrollo.
Ana no considera que las habilidades que adquirió como developer fueran las que la llevaron a destacar en comunicación o comunidad. Su interés por esos ámbitos venía de antes.
Pero el proceso inverso sí fue muy evidente.
Al volver a la ingeniería, descubrió que todo aquello que había aprendido fuera del código tenía un impacto directo en su forma de trabajar.
Escribir buenos textos, hablar en público con tranquilidad, explicar conceptos complejos de manera sencilla, organizar grupos de trabajo o compartir conocimiento con compañeros son habilidades que pueden marcar una diferencia importante dentro de un equipo técnico.
“Es algo que siempre aporta y pocos le dedican tiempo a mejorarlo.”
Y esa capacidad de comunicación puede convertirse en una ventaja profesional.
Incluso cuando el objetivo de alguien sea simplemente programar y trabajar tranquilo dentro de un equipo.
“Saber no ocupa lugar y tener estas habilidades te hace destacar y convertirte en un ‘unicornio’.”
La charla en Alemania que cambió las reglas del juego
La relación de Ana con la comunicación pública dio un salto cuando llevaba menos de un año en su primer trabajo.
Apareció la oportunidad de viajar a Alemania para dar una charla. Decidió hacerlo.
Y no era precisamente el escenario más sencillo para estrenarse: sería su primera charla profesional y, además, en inglés.
Con apoyo de sus compañeros para prepararla, se plantó delante del público.
Y ocurrió algo que ella misma todavía recuerda con cierta sorpresa.
“Yo no recuerdo nervios, sólo recuerdo pasarlo muy bien y querer repetirlo.”
No sabe exactamente de dónde salió aquella seguridad ni por qué se atrevió a hacerlo. Pero sí sabe qué ocurrió después.
Quiso repetir. Desde entonces, los eventos, las charlas y la creación de contenido se convirtieron en una parte habitual de su trayectoria.
Y fue precisamente esa mezcla entre ingeniería y comunicación la que acabaría llevándola hacia DevRel.
Lo que cambia cuando trabajas con otros departamentos
Salir del mundo puramente técnico también obligó a Ana a enfrentarse a algunos prejuicios.
Ella misma reconoce que tenía ideas preconcebidas sobre departamentos menos técnicos antes de trabajar más cerca de ellos.
“Yo también tenía muchos prejuicios sobre departamentos menos técnicos.”
Algunos terminaron confirmándose dependiendo de las personas con las que trabajaba. Otros, en cambio, desaparecieron por completo.
La conclusión fue bastante sencilla: generalizar sirve de poco.
Trabajar con perfiles diferentes le permitió ver de primera mano que una organización tecnológica necesita mucho más que buenos ingenieros.
Y que entender lo que hacen otros equipos también forma parte de ser un buen profesional.
Volver a programar no significa volver a ser la misma developer
Con el tiempo, Ana empezó a echar de menos algo.
Programar.
“Yo soy una feliz ingeniera y necesitaba esos retos técnicos.”
Por eso decidió volver a la ingeniería.
Y la Ana que volvió no era exactamente la misma que había salido.
“Para nada.”
Su forma de entender la comunicación dentro de los equipos había cambiado. Ahora presta mucha más atención a cómo se documentan las decisiones, a explicar por qué se hacen las cosas y a dejar información clara para quienes tendrán que trabajar después sobre ese código o esa funcionalidad.
“No aprendí nada nuevo sobre programación, pero aprendí mucho sobre comunicación entre equipos.”
Dos lobos y una carrera profesional
Volver a la ingeniería no significó abandonar la comunicación. Ana lo explica con una imagen bastante gráfica: dentro de ella conviven dos lobos.
“Uno me pide hacer temas de comunicación, de hablar en público, de comunidad… y otro me pide programar y acabar con dolores de cabeza después de sacar una feature nueva.”
La diferencia es que ahora ha encontrado una manera de escuchar a los dos.
Su actual empresa le permite colaborar ocasionalmente con marketing y continuar participando en eventos y dando charlas. Así puede mantener esa parte de su perfil sin renunciar a aquello que echaba de menos.
La solución no ha sido elegir definitivamente entre ingeniería y comunicación.
Ha sido encontrar una forma de hacer convivir ambas.
Una carrera profesional no tiene por qué ser una línea recta
La historia de Ana también plantea una pregunta cada vez más relevante en tecnología: ¿hasta qué punto necesitamos tener una trayectoria perfectamente definida?
Su respuesta no es un “haz lo que quieras” sin matices.
Por un lado, considera que encontrar pronto aquello que te gusta y especializarte puede ser una ventaja.
Pero también cree que cambiar de rol, probar algo diferente o explorar otras áreas no debería interpretarse automáticamente como un fracaso o un retroceso.
“Nos lo merecemos, salimos al mundo laboral sin tener idea de nada.”
La clave está en hacerlo con cierto margen y siendo consciente de lo que se está buscando.
“Me gusta este sector y me hace feliz.”
¿Y si cambiar de camino te penaliza?
Ese miedo también estuvo presente en su propia experiencia.
Cuando empezó a acercarse a DevRel, Ana se sentía demasiado joven para reducir su carga de programación. Le preocupaba que aquello pudiera perjudicarla profesionalmente en el futuro.
“Me sentía demasiado joven para ser DevRel y bajar mi carga de programación. Sentía que me penalizaría en el futuro.”
Una charla en Tarugo Conf terminó ayudándola a mirar la situación desde otra perspectiva. Allí conoció a una persona que le hizo una pregunta sencilla: ¿qué quieres estar haciendo dentro de cinco años?
No tenía por qué tener todas las respuestas en ese momento.
Podía probar.
Podía cambiar.
Podía volver atrás.
Y esa idea terminó siendo importante para ella.
“Es normal sentir miedo, y la única forma de superarlo es sentarse y ordenar las ideas.”
No hace falta decidir una carrera profesional completa de una vez.
“No tienes que levantarte un martes a las 8 y tener decidida tu vida a 10 años vista. Puedes simplemente tener decidido qué harás hoy.”
La única forma de saberlo es probar
Para Ana, explorar no significa necesariamente abandonar un trabajo y empezar de cero.
Muchas cosas pueden probarse antes, de manera pequeña.
Si quieres saber si te gusta DevRel, puedes empezar hablando en público. No necesitas subirte a un escenario internacional. Puede ser un evento pequeño, una charla entre amigos o incluso una PowerPoint party.
Si te interesa cloud, puedes hacer un curso y comprobar si realmente te gusta.
Y si algún día quieres dejarlo todo para montar un huerto, también tiene una solución:
“Empieza con una cebolla en la terraza y a ver qué pasa.”
Detrás del humor hay una idea bastante práctica: experimentar es una forma de conocerse.
Porque a veces pensamos que sabemos lo que queremos simplemente porque nunca hemos probado otra cosa.
“La única forma de saberlo es probando.”
Conclusión
La trayectoria de Ana García demuestra que una carrera tecnológica no tiene por qué construirse siguiendo una única dirección.
Pasar de backend a DevRel, acercarse a comunicación y marketing y después regresar a la ingeniería no ha sido un desvío inútil. Cada etapa le ha permitido incorporar una perspectiva diferente y entender mejor cómo se relacionan el código, los equipos, el negocio y las personas.
También deja una reflexión importante para quienes sienten que están alejándose demasiado de su camino profesional por probar algo diferente: cambiar no significa necesariamente perder lo que ya has construido.
A veces significa volver con más herramientas.
Ana no ha dejado de ser ingeniera por haber explorado otros mundos. Al contrario, ha regresado a la programación entendiendo mejor la importancia de explicar, documentar, escuchar y trabajar con personas que ven los problemas desde perspectivas diferentes.
Y quizá esa sea la idea que mejor resume toda su trayectoria: no hace falta saber exactamente dónde vas a estar dentro de diez años para tomar una buena decisión hoy. A veces basta con probar algo, descubrir qué te aporta y decidir cuál será el siguiente paso.

