Sobre convertirse en un Tech Lead

Hola, soy Suez y voy a hablar sobre algunas lecciones aprendidas después de convertirme en un Líder Técnico. ¿Por qué querrías ser un Líder Técnico y qué es lo que hacen los Líderes Técnicos?

Entonces, en primer lugar, ¿qué es un Líder Técnico? La definición o la descripción del trabajo de un Líder Técnico varía entre diferentes empresas. Algunas empresas piensan en esto como un tipo de ingeniero de personal. Algunas personas lo ven como un trampolín hacia convertirse en un ingeniero de personal.

Y sabes, se supone que el papel es una de las primeras o las formas más comunes de entrar en la pista de liderazgo técnico, que es una especie de pista paralela a la gestión donde muchas empresas hoy en día tienen una pista técnica donde se pasa de ingeniero junior a ingeniero de nivel medio a ingeniero senior y puede haber múltiples niveles de un ingeniero senior. Y luego se detiene. Puedes ser un ingeniero senior básicamente por el resto de tu vida. Normalmente se considera un título terminal, lo que significa que una vez que eres un ingeniero de software senior, confiamos en ti para trabajar de forma independiente, seguir con éxito los objetivos empresariales y hacer tu trabajo.

Y luego puedes ir más allá de eso, ya sea en la pista técnica, que eventualmente, que lleva a personal principal, ingenieros distinguidos, y todas esas personas. O puedes ir por la pista de gestión, que es gerente de ingeniería, VP, CTO, y eso tipo de cosas. Como no sé los pasos exactos. Normalmente hay un montón de ellos entre diferentes empresas. Y donde realmente se complica es este cruce de caminos donde pasas de ser solo un ingeniero senior, o ser un ingeniero senior hacia algo más. ¿Cuál es el siguiente paso? A menudo, el líder técnico es el primer siguiente paso que la gente toma. Y si lo ves como un cruce de caminos, normalmente, el líder técnico está más en el lado de la pista de liderazgo técnico, personal, principal, etc., y el líder del equipo es el primer paso hacia la pista de gestión. Algunas empresas mezclan estos dos, pero así es como suele funcionar. Y la idea de una pista de liderazgo técnico es que no eres responsable de gestionar personas, al menos no directamente. Eres más responsable de gestionar la dirección técnica de un equipo, especialmente como un técnico Normalmente te centras en un equipo específico, lo que significa que aunque sigues siendo un contribuyente individual, tu rendimiento ahora se juzga por lo que hace el equipo como un todo, excepto que a diferencia de un líder de equipo o un gerente, no estás lidiando con las responsabilidades de gestión de personas. No tienes ninguna autoridad directa. Se trata más de influencia suave y de dirigir a las personas y ayudar, básicamente ayudar al equipo a tomar buenas decisiones técnicas para asegurar que los proyectos fluyan sin problemas, que estés trabajando con tu dueño de producto y multiplicando las fuerzas del equipo. Diría que la multiplicación de fuerzas es probablemente la principal tarea que hacen los líderes técnicos. La multiplicación de fuerzas es la principal tarea que hacen los líderes técnicos.

La pregunta que mucha gente hace es, ¿por qué te convertirías en un líder técnico? ¿Qué es lo que hace que alguien quiera convertirse en un líder técnico? Honestamente, varía entre individuos, pero para mí, la principal razón por la que decidí convertirme en un líder técnico fue que después de hacer esto durante muchos años, la codificación se convirtió en la parte fácil. Empecé a buscar cosas más interesantes que hacer que simplemente escribir código, y una cosa que me di cuenta mientras trabajaba en un equipo en una startup de hipercrecimiento es que hay mucho más que puedes hacer si no eres la persona que está golpeando el teclado. Puedes tener un impacto mucho mayor, una contribución mucho mayor si estás ayudando a todo el equipo a hacer más cosas y a trabajar en los proyectos correctos que si eres solo la persona que recibe instrucciones y escribe código.

Y una forma de tener más de ese impacto es que como líder técnico, tienes la oportunidad de, citando estar en la sala donde se toman las decisiones más importantes, donde los dueños de los productos y otros líderes técnicos están decidiendo en qué va a trabajar este equipo a continuación, qué es lo que vamos a decidir que es importante, en qué nos vamos a centrar. Si estás en esa sala, puedes ayudar a dar forma a la hoja de ruta y puedes ayudar con, ya sabes, cosas simples como, oye, tenemos estas cinco ideas. ¿Cuál de estas es realmente alcanzable en un cierto período de tiempo? Y si estás en esa sala, como líder técnico, puedes decir, oye, eso llevaría, no sé, como tal vez un par de semanas. Eso es realmente fácil. Eso es realmente difícil.

