MANRIQUE GARCÍA, Technical Account Manager en Red Hat

"Si participas, si preguntas y si ayudas, la gente sabe que puede contar contigo"

Qué es un Technical Account Manager?

Es un rol de acompañamiento al cliente. Por un lado están los consultores de IT, que instalan el producto. Pero, una vez instalado, el cliente necesita soporte, orientación y acompañamiento para evolucionar el producto dentro de su infraestructura. Yo doy servicio a varias empresas y las acompaño en el uso y evolución del producto.

¿Son empresas de España o das servicio a un mercado más amplio?

Principalmente doy servicio en España, aunque nuestro equipo depende de la región EMEA. Trabajamos juntos y a veces damos soporte a otras cuentas, pero nuestro foco principal es regional. Para muchos clientes es importante tener a alguien que hable su idioma. Aunque el cliente sepa inglés, en momentos críticos o de crisis el idioma importa mucho.

En una crisis, uno se expresa mejor en su propio idioma.

Exacto. En esos momentos, comunicarse en el idioma del cliente ayuda mucho.

Vosotros trabajáis sobre todo con grandes corporaciones, las cuales tienen fama de ser lentas. ¿Cómo es trabajar con ellas? ¿Las metodologías ágiles han cambiado algo?

Son empresas grandes, con muchos equipos y responsabilidades, y mover las cosas cuesta. Hay mucha burocracia, muchos trámites y muchas capas organizativas. Es cierto que hay una tendencia hacia metodologías ágiles, pero normalmente se aplican en equipos pequeños. Es muy difícil extrapolarlo a toda la organización.

Las metodologías ágiles nacieron en proyectos de desarrollo de software, pero siempre existe la intención de extrapolarlas a toda la empresa.

Sí. Yo empecé a oír hablar de Agile hace ya muchos años, cuando estaba en IBM. Durante un tiempo parecía que todo el mundo quería imponer Agile en toda la organización, pero eso no funciona así. Ahora veo una tendencia más práctica: los equipos sienten que, aunque toda la organización no trabaje de esa forma, ellos sí pueden hacerlo porque les ayuda. Si luego se puede extrapolar, bien; y si no, tampoco pasa nada.

Cuando un equipo es Agile, ¿qué herramientas utiliza para organizar el trabajo?

Herramientas hay muchas. Mi recomendación es no empezar por la herramienta. Primero hay que estudiar cómo quieres trabajar y después escoger la herramienta que mejor se ajuste a tus necesidades. Las que más veo son Jira y Miro. También se sigue usando Trello, aunque a veces se cae en el error de pensar que por poner Trello ya eres Agile. La herramienta es solo un soporte; no te convierte automáticamente en ágil.

¿Crees que la figura tradicional del Project Manager ha perdido protagonismo frente a otros roles como el Scrum Master o el Product Owner?

Es verdad que el rol se está modificando, pero hay tareas del Project Manager tradicional que siguen siendo necesarias. En nuestro caso, aunque trabajemos con metodologías ágiles, cuando un cliente pide un proyecto sigue siendo necesario alguien que defina el alcance, gestione el proyecto y mantenga una visión global.

Si no existiera esa figura, algunas tareas de gestión tendrían que asumirlas los equipos de desarrollo.

Claro. Hay tareas como la gestión presupuestaria, la gestión de horas o la coordinación global que no deberían recaer sobre el equipo técnico. El equipo de desarrollo debe centrarse en desarrollar. Recuerdo una situación en la que, durante una incidencia crítica, se pidió a un desarrollador que entrara en una reunión. Él dijo: «Puedo entrar y hablar, o puedo arreglar el problema, pero las dos cosas a la vez no puedo hacerlas». Y tenía razón.

Desde tu experiencia como Project Manager y como profesional con muchos años en IT, ¿qué habilidades crees que son importantes para hacer bien ese papel?

Además de las habilidades académicas o las que pueda indicar una certificación, creo que una de las más importantes es la empatía con el cliente. Un buen Project Manager tiene que entender qué pide el cliente, cuáles son sus presiones, qué impacto tiene el proyecto para él y cómo trasladar todo eso al equipo técnico. También tiene que acercar lenguajes: traducir las necesidades del cliente al lenguaje técnico y, al mismo tiempo, explicar al cliente lo que ocurre en términos que pueda entender.

