Capítulo 3: Líder Técnico

Me convertí en jefe técnico hace muchos años. Me habían ascendido a ingeniero senior y trabajaba en un pequeño equipo con otros ingenieros senior. Fue una especie de sorpresa que me ascendieran a jefe técnico, porque no era la persona más veterana del equipo ni por título ni por años de experiencia. En retrospectiva, tenía algunas ventajas. En primer lugar, era algo más que un buen ingeniero. Era un buen comunicador. Podía escribir documentos claros, podía hacer presentaciones sin derretirme y podía hablar con personas de diferentes equipos y funciones y explicarles lo que estaba pasando. También se me daba bien priorizar. Tenía ganas de hacer avanzar el trabajo y decidir lo que había que hacer a continuación. Por último, estaba dispuesto a recoger los pedazos y hacer lo que había que hacer para progresar. Creo que, al final, esta urgencia pragmática fue el factor decisivo. Después de todo, el papel de líder tecnológico es un puesto de liderazgo, incluso cuando no es un puesto de gestión.

También he visto a líderes tecnológicos fracasar. Una lucha particularmente memorable fue la de una persona que era un ingeniero increíble, que escribía un gran código, pero que odiaba hablar con la gente y a menudo se distraía con los detalles técnicos. Le vi meterse en una madriguera tras otra y, mientras tanto, el director de producto aprovechó su ausencia para hacer que el resto del equipo se comprometiera a entregar características mal diseñadas y demasiado agresivas. El proyecto era un desastre, ¿y qué hizo el director técnico? Fue a buscar la siguiente refactorización, porque estaba seguro de que los problemas estaban enteramente en la forma en que el código estaba estructurado. Probablemente reconozcas esta historia, porque ocurre en todas partes. La idea de que el papel de líder técnico debe otorgarse automáticamente al ingeniero más experimentado, el que puede manejar las características más complejas o el que escribe el mejor código, es un error común en el que caen incluso los gerentes experimentados. El liderazgo técnico no es el trabajo para la persona que quiere la libertad de centrarse profundamente en los detalles de su propio código. Un líder técnico que hace esto no está haciendo su trabajo. Pero, ¿cuál es realmente el trabajo de un jefe técnico? ¿Qué esperamos de esta persona?

Como ocurre con muchos títulos en la ingeniería de software, el de “jefe técnico” carece de una definición común. Lo mejor que puedo hacer es basarme en mi propia experiencia y en la de otros. Mi trabajo como director técnico era seguir escribiendo código, pero con las responsabilidades añadidas de representar al grupo ante la dirección, revisar nuestros planes de entrega de características y ocuparme de muchos de los detalles del proceso de gestión de proyectos. Podía ser el líder tecnológico, a pesar de no ser la persona con más antigüedad, porque estaba dispuesto y era capaz de asumir las responsabilidades del papel, mientras que el resto de mi equipo estaba más interesado en mantenerse puramente centrado en el software que estaban escribiendo. Cuando mi equipo de Rent the Runway creó nuestra escalera profesional de ingeniería, elegimos conscientemente definir el papel de líder técnico como un conjunto de características que un ingeniero podía asumir en muchos puntos de la escalera, en lugar de un nivel específico. Adoptamos este enfoque porque queríamos reconocer que, a medida que los equipos cambian y evolucionan, la función de líder técnico puede ser desempeñada por muchos niveles diferentes de ingenieros, y puede pasar de un ingeniero a otro sin que ninguno de ellos cambie necesariamente su nivel de trabajo funcional. Es posible que el jefe técnico no tenga exactamente el mismo papel de una empresa a otra, o incluso de un equipo a otro dentro de una empresa, pero sabemos por el título que se espera que sea tanto un puesto técnico como un papel de liderazgo, y que a menudo es un conjunto temporal de responsabilidades más que un título permanente. Así que, dicho todo esto: ¿qué es un líder tecnológico? Esta es la descripción que hemos creado en Rent the Runway:

El papel de líder técnico no es un punto en la escalera, sino un conjunto de responsabilidades que cualquier ingeniero puede asumir una vez que alcanza el nivel superior. Esta función puede incluir o no la gestión de personas, pero si lo hace, se espera que el líder técnico gestione a estos miembros del equipo según los altos estándares de gestión de RTR tech. Estos estándares incluyen

• Contactos regulares (semanales) 1-1
• Comentarios regulares sobre el crecimiento de la carrera, la progresión hacia los objetivos, las áreas de mejora y los elogios cuando se justifique
• Trabajar con los informes para identificar las áreas de aprendizaje y ayudarles a crecer en estas áreas a través del trabajo en proyectos, el aprendizaje externo o la tutoría adicional

Si un jefe de tecnología no dirige directamente, se espera que proporcione tutoría y orientación a los demás miembros del equipo.

El líder tecnológico está aprendiendo a ser un sólido gestor de proyectos técnicos y, como tal, se está escalando a sí mismo delegando el trabajo de forma efectiva sin microgestión. Se centran en la productividad de todo el equipo y se esfuerzan por aumentar el impacto del producto del trabajo del equipo. Están facultados para tomar decisiones independientes para el equipo y están aprendiendo a manejar situaciones difíciles de gestión y liderazgo. También aprenden a colaborar eficazmente con el producto, el análisis y otras áreas de la empresa. No es necesario que un ingeniero trabaje como jefe de tecnología para progresar, pero es la forma más común de que los ingenieros crezcan desde el puesto de ingeniero senior 1 → 2 y es necesario para crecer desde el puesto de ingeniero senior 2 hasta el de jefe de ingeniería. En realidad, es muy difícil pasar de ingeniero sénior 2 sin haber actuado nunca como líder técnico, incluso en la vía de colaborador individual, debido a la importancia del liderazgo y la responsabilidad en los niveles superiores.

Tal vez sea mejor la descripción utilizada por Patrick Kua en su libro Talking with Tech Leads:

Un líder, responsable de un equipo de desarrollo (de software), que pasa al menos el 30 por ciento de su tiempo escribiendo código con el equipo.

Los líderes técnicos están en posición de actuar como fuertes líderes de proyectos técnicos, y de utilizar su experiencia a mayor escala para que todo su equipo mejore. Pueden tomar decisiones independientes y desempeñan un papel importante en la coordinación con otros socios no ingenieros que pueda tener su equipo. Observarás que aquí no hay nada de trabajo específicamente técnico. Se trata de una función de ingeniería de alto nivel, pero es un error vincular la noción de líder técnico a una que se reduce al mejor ingeniero o al más experimentado del equipo. No se puede liderar sin involucrar a otras personas, y las habilidades de las personas son lo que estamos pidiendo al nuevo líder tecnológico que se extienda, mucho más que la pura experiencia técnica. Sin embargo, los líderes tecnológicos trabajarán en una nueva e importante habilidad técnica: la gestión de proyectos. El trabajo de desglosar un proyecto tiene mucha similitud con el trabajo de diseñar sistemas, y el aprendizaje de esta habilidad es valioso incluso para los ingenieros que no quieren gestionar personas.

Si te has encontrado en el puesto de jefe de tecnología, ¡felicidades! Alguien piensa que tienes lo que hay que tener para ser la persona clave de un equipo. Ahora es el momento de aprender nuevas habilidades.

Eres un líder tecnológico, lo que significa que sabes algo de software, y tu jefe cree que eres lo suficientemente maduro como para que te den una mayor responsabilidad en los proyectos. Sin embargo, la madurez y los conocimientos técnicos no sirven de nada si no eres capaz de descubrir el mayor truco para ser un buen líder tecnológico: la voluntad de alejarte del código y descubrir cómo equilibrar tus compromisos técnicos con el trabajo que necesita todo el equipo. Tienes que dejar de confiar por completo en tus antiguas habilidades y empezar a aprender algunas nuevas. Vas a aprender el arte del equilibrio.

A partir de ahora, vayas donde vayas en tu carrera, es probable que el equilibrio sea uno de tus principales retos. Si quieres tener autonomía sobre tu trabajo, si quieres tener la libertad de elegir en qué trabajas y cuándo lo haces, tienes que dominar tu tiempo y cómo lo utilizas. Y lo que es peor, a menudo tendrás que compaginar cosas que sabes hacer y que te gustan, como escribir código, con otras que no sabes hacer. Es natural que los humanos prefieran las actividades que dominan, así que cuando tengas que dedicar menos tiempo a tus talentos actuales en favor de aprender cosas nuevas, te sentirás bastante incómodo.

Puede ser difícil equilibrar el trabajo de gestión y supervisión de proyectos con la entrega técnica práctica. Algunos días tienes un horario de técnico y otros de gestor. A través de la prueba y el error, tendrás que aprender a gestionar tu tiempo para disponer de bloques de trabajo del tamaño adecuado. El peor error de programación es dejarse arrastrar al azar a las reuniones. Es muy difícil entrar en el ritmo de escribir código si te interrumpen cada hora con una reunión.

Incluso con una programación cuidadosa, a menudo no tendrás tiempo para concentrarte durante varios días en problemas de codificación. Con suerte, ya has aprendido algunos trucos que te ayudarán a dividir tu propio trabajo para que no tengas que dedicar varios días de esfuerzo concentrado a terminar las tareas técnicas. También sabes que es importante conseguir que tu equipo tenga un horario que les permita estar centrados en el desarrollo durante largos tramos de tiempo, porque necesitarán centrarse durante varios días en problemas de codificación. Parte de tu liderazgo consiste en ayudar a las demás partes interesadas, como tu jefe y el director de producto, a respetar el enfoque del equipo y a establecer calendarios de reuniones que no sean abrumadores para los colaboradores individuales.

Supongamos que estás colaborando con un director de producto y un equipo de otros cuatro ingenieros en un gran esfuerzo de varias semanas para lanzar una nueva iniciativa. En este caso, el director técnico tiene una serie de responsabilidades, dependiendo de la fase del ciclo de vida del proyecto en la que se encuentre. Por supuesto, tendrá que escribir algo de código y tomar algunas decisiones técnicas. Pero ése es sólo uno de los papeles que desempeñará, y probablemente ni siquiera sea el más importante.

Tu mayor prioridad como líder técnico es tener una visión amplia del trabajo para que el proyecto siga avanzando. ¿Cómo se pasa de organizar y planificar el código que hay que escribir por cuenta propia a organizar y dirigir el proyecto en general?

En las funciones de arquitecto de sistemas y analista de negocio, se identifican los sistemas críticos que hay que cambiar y las características críticas que hay que construir para entregar los próximos proyectos. El objetivo es proporcionar cierta estructura para basar las estimaciones y ordenar el trabajo. No es necesario identificar perfectamente todos los elementos de un proyecto, pero es muy valioso dedicar tiempo a pensar en las externalidades y los problemas relacionados con un proyecto. Esta función requiere que tenga un buen sentido de la arquitectura general de los sistemas y una sólida comprensión de cómo diseñar software complejo. Probablemente también requiera que sea capaz de entender los requisitos empresariales y traducirlos en software.

Los planificadores de proyectos desglosan el trabajo en productos aproximados. Con este sombrero puesto, aprendes a encontrar formas eficientes de dividir el trabajo para que el equipo pueda trabajar rápidamente. Parte del reto consiste en realizar la mayor cantidad posible de trabajo productivo en paralelo. Esto puede ser difícil porque probablemente estés acostumbrado a pensar sólo en tu propio trabajo, en lugar de en el trabajo de grupos de personas. Es fundamental encontrar lugares donde aplicar abstracciones acordadas para permitir el trabajo en paralelo. Por ejemplo, si tienes un frontend que consume objetos JSON de una API, no debería ser necesario que la API esté completamente terminada para que comience el desarrollo del frontend. En su lugar, acuerda el formato JSON y empieza a codificar en ese formato utilizando objetos ficticios. Si tienes suerte, ya has visto esto antes y simplemente estás haciendo un patrón de tu trabajo anterior. En esta etapa, querrás reunir las aportaciones de los expertos de tu equipo y hablar con las personas que conocen profundamente las partes afectadas del software, para que puedan ayudar con los detalles aquí. También querrá empezar a identificar las prioridades como parte de este proceso. ¿Qué partes son críticas y cuáles son opcionales? ¿Cómo se puede trabajar en los elementos críticos al principio del proyecto?

Los desarrolladores de software y los jefes de equipo escriben el código, comunican los retos y delegan. A medida que los proyectos avanzan, surgen obstáculos inesperados. A veces, los líderes tecnológicos se ven tentados a hacer heroicidades y a superar ellos mismos estos obstáculos, trabajando excesivas horas extras para conseguirlo todo. En tu posición de líder tecnológico, debes seguir escribiendo código, pero no demasiado. Incluso si tienes la tentación de sacar un conejo del sombrero tú mismo, debes comunicar este obstáculo primero. Tu jefe de producto debe conocer lo antes posible cualquier posible reto. Solicite la ayuda de su director de ingeniería cuando sea necesario. En una organización sana, no hay que avergonzarse ni perjudicarse por plantear los problemas desde el principio. A menudo, los equipos fracasan porque se han excedido en el trabajo con una característica con la que su director de producto habría estado dispuesto a comprometerse. A medida que un gran proyecto se acerca a su fecha de entrega, habrá que hacer concesiones en cuanto a la funcionalidad. Empieza a buscar oportunidades para delegar trabajo, especialmente si hay una parte del sistema que esperabas construir tú mismo y que no has tenido tiempo de abordar.

Como puedes ver en estas descripciones, en el proceso de ser un líder tecnológico, tienes que actuar como un desarrollador de software, un arquitecto de sistemas, un analista de negocios y un líder de equipo que sabe cuándo hacer algo sin ayuda y cuándo delegar el trabajo a otros. Afortunadamente, no hay que hacer todas estas tareas a la vez. Puede resultar incómodo al principio, pero con el tiempo y la práctica encontrarás el equilibrio.

Recuerdo muy bien mi primera experiencia con la gestión de proyectos complejos. Era un líder tecnológico novato y mi equipo estaba llevando a cabo una tarea muy compleja. Teníamos un sistema existente que habíamos escalado hasta su punto de ruptura. Después de aplicar todos los trucos posibles, decidimos que era hora de averiguar cómo ejecutarlo en varias máquinas. Esto fue en los primeros días de los sistemas distribuidos, cuando la mayoría de los desarrolladores de software realmente no sabían mucho sobre las mejores prácticas para crearlos. Pero contábamos con un gran equipo de personas inteligentes y confiábamos en que podríamos resolverlo.

Y así fue, sin prisa pero sin pausa. Pasamos mucho tiempo pensando en el diseño y en las diferentes formas de dividir nuestros cálculos para que tuvieran sentido cuando se computaran en varias máquinas. Y entonces, un día, mi jefe Mike me llevó a su oficina y me dijo que tenía que hacer un plan de proyecto.

Fue una de las peores experiencias de mi vida.

Tuve que tomar este conjunto increíblemente complicado de tareas y tratar de averiguar cuáles dependían de otras. Tuve que pensar en todo tipo de dependencias. ¿Cómo lo haríamos funcionar en el complejo marco de pruebas del que dependíamos? ¿Cómo lo íbamos a desplegar? ¿Cuándo teníamos que pedir el hardware para probarlo? ¿Cuánto durarían las pruebas de integración? Las preguntas se sucedían. Iba a la oficina de Mike, me sentaba frente a él en un gran escritorio de madera y repasábamos las descripciones de las tareas, las fechas y los desgloses. Me ayudaba a hacer una parte y luego me enviaba con las partes que necesitaban más trabajo.

No era algo que me gustara hacer. Está grabado a fuego en mi memoria como una serie de pasos frustrantes y tediosos en los que tenía que superar la incertidumbre y el miedo a cometer errores, el miedo a que faltaran piezas, para crear un plan que pasara el juicio de Mike. Luego tuvimos otra ronda de trabajo tedioso para ponerlo en un formato que pudiéramos presentar al equipo de liderazgo, para que lo aceptaran. Casi me mata. Y fue una de las experiencias de aprendizaje más importantes de mi carrera.

¿El desarrollo ágil de software no elimina la necesidad de la gestión de proyectos? No. El desarrollo ágil de software es una gran manera de pensar en el trabajo porque te obliga a centrarte en dividir las tareas en trozos más pequeños, planificar esos trozos más pequeños y entregar el valor de forma incremental en lugar de todo a la vez. Nada de esto significa que no necesites saber cómo gestionar un proyecto. Tendrás proyectos que, por la razón que sea, no pueden completarse en un solo sprint, o incluso en dos pequeños sprints. Tendrás que estimar la duración del proyecto para tu equipo de gestión, y dar algunos detalles sobre por qué crees que las cosas van a tardar tanto. Hay algunos proyectos, normalmente descritos con palabras como infraestructura, plataforma o sistema, que requieren una arquitectura o una planificación avanzada importante. Cuando te enfrentes a este tipo de proyectos, que incluyen muchas incógnitas y plazos relativamente duros, verás que no encajan tan bien en el proceso ágil estándar.

A medida que avanzas en tu carrera, necesitas entender cómo dividir el trabajo que tiene una complejidad que va más allá de lo que puedes hacer como individuo. La gestión de un proyecto de larga duración y en equipo no es lo que la mayoría de la gente considera divertido. A mí me resulta tedioso y a veces me da algo de miedo. Quiero estar construyendo y obteniendo valor, no tratando de pensar en cómo desglosar un proyecto que todavía tiene detalles de implementación muy difusos. Tengo miedo de que me pidan cuentas y de que se me escape algo importante en el proceso que haga fracasar el proyecto. Pero la alternativa es que el proyecto fracase más lentamente, no más rápido.

La gestión de proyectos no es algo que tenga que hacerse en detalle para cada esfuerzo, y se utiliza en exceso en algunas organizaciones. Ni siquiera me gusta contratar gestores de proyectos porque a menudo actúan como una muleta para que los ingenieros la utilicen en lugar de aprender a pensar en su futuro trabajo y hacer preguntas reales sobre lo que están haciendo y por qué, y su presencia significa que tienes más proyectos de estilo cascada en lugar de un proceso ágil. Aun así, la gestión de proyectos tiene que producirse y, como líder tecnológico, deberías hacerlo cuando sea necesario, especialmente en proyectos muy técnicos.

En última instancia, el valor de la planificación no es que ejecutes el plan a la perfección, que captes todos los detalles de antemano o que predigas el futuro; es que te impongas la autodisciplina de pensar en el proyecto con cierta profundidad antes de lanzarte a ver qué pasa. El objetivo es un cierto grado de previsión, en lugares donde se puedan hacer razonablemente predicciones y planes. El plan en sí, por muy preciso que resulte, es menos importante que dedicar tiempo al acto de planificar.

Vuelvo a mi primera experiencia en gestión de proyectos. ¿El proyecto se desarrolló perfectamente según lo previsto? Por supuesto que no. Hubo baches, errores, retrasos inesperados y cosas que se nos pasaron por alto. Sin embargo, sorprendentemente, entregamos el proyecto casi a tiempo y no tuvimos que pasar noches en vela para conseguirlo. Nos las arreglamos para hacer los cambios necesarios para convertir este complejo sistema en un artefacto desplegable distribuido, todo ello mientras trabajábamos contra la rama de código maestro con otros 40 desarrolladores que hacían sus propios cambios simultáneamente. Todo esto fue posible porque teníamos un gran equipo, y teníamos un plan. Habíamos pensado en cómo sería el éxito, y habíamos identificado algunos de los riesgos que podrían causar el fracaso.

Desde aquella frustrante serie de reuniones con Mike, he tenido mi propia serie de reuniones de planificación de proyectos en las que yo era el que se sentaba en el lugar de Mike, y frente a mí estaba Carlo, o Alicia, o Tim. Cada uno de ellos sintió la frustración de que el plan careciera de detalles, y cada uno de ellos se alejó e hizo el incómodo trabajo de pensar en cosas que no son código, que no pueden predecirse perfectamente. Y cada uno de ellos ha llevado proyectos complejos a resultados exitosos gracias a este trabajo, y están mejor equipados para construir sistemas más grandes y liderar equipos más grandes ahora que entienden lo que significa realmente el desglose de un proyecto.

La gestión de un proyecto es el acto de dividir un objetivo final complejo en partes más pequeñas, colocando esas partes en el orden más efectivo en que deben hacerse, identificando qué partes pueden hacerse en paralelo y cuáles deben hacerse en secuencia, e intentando descifrar las incógnitas del proyecto que pueden hacer que se ralentice o fracase por completo. Se trata de abordar la incertidumbre, tratar de encontrar las incógnitas y reconocer que se van a cometer errores en el proceso y que se van a pasar por alto algunas incógnitas a pesar de los esfuerzos realizados. He aquí algunas pautas:

1. Desglosa el trabajo. Saca una hoja de cálculo, o un diagrama de Gantt, o lo que sea que funcione para ti, y empieza a dividir tu gran objetivo (por ejemplo, reescribir tu sistema de facturación) en tareas. Empieza por las piezas más grandes, luego divide las piezas grandes en piezas más pequeñas, y luego divídelas en piezas aún más pequeñas. En realidad, no tienes que hacerlo todo tú mismo. Si hay partes del sistema que no entiendes bien, pide ayuda a la persona que sí lo hace. Desglosa un poco las partes más importantes y luego presta atención a la ordenación del trabajo. ¿Qué puede empezar inmediatamente? Deja esas tareas en manos de las personas que pueden convertirlas en un trabajo del tamaño de un billete.
2. Deja de lado los detalles y las incógnitas. El truco de la gestión de proyectos es no detenerse cuando te sientas un poco atascado o cansado de ello. Es agotador y tedioso, como he dicho antes. Y no es algo que probablemente sepas hacer bien. Así que sigue presionando más allá de esos puntos de irritación, aburrimiento y dolor. Un buen director se sentará contigo y te dirá dónde no es lo suficientemente bueno, te hará preguntas para estimularte o incluso trabajará contigo en algunos aspectos. A nosotros tampoco nos gusta, pero forma parte del ejercicio de enseñanza. Trabaja con las incógnitas hasta que sientas que ya no tiene sentido dedicarles tiempo.
3. Ejecute el proyecto y ajuste el plan sobre la marcha. El valor de un buen proceso de planificación es que te ayuda a saber aproximadamente hasta dónde ha llegado el proyecto, y aproximadamente cuánto le falta para completarse. A medida que las cosas se desvían (y siempre lo hacen), mantén a todos informados del estado. Pero ahora, en lugar de adivinar lo que queda por hacer, puedes señalar claramente los hitos que se han alcanzado y describir el trabajo restante previsto.
4. Utiliza la información obtenida en el proceso de planificación para gestionar los cambios en los requisitos. Has aprendido mucho al desglosar el proyecto a partir del conjunto original de requisitos. Si los requisitos empiezan a cambiar a mitad de camino, tome esos conocimientos y aplíquelos a los cambios. Si los cambios añaden un riesgo significativo al proyecto, requieren un montón de nueva planificación o simplemente exigen mucho trabajo adicional, tenga claro el costo de esos cambios. Si estás trabajando con un plazo muy ajustado, conocer aproximadamente el esfuerzo necesario te ayudará a priorizar, recortar y simplificar el trabajo para conseguir el mejor compromiso de características, calidad y fecha de entrega.
5. Revisa los detalles a medida que te acercas a la finalización. Hacia el final del proyecto, vuelve el tedio. Es el momento de ocuparse realmente de los detalles de acabado. ¿Qué falta? ¿Qué pruebas? ¿Qué verificación? Realiza un premortem, un ejercicio en el que repases todas las cosas que podrían fallar en el lanzamiento de este gran proyecto. Decide dónde está el límite de lo “suficientemente bueno”, socialízalo y comprométete con él. Recorta el trabajo que quede por debajo de la línea de “suficientemente bueno” y centra al equipo en los detalles finales más importantes. Haz un plan de lanzamiento; haz un plan de retroceso. Y al final, ¡no olvides celebrarlo!

La decisión de ser gerente o seguir en la vía técnica es difícil. Depende mucho del contexto y no puedo decirte qué hacer. Sin embargo, como alguien que ha soñado y vivido ambas vías, puedo decirte cómo me imaginaba las funciones frente a lo que acabé experimentando y observando. Así que, con la advertencia de que son simples caricaturas y no están grabadas en piedra, déjame contarte cómo divergieron para mí la imaginación y la realidad.

Tus días transcurren en una mezcla de pensamiento profundo, resolviendo problemas difíciles que te desafían intelectualmente pero que siguen siendo divertidos y novedosos, y colaborando con otros pensadores profundos. Se trata de software, así que sabes que habrá que afeitar algunos yaks¹⁾, pero tienes que hacer algunos de los trabajos más interesantes, y tienes mucho poder para elegir en qué trabajas. Te encanta escribir código, corregirlo, hacerlo más rápido y hacer que las computadoras hagan cosas nuevas, y puedes dedicar la mayor parte de tu tiempo a ello.

Debido a tu antigüedad, los directivos te piden consejo sobre cómo enfocar el desarrollo antes de que empiece, así que sabes todo lo que está pasando pero no tienes que ocuparte de los detalles de la gente que lo construye. Se te invita a las reuniones justas en las que se toman las decisiones importantes, pero no tantas como para interrumpir tu flujo. Los desarrolladores más jóvenes te admiran y están pendientes de cada una de tus palabras, aceptando tus comentarios pero sin imponerlos en tu tiempo de reflexión.

Tu trayectoria ascendente nunca se ve frenada, y siempre hay nuevos grandes problemas que puedes resolver para mostrar tu valor a la organización. Trabajas duro, pero rara vez se te pide que te quedes hasta tarde o que trabajes los fines de semana, porque como todos sabemos es imposible hacer un trabajo de calidad y reflexivo durante demasiadas horas a la semana. Cuando trabajas hasta tarde, es porque estás tan atrapado en el flujo que no puedes esperar a terminar la función que tienes entre manos o a arreglar el error que acabas de encontrar.

Consigues escribir libros, dar charlas y crear trabajos de código abierto y, con algo de suerte y persistencia, te ganas un poco de fama en la industria. A nadie le importa que seas un poco torpe o tímido ni espera que evoluciones mucho tu estilo de comunicación, porque lo que dices es muy importante. Todo el mundo en tu organización sabe quién eres, entiende lo valioso que es tu trabajo y es deferente con tus opiniones.

En resumen, tienes el equilibrio perfecto de trabajo atractivo, fama y experiencia acumulada que te hace valioso y respetado, muy pagado e influyente.

Cuando encuentras el proyecto adecuado, y el ciclo de vida del proyecto adecuado, tu vida es genial. Tienes retos y aprendes cosas nuevas. Tienes mucho control sobre tu día a día, y ciertamente menos reuniones que tus homólogos de gestión, pero tus días no siempre transcurren en un feliz estado de flujo. En cada proyecto hay un periodo en el que tienes la idea y la vendes a la gente, intentando convencerla de que es el enfoque correcto. O bien has implantado el sistema, pero ahora tienes que conseguir que otros equipos empiecen a utilizarlo, así que te sientas con ellos durante días para enseñarles los entresijos, explicarles por qué es útil e intentar convencerles de que presionen a su jefe para que les dedique tiempo a adoptarlo.

Tu trayectoria ascendente no es tan rápida y fácil como esperabas. De hecho, es bastante lenta. Esos grandes proyectos que demuestran que eres un arquitecto inestimable son difíciles de encontrar. El equipo no necesita un nuevo lenguaje de programación, una nueva base de datos o un nuevo marco web. Tu jefe no es muy bueno a la hora de darte asignaciones de peso que muestren tu talento a toda la organización; espera que tú le digas dónde están esas oportunidades. Descubrir buenos proyectos parece ser una cuestión de suerte. Si eliges el proyecto equivocado, pasarás meses o incluso años en algo que puede ser cancelado a pesar de todos tus esfuerzos. Estás un poco celoso de tus amigos de administración, que parecen ascender más rápido mientras ellos siguen haciendo crecer sus equipos.

Los otros desarrolladores son una mezcla. Eres una buena persona, así que algunos te admiran y escuchan tus opiniones, pero otros parecen estar celosos de tu influencia. Los nuevos desarrolladores quieren demasiado de tu tiempo o parecen tenerte miedo por alguna razón. Definitivamente, hay cierta competitividad con tus compañeros en torno a quién consigue liderar proyectos grandes e interesantes.

Tu jefe es un poco pesado. No te apoya mucho en tu deseo de abrir un sistema porque crees que proporciona un nuevo giro en el registro que la industria necesita, y te sugiere que si quieres dar charlas o escribir libros quizás debas dedicar parte de tu tiempo personal a esos esfuerzos. Busca tu opinión sobre cuestiones técnicas, pero a veces se olvida de contarte las nuevas iniciativas hasta que es demasiado tarde para que puedas aportar tu granito de arena. Sospechas que te estás perdiendo información crucial porque no estás en las reuniones adecuadas, pero cada vez que te invita a participar en ellas recuerdas lo aburridas e ineficaces que son, y el valioso tiempo de concentración que estás perdiendo. Además, no tiene mucha paciencia con tu deseo de librarte de trabajos tediosos como responder al correo electrónico, hacer entrevistas o responder a las revisiones de código con prontitud.

Aun así, consigues construir cosas la mayor parte del tiempo. Puedes dedicar tu tiempo a los problemas técnicos, al diseño de sistemas y a las cuestiones de ingeniería, y no tienes que tratar mucho con la gente ni sentarte en reuniones aburridas. A menudo puedes elegir tus proyectos y puedes cambiar fácilmente de equipo si quieres algo nuevo. Y acabas de descubrir que te pagan más que a tu jefe. Así que la vida no es tan mala.

Tienes un equipo, tienes el control, puedes tomar las decisiones y por fin puedes conseguir que los demás hagan las cosas a tu manera. Tu equipo te respeta y se somete con gusto a tu autoridad en todos los asuntos. ¿Crees que deberían escribir más pruebas? Les dices: “Escribe más pruebas”, ¡y lo hacen! ¿Quieres asegurarte de que todo el mundo recibe un trato justo a pesar de su sexo, raza, etc.? Te aseguras de que así sea, y despides a cualquiera que se pase de la raya y cree un ambiente poco saludable para el resto del equipo.

Como te preocupas por la gente, saben que siempre intentas hacer lo mejor para ellos, incluso cuando no están de acuerdo contigo. Te dan el beneficio de la duda, y acuden a tus 1-1 con comentarios abiertos para ti cuando metes la pata, y deseosos de recibir comentarios tuyos. Tratar con la gente es estresante, claro, pero saben que te preocupas por ellos, así que también es muy gratificante. Ahora que estás en esta posición de autoridad, ves que el impacto de tu coaching se produce rápidamente.

Cuando ves que otro directivo hace algo que parece incorrecto, eres libre de ir a darle consejo de la misma manera que hablarías con otro ingeniero que necesitara ayuda en el diseño de un sistema. Los demás directivos siempre están interesados en saber lo que piensas, y pueden ver lo eficazmente que has hecho trabajar a tu equipo, lo claramente que te preocupas por la salud de la organización y lo genuino que es tu interés por hacer que todo el mundo mejore.

Tu jefe te da mucho entrenamiento, pero rara vez interviene para decirte lo que tienes que hacer. En el momento en que te sientes preparado para asumir un equipo más grande, tu gerente está abierto a darte más gente y a ampliar tu organización. Te da objetivos claros y rara vez cambia las cosas. Aunque tengas muchas responsabilidades, sigues teniendo algo de tiempo para escribir posts en el blog y dar charlas, y esto se fomenta porque ayudará a tu equipo a contratar y a mejorar tu posición en la industria tecnológica.

En resumen, tú tomas las decisiones, creas la cultura y tu eficacia es evidente para todos los que te rodean, lo que hace que tu camino hacia el ascenso sea rápido y tu carrera, emocionante y lucrativa.

Tienes un equipo. Tienes cierto control, pero rápidamente has descubierto que conseguir que la gente haga algo es más difícil que decirles que lo hagan. Parece que has renunciado a todo el control sobre tu propio día a día. La mayoría de las veces te pasas el día en reuniones. Sabías que esto iba a ocurrir, pero no es hasta que lo vives que entiendes realmente lo que significa. Cuando sólo tenías un equipo pequeño podías equilibrar las cosas y seguir escribiendo código, pero a medida que tu equipo ha crecido has perdido el contacto con el código. Te carcome como algo que deberías estar haciendo, pero no hay tiempo. Cada vez que sacas unas horas para escribir código, te das cuenta de que sería irresponsable comprobarlo y hacer que el equipo lo soporte, así que como mucho sacas un script aquí, depuras un problema allá. Tener el enfoque para construir algo grande por ti mismo es un recuerdo lejano.

Puedes tomar decisiones, bueno, algunas decisiones. Siendo realistas, tal vez puedas reducir las cosas que se decidirán. Puedes centrar a tu equipo en algunas cosas, como escribir mejores pruebas, pero ellos siguen teniendo una hoja de ruta del producto que implementar, y tienen sus propias ideas sobre qué tareas técnicas deberían priorizarse. Así que, más que tomar decisiones tú, estás ayudando al equipo a tomarlas. Tu jefe te da objetivos, pero a veces los cambia por completo, y eres tú quien debe explicar los cambios al equipo.

Tú estableces las normas de la cultura de tu equipo, lo cual es bueno y malo. Es bueno cuando adoptan tus mejores aspectos, y es malo cuando te das cuenta de que tu equipo también refleja tus defectos.

Tu equipo no está naturalmente de acuerdo contigo, ni te respeta, ni siquiera les agradas. Te das cuenta de que la autoridad requiere algo más que un título. Te encuentras luchando por motivarles en los periodos difíciles, cuando los proyectos no van bien, o cuando tienes que decirles que todavía no están preparados para ser ascendidos, que no van a recibir un aumento de sueldo, que no hay bonificación este año. Algunos no se molestan en decirte cuando están descontentos; simplemente se hartan y renuncian antes de que te des cuenta de que hay algo mal. Cuando la empresa va bien, y tienes mucho dinero para pagar, y hay muchos proyectos interesantes, la vida es estupenda; pero cuando las cosas son estresantes, ves el poco poder que tienes para hacer feliz a la gente. Y lo que es peor, ¡ni siquiera puedes despedir a la gente sin pasar por un loco proceso de RRHH! Aun así, puedes ver que tu trabajo es importante para algunos de ellos, que son más felices y tienen más éxito gracias a tu entrenamiento. Estas pequeñas victorias te sostienen en los momentos difíciles.

A otros directivos no les interesan tus comentarios. De hecho, consideran que te entrometes y se vuelven competitivos cuando creen que invades su terreno. Tu propio jefe no está de acuerdo en que estés preparado para un equipo más grande, y no puede explicar por qué; sus habilidades como coach dejan mucho que desear. ¿Quizá le preocupa que le eclipse? Sin embargo, no quiere que te pases todo el tiempo dando charlas: le molesta que estés demasiado tiempo fuera de la oficina, sea cual sea el valor que el equipo pueda obtener de ello. La política de saber cómo liderar sin socavar a tus compañeros o a tu jefe es más complicada de lo que esperabas. Pero si consigues ese equipo más grande, sabes que conseguirás ese ascenso, así que al menos tienes el camino despejado. Cuando descubres que el ingeniero de plantilla que trabaja para ti gana más que tú, casi lo pierdes, así que será mejor que descubras cómo conseguir ese equipo más grande rápidamente. Si no, ¿qué sentido tiene todo este estrés y estas tonterías?

Mi último consejo es que recuerdes que puedes cambiar de pista si quieres. Es habitual que la gente pruebe la gestión en algún momento, se dé cuenta de que no la disfruta y vuelva a la vía técnica. Esta elección no tiene por qué ser permanente, pero hay que ir con los ojos bien abiertos. Cada función tiene sus ventajas y sus inconvenientes, y depende de ti sentir qué es lo que más te gusta.

El zar de los procesos cree que hay un proceso verdadero que, si se implementa correctamente y se sigue como está diseñado, resolverá todos los problemas más importantes del equipo. Los zares de los procesos pueden estar obsesionados con los métodos ágiles, Kanban, scrum, lean o incluso en cascada. Pueden tener una idea muy precisa de cómo debe funcionar la guardia, cómo deben hacerse las revisiones de código o cómo tiene que funcionar el proceso de liberación. Suelen ser muy organizados y se sienten cómodos con los detalles, y son buenos conociendo las reglas y siguiéndolas con precisión.

Los zares de procesos suelen encontrarse en grupos de control de calidad, servicio de asistencia técnica o gestión de productos. También son comunes en las agencias de consultoría y otros lugares en los que se premia mucho la medición del progreso de un trabajo específico. Pueden estar centrados en las operaciones, aunque, según mi experiencia, hay relativamente pocas personas de este tipo dentro de los equipos clásicos de operaciones de sistemas. Pueden ser miembros increíblemente valiosos de un equipo de gestión de proyectos porque tienden a asegurarse de que no se olvida ninguna tarea y de que todo está envuelto en la forma en que debe estar.

Los zares de los procesos tienen problemas cuando no se dan cuenta de que la mayoría de las personas no son tan buenas como ellos para seguir los procesos. Tienden a culpar de todos los problemas a la incapacidad de seguir el mejor proceso, en lugar de reconocer la necesidad de flexibilidad y la inevitabilidad de los cambios inesperados. A menudo se centran en cosas fáciles de medir, como las horas en la oficina, y pasan por alto los matices que no captan al centrarse en las cosas fáciles de medir.

Los ingenieros que creen en la “herramienta adecuada para el trabajo” a veces se convierten en zares de los procesos cuando se convierten en líderes tecnológicos, buscando la herramienta adecuada para resolver todos los problemas de planificación, enfoque, gestión del tiempo y priorización. Intentan detener todo el trabajo mientras buscan el proceso perfecto, o impulsan constantemente nuevas herramientas y procesos en el equipo como soluciones a los problemas más complicados de las interacciones humanas.

Lo contrario del zar de los procesos no es un gestor que renuncie por completo a los procesos, sino alguien que entienda que los procesos deben satisfacer las necesidades del equipo y del trabajo. Irónicamente, aunque el término “ágil” se aplica a menudo de forma rígida, los principios del Manifiesto Ágil son un gran resumen de un liderazgo de procesos saludable:

• Las personas y las interacciones por encima de los procesos y las herramientas.
• El software de trabajo por encima de la documentación exhaustiva.
• La colaboración con el cliente por encima de la negociación de contratos.
• Responder al cambio en lugar de seguir un plan.

Como nuevo líder tecnológico, ten cuidado con confiar en el proceso para resolver los problemas que son el resultado de la comunicación o de los vacíos de liderazgo en tu equipo. A veces, un cambio en el proceso es útil, pero rara vez es una bala de plata, y no hay dos grandes equipos que se parezcan exactamente en el proceso, las herramientas o el estilo de trabajo. Mi otro consejo es que busques procesos autorregulados. Si te encuentras desempeñando el papel de capataz -criticando a las personas que se saltan las normas o no siguen el proceso- comprueba si el propio proceso puede cambiarse para que sea más fácil de seguir. Es una pérdida de tiempo hacer de policía de las reglas, y la automatización puede hacer que las reglas sean más obvias.

Como gestor de un zar de los procesos, ayude a esa persona a sentirse más cómoda con la ambigüedad. Como ocurre con muchos de los errores de los directivos, la obsesión por los procesos puede estar relacionada con el miedo al fracaso y el deseo de controlar las cosas para evitar lo inesperado. Si se es honesto y se deja claro que es seguro fracasar y ser imperfecto, eso suele ser suficiente para que el zar de los procesos se relaje un poco y deje entrar algo de ambigüedad. Es muy importante evitar que los zares de procesos dediquen todo su tiempo a buscar la herramienta o el proceso perfecto, y especialmente importante es asegurarse de que no están castigando a sus equipos por no seguir los procesos.

Los grandes líderes tecnológicos tienen una serie de características, pero éstas son las más importantes.

Si entras en un rol de líder tecnológico y sientes que no entiendes completamente la arquitectura que estás apoyando, tómate el tiempo para entenderla. Apréndala. Compréndela. Visualízala. Comprenda sus conexiones, dónde viven los datos, cómo fluyen entre los sistemas. Entienda cómo refleja los productos que soporta, dónde vive la lógica central de esos productos. Es casi imposible dirigir bien los proyectos cuando no se entiende la arquitectura que se está cambiando.

Si estás haciendo tú mismo todo el trabajo interesante, deja de hacerlo. Fíjate en las áreas difíciles, aburridas o molestas de la necesidad técnica y ve si puedes desatascar esas áreas. Trabajar en las partes menos emocionantes de la base de código puede enseñarte mucho acerca de dónde se rompe el proceso. En los proyectos aburridos o frustrantes, a menudo hay algo obvio que se puede detectar y arreglar si una persona con experiencia se toma el tiempo de mirarlos. Si sólo haces el trabajo más aburrido, deja de hacerlo también. Eres un ingeniero senior que tiene mucho talento como desarrollador, y es razonable que asumas algunas de las tareas más difíciles. Quieres animar a los demás miembros de tu equipo a que aprendan todo el sistema, y quieres darles oportunidades para que se esfuercen, pero no es necesario que siempre te sacrifiques en lo que elijas para trabajar. Date una tarea divertida de vez en cuando, siempre que sepas que tienes tiempo para hacerla bien.

Participarás en la mayoría de las decisiones técnicas importantes de tu equipo. Sin embargo, participar no es lo mismo que ser la persona que las toma todas sola. Si empiezas a tomar todas las decisiones técnicas sin solicitar la opinión de tu equipo, se resentirán y te culparán cuando las cosas vayan mal. Por otro lado, si no tomas ninguna decisión técnica y lo dejas todo en manos del equipo, decisiones que podrían haberse tomado rápidamente pueden alargarse sin solución.

Determina qué decisiones debes tomar tú, qué decisiones deben delegarse en otras personas con más experiencia y qué decisiones deben ser resueltas por todo el equipo. En todos estos casos, deja claro cuál es el asunto que se discute y comunica el resultado.

Tu productividad es ahora menos importante que la de todo el equipo. A menudo, esto significa que usted paga el precio de la sobrecarga de comunicación. En lugar de hacer que todos los miembros del equipo se sienten en una reunión, usted representa al equipo, comunica sus necesidades y devuelve la información de esa reunión al equipo. Si hay un talento universal que separa a los líderes de éxito del resto, es la capacidad de comunicación. Los líderes de éxito escriben bien, leen con atención y pueden ponerse delante de un grupo y hablar. Prestan atención en las reuniones y ponen constantemente a prueba los límites de sus conocimientos y los del equipo. Ahora es un buen momento para practicar sus habilidades de escritura y oratoria. Escriba documentos de diseño y reciba comentarios sobre ellos de los mejores escritores. Escribe entradas para tu blog tecnológico o tu blog personal. Habla en las reuniones del equipo, habla en las reuniones y practica cómo ponerte de pie frente a una audiencia.

No te olvides de escuchar durante toda esta comunicación. Da a los demás la oportunidad de hablar y escucha lo que dicen. Practica repitiendo las cosas para asegurarte de que las entiendes. Aprende a escuchar lo que alguien dice y a reformularlo con tus propias palabras. Si no eres un buen tomador de notas, puede que tengas que convertirte en uno. No importa si eliges sumergirte en la tecnología o convertirte en gerente: si no puedes comunicarte y escuchar lo que dicen los demás, tu crecimiento profesional a partir de este momento se verá afectado.

• ¿Tiene su organización líderes tecnológicos? ¿Existe una descripción escrita del puesto para esta función? Si es así, ¿qué dice? Si no es así, ¿cómo definiría la función en su organización? ¿Cómo definiría la función un líder tecnológico?

• Si estás pensando en convertirte en líder tecnológico, ¿estás preparado para esforzarte? ¿Te sientes cómodo pasando parte de tu tiempo fuera del código? ¿Te sientes lo suficientemente experto en tu base de código como para liderar con éxito a otros mientras trabajan en ella?

• ¿Has preguntado a tu jefe lo que espera del director técnico?

• ¿Quién es el mejor jefe técnico con el que has trabajado? ¿Qué cosas hizo esa persona que la hicieron grande?

• ¿Has trabajado con un jefe técnico frustrante? ¿Qué es lo que hizo que te frustró?

• Elogios para El Camino del Gerente
• Agradecimientos
• Introducción
• Capítulo 1: Gestión 101
• Capítulo 2: Mentoring
• Capítulo 3: Líder Técnico
• Capítulo 4: Gestión de Personas
• 07_gestionar_un_equipo
• 08_gestionar_varios_equipos
• 09_gestionar_gerentes
• 10_las_grandes_ligas
• 11_la_cultura_bootstrapping
• Capítulo 10: Conclusión

Volver al índice