Por qué contratamos a Ingenieros de producto y a no ninjas

Después de escribir sobre máquinas de café en mi último artículo, he descubierto que es un tema más controvertido de lo que esperaba. El ejemplo del café es tan solo un ejemplo random de las cosas a las que NO se les debería dar tanta importancia a la hora de escoger a una empresa en la que trabajar. Pero para mí, una máquina de café representa mucho más... ¡toda una inspiración para este artículo!

Estaba haciendo una pausa y charlando en la cocina de nuestra ofi, mientras observaba a mis compis de Xolo que rellenaban sus tazas con ese líquido amargo y con cafeína que les da la energía para afrontar su jornada laboral (yo en realidad prefiero el té de menta). Fue ahí que me quedé reflexionando sobre todas las cosas que hacen que nuestro equipo de ingeniería de software sea la crème de la crème de los equipos de ingeniería de software. Así que, si te interesa, voy a compartir contigo qué es lo que nos hace especiales.

¿Qué hay detrás de un simple nombre? (spoiler: mucho más de lo que crees)

Últimamente me han preguntado bastante qué hace exactamente alguien con el rol de "Ingeniero de producto" en Xolo. En Internet hay un montón de opiniones diversas sobre cómo deberían llamarse aquellos que trabajan con código todo el día (nos referimos al código de software, claro), así que he pensado en dar mi opinión sobre el tema y cómo lo aplicamos a nuestro equipo.

A los que hacen "esas cosas de informática y ordenadores" se les llama de mil y una maneras. Desarrolladores. Frikis. Ingenieros de software. Programadores. Hackers. Técnicos. Especialistas en informática. Recuerdo una época en la que estaba de moda crear nombres inventados como "Gurú del Código" o "Ninja del Software". 

Yo me quedo con “Ingeniero de producto” y voy a explicarte por qué:

Trabajamos en un producto, no en un proyecto

Puede que algunas de nuestras iniciativas parezcan proyectos, pero nanay. Cuando la gente se entera de que ni siquiera tenemos Project managers en nuestro equipo, ¡flipan! Pero es que enfocamos nuestro trabajo de otra forma. Nuestro trabajo es un continuo aprendizaje, es plantearse a diario qué es lo que podríamos desarrollar para aportar el máximo valor. Dicho de otro modo, ¿a quién le interesa que construyamos esta nueva funcionalidad? La respuesta no debería ser únicamente “a los Product managers”, sino a que a los “Ingenieros de producto” también debería interesarles. Porque, ¿quién quiere invertir su tiempo, energía y capacidades en desarrollar algo que al final nadie quiere?

Empieza con "¿Por qué?"

Es crucial que todo el equipo entienda *por qué* estamos desarrollando lo que sea que estemos desarrollando en ese momento. Creo que hasta que los ingenieros no tienen la respuesta a esta importante pregunta, no pueden crear la solución más innovadora (y eficaz). Damos la posibilidad a todos los miembros del equipo, por igual, de fijar los objetivos y las hipótesis, hacer la investigación que sea necesaria y, por supuesto, decidir cómo se implementa todo. Además valoramos la autonomía de nuestros empleados, nos gusta que nuestro equipo trabaje de manera independiente y les damos la autoridad para tomar decisiones que tengan impacto. 

Ninguno de nuestros ingenieros quiere crear código sin sentido y, lo que es más importante, sin saber dónde va a parar o qué uso se le va a dar. En Xolo velamos para que cada uno de ellos sepa que el software que han creado tiene un impacto positivo para nuestra empresa y, por supuesto, para nuestros usuarios. Es vital entender qué piensan nuestros clientes de nuestros productos y por eso les pedimos que compartan su opinión a través de nuestra NPS o a través de entrevistas personalizadas. De esta manera evaluamos el feedback de nuestros clientes y determinamos su interés en las distintas funcionalidades de nuestro producto. También apostamos por el análisis continuo de los datos para tomar mejores decisiones (y más adecuadas). Todos los datos y los insights que recoge nuestro equipo de BI están disponibles para todos los miembros de la empresa. Lo que quiere decir que los ingenieros podrán analizar la información directamente desde la fuente siempre que lo necesiten para sus desarrollos.

Aunque somos una empresa tecnológica, no todo se reduce a desarrolladores. Nuestro equipo de Service Delivery (quienes se encargan de manejar el back-office) es increíble. La pregunta es: ¿pueden nuestros ingenieros de producto ayudarles a optimizar su trabajo? Hicieron un análisis de datos y se dieron cuenta de que este equipo pasaba la mayor parte de su tiempo procesando las facturas de compra de nuestros clientes. Hay decenas de miles de facturas cada mes que deben ser revisadas añadiendo, por ejemplo, la categoría de gasto correcta y las normas de imposición para los informes contables y fiscales (y eso supone muuucho tiempo que podría ser usado de otra manera). Al automatizar este paso, se consiguió devolver semanas enteras de trabajo cada mes para el equipo de Service Delivery y, al hacerlo, hicieron que nuestra oferta de productos fuera aún más escalable.

La metodología Agile es nuestra aliada

