Guiando Equipos de Software por Casualidad: De Ingeniero a Líder Técnico
La primera vez que tuve la oportunidad de liderar un equipo fue por necesidad, podría decir que ni siquiera fue de manera “formal”, yo era un desarrollador más, mi rol era evangelizar sobre buenas prácticas, crear herramientas para desarrolladores y facilitar el trabajo de mi equipo, algo que a día de hoy se conoce como equipo de “core o plataforma”.
Mi Manager en ese momento saldría de vacaciones por un par de semanas y me propuso quedar a cargo del equipo durante su ausencia, fue una especie de “Free Trial”, estuve en un periodo de prueba de forma implícita, cuando se me propuso esta idea la realidad no estaba muy interesado, pues en ese tiempo a mi solo me motivaba escribir código, disfrutaba mucho de hacer cosas técnicas, todo lo que era negocio y personas, para ser transparente me daba un poco de pereza, ahora que lo pienso era más por el momento que pasaba, estaba super entusiasmado por subir mi nivel técnico, me obsesione con aprender a escribir software de alta calidad y convertirme un desarrollador de élite, y creía que eso no se alineaba con lo que yo buscaba, así que emprendí el viaje, me dieron un día para pensar, al otro día regrese y acepte, pues ¿Qué podría salir mal?.
El equipo eran 6 personas si no mal recuerdo, entonces pregunté: ¿Qué debo hacer? Pues no tenía ni idea de que significaba quedar a cargo y del negocio muy poca idea, la respuesta fue: Solo tienes que asegurarte que cumplan con su trabajo y terminen sus tareas del proyecto, es importante que cumplan por que se va lanzar a final del mes.
Así que pensé, ¿Porque alguien no haría su trabajo, no es por eso que recibimos un pago mensual?… claro yo me encargo, si algo no entiendo le pregunto a los otros managers.
Llegó el siguiente lunes y ya me estaban esperando para que entrara a una primera reunión con el resto de Managers, en esa sesión se compartieron avances de los equipos y sucesos relevantes de la semana, yo miraba que todos leían sus notas, en sus computadoras, cuando fue mi turno, ¡Oh sorpresa! No tenía nada que compartir, no había tomado notas de nada, dije todo lo que recordaba en ese momento, me preguntaron como iba X persona, y como iba X equipo, a lo que no puede responder del todo, pues no había entendido las letras pequeñas cuando acepte “quedar a cargo”, esa parte donde tenía que interactuar con personas de producto, asistir a reuniones, dar seguimiento y ayudar a desbloquear cualquier problema que ocurriera.
A la semana siguiente, ya había interactuado con más personas, ya llevaba mis notas, ya había asistido a reuniones, ya tenía más contexto de lo que estaba sucediendo había replicado el comportamiento que hacían los managers más experimentados ;pero ahora tenía un nuevo problema, una persona de las que yo estaba a cargo, había renunciado días antes y estaba en su periodo de salida, ese donde se comprometen a cerrar ciertas tareas y se van de la compañía.
Yo sabía que esa persona era a la que más me tocaba poner atención, con toda seguridad me dijo que él terminaría “su parte” el miércoles, confíe en que así pasaría, llegó ese miércoles, me dijo: “Ya acabe, deje la tarea terminada, solo ya no me va dar tiempo de cerrarla” (es decir introducir a nuestra base de código principal todos los cambios realizados) ;pero esta terminado, ese día era su último día, así que se marchó de la empresa, al otro día, cuando comencé a revisar el código me di cuenta que no cumplía con los requerimientos descritos en la tarea, así que pregunte a la persona de producto responsable, pensé que yo no había entendido, le cuestione que era lo realmente esperado, así que cuando entendí el problema, le comente: “Ese código hace algo ;pero no cumple los requerimientos esperados”, va tocar escribirlo otra vez.
El pánico salió a flote, como suele suceder, ¡Cómo que no funciona de esta forma!, “revisamos todos los casos muchas veces en las reuniones”, le mostré la funcionalidad, intento hacer los casos de uso desde su teléfono, probando la interfaz y solo se resigno a que realmente no funcionaba, bueno ya era jueves, teníamos un día para escribir el trabajo de casi 2 semanas, al siguiente día, me dedique a entender en profundidad solamente el requerimiento y las reglas de negocio, el lunes sabia que ya no sería problema mío 😄, mi manager volvía de sus vacaciones y ahora le tocaba a él resolverlo y asignar a alguien más a resolverlo, yo estaba entusiasmado por volver a mi vida feliz de desarrollador y solo escribir código.
Llegó otra vez el lunes, me tocó tener una sesión con mi manager para ponerlo al día, al instante se preocupó, de igual forma que había sucedido con la persona de producto de ese equipo.
Comencé a retomar mis tareas de desarrollador que había dejado pendientes, el se levanto y reunió a todas las personas involucradas explicó la situación, y de alguna manera logró unos días extras para poder reparar (reescribir toda la solución), minutos después fue a mi lugar y me comento que me tocaba ayudar a ese equipo, y bueno así fue como un problema que no era de mi incumbencia pasó a ser mío, ahora todo dependía de mí, no tenía salida, la verdad me frustro un poco, que algo que no era mi problema, pasará a ser completamente mi responsabilidad, fue una semana intensa, muy difícil ;pero por fortuna logramos cumplir lo que se esperaba en el nuevo plazo.
Lo que días después me llevó a reflexionar, Si no hubiese aceptado cubrir a mi manager durante su ausencia, ¿Tal vez este problema nunca me lo hubiesen asignado?. La realidad es que nadie me impuso hacerlo, así que tocaba aceptarlo y dejar de quejarme, fue mi elección, ahí descubrí algunas cosas, la primera es que a la semana, yo ya estaba replicando estrategias y prácticas que hacen los otros managers, sin saber si estaba bien o mal, que había manejado mal la situación, como no revisar en el momento la solución con el desarrollador, y pedir apoyo de alguien más para asegurarme que su solución era funcional, no había entendido, si mi trabajo era dar permisos a las personas o enfocarte en lo técnico, o todo, y lo más importante que en ese momento no me había gustado tanto la vida de manager ;pero estaba convencido que quería volver a intentarlo en el futuro con más experiencia y aprendizajes.
Transicionando de Ingeniero de Software a Líder Técnico
Durante mi carrera profesional, he tenido líderes increíbles, a los que estaré eternamente agradecido por las oportunidades que me dieron ;pero también he tenido otros “Jefes” con los que me tocó aprender de esas situaciones no tan agradables, te enseñan lo que no debes hacer y lo que no debes aprender o replicar.
Al día de hoy he tenido la fortuna de crear y liderar equipos con gente muy talentosa, los que me han ayudado a formarme como el líder que tal vez soy al día de hoy, así que si estás en un momento de transición donde cada vez te está toca menos escribir el código y esas soluciones que tanto nos apasionan, te voy a compartir algunas de las prácticas que he utilizado en el camino:
Clarifica tus Responsabilidades: Es importante no confundir que hay una diferencia entre ser un “Líder Técnico” el que influencia y guía sobre las decisiones técnicas del software y un “Líder de Equipo” que se enfoca en la parte de personas y estratégica del negocio. (En otro post hablaré de sus diferencias), que no se mal entienda, en algunas compañías tienden a mezclar y mal entender las responsabilidades, aún teniendo los dos roles y en otras más una persona haciendo cosas de los dos mundos.
Es verdad que siempre están relacionados de alguna u otra manera, las decisiones técnicas también tienen que ver con las personas y el negocio ;pero tal vez tu no seas quien tiene que mirar por el crecimiento de las personas o el que aprueba y da los “permisos” de vacaciones.
Al igual que asumiendo cualquier nuevo rol, debes tener muy claro cuales son tus tareas principales, normalmente la persona a la que reportas debería saberlo, es quien pone las expectativas sobre ti y tu trabajo, y si no te las han comunicado, tal vez es momento de preguntar y clarificar.
Entender tus responsabilidades, te va dar una guía de a donde debes enfocar y priorizar tus esfuerzos.
Identifica a tus Principales Colaboradores: preocupate por entender quienes son esas personas clave para que puedas realizar tu trabajo de la mejor forma, ¿Es una persona de producto?, ¿Otro líder técnico?, ¿Un Stakeholder?, debes tener claro quienes son esas personas de las cuales depende que tu trabajo se facilite, entiende a quien le puedes consultar sobre algún tema específico, de quién puedes apoyarte si algo falla o tienes duda, identifica quien es esa persona que puede ayudarte a convencer o revertir una situación compleja o que va más allá de tus posibilidades, como lo repito muy a menudo, el software es un proceso y una tarea de equipo, cada decisión de negocio tenemos que ser capaces de expresarla en código, y eso requiere una interacción de muchas áreas.
Comunica Efectivamente: siempre digo que no es suficiente con hablar, o hablar por hablar, debemos ser capaces de comunicar de forma clara y concisa. Se trata de aprender a escuchar, dar nuestros puntos de vista, negociar, elevar el nivel de la discusión y decir las cosas complicadas o difíciles cuando lo amerita, aprender a comunicar es una habilidad que hay que trabajar mucho, es más difícil de lo que parece y que tendemos a subestimar ;pero la mala comunicación genera la mayoría de los conflictos dentro de los equipos, y me gusta la parte de ser redundante, los mensajes deben de llegar, si es necesario documentar, ¡hazlo!, si es necesario decirlo a una persona especifico, ¡hazlo!, si es necesario mandarlo en un mensaje o email a un grupo de personas, ¡hazlo!, la comunicación y más en esta era de trabajo, físico, remoto e híbrido hay que ser redundantes por todos los canales posibles.
Si no sabes comunicar y no puedes decir lo que nadie quiere escuchar es probable que pierdas el control de muchas situaciones de manera simple, lo que va repercutir en tus objetivos y en los de tu equipo. Busca la manera de que las cosas sucedan explicando detenidamente las razones técnicas que lo justifican y el impacto negativo/positivo que esa decisión puede tener.
Delimita tu Alcance: no podemos ir por la vida intentando pelear todas las batallas, y tratando de solucionar cada problema que se presenta, elige las que realmente te pertenecen y son parte de tu responsabilidad, no cruces la línea de nadie, no tomes decisiones que no te corresponden ;pero siempre mantente dispuesto a ayudar y apoyar en lo que sea necesario. No se trata de mirar solo por tus intereses ;pero sí de tener claridad de que está dentro de tu influencia de decisión, si algo no es para ti, aprende a re-direccionar con la persona correspondiente, no te añadas más tareas que no te corresponden, o posiblemente vas a perder de vista tus objetivos importantes.
Cuida a tu equipo, entiende las métricas que tu trabajo debe impactar, y trabaja por ello.
Sé un mentor: se esa persona que te gustaría que fueran contigo, predica con el ejemplo, ensuciate las manos cuando sea necesario, toma iniciativa y empuja para que las cosas sucedan, se un multiplicador de voz para tu equipo, aboga por el cambio y lidera el cambio, defiende la calidad y el buen código, comparte tu experiencia y todo lo que aprendes con tu equipo, fomenta el autoaprendizaje y la comunidad, si todos se mantienen en continuo aprendizaje, todo el equipo se vuelven mejor y suben el nivel técnico.
Piensa que ahora tienes la responsabilidad de que cada acción o comportamiento bueno o no tan bueno, es posible que alguien más lo replique en el futuro.
Aprende a negociar y priorizar: tal vez al iniciar en un rol de líder técnico, te das cuenta que ahora tienes que estar pendiente de múltiples temas al mismo tiempo, lo cual puede generar mucha confusión, ¿Que atiendo primero? eso puede causar estrés y en situaciones más complejas desmotivación.
Existen ciertas metodologías para iniciar y aprender a priorizar, como la matriz de “Eisenhower”, te sugiero que intentes aplicar, y luego irás formando tu propio criterio de acuerdo a las necesidades de la empresa en la que colaboras.
Otro punto importante que influye en la priorización son las “fechas de entrega” un error común es que nos centramos en lo inalcanzable que es la fecha límite, y eso es una distracción, pasamos más tiempo pensando y preocupándonos por lo que no se puede hacer y las posibles consecuencias.
Enfócate en solucionar el problema, en lo que realmente se puede hacer, define lo que se puede hacer y pon manos a la obra en ello, habla con quien debas hablar si necesario pedir más tiempo o recortar el alcance ;pero no comprometas nada que no puedes cumplir.
Lo que me ha funcionado para priorizar, el día a día, proyectos a corto y largo plazo:
Establecer mis objetivos por semana ;pero siempre flexibles, por si hay que ajustarse a alguna situación.
Reviso mis tareas a completar del día siguiente antes de irme o al iniciar el siguiente día, como primera actividad del día y hago todo lo posible por cumplirlas. (Cumplir es lo que hará la diferencia, no llenarte de planeación)
Seguimiento a todas las iniciativas que tengo a cargo, y anotar avances, planes y problemas, personalmente me gusta mantenerlo en un spreadsheet o alguna aplicación de notas personal.
No memorizar, tomar mis propias notas en reuniones, necesario para no asumir y no olvidar nada.
Soltar el código, si somos líderes técnicos ya no es del todo nuestra responsabilidad escribir la solución, sin embargo sí implica colaborar de otra manera, hacer code review, guiar al equipo, aportar con ideas y soluciones técnicas. Si sigues escribiendo tu código es probable que estés desatendiendo otros temas. Hazlo solo si es necesario.
Elijo menos cosas para hacer ;pero las que tienen más impacto, aunque sea solo una, intento cumplirlas con consistencia y disciplina.
Si necesito escribir código por alguna situación, inició el día antes que todos y con eso evitar distracciones . (Yo soy morning person)
Me concentro en una prioridad a la vez, sin realizar múltiples tareas al mismo tiempo, a menos que sea necesario.
Bloqueo mi calendario para revisar temas puntuales en determinado tiempo, e incluso para comer.
Trato de entender el nivel de urgencia en los temas que me involucro, así evitó fechas sorpresa y las agendo en mi calendario.
Tomó un respiro de 10 mins cada que termino una tarea, para despejar y ponerme con la siguiente.
No tomo reuniones sin una agenda clara o trato de preguntar de qué va la reunión, evaluó mi posible aportación en esa reunión cuando tengo dudas sobre la agenda.
Esto es lo que me ha funcionado a mí, tú debes descubrir lo que te funciona a ti, experimenta y adapta lo que a ti te funciona.
Conclusión
La industria debería tener menos “Líderes o Managers” y más “Ingenieros”, no siempre es garantía que la persona más experimentada técnicamente sea la que debe convertirse en el nuevo líder del equipo, en ocasiones perdemos un gran ingeniero y ganamos un mal líder. De igual forma es verdad que hay muchos desarrolladores que no quieren tomar cargos de liderazgo, otros a los que no se les da, y otros más que no deberían serlo.
Si aún no tienes la oportunidad de serlo te sugiero que cuando la tengas hagas tu “Free Trial” aunque sea interino por 1 semana, aunque no te guste, no sabes si serás bueno o si realmente te va gustar si no lo intentas y si ya lo eres preocúpate por hacerlo mejor día con día, toma riesgos calculados, acepta nuevos retos, se flexible, desarrolla tu instinto de producto y negocio, tu impacto ahora lleva más responsabilidad, hacer que funcione y hacerlo visible depende solo de ti.
Si en el peor de los casos encontramos que no es lo te gusta o aún no es tu momento, también es de profesionales dar un paso al costado, hay más roles que pueden ser más cercanos a tus objetivos personales y profesionales, no lo hagas por cubrir un espacio, o por que era lo que tocaba, es probable que no salga bien cuando es por las razones incorrectas, no pierdas la confianza de las personas que ya confían en ti por tu calidad como ingeniero, solo por tomar un rol que no quieres o no te satisface.
Sea la razón que sea por la que te tocó asumir el nuevo rol, soy creyente que un líder técnico siempre comienza a destacar dentro de un equipo, aún sin el título como tal, siempre están retando por aprender, mejorar, compartir y de alguna forma se vuelven como un tipo de influencers que tienen sus seguidores, escucha a tu equipo, hazles la vida más fácil, impulsa sus decisiones, sigue tu instinto, desarrolla el arte de gestionar, aprende con otros ingenieros con mentalidad de crecimiento, confía en ti y en tu experiencia, vas a fallar múltiples veces, ten paciencia, no dejes de intentarlo. Haz todo lo que esté en tus manos para que las cosas pasen, sin sacrificar tu bienestar.
“You’ve got to find what you love. And that is as true for your work as it is for your lovers. Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work.” Steve Jobs