Entonces, ¿cuáles son algunas lecciones que he aprendido mientras desempeño este papel? Ten en cuenta, estas son lecciones tempranas. Soy un líder técnico bastante nuevo. Lo bueno de estas lecciones es que aún provienen de una perspectiva de recordar cómo es no ser un líder técnico en lugar de, ya sabes, 20 años después cuando es como, huh, ¿qué fue realmente lo que se sintió nuevo al ser un líder técnico?

Entonces, la primera lección que aprendí es que generalmente la persona que se convierte en líder técnico es el ingeniero más fuerte del equipo, o al menos generalmente son un ingeniero muy, muy fuerte. Entonces, lo que puedes hacer como líder técnico para ayudar al resto del equipo y empoderarlos es ser el payaso. Cuando alguien, cuando, ya sabes, el gerente o el propietario del producto está pidiendo ideas. Una de mis cosas favoritas para decir es, bueno, está bien. Entonces necesitamos datos inmutables, pero no usemos la blockchain. Ya sabes, broma divertida, ja ja. Pero también está estableciendo el piso para lo que parece una idea tonta. Como eres un líder técnico, tienes mucha reputación llamada que puedes quemar o puntos de karma. Entonces, ya sabes, si haces una sugerencia estúpida, nadie va a pensar que eres estúpido, pero libera a todos los demás en el equipo para dar sus ideas porque saben que no pueden decir nada más estúpido que lo que acabas de decir, lo que luego saca muchas de sus ideas, facilita la colaboración y se asegura de que nadie tenga miedo de compartir lo que, lo que podrían pensar que es una idea estúpida, pero en realidad es una idea realmente, realmente buena, y una gran solución para cualquier problema que estés resolviendo. Entonces, ser el payaso funciona realmente, realmente bien.

Otro es que los ingenieros que llegan a ser líderes técnicos, son, ya sabes, ingenieros fuertes, asumen mucho la propiedad, sienten mucha responsabilidad. De hecho, recuerdo haber leído un estudio que decía que sentirse responsable y sentir algo de culpa, también lo he escuchado llamar culpa del líder técnico, es que si sientes un cierto tipo de culpa por no hacer las cosas, eso en realidad significa que tienes un gran potencial de líder técnico y potencial de ingeniero de personal, etc. porque asumes mucho orgullo y mucha propiedad y tratas de asegurarte de que haces mucho. Pero eso también es una trampa porque una vez que eres un líder técnico, te conviertes en, por así decirlo, responsable del rendimiento de todo el equipo. Entonces, es muy fácil caer en el papel de tratar de ser el héroe y ser como, oh, mierda, eso no se hizo. Yo lo haré. Oh, esa otra cosa no se hizo. Yo lo haré. Oh, mierda. Este proyecto va mal. Yo lo haré. Oh, no, ese ingeniero está luchando. Voy a saltar a un Zoom con ellos y ayudarles a hacerlo. Si intentas hacer el trabajo de todo un equipo, te quemarás. Entonces y he visto esto con muchos de mis amigos cuando eran gerentes tempranos, eran como, Bueno, genial, estoy administrando un equipo de cinco personas. Y simplemente estaban haciendo el trabajo de cinco personas en lugar de delegar. Entonces, es realmente importante enfocarse y pensar en hacer menos y dejar que tu equipo haga el trabajo. Ya sabes, estás ahí para ayudar al equipo a ser efectivo, no para hacer el trabajo del equipo por ellos.

Así que haz menos, deja que las personas luchen, que fallen, que se caigan de bruces. Si no funciona, ya sabes, después de un día o dos días, déjalos ser y luego di, hey, ¿necesitas ayuda y luego te involucras? Pero no tienes que, realmente, tienes que evitar conscientemente tratar de hacer el trabajo de todos y cede tus Legos y deja que otras personas brillen porque te prometo, va a estar bien incluso si no lo hacen de la manera en que tú lo harías, va a estar bien. Enfócate en el resultado, no en cómo se hace el trabajo.

Y lo siguiente que surge de esto, mencioné antes, es, ya sabes, trabajar en hojas de ruta y cosas futuras. Se vuelve realmente, realmente confuso una vez que estás más allá de la etapa de ingeniero senior. Las empresas, resulta, y creo que esto es cierto en todos los casos con cualquiera con quien he hablado que estaba en una posición de liderazgo, nadie sabe qué demonios están haciendo. Es como, oh Dios mío, tenemos tantas prioridades, tenemos tantos proyectos grandes, críticos, importantes. Si no hacemos esa cosa, la empresa va a fracasar. Si no hacemos esa otra cosa, el sistema va a explotar. Si no hacemos feliz a este cliente, se va a ir. Y hay tantas cosas críticas, urgentes que parecen que deberían ser lo siguiente en lo que trabajas. Pero cuando estás presentando al equipo, tienes que mostrar liderazgo y sí.

Así que básicamente es confuso allá arriba, pero lo que tienes que hacer por el equipo es tener ese sentido de liderazgo y casi actuar o presentar una fachada de certeza. Aunque no estés seguro de si tomaste la decisión correcta o si no estás seguro de que estás trabajando en lo siguiente correcto, una vez que llega al resto del equipo, una vez que las personas empiezan a trabajar en ello, tienes que mostrar cierto nivel de certeza. Tienes que, incluso si en el fondo no estás seguro de que estás haciendo lo correcto o si no estás seguro acerca de las decisiones técnicas que has tomado, de alguna manera tienes que seguir adelante y comprometerte con un camino. Miras diferentes posibilidades, idealmente cuando estás haciendo planes para una historia específica, involucras a todos para que todo el equipo esté generando ideas y luego cuando tienes ideas en competencia, tu trabajo como líder técnico es decir, está bien, esa es 60% mala, esa otra es solo 50% mala, vamos con la opción del 50% y luego reevaluamos si no está funcionando en las próximas horas o en los próximos días, dependiendo de cómo sean tus ciclos de historia. La idea es que haces un plan y te comprometes con un plan y luego cuando tomas estas decisiones las mantienes en tu cabeza. Al resto de tu equipo, debería parecer que estás mayormente seguro, deberías explicar tu razonamiento, deberías explicar que hay márgenes de error en tus decisiones, pero una vez que se ha tomado una decisión, comprométete con ella, no intentes cambiar de opinión cada par de segundos o cada vez que entran a una reunión y te preguntan, hey, ¿cómo deberíamos hacer esto? No cambies tu decisión o cambies todo tu enfoque. Pero también es muy importante, cuando estás haciendo un plan con tu equipo, es dejar suficiente espacio para que el equipo tenga autonomía y para que todos sientan, no solo sientan, para que todos tengan espacio para contribuir. No digas, está bien, para ese botón, tienes que ir a ese archivo, cambiarlo a morado, ir allí para cambiarlo, para cambiar dónde aparece. No tienes que darles todos esos detalles. No tienes que, y no deberías dar todos los detalles a tu equipo de lo que están haciendo, porque entonces podrías hacerlo tú mismo. Es más como, está bien, tú te encargas del botón, asegúrate de que esté en el lugar correcto. Este es el lugar donde queremos que esté. Tú te encargas de la API, construye la API de back end para esto. Tú trabajas en la capa intermedia donde el botón está hablando con la API, y luego cuando lo tengamos todo junto, vamos a averiguar cómo ensamblarlo. Haz un plan más basado en cómo las diferentes piezas móviles van a hablar entre sí en lugar de qué van a ser las piezas móviles reales y luego deja que tu equipo se enfoque en el interior de cada pieza móvil individual y averigüe cómo construir la implementación en sí misma.

Lo que me lleva a mi próximo punto, que es que como líder técnico, lo que puedes hacer es mucho más ingeniería y mucho menos codificación. Y esto es una de esas cosas que me llevó mucho tiempo darme cuenta de la diferencia entre codificación e ingeniería.

Y la mejor manera que tengo de explicar la diferencia es que cuando estás haciendo ingeniería, puedes trabajar con una pizarra y, o una pizarra virtual, o incluso notas adhesivas, y puedes simplemente dibujar círculos, cuadrados, flechas y cosas así en una pizarra de algún tipo, o en notas adhesivas, y descubrir cuáles son las piezas móviles, cómo deberían interactuar, cómo deberías, ya sabes, gran parte de esto es modelado de dominio, cómo deberías desglosar un problema, cuáles son los pasos que nos llevarán desde una solución de trabajo inicial valiosa hasta la solución completa, así como cómo pasar de un monopatín a un coche, que es una analogía para un vehículo en movimiento que, o un transportador de personas, empiezas con un monopatín, terminas con un coche, ¿y cuáles son los pasos que te llevan allí? ¿Cuáles son incluso todos los pasos en un proceso de negocio que la gente está haciendo, y cómo puedes convertir esos en code software, y básicamente en software. El papel del líder técnico es hacer gran parte de ese desglose y menos de la implementación final y codificación real. Es importante que aún te mantengas en el code, y que hagas el trabajo, y que estés manos a la obra con el equipo. Pero en lo que te estás enfocando día a día es mucho más en la ingeniería, y luego dejando que el resto de tu equipo descubra los detalles de codificación, donde ellos construyen la implementación real.

