Quizás el título huele a clickbait, pero espero poder entregarte un consejo que sí te ayude en tu carrera como ingeniero de software.
No sé si te pasa como a mí, que estoy un poco aburrido de tanto consejo esotérico pululando por ahí: rutinas avaladas por neurólogos sobre cuál es la hora óptima de dormir o despertar, millonarios aconsejando trabajar 12 horas por 7 días a la semana, monstruosos toolsets de herramientas para tomar notas y la manera correcta de organizarlas, u otro framework “agile” de moda.
Por estas razones me sorprendió encontrarme hace unas semanas con una conferencia titulada “Grow Your Own Tech Leads • Ken Scambler • YOW! 2019” en Youtube, que se aleja totalmente de los consejos esotéricos y vuelve a algo completamente básico y esencial en los equipos: la confianza.
Es por esto que quiero presentarte un modesto resumen de la conferencia, y en honor al tiempo que tomaste en leer esta entrada, te dejo de inmediato con el consejo que te convertirá en un ingeniero de otro planeta. Redoble de tambores…
No lo hagas pésimo
Medio en broma, medio en serio. Así de simple. En inglés el consejo es “don’t be terrible”. Ten un poco de paciencia y te explico con unos ejemplos a qué me refiero.
1. El action item de la retro
De seguro tras salir de la retrospectiva te anotaste para algún action item, habitualmente está en una actividad voluntaria, y tras llegar a la siguiente retro tu jefe te pregunta cómo te fue con el action item y… olvidaste hacerlo. Pésimo 😞
En estas tareas sencillas es donde se construye confianza y muchos fallan en darle la importancia que merece. Están más preocupados en convertirse en el 10x programmer, memorizando cada patrón de diseño, estructura de datos y algoritmo en Leetcode.
El efecto que tiene esto en tu jefe es que tendrá que encontrar un espacio en su calendario que ya luce como un Tetris
Preguntando constantemente el estado de avance de tu tarea, ya que perdiste su confianza.
Aquí tienes una primera señal: si tu jefe está pidiendo constantemente un status, puede que lo estés haciendo terrible.
Informa tu avance de manera proactiva, así no tienen que venir a molestarte.
2. Nos comunicamos abiertamente
Estás pegado en un problema durante varios días, y cuando tu jefe te pregunta: ¿estás bloqueado? ¿necesitas ayuda? Respondes: “Nah, voy como al 80%”. A pocos días de la fecha límite te vuelven a preguntar y ahora la respuesta es: “en realidad estuve pegado varios días…” Pésimo 😞
Muchas veces fallamos creyendo que pedir ayuda nos hace ver de alguna manera incompetentes, pero en un equipo donde la confianza es alta, justamente se espera que puedas apoyarte en otros compañeros y comunicarte de manera abierta y oportuna.
Avisar este tipo de situaciones de manera anticipada abre un océano de posibilidades para sortear el problema y evita tener que sacar de sus tareas a los expertos de un dominio de negocio o expertos técnicos, justo el día antes de la demo con el cliente para solucionar el problema.
3. Entre compañeros nos ayudamos
Un colega de tu mismo equipo, u otro equipo, te pide ayuda con algún problema. Le comentas que, aunque no tienes la solución, vas a averiguar cómo ayudar. Pasa una semana y te contacta nuevamente; recuerdas que no intentaste averiguar nada y, si tu líder te pregunta, resulta que en realidad no era tu problema y estabas ocupado con otra cosa… Pésimo 😞
Más importante que un entregable en particular es alcanzar un objetivo estratégico. Si el equipo puede confiar en ti para alcanzar esos objetivos, es muy probable que en el futuro te entreguen desafíos más interesantes e importantes para tu organización, ya que reconocen en ti a alguien en quien confiar para entregar valor.
4. Palabras y acciones
Te encuentras en un equipo con varios devs junior y cuando te toca revisar su código el comentario que sale de tu boca es “Este código es horrendo y ustedes programan mal”. Acompañas ese comentario sin ninguna acción concreta para mejorar la situación… Pésimo 😞
Ojo: puede ser completamente correcto que esos devs programen mal y su código apeste. Pero las palabras deben ir acompañadas de acciones. Si constantemente tomas acciones para que el equipo programe mejor, entonces un comentario como ese puede ser recibido como un feedback positivo y un llamado a mejorar. Pero si solo te estás quejando y no aportas a que el equipo mejore, entonces ese mismo comentario es completamente tóxico.
Conclusiones
No te voy a dar la lata con más ejemplos, me imagino que ya captaste la idea. Construir una red de confianza con el equipo y con tus líderes, utilizando este tipo de tareas que nada tienen que ver con la imagen del 10x programmer tipeando 200 palabras por minuto, es lo que te va a hacer destacar en tu equipo y potenciar tu carrera.
Naturalmente, otros colegas se van a acercar a ti para solicitar ayuda y vas a ganar experiencia con distintos problemas. Tus líderes van a acudir a ti con nuevos desafíos y más responsabilidades, ya sea diseñando sistemas o pidiendo tu opinión identificando factibilidad o riesgos técnicos.
Espero que este artículo sea de ayuda en tu camino profesional 😀
Todo el material original y en el que plagie me basé para escribir esta entrada, lo encontrarás en este link Grow Your Own Tech Leads • Ken Scambler • YOW! 2019