Es un intermediario entre negocio y tecnología.

Sí. Y también tiene que mantener la calma. En situaciones de presión, eso es fundamental.

En esas situaciones de presión —por ejemplo, una puesta en producción que falla o una incidencia crítica—, ¿qué consejos darías para gestionarlas?

Lo primero es escuchar y entender por qué hay nervios, presión o reclamaciones. Después, mantener la calma y comunicar bien. Para mí, informar es clave. Recuerdo una situación hace años, cuando estaba en HP. Tuvimos un problema grave: se cayó una cabina y muchos sistemas dejaron de funcionar. Yo era técnico y coordinaba un equipo de Linux y Unix. Entramos en una sala de crisis para trabajar, y el responsable del proyecto se fue a otra sala. Me sorprendió, porque estaba acostumbrado a que los gestores entraran con nosotros y empezaran a preguntar. Pero él me dijo: «Tu trabajo es arreglar las cosas. El mío es informar al cliente para que esté tranquilo. Tú me vas contando, pero déjame hacer mi parte». Eso me pareció muy acertado. A veces pensamos que el cliente quiere una solución inmediata, pero muchas veces lo que necesita es saber cómo están las cosas.

Estoy de acuerdo. A veces, evitamos comunicar porque no tenemos buenas noticias, pero informar tranquiliza a todo el mundo.

Exacto. Otro punto importante es no buscar culpables en medio de una crisis. No es el momento. Lo importante es saber dónde estamos y cómo lo solucionamos. Después, una vez superada la crisis, sí conviene analizar qué ha pasado y qué se puede hacer para que no vuelva a ocurrir.

Hablas de hacer retrospectivas: revisar qué ha ocurrido y cómo mejorar.

Sí. Las retrospectivas son una práctica muy útil. Internamente sí las hacemos, aunque con clientes depende mucho de la metodología que imponga cada uno. Cuando trabajábamos en modo consultoría, íbamos al cliente, hacíamos el proyecto y nos íbamos. En esos casos no siempre puedes integrarte en el día a día del equipo del cliente. Pero cuando hay un modelo de servicio más continuo, sí tiene sentido hacer retrospectivas.

En los equipos técnicos —como, de hecho, en cualquier otro tipo de equipo— es normal que surjan conflictos. ¿Qué estrategia sueles seguir para gestionarlos?

De nuevo, escuchar a todos y entender los motivos de cada comportamiento. También es importante dar feedback de forma positiva. No se trata de decirle a alguien «lo estás haciendo mal», porque a nadie le gusta escuchar eso. Es mejor abrir una conversación: «Entiendo tu punto de vista, pero yo lo veo de otra forma. Vamos a discutirlo». Lo fundamental es no señalar a nadie y no buscar culpables. Eso aplica tanto en conflictos internos como en situaciones críticas.

Se habla mucho de la falta de profesionales de IT. ¿Lo estáis notando? ¿Trabajáis con equipos infradimensionados?

Falta de profesionales, en mi caso, no lo estamos notando especialmente. Equipos infradimensionados sí, pero por otros motivos: reducción de costes, decisiones organizativas, etc. Lo que sí veo es un cambio en el sector. Hace años, los profesionales más cualificados estaban en consultoras o fabricantes. Ahora muchos clientes finales están internalizando mucho conocimiento técnico. Cada vez me encuentro con equipos técnicos muy potentes en los clientes. A veces, cuando me hacen una pregunta, ya sé que no voy a resolverla directamente porque ellos ya han investigado mucho. Entonces tengo que ir al ingeniero correspondiente.

Si los equipos están infradimensionados, los profesionales pueden acabar trabajando muchas horas. ¿Cómo se mantiene la motivación?

Creo que una de las principales causas de desmotivación es estar demasiado tiempo en el mismo sitio, haciendo siempre lo mismo y con poca evolución. Una estrategia útil es rotar parcialmente a las personas. No cambiarles constantemente de proyecto, pero sí permitir que, en proyectos largos, puedan salir una o dos semanas a otro proyecto o a otro cliente. Eso refresca mucho. También es fundamental dejar tiempo para la formación. Si la gente tiene que formarse siempre en su tiempo libre, al final acumula horas sobre horas, y aparece el cansancio y la frustración.

