The (infamous) ultimate KPI: $
Cuando tenía 22 años tuve una charla a modo de “queja” con un gerente de una empresa que era cliente de la consultora donde yo estaba y en la que había trabajado por un año. En esa charla le planteaba que no estaba conforme con las tecnologías que usaban porque eran anticuadas, que tampoco tenían buenas prácticas, ojo crítico ni estándares de calidad a la hora de desarrollar. Básicamente su equipo era “malo”, y no les importaba serlo. La respuesta del gerente fue un número bastante intimidante, que mostraba cuánto habían facturado el año pasado. Si bien fue muy antipático, creo que me dio una muy buena lección. El problema no era él, o no solo él, sino el enfoque con el que yo planteé la charla.
Desde hace más de 10 años me dedico a la docencia. En la primera clase de la materia (una electiva orientada a la construcción de software en el contexto de industria y mundo “real”) dejamos bastante claro que todo lo que hacemos como ingenieros debería tener como fin afectar un indicador de negocio, que a su vez debería tener como fin, más directa o indirectamente, a mayor o menor plazo, terminar impactando en un indicador monetario, ya sea revenue, ahorros, etc.
¿Esto significa que debemos relegar calidad, que no hay lugar para la innovación o para hacer refactors y mejoras técnicas? No, no y no! La respuesta es que todo eso es una de las tareas principales de nuestro rol, ya que si no lo planteamos nosotros, va a ser difícil que otra área lo empuje.
La clave es la forma y los indicadores que presentemos como motivo para llevar adelante estas tareas. El peor error que podemos cometer, y déjenme decirles que “been there, done that”, es enamorarnos de la tecnología como fin en sí mismo o por amor al arte.
Hace ya varios años que en Despegar reconocimos haber explorado ese sendero con resultados poco felices, y fuimos adaptando nuestro discurso y nuestra cultura hasta entender que tenemos que enamorarnos del problema y no de la tecnología, usar la tecnología como un medio y no como un fin en sí mismo y nunca perder de foco el mayor indicador de todos: $ (dinero hoy, dinero en el futuro, ganar más, gastar menos, todas diferentes formas de mover ese indicador).
Vale la aclaración: Las historias técnicas son historias de negocio, solo es cuestión de cantidad de saltos e indirecciones. Todo lo que hacemos tiene como fin impactar de alguna manera más o menos directa, más o menos inmediata en el negocio. Hacer equipos más productivos, stacks tecnológicos más mantenibles y flexibles o menos propensos a errores tiene un impacto en la velocidad con que podemos dar respuesta como organización al negocio, en minimizar las pérdidas o sumar a la tranquilidad mental con la que nos vamos a dormir todas las noches, en bajar cargas operativas para que los equipos se enfoquen en resolver los problemas que queremos que resuelvan, y disfruten en el camino.
En el último tiempo, siguiendo esta línea, comenzamos a tener status del sponsor IT. Reuniones para charlar de aquellas historias que entendemos que son técnicas, y son sponsoreadas directamente por el área de tecnología (pagadas, empujadas, que tenemos accountability) , sin ningún área de negocio que lo solicite. En esta reunión contamos de refactors, cambios de arquitectura y responsabilidades, desarrollos de herramientas que repercuten en todo el equipo, y cualquier otra tarea que entendemos que afecta al negocio pero de forma indirecta y no como un pedido de un área comercial.
Lo que buscamos con este ejercicio es seguir trabajando el “business sense” del equipo, hacernos preguntas como: “si no hacemos esto, ¿qué podría pasar?” o “¿qué estamos dejando de hacer para llevar adelante este desarrollo?”. Además, reforzamos la sana costumbre de explicar las decisiones que tomamos, el impacto que esperamos tener y hacerle saber al resto del equipo lo que debería esperar.
Si pudiera darle un consejo a mi yo de 22 años que quería hacer todos esos cambios, le diría que se enfoque en lo que esperaba conseguir, y no solo en los blancos y negros de “trabajar bien” vs “trabajar mal”. Que lo pusiera en términos que pudieran ser de interés para ese Gerente, en capacidad para reducir errores, para aumentar el delivery, para atraer y retener talento y mantener al equipo motivado y productivo. Creo que de esa forma es cómo me gustaría que alguien que trabaja conmigo me lo plantee a mí, pero sobre todo la estrategia que considero que tiene más chances de ser efectiva.
En conclusión, en Despegar estamos muy orgullosos de nuestro equipo, su solvencia técnica y su capacidad de resolver problemas tan interesantes como complejos, pero sobre todo nos enorgullecen los aprendizajes que hemos hecho a lo largo de este camino, el habernos convertido en socios y abanderados del negocio y poder poner a servicio del mismo nuestra expertise profesional sin perder el espíritu de innovación y pasión por la tecnología que todos compartimos. Creemos profundamente que este tipo de cultura y visión es clave para cualquier equipo de tecnología sin importar la organización o contexto en el que le toque desenvolverse.
Si te interesa usar todo tu conocimiento técnico para impulsar un negocio muy desafiante, y desarrollarte en un equipo con muchas posibilidades de crecer y aprender, entonces te estamos buscando. Sumate!