Esto es una de esas cosas que es realmente difícil de explicar hasta que lo has probado, pero una vez que hace clic, se siente muy liberador. Porque, al menos para mí personalmente, después de haber estado codificando ahora durante 25, 26 años, ha sido mucho tiempo. Lo que me di cuenta es que cuanto más de estos sistemas construyes, más ves la filosofía y la estructura detrás del code real. Y entonces puedes, en tu cabeza o en una pizarra o con tu equipo, simplemente mover piezas y descubrir qué deberían ser y cómo encajan sin siquiera saber o preocuparte por la implementación final de esas porque entonces los ingenieros senior y los de nivel medio y los junior y todos los demás pueden trabajar en la implementación real después de que se haya hecho la pieza de ingeniería general. Y también, ya sabes, es realmente divertido codificar. Así que personalmente todavía me meto en muchas de las piezas móviles, pero descubro que soy mucho más efectivo y tengo un impacto mucho mayor y es mucho más útil para mi equipo si me centro en las partes de ingeniería y les ayudo a razonar a través de las partes de ingeniería. Ya sabes, a veces puede ser simplemente hacer buenas preguntas cuando tienes ingenieros senior realmente fuertes que son realmente buenos que solo necesitan algo de orientación, puedes hacer preguntas apuntadas para guiarlos en una cierta dirección y ayudarles a descubrir cómo debería encajar todo el sistema. Y, ya sabes, en general, yo recomendaría totalmente optar por un puesto de liderazgo técnico y seguir esa pista. Honestamente ha sido lo más divertido que he tenido con la codificación y la ingeniería de software en mucho tiempo. Se siente un poco abstracto a veces y se siente como si estuvieras muy alejado de la implementación, pero por otro lado, también no tienes que hacer las partes que se sienten aburridas. Es realmente agradable simplemente trabajar en nuevos desafíos interesantes y centrarse más en las cosas de nivel superior y descubrir qué viene después, qué hacer en el futuro, qué partes de los proyectos pueden ser intercambiadas. Oye, ¿sabes qué? Esto es mucho trabajo que no necesitamos hacer ahora mismo. Si cambiamos el mapa de ruta, vamos a obtener mucho más valor en última instancia más rápido, y todavía vamos a terminar todo al final. Y personalmente encuentro eso mucho más divertido que simplemente golpear un teclado y, ya sabes, y, ya sabes, discutir en Internet sobre la mejor manera de escribir un bucle for en JavaScript. Así que sí, si tienes la oportunidad, pruébalo. Es definitivamente interesante. Y abre todo un nuevo mundo de posibilidades y un nuevo mundo de ingeniería de software que como ingeniero senior, tal vez

Entonces, bien. Entonces, la primera pregunta aquí de, de, de la audiencia es, dice, ya sabes, haces un punto interesante sobre la ingeniería versus la codificación, y luego usan el término arquitectura específicamente, ¿qué consideras que son las diferencias entre la ingeniería y la arquitectura? Entonces, yo, yo creo que la diferencia entre la ingeniería y la codificación es principalmente que cuando estás haciendo ingeniería, estás lidiando principalmente con la resolución de los problemas difusos y creando sus soluciones. La codificación es como la parte de implementación del proceso de ingeniería. Por lo general, estos días hacemos ambos, ambos de ellos de manera paralela simultáneamente. Y luego, si te adentras en la arquitectura, creo que muchos, donde muchos arquitectos se meten en problemas, en problemas, es que si te vuelves demasiado abstracto, pierdes la parte de codificación y empiezas, creo que hemos, probablemente todos hemos experimentado los llamados astronautas de la arquitectura que tienen una solución realmente genial en papel, grandes diagramas, grandes esquemas. Ahora solo alguien tiene que ir e implementarlo y escribes la primera línea de code y todo se desmorona porque alguna suposición básica no funciona. Así que creo que la ingeniería es como el punto dulce entre esos donde estás haciendo suficiente arquitectura para estar pensando en soluciones de una manera un poco más abstracta, pero todavía estás haciendo suficiente de la parte de codificación para que realmente te ensucies las manos y, ya sabes, implementes esas soluciones y puedas ver cómo funcionan y puedas adaptarlas en tiempo real.