¿La formación es solo técnica o también incluye soft skills?

Depende. Cada uno escoge su formación, normalmente orientada al trabajo que realiza. Pero también se fomenta mucho la formación en soft skills, sobre todo para perfiles que tratan con clientes. Siempre digo que no basta con ser bueno: también hay que parecerlo. Hay que saber explicar las cosas, adaptar el lenguaje y comunicarse bien con quien tienes delante.

Después de la pandemia, el teletrabajo ha cambiado mucho la forma de trabajar. ¿Funciona realmente el teletrabajo al cien por cien en IT?

Creo que depende mucho del carácter de cada persona. Sí puede funcionar, y funciona muy bien, pero creo que de vez en cuando hay que juntarse y verse las caras. Me ha pasado gestionar un equipo en remoto, ver a la gente todos los días por cámara y, cuando quedamos presencialmente en Madrid, no reconocer a algunas personas al entrar por la puerta. Las reconocía cuando hablaban, por la voz. La cámara cambia mucho la percepción. Por eso creo que es útil verse en persona de vez en cuando, hablar, conocerse y socializar.

También se afirma que la creatividad y la innovación funcionan mejor cuando las personas están juntas.

Exacto. Los días de oficina pueden ser menos productivos en cuanto a trabajo individual, pero a largo plazo aportan mucho: desconexión, conversación, creatividad, relación con el equipo. En Red Hat tenemos un servicio llamado Open Innovation Labs, pensado para ayudar a los clientes a trabajar con metodologías ágiles sobre casos reales. Se coge una aplicación real que el cliente quiere llevar a producción y se trabaja durante unos días, normalmente de forma presencial. Al final se presenta un MVP (producto mínimo viable) y se revisa cómo ha funcionado. Durante la pandemia se hizo en remoto, pero el resultado no era ni de lejos igual de bueno que cuando se hacía presencialmente.

¿Por qué crees que pasa eso?

Porque la participación cambia mucho. Si estás en casa usando Miro, puedes estar haciendo otras cosas a la vez. En presencial, si tienes que escribir un post-it, levantarte y ponerlo en una pizarra, participas de otra manera. En esas sesiones, incluso se limita el uso del portátil: solo se usa cuando toca programar. En sesiones de discovery, portátil fuera.

Todo evoluciona muy rápido: inteligencia artificial, nuevas tecnologías, nuevas herramientas… ¿Cómo te mantienes al día?

Difícilmente. Es difícil estar al día de todo. Lo que hago es leer noticias, participar en comunidades y estar en canales de Slack, Telegram, Discord o LinkedIn. Estar dentro de comunidades ayuda mucho. También es importante participar, no solo observar. Si te conocen, es más fácil abrir conversaciones, preguntar, conocer gente y enterarte de cómo se están haciendo las cosas. Además, intento asistir a eventos. No solo por la parte técnica, sino para ver cómo otros clientes o profesionales están resolviendo problemas. A veces una charla de media hora, con un caso de uso o una demo, te hace entender algo que no habías terminado de ver leyendo documentación.

Para terminar: ¿qué consejo le darías a alguien que está empezando su carrera profesional?

Le daría un consejo que a mí me costaba aplicar, sobre todo al principio: tener coraje. Significa no tener miedo a preguntar, a intentar cosas, a presentarte, a ir a eventos, a participar. Aunque te equivoques, no pasa nada. Aprendemos equivocándonos. También es una forma de hacerse valer. Si participas, si preguntas y si ayudas, la gente sabe que puede contar contigo. Quedarse agazapado por miedo a fallar no ayuda. Cada uno a su ritmo, pero sin miedo: sin miedo a tocar, a probar y a hacer cosas.

---------

Si te ha gustado esta aportación y quieres recibir otras parecidas, apúntate a la newsletter de Mejores Equipos aquí abajo. Es gratis y puedes darte de baja cuando quieras: