El Rol de Machine Learning Engineer

Recuerdo que hace unos meses tuvimos un pequeño encuentro con un integrante de otra área dentro de la compañía, el que nos exigió llamar a nuestro 'arquitecto' para que le explique una propuesta de arquitectura que diseñamos. Allí estábamos, por nuestro lado un Machine Learning Engineer (MLE), un Data Scientist y yo (DevOps). Ningún arquitecto cloud, ninguno de software. Y no es porque éstos no estuvieran presentes, sino que simplemente nuestra área de analítica no cuenta ni contempla estos roles.

Si no tenemos arquitecto, ¿quién decide el tipo de base de datos a usar? ¿cuándo balancear un servicio o no? ¿si usamos una arquitectura serverless en conjunto con un pub/sub? ¿si la estructura de nuestros servicios estará bajo una u otra VPCs? Claramente, alguien tiene que hacerse cargo y tomar la decisión final, pues si no, la cosa no avanza.

En otra situación con otro equipo (sí, nos gusta discutir), uno de nuestros MLE levantó un problema que le afectaba al Product Owner (PO) de cierto servicio, y surgió un tema similar: una persona nos consultó por qué un MLE se estaba haciendo cargo del trabajo de un DevOps (yo).

Los roles de DevOps, MLE y otros en el área de analítica avanzada, los hemos definido después de observar nuestras necesidades. También hemos definido las habilidades y las responsabilidades mínimas que estos necesitan para alcanzar nuestros objetivos como área. A pesar de estas definiciones, somos un equipo heterogéneo, y los distintos desafíos del día a día nos llevan frecuentemente a enfrentar los roles previamente definidos. Es así que nos permitimos tener roles dinámicos y flexibles, los que cambian con el paso del tiempo.

La flexibilidad y el dinamismo suelen ser palabras que dan una cualidad positiva, pero me ha tocado presenciar que no siempre es así, al menos cuando de roles y responsabilidades profesionales hablamos. Aquí juega un rol importante la  capacidad técnica, ya que esta es la que nos habilita para resolver problemas específicos. Sin embargo, en estos casos los problemas que nos toca resolver  no siempre van de la mano con dicha capacidad técnica, y este es un gran punto a considerar al momento de flexibilizar un rol en particular. Me encantaría relatar más de mis experiencias (y más situaciones incómodas con otros equipos), pero me limitaré a señalar algunas cosas que no queremos que ocurran por hacernos cargo de tareas que exceden nuestra capacidad:

• Poner en riesgo nuestros sistemas y/o nuestros datos
• Entorpecer/bloquear el trabajo de los demás reduciendo su performance
• Excesiva utilización de recursos al desarrollar
• Generar soluciones rápidas poco escalables con una alta deuda técnica asociada
• Alterar indebidamente servicios en producción
• Perjudicar la gobernanza del desarrollo

Estoy seguro que estamos de acuerdo en que estos sucesos no deben ocurrir bajo ninguna circunstancia, pero desafortunadamente pasan, y muy seguido. Aquí es donde viene la frase de pastelero a tus pasteles, pero cuando surgen problemas que no son formalmente de la responsabilidad de nadie, se convierte en un problema de todos. Quedarnos de brazos cruzados no es una opción, alguien debe tomar la responsabilidad. Más adelante daremos algunos lineamientos a considerar cuando nadie en el equipo tiene las capacidades técnicas específicas para hacerse cargo.

Para reforzar lo anterior, no somos los únicos con roles que avanzan hacia un camino con nuevas responsabilidades. Algorithmia lo dejó muy claro en una de sus encuestas  exponiendo que los Data Scientist invierten entre un 25% y más del 75% de su tiempo en deployar modelos de Machine Learning. Esta labor podría ser manejada de forma más eficiente por un rol más apropiado, como un MLE o un rol más cercano a la operación.

La pregunta restante ahora es cómo permitir la flexibilidad de nuestros roles minimizando cualquier tipo de impacto negativo. Si bien no tengo la respuesta exacta, quiero compartir algunos puntos que nos han ayudado como equipo para que los tengas en consideración:

• Desarrollar capacidad técnica: Si nuestros integrantes no la tienen, fomentar su desarrollo mediante cursos, workshops, talleres, etc. Por supuesto, dentro del horario laboral.
• Traer un especialista: Ya sea por contratación o consultoría, es ideal tener a un experto o un profesional con más experiencia sobre un tema específico.
• Diseminar conocimiento: Un punto súper importante es que si ya tenemos la capacidad, puede que solo falte diseminarse a otros integrantes de nuestro equipo.
• Validación y feedback: si bien somos seres individuales, estamos trabajando en equipo y la colaboración es indispensable. Gran parte de los problemas internos que hemos tenido han sido a causa de la nula validación que ha habido para ciertos trabajos realizados. Sin ánimos de extenderme, en el caso del código tenemos el famoso code review, pero el trabajo realizado por un equipo completo dista mucho de ser solo código, por lo que se requieren de otras herramientas de validación y feedback oportuno.
• Estandarización de flujos y procesos: Tener estándares mínimo y frameworks para facilitar los procesos y flujos de nuestro día a día habilitará al equipo a realizar tareas que demandan mayor capacidad técnica
• Correcta gestión de permisos: Para mitigar los riesgos de flexibilizar un rol, es importante proteger los sistemas y desarrollos con pipelines y permisos que garanticen la aprobación solamente de desarrollos correctos.
• Fomentar trabajo en equipo y colaboración: No todos sabemos pedir ayuda, sin mencionar que en algunos casos puede ser incluso mal visto que el resto se entere que no manejas cierto tema. La invitación aquí es a generar un ambiente propicio para ofrecer y pedir ayuda con tus labores diarias.
• Conocer al equipo: Puede sonar a que es un punto con menos valor, pero la verdad es que conocer las capacidades de los equipos y sus integrantes ayudará a situarlos de mejor manera al momento de enfrentarse a un problema en particular.

Los problemas ocasionados por la falta de capacidad técnica seguirán ocurriendo, pero si queremos ser flexibles y evolucionar de una forma responsable, debemos ser conscientes de nuestras debilidades como individuos y como equipo. Una vez detectemos nuestras carencias técnicas sabremos exactamente qué hacer para un ir paso hacia delante.

‌‌