400 Tech Leads. Mismos Problemas. Ninguno de Ellos Técnico

Hola, bienvenidos a todos. Así que durante los próximos 20 minutos, voy a compartir con ustedes los principales desafíos que los tech leads siguen trayendo en sesiones de formación y coaching. Pero primero, voy a comenzar con una breve introducción. Así que soy Henri Fischer. He estado en tecnología por más de 12 años. Comencé como ingeniero de software y luego pasé a diferentes roles de liderazgo como tech lead, gerente de ingeniería. Pero mi enfoque principal durante los últimos cinco años ha sido entrenar y asesorar a tech leads en la construcción de equipos de alto rendimiento. Y es por eso que quiero comenzar con la definición del rol del tech lead.

Así que el tech lead es un ingeniero de software responsable de liderar un equipo de desarrollo y responsable de los entregables técnicos de ese equipo. La razón por la que es importante enfatizar esta definición es porque dependiendo de a quién le preguntes, podrías obtener diferentes respuestas sobre lo que es un tech lead. Me sorprende cómo incluso preguntando a personas en la misma empresa, obtengo respuestas diferentes, completamente diferentes respuestas y diferentes expectativas sobre lo que el tech lead debería hacer. Y así es a lo que me referiré cuando hable sobre el tech lead durante esta presentación. Y esto es como lo que encontré, la definición que todas estas diferentes empresas y personas con las que trabajo de diferentes culturas, diferentes entornos, están de acuerdo como una definición de alto nivel.

Entrando en detalles, las cosas se vuelven un poco confusas, pero a alto nivel, todos están de acuerdo en que esto es lo que hace un tech lead. Así que, por supuesto, esta confusión alrededor del rol muy a menudo pone presión sobre las personas porque no tienen claro exactamente a quién deben escuchar, en qué exactamente deben enfocarse, lo que nos lleva al primer desafío en el rol, que es la gestión del tiempo. Así que este desafío se presenta de diferentes formas, pero generalmente es una forma de no tengo tiempo para codificar. No tengo tiempo para planificar.

En este caso, tengo este caso particular de coaching, un cliente que vino a mí en coaching y dijo que no tenía tiempo para el trabajo estratégico. Los stakeholders le están dando retroalimentación de que debería dedicar más tiempo a planificar con anticipación. Y así, para abordar esto, comenzamos a mirar todas las cosas que ella estaba haciendo actualmente. Y a primera vista, las cosas empezaron a parecer muy sencillas, como gestionar stakeholders, gestionar iniciativas entre equipos, planificar el trabajo. Pero luego las cosas se volvieron un poco más confusas cuando vi cosas como que ella estaba conduciendo todas las reuniones uno a uno, estimando todo el trabajo, asignando todas las tareas individualmente, teniendo la responsabilidad del crecimiento de las personas, construyendo sus planes de crecimiento y dirigiendo todas las presentaciones de onboarding.

Así que le pregunté, OK, ¿cuáles de estas tareas puedes compartir con tu equipo? ¿Qué responsabilidades tal vez puedas delegar o compartir con tu equipo? Y ella propuso varias de ellas. Las amarillas son las que se sintió más cómoda comenzando. Y luego le pregunté, OK, pero si tuvieras que elegir una, ¿dónde exactamente comenzarías? Y ella eligió las reuniones uno a uno. Así que estaba luchando mucho preparando las reuniones uno a uno. Era mucha presión, siempre preocupada de que no fueran a tener de qué hablar. Ella estaba revisando notas. Estaba revisando sus tareas, su trabajo, poniendo mucho esfuerzo solo para asegurarse de que las reuniones uno a uno las estaba conduciendo adecuadamente.

Y así comenzamos a trabajar en una estrategia que la llevó del asiento del conductor en las reuniones uno a uno al rol de apoyo. Y eso significó cambiar la propiedad de la agenda de las reuniones uno a uno a los miembros de su equipo. Así que para hacer eso, lo primero que hizo fue volver a nuestro equipo y establecer la nueva expectativa de que, miren, ya no voy a traer temas. Así que van a tener que ser ustedes quienes traigan los temas. Voy a presentarme, responder cualquier pregunta que puedan tener y apoyarlos en su proceso, pero van a tener que ser ustedes quienes conduzcan esta conversación. Por supuesto, esto funcionó para algunas personas, algunas trajeron temas, pero otras no.

Y así teníamos la estrategia en marcha para esto. Y para aquellos que no trajeron ningún tema, acordamos que ella iba a usar esos uno a uno para discutir exactamente sobre el elefante en la habitación y por qué no hay temas. Así que una vez que se metió en ello, una de las respuestas más comunes que recibiría es que, bueno, no sabemos exactamente de qué hablar. Este era como el problema común, la lucha común. Y así ella dijo, OK, quiero darles algunas ideas sobre lo que pueden hablar y para compartir estas ideas, miramos a las personas que sí trajeron temas como de qué hablaron. ¿En qué estaban interesados en traer a los uno a uno? Y lo que surgió fueron principalmente temas relacionados con el crecimiento. ¿Cómo puedo llegar al siguiente nivel? ¿Cómo puedo desarrollar esa habilidad en particular? Y así identificamos esto como el principal interés para las personas. Y ella llevó eso de vuelta a los miembros del equipo que no tenían nada de qué hablar. Y paso a paso, logró pasar también la propiedad del crecimiento y ayudar a las personas a desarrollar sus planes de crecimiento y tener completa propiedad e identificar oportunidades en lugar de ser ella quien lo hiciera. Así que pasó a un rol de apoyo en lugar de un rol de conductor para su crecimiento y para los uno a uno. Así que para este momento, nuestra relación de coaching terminó, pero ella ya tenía más tiempo en su calendario, menos presión.

Y comenzó a pensar en adelante sobre el trabajo que venía y a poner más esfuerzo en eso. Pero la parte clave es que ella obtuvo el aprendizaje principal de esto. Y es que como tech lead, eres responsable de asegurarte de que todas estas cosas sucedan. Pero todo el equipo es responsable de asegurarse de que el trabajo se haga. Así que aprende a confiar en tu equipo y a integrarlos en el proceso. Va a beneficiarte y definitivamente también los va a beneficiar a ellos.

La segunda lucha que los tech leads siguen trayendo en las discusiones es dar feedback constructivo. Y esto se basa en diferentes razones. Algunos dicen que no tienen feedback. En este caso, miramos diferentes estrategias sobre cómo pueden rastrear conversaciones, cómo pueden observar tareas y cosas que suceden en el equipo para generar ideas. Algunos me dicen que no saben cómo dar feedback. Y en ese caso, miramos cómo prepararse adecuadamente, dedicando tiempo a una estructura adecuada, utilizando marcos como SBI para entregar el feedback.

Pero la razón más común por la que luchan con el feedback constructivo es que tienen miedo de cómo la gente podría reaccionar cuando entregan este feedback. Se van a poner a la defensiva. Se van a enojar. Así que hay muchas maneras diferentes en que esto puede ir. Así que para abordar eso en nuestra conversación, exploramos juntos todos los escenarios que temen, especialmente aquellos que más les preocupan.

Y lo que he notado es que este proceso de exploración y realmente empujarlos y desafiarlos a pasar por sus pensamientos y lo que imaginan que podría suceder, es muy beneficioso para reducir la presión porque la mayoría de las veces se dan cuenta de que lo que imaginan es muy poco realista. Hay una probabilidad muy pequeña de que esos escenarios realmente puedan suceder o si algo sucede, ellos idean estrategias y soluciones que los ponen en control en esa conversación. Así que el aprendizaje aquí es que muy a menudo nuestros cerebros tienden a hacer los problemas mucho más grandes de lo que son. Así que si estás luchando con esto, definitivamente te animo a hablar con alguien, con alguien que pueda desafiarte y hacerte algunas preguntas desafiantes a través de coaching, a través de mentoría, pero también tal vez solo escribiéndolo en un pedazo de papel y hacer un volcado de cerebro de todo lo que estás pensando puede ayudarte enormemente a quitar esa presión.

El tercer desafío que los tech leads siguen trayendo es sobre la delegación. Así que esta clienta en particular vino a mí y me dijo, quiero delegar más. Sé que tengo que hacerlo. Pero la última vez que delegué, no salió como esperaba. Así que le di esta tarea al ingeniero senior en mi equipo. Y omitieron un caso límite muy importante, que era obvio que necesitaban cuidar. Y entonces le pregunto, OK, si era tan claro para ti, ¿por qué no les dijiste de antemano que necesitaban cuidar de esto? Y ella dijo, bueno, porque era sentido común. Eran un ingeniero senior y obviamente deberían saberlo. Bueno, el problema con el sentido común es que no es tan común. Y dependiendo de a quién le preguntes, cuál es la definición de hecho y cómo se ve bien podrías obtener diferentes respuestas.

Así que dejando esta suposición de lado y volviendo a los desafíos y su preocupación de que el resultado podría ser diferente o que la calidad podría bajar si ella no lo hace ella misma o perderá el control completo sobre lo que está sucediendo con esa tarea. Hay una estrategia principal que la ayudó y es la clave para una delegación adecuada, que es establecer expectativas claras sobre el resultado. ¿Cómo, qué exactamente espero que suceda? ¿Qué entregable debería estar hecho al final de este proceso? Y tal vez incluso cualquier pensamiento que tengas sobre cómo lo mirarías y cómo se vería si lo hicieras tú? Segundo, acordar el plazo. Así que sé que las fechas límite son he visto a muchos equipos evitar hablar sobre fechas límite. Es como si fuera una gran presión. No queremos presionar a la gente. Pero la realidad es que siempre hay una fecha límite. La única diferencia es si hablas de ello o no, si es explícito o poco claro y oculto, siempre hay una fecha límite y simplemente hacerlo claro ayuda a todos a alinearse y estar en la misma página.

Así que acordar si cuando esto necesita ser entregado y si hay algún hito en el ínterin, es clave. Y tercero, y el más importante, es acordar el proceso. Y este es el que la gente más pasa por alto y el que hace la mayor diferencia. Así que cuando pensamos en ese miedo a perder el control. La gente suele pensar, oh, voy a delegar esta tarea y van a volver a mí en cuatro semanas y no se verá como esperaba. Y no tendré nada que decir porque será demasiado tarde. Así que al acordar un proceso sobre el proceso, sobre cómo vamos a trabajar juntos, puedes crear una estrategia que te ayude a mantener el control con este cliente en particular. Ella acordó con la persona a la que estaba delegando que se reunirían cada semana y discutirían sobre el progreso y discutirían sobre riesgos potenciales. Esto le dio la oportunidad de básicamente hacer preguntas, pero también intervenir si sentía que las cosas se estaban desviando o había un problema. Así que esto la puso de nuevo en modo de control y se sintió mucho más cómoda comenzando en este proceso. Y paso a paso, ganó confianza y las cosas se volvieron mucho más fáciles. Pero el principal aprendizaje que quiero que saques de esta historia es que la mayoría de los problemas en los equipos de tecnología provienen de asumir que todos están en la misma página cuando en realidad no lo están.

Así que en lugar de asumir, sé explícito, lo que sea que tengas en mente, no importa cuán simple pueda parecer, dilo en voz alta, ponlo en papel. En el peor de los casos, la gente dirá, ya sabía esto, lo que te lleva de vuelta a donde estabas. El cuarto desafío proviene de la startup con la que trabajé. Así que tenían esto en una iniciativa entre equipos que salió realmente mal y me trajeron para solucionar exactamente qué pasó. ¿Por qué salió tan mal? Así que me reuní en una sala con los tres tech leads y comenzamos a discutir sobre ello. Y la primera pregunta que les hice realmente me mostró el problema principal de este proyecto que se salió tanto de control. Y la pregunta fue, ¿quién es el dueño de esta iniciativa? Así que el primer tech lead me dijo el PM. El segundo tech lead me dijo el EM. El tercer tech lead dijo, creo que el CEO, pero no estaba realmente seguro. Así que el problema es que al no tener un dueño claro, no había una línea de tiempo compartida, no había expectativas impuestas en absoluto. Era solo como diferentes presiones viniendo de diferentes personas en diferentes momentos. Cada equipo tenía su propia planificación y estaba definiendo sus propias expectativas. No había una coordinación real en la visión general. Así que cuando intentaron integrar, todo explotó. Así que el principal aprendizaje que quiero que saques de esto es que siempre debe haber un dueño. Si estás pensando si estás en un proyecto y no puedes responder la pregunta, ¿quién es el dueño de esto?

Así que asegúrate de que lo que sea que esté sucediendo en tu equipo, siempre tengas un dueño asignado. Ten en cuenta que el dueño no significa que deba ser el que necesita hacer el trabajo. Es solo el que supervisa que el trabajo se realice, trabajando junto con todas las otras personas involucradas.

Así que estos son los principales desafíos que siguen surgiendo cuando se trata de tech leads. E incluso en el área de AI, lo que podría parecer como nuevos problemas como cómo encuentro tiempo para mantenerme al día con AI y cómo encuentro tiempo para seguir aprendiendo se remonta a no tener habilidades adecuadas de delegación o luchar con la gestión del tiempo o una falta de prioridad clara y cómo básicamente entender cómo puedes llevar esto a tu lista de prioridades y enfocarte en ello.

O cuando el CEO abre el PR en medio de la noche, también se remonta a la lucha por dar retroalimentación al CEO sobre el PR o sobre el proceso y lo que nos lleva de nuevo al segundo desafío, que obviamente hay una falta de alineación sobre cómo estamos gestionando estos PRs y cuál sería el proceso y qué hacemos si alguien que no tiene tanto conocimiento técnico básicamente abre este PR.