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 las sesiones de entrenamiento y coaching. Pero primero, voy a comenzar con una breve introducción. Así que soy Anri Fisher. 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 coachar 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 en 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 completamente diferentes y diferentes expectativas sobre lo que debería hacer el tech lead. Y así es a lo que me referiré cuando hable sobre el rol del tech lead en esta presentación.

Y esto es como donde 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. Al entrar 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 deberían escuchar, en qué exactamente deberían 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 alguna forma de, no tengo tiempo para codificar, no tengo tiempo para planificar. En este caso, tengo este cliente en particular que vino a mí en coaching y ella dijo, no tengo tiempo para el trabajo estratégico. Los stakeholders me 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 parecían 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 dirigiendo todas las one on ones, estimando todo el trabajo, asignando todas las tareas individualmente, teniendo la responsabilidad del crecimiento de las personas, construyendo sus planes de crecimiento y llevando a cabo todas las presentaciones de onboarding.

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

Y así comenzamos a trabajar en una estrategia que la llevó del asiento del conductor en las one on ones al rol de apoyo. Y eso significó cambiar la propiedad de la agenda de las one on ones 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 en su proceso. Pero van a tener que ser ustedes quienes dirijan esta conversación. Por supuesto, esto funcionó para algunas personas, algunos trajeron temas, pero otros 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 one on ones para discutir exactamente sobre el elefante en la habitación y por qué no hay temas. Así que una vez que ella se adentró 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. Y entonces 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 one on ones? 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 comenzó a pensar en adelantarse 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 ello. 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 e intégralos en el proceso. Va a beneficiarte y definitivamente también los beneficiará a ellos. La segunda dificultad que los tech leads siguen mencionando en las discusiones es dar, construir retroalimentación. Y esto se basa en diferentes razones.

Algunos dicen que no tienen retroalimentación. 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 retroalimentación. Y en ese caso, miramos cómo prepararse adecuadamente, dedicando tiempo a una estructura adecuada, utilizando marcos como SBI para entregar la retroalimentación.

Pero la razón más común por la que tienen dificultades con la retroalimentación constructiva es que tienen miedo de cómo la gente podría reaccionar cuando entregan esta retroalimentación. 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, 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 que pueda desafiarte y hacerte algunas preguntas desafiantes a través del coaching, a través del mentoring, pero también tal vez solo escribiéndolo en un papel y hacer un volcado de ideas de todo lo que estás pensando puede ayudarte enormemente a quitar esa presión. El tercer desafío que los tech leads siguen mencionando 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 atender.

Y así que pregunto, OK, entonces si estaba tan claro para ti, ¿por qué no les dijiste de antemano que necesitaban encargarse 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ía 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 disminuir si no lo hace ella misma o perderá el control completo sobre lo que está sucediendo con esa tarea.

Hay una estrategia principal que la ayuda y es la clave para una delegación adecuada, que es establecer expectativas claras sobre el resultado. ¿Cómo exactamente espero que suceda? ¿Qué entregables se harían 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 los plazos son, he visto a muchos equipos evitar hablar sobre los plazos. Es como si fuera una gran presión. No queremos presionar a la gente. Pero la realidad es que siempre hay un plazo. La única diferencia es si hablas de ello o no, si es explícito o poco claro y oculto, siempre hay un plazo y simplemente hacerlo claro ayuda a todos a alinearse y estar en la misma página.

Así que acordar cuándo esto necesita ser entregado y si hay algún hito en el mientras tanto, 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 estamos pensando en ese miedo a perder el control, la gente suele pensar, oh, voy a entregar 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 el proceso sobre el proceso, sobre cómo van a trabajar juntos, usted puede crear una estrategia que le ayude a mantenerse en control. Con este cliente en particular, ella acordó con la persona a la que estaba delegando que se van a reunir cada semana y van a discutir sobre el progreso y van a discutir sobre los 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 saquen de esta historia es que la mayoría de los problemas en los equipos tecnológicos 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, sea explícito. Cualquier cosa que tenga en mente, no importa cuán sencilla pueda parecer, dígala en voz alta, póngala en papel. En el peor de los casos, la gente dirá, yo sabía esto. Lo que lo lleva de vuelta a donde estaba.

El cuarto desafío proviene de la startup con la que trabajé. Así que tenían esta iniciativa entre equipos que salió realmente mal y me trajeron para solucionar con ellos exactamente qué pasó. ¿Por qué salió tan mal? Así que me reuní en una sala con tres líderes técnicos 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 era el dueño de esta iniciativa? Así que el primer líder técnico me dijo el PM, el segundo líder técnico me dijo el EM, el tercer líder técnico 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 un plazo compartido, no se establecieron expectativas de ninguna manera. Era simplemente como diferentes presiones viniendo de diferentes personas en diferentes momentos. Cada equipo tenía su propia planificación y estaban definiendo su propia expectativa. No había una coordinación real en el panorama general. Así que cuando intentaron integrar, todo explotó.

Así que el principal aprendizaje que quiero que saquen de esto es que siempre debe haber un dueño. Si estás pensando si estás en un proyecto y no puedes responder a la pregunta de quién es el dueño de esto, entonces hay una gran posibilidad de que las cosas se desvíen. Así que asegúrate de que lo que sea que esté sucediendo en tu equipo, siempre haya 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 problemas nuevos, 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 luchar para dar retroalimentación al CEO sobre el PR o sobre el proceso, lo que nos lleva 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. O cuando hay mucha presión hoy en día para que los tech leads o los equipos entreguen más rápido solo porque supuestamente tienen mejores herramientas ahora.

Así que solo por dar acceso a las herramientas no significa que la gente de repente va a crecer más rápido. Necesitan un nuevo proceso sobre cómo integrar esas herramientas. Y esto se remonta a una falta de alineación sobre exactamente cuál es la estrategia, qué significa más rápido, de dónde viene esto, en qué vamos a estar trabajando.