En mi chamba como Engineering Manager de un equipo de plataforma, he desarrollado un modelo mental para pensar en el tipo de trabajo que hacemos. Es simple. Todo lo que hacemos termina siendo una de dos cosas:
- Herramientas, o
- Sistemas
Las diferencias son sutiles, pero importantes.
Las herramientas necesitan un esfuerzo de evangelización para que las empiecen a usar y que lleguen a un nivel de adopción aceptable. Críticamente, las herramientas también pueden “agarrarse mal”, es decir, usarse de la manera incorrecta, o en los contextos incorrectos. El éxito de una herramienta depende mucho de cómo y cuándo se use. Cuando hacemos herramientas, gran parte de nuestra responsabilidad es crear documentación y materiales de entrenamiento para procurar que los que la quieran usar puedan hacerlo y logren sus objetivos. Además, tenemos que buscar la forma en que las personas encuentren las herramientas en el momento adecuado —cuando las necesitan. Eso requiere que analicemos con cuidado el terreno y los modos en los que nuestros clientes ejecutan. No podemos decirles solamente “usa esto”. Si queremos que usen nuestras herramientas, tenemos que hacérselo fácil.
Si tuviera que ponerle porcentaje, creo que las herramientas nos llevan 30 % del tiempo en diseño e implementación, y 70 % en documentación, evangelización y estrategización de adopción.
Los sistemas, por otro lado, no necesitan tanto esfuerzo de evangalización. Un sistema, por definición, tiene inputs y outputs, y te garantiza que mientras le des ciertos inputs, vas a tener ciertos outputs. Cómo el sistema logra entregarte esos outputs es un detalle de implementación que no debería ser relevante para el usuario (porque si lo fuera, entonces ese sistema sería más una herramienta). Mientras le entregues los inputs correctos al sistema, puedes confiar en que vas a tener los outputs que esperarías. Un sistema debe tener una buena API y SLAs bien documentados. El sistema existe para darle la confianza a su cliente de que puede contar con las capacidades que el sistema está diseñado para proveer.
Los sistemas nos llevan 70 % del tiempo en diseño e implementación, y 30 % en documentación y evangalización.
Este framework me ha servido bastante también para tomar decisiones estratégicas de cómo construir y evolucionar mis equipos. Dependiendo de las circunstancias de la empresa, así como de las competencias, seniority y habilidades de las personas con las que trabajo, en algunos casos es más viable desarrollar herramientas que sistemas. En otros casos, desarrollar sistemas es la respuesta obvia. Si cualquier factor cambia, puedo ajustar la estrategia de desarrollo del equipo.
A veces desarrollamos herramientas. A veces sistemas. Nos ajustamos a las circunstancias de la empresa. Y así es como logramos avanzar de manera consistente, agregando valor donde y como podemos.
Deja un comentario