Nuestro equipo sigue el marco de trabajo de Scrum. Cada dos semanas, organizamos una sesión en la que están invitados todos los empleados de la empresa (no es obligatorio asistir, pero está abierto a todo el mundo) y hacemos una demo de las últimas implementaciones. Nuestros ingenieros aprovechan esta oportunidad para presentar las mejoras que han creado para nuestra plataforma. No sólo enseñan cómo funciona, sino que, también comparten el valor real que ha aportado ese cambio para nuestros usuarios. Por ejemplo, cuántos de nuestros clientes se han dado cuenta de que ahora nuestro producto es más fácil de usar e intuitivo o cuántas horas de trabajo manual nos hemos ahorrado gracias a la automatización (como comentábamos anteriormente). Esto no sólo sirve para justificar su trabajo, sino, lo que es más importante, para dar contexto y sentido a estas mejoras. 

Y como tenemos de tres a cinco mejoras al día, estas reuniones siempre están repletas de información y aprendizajes útiles. Lo que me lleva al siguiente punto…

El aprendizaje continuo es la clave

Aunque todos los miembros de nuestro equipo quieren crear un código elegante que genere valor, a veces nuestras hipótesis no funcionan en la vida real. Y a menudo, no son las soluciones sofisticadas que inicialmente nos propusimos crear. Pero eso no significa que las veamos como errores. Por el contrario, los vemos como una oportunidad para aprender y mejorar. Normalmente, un análisis de causa raíz (ACR) se realiza después de una escalada y contiene frases performativas como "Esta es nuestra máxima prioridad para resolver" o "Nuestro equipo se compromete a garantizar que esto no vuelva a suceder". Nadie nos pide estos ACR. Al contrario, decidimos que los necesitábamos para nosotros mismos. 

Tenemos una reunión periódica de ACR para todo el equipo en la que presentamos al resto del equipo lo que ha aprendido alguien del equipo para que los demás eviten cometer los mismos errores. A partir de esta información, algunas veces hemos iniciado talleres o hemos cambiado los procesos existentes y ¡a veces ambas cosas! 

Por ejemplo, hubo un periodo de tiempo en el que tuvimos problemas con grandes cambios en nuestra plataforma. Como tenemos varios nodos de aplicación en nuestro clúster que comparten una base de datos común, cuando se lanzaba una nueva versión con cambios en la estructura de datos en todo el clúster, los diferentes nodos (ya actualizados y no actualizados) tenían diferentes expectativas para las estructuras de datos y esto causaba errores. Tuvimos que aprender a lanzar esos cambios en la estructura de datos en varios pasos para mantener la compatibilidad con las versiones anteriores hasta que todos los nodos estuvieran actualizados. Después de eso, ahora nuestro producto es más estable para los usuarios y el equipo se siente más seguro al enfrentarse a tener que hacer cambios más grandes. 

A medida que la vida cambia rápidamente a nuestro alrededor, la forma de trabajar también debe evolucionar para seguir el ritmo. Especialmente cuando se trabaja en un entorno de startup. Además de todas las novedades que lanzamos el año pasado, también lanzamos dos nuevos productos: Xolo Teams y Xolo España. A finales de enero de 2022 lanzamos nuestro quinto producto, Xolo Italia. 

Como puedes ver, este año ha tenido un comienzo productivo. Dicho esto, es una de mis principales prioridades inspirar a todos los miembros de nuestro equipo para que inviertan tiempo en aprender cosas nuevas y que establezcan los límites y el tiempo necesarios para seguir adelante. Esto podría significar el perfeccionamiento de sus habilidades técnicas en nuestra pila tecnológica o la adquisición de nuevos conocimientos sobre el aprendizaje automático. En otras ocasiones, dedican tiempo a desarrollar sus soft skills, como por ejemplo una mejor gestión del tiempo o estrategias para que su comunicación sea más eficaz con el resto de los equipos. En Xolo, la gran pasión por el software es algo que se valora y se fomenta. 

Esto no es una oferta de empleo

Pero sí, lo es. Lo cierto es que las ofertas de empleo suelen estar llenas de palabras ambiguas o palabras que de repente se han puesto de moda. Lo que hace realmente difícil llegar a entender en qué tipo de entorno estás postulando para trabajar, hasta que te contratan y ya estás dentro (y ya es demasiado tarde para pensárselo mejor). Como nuestra empresa está creciendo y estamos buscando nuevos talentos para unirse al equipo (y seamos sinceros, los desarrolladores con talento siempre tienen muchas opciones donde elegir), quería aprovechar esta oportunidad para mostrar por qué trabajar en el equipo de ingeniería de Xolo es diferente de otros equipos con los que puedas haber trabajado. No te queremos sólo por tus habilidades, te queremos por tu mente. Se te animará a que te hagas cargo de las cosas, a que tomes decisiones y tomes la iniciativa, a que hables y compartas tu opinión, a que construyas algo que realmente importe. ¿Suena esto a un sitio en el te gustaría trabajar? Si es así, ¡nos encantaría conocerte!

Ver vacantes

Sobre Piret

Piret lidera el Engineering Team en Xolo desde 2019. Como jefa, cree firmemente en un estilo de liderazgo que da prioridad a las personas y en el que la cultura de la autonomía y la responsabilidad personal se valoran por encima de todo. Su experiencia en comunicación le ha enseñado la importancia que tiene ser transparente, el tener expectativas claras y dar feedback constructivo y amable.
Conecta con Piret en LinkedIn

Este artículo una versión en español adaptada por Marta Puerto del artículo original de Piret: Why we hire Product Engineers, not Ninjas