Gestión de Equipos Técnicos Múltiples

Este elemento es una expansión del contenido de los cursos y guías de Lawi. Ofrece hechos, comentarios y análisis sobre la gestión de equipos técnicos. [aioseo_breadcrumbs]

Gestión de Equipos Técnicos Múltiples

Vamos a hablar de la gestión de equipos múltiples antes de hablar de la gestión de jefes (en otro lugar), porque aunque esas cosas están relacionadas, no coinciden necesariamente. Sin embargo, es probable que ahora tenga jefes técnicos que le rinden cuentas, y compaginar el trabajo de gestionar directamente a más de tres o cuatro personas con el proceso de comprender los detalles de lo que ocurre en un par de equipos probablemente signifique una cosa importante: no está redactando (mucho, nada, producción) de código.

Cuando creé la escala profesional para mi anterior trabajo, el puesto de director de ingeniería solía ser el lugar en el que una persona empezaba a gestionar varios equipos grandes. Repasemos algunas de las descripciones de la práctica de la ingeniería:

El director de ingeniería es responsable de un área importante del equipo tecnológico. El director de ingeniería suele dirigir a ingenieros de varias áreas de producto o de varias funciones tecnológicas. Tanto los jefes de tecnología como los colaboradores individuales dependen de ellos.

Por lo general, no se espera que el director de ingeniería redacte código en el día a día. Sin embargo, el director de ingeniería es responsable de la competencia técnica general de su organización, guiando y haciendo crecer esa competencia en todo el equipo según sea necesario a través de la formación y la contratación. Deben tener una sólida formación técnica y dedicar parte de su tiempo a investigar nuevas tecnologías y a mantenerse al día de las tendencias del sector tecnológico. Se espera que ayuden a depurar y triar sistemas críticos, y deben comprender los sistemas que supervisan lo suficientemente bien como para realizar revisiones de código y ayudar a investigar problemas según sea necesario. Deben contribuir a los esfuerzos de arquitectura y diseño principalmente sirviendo como la voz técnicamente experta que hace preguntas de negocio y de producto a los ingenieros de sus equipos, asegurándose de que el código que estamos redactando se ajusta a las necesidades del producto y del negocio y puede escalar adecuadamente a medida que crecen esas necesidades.

El director de ingeniería se ocupa principalmente de garantizar una ejecución sin problemas de los entregables complejos. Para ello, se centran en garantizar que evaluamos y perfeccionamos continuamente nuestras normas y procesos de desarrollo/infraestructura para crear una tecnología que aporte un valor sostenido al negocio. Son responsables de crear organizaciones de alto rendimiento y alta velocidad, midiendo e iterando sobre los procesos a medida que crecemos y evolucionamos como empresa. Son los líderes de la selección, la gestión y la planificación de la plantilla, el crecimiento profesional y la formación de la organización. En caso necesario, los directores gestionarán las relaciones con los proveedores y participarán en el proceso de elaboración de presupuestos.

El impacto de un director de ingeniería debe llegar a múltiples áreas de la organización tecnológica. Son responsables de crear y hacer crecer la próxima generación de talento de liderazgo y gestión en la organización, y de ayudar a ese talento a aprender a equilibrar el liderazgo y la gestión técnica y de personas. Están obsesionados con crear organizaciones de alto funcionamiento, implicadas y motivadas, y se espera de ellos que sean los dueños de los objetivos de retención dentro de su organización. Además, los directores de ingeniería son responsables de equilibrar estratégicamente el trabajo inmediato y a largo plazo centrado en el producto/negocio con la deuda técnica y el desarrollo técnico estratégico.

Los directores son líderes fuertes que dan ejemplo de colaboración interfuncional tanto entre tecnología y otras áreas de la empresa, como entre divisiones de tecnología. El objetivo de esta colaboración es crear una hoja de ruta tecnológica tanto estratégica como táctica que aborde las necesidades empresariales, la eficiencia y los ingresos, así como la innovación tecnológica fundamental. El director es un comunicador muy fuerte que puede tanto simplificar conceptos técnicos para explicarlos a socios no técnicos como explicar la dirección empresarial al equipo tecnológico de forma que les inspire y les guíe. Los directores de ingeniería ayudan a crear una presencia pública positiva para la tecnología de Rent the Runway y son capaces de vender la empresa y su área a posibles candidatos.

Debido a su amplia exposición tanto a la tecnología como a los impulsores del negocio, los directores son responsables de guiar el proceso de fijación de objetivos para todos los equipos de su organización, ayudando a estos equipos a articular objetivos que apoyen tanto las iniciativas empresariales como la tecnología y la calidad organizativa.

Me esforcé por asegurarme de que se señalara el hecho de que los directores de ingeniería no necesariamente estarían escribiendo código todos los días, porque creo que es muy difícil que una persona responsable de la gestión práctica de varios equipos escriba código. Su horario, a estas alturas, probablemente se haya alejado del de “creador” y se haya convertido firmemente en el de “gestor”. Entre sus reuniones individuales, las reuniones con otros jefes de ingeniería, las sesiones de planificación de equipos y las sesiones con sus compañeros en la gestión de productos u otras funciones empresariales, probablemente esté bastante ocupado. Sea realista sobre su agenda en este punto. Si no dispone de bloques sólidos de tiempo para dedicarle y no puede garantizar de forma realista bloques sólidos de tiempo al menos unos días a la semana, cualquier código que redacte va a ir muy lento.
Afortunadamente para nosotros, hay formas de mantenerse en activo que no requieren redactar mucho código de producción. Las revisiones de código son una buena forma de mantener la práctica, al menos como revisor secundario.

Si creó sistemas cuando era más práctico, manténgase implicado con esos sistemas, porque recordará los detalles mejor que la mayoría y podrá ayudar a los ingenieros que trabajan en esos sistemas con revisiones de código y preguntas. La depuración y el apoyo a la producción también son valiosos. La forma en que se mantenga involucrado dependerá de su conjunto de habilidades. Si usted no era un depurador fuerte antes de entrar en la gestión, saltar a los incidentes puede ser más molesto que útil. Puede que sea más útil haciendo programación en parejas, o arreglando pequeños fallos o características. Tan a menudo disminuimos estos pequeños esfuerzos como si no valieran la pena, pero son muy buenos para mantenerle en sintonía con el sentimiento del desarrollo de software y mostrar a sus equipos que usted está dispuesto y es capaz de ayudar en el día a día de una manera valiosa.

El riesgo de ir de manos libres se amplifica enormemente si no pasa suficiente tiempo codificando antes de pasar a este papel para sentirse profundamente y con fluidez cómodo con al menos un lenguaje de programación. Abogo firmemente por que dedique el tiempo necesario a conseguir el dominio de la programación antes de pasar a la gestión. En mi caso, esto me llevó unos 10 años, incluyendo mis estudios universitarios y de posgrado. Puede que usted lo haga más rápido que yo, pero examínese cuidadosamente a este respecto. ¿Se siente lo suficientemente fluido en al menos un lenguaje de programación como para contribuir de forma productiva a una buena base de código escrito en él, tras un tiempo limitado dedicado a ponerse al día en los aspectos básicos de su redacción, utilizando un entorno de desarrollo estándar y trabajando en marcos y bibliotecas estándar? Con el tiempo, incluso los conocimientos más profundos se atrofiarán, pero la fluidez en el trabajo en un lenguaje (que incluye la comodidad con sus herramientas, bibliotecas y tiempos de ejecución estándar) es algo que se le pega a uno durante mucho tiempo.

La fluidez útil también requiere una comprensión arraigada de lo que significa trabajar de forma productiva en ese lenguaje, con suerte en un equipo con otras personas que construyen software de producción. Sin este sentido de los ritmos de construcción de software, tendrá dificultades con una de las partes críticas del trabajo a este nivel: depurar los problemas del equipo y mantener a sus equipos produciendo software de calidad sin problemas.
Por último, aunque no tenga intención de escribir mucho código, le aconsejo encarecidamente que mantenga al menos medio día sólido una vez a la semana completamente libre de reuniones u otras obligaciones, e intente emplear este tiempo al menos parcialmente en alguna actividad creativa. Podría redactar entradas para su blog de ingeniería, preparar charlas para conferencias o participar en un proyecto de código abierto. Haga algo para rascarse esa comezón creativa, que de otro modo puede resultarle difícil de rascar como directivo.

Gestionar su tiempo: ¿qué es lo importante?

Ya es hora de que descubra cómo gestionar su tiempo. De lo contrario, se encontrará con días pasados y poco que mostrar por ellos. Aún tiene responsabilidades como directivo. Todavía tiene tareas que cumplir que requieren que haga algo más que sentarse en una reunión: cosas como establecer objetivos para el equipo, ayudar a su equipo de producto a poner detalles en las hojas de ruta del producto y asegurarse de que una tarea asignada realmente se terminó. Esto último, el seguimiento de la finalización de la tarea, puede convertirse en uno de los mayores sumideros de tiempo y distracciones de su día si no tiene cuidado.

La gestión del tiempo es algo personal. Algunas personas son muy organizadas, y esas personas desarrollan estrategias complejas para gestionar sus calendarios y listas de tareas pendientes. La información sobre la gestión del tiempo de trabajo de equipos técnicos se encuentra en otro lugar.

Decisiones y delegación

¿Cómo se siente al final del día estos días? Si es usted como muchos nuevos directivos a tiempo completo, probablemente se sienta bastante agotado. Aunque no haya escrito mucho código -¡o ningún código!- en todo el día, cuando llega a casa se encuentra sin energía para decidir qué cenar, sin energía para pasatiempos y con ganas de comer comida reconfortante, beber una cerveza quizás y mirar fijamente el ordenador o la televisión hasta que sea hora de irse a la cama.

Los primeros meses de gestión de varios equipos pueden parecer una marcha de la muerte, incluso cuando sus horas de trabajo no son excesivas. Su atención, antes concentrada, se trocea entre las diversas reuniones que salpican su jornada. Yo me quedé sin voz en repetidas ocasiones durante mis primeros meses dirigiendo múltiples equipos; estaba totalmente desacostumbrada a hablar tanto todos los días. Una amiga mía se convirtió hace poco en directora de ingeniería y tuvo que empezar a pedirle a un asistente que le encargara el almuerzo porque descubrió que se olvidaba de comer y no tenía energía para decidir qué comer cuando se daba cuenta de que necesitaba comida.
Así que, primero, las malas noticias: la única forma de salir de esta situación es pasar por ella. De hecho, yo esperaría que la mayoría de la gente pasara por esto durante un tiempo. Si no lo ha experimentado en absoluto, o bien considérese extremadamente afortunado, o bien asegúrese de que realmente está prestando atención a todo lo que requiere su atención. En mi experiencia tanto pasando por esta transición como dirigiendo a personas en ella, si no se siente un poco abrumado, es probable que se esté perdiendo algo.

La mejor forma de describir la sensación de gestión de aquí en adelante es la de dar vueltas a los platos. Si no está familiarizado con él, el giro del plato es una forma elegante de malabarismo en la que el malabarista tiene varios palos, cada uno con un plato girando encima. El malabarista debe atender a cada plato antes de que se frene lo suficiente como para caerse del palo. Sus platos son las personas y los proyectos que está supervisando, y su trabajo consiste en averiguar cuánta atención necesita cada uno y en qué momento. Es importante que aborde este hilado con la mente de un estudiante. Aún está aprendiendo a girar platos, y se le caerán algunos al suelo porque los ha descuidado durante demasiado tiempo. Afinar sus instintos sobre cuándo tocar cada plato es el nombre del juego.

Ahora las buenas noticias: mejorará en esto con el tiempo. Sus instintos mejorarán. Empezará a reconocer las primeras señales de advertencia de los proyectos que van mal, de la gente que está a punto de abandonar y de los equipos que rinden por debajo de sus posibilidades. En la última sección le recomendé que se lo pensara bien antes de abandonar las reuniones, y parte de la razón es que en esas reuniones es donde aprende cómo son las dinámicas sanas y las que no lo son. Esta es también la razón por la que le aconsejo encarecidamente que mantenga su práctica de reuniones periódicas y fiables de uno a uno con todas las personas que dependen directamente de usted. Si tiene demasiada gente, puede que tenga que acortar esas reuniones o celebrarlas quincenalmente en lugar de semanalmente, pero saltarse las 1-1 porque está demasiado ocupado con otras cosas es una forma estupenda de pasar por alto las señales de advertencia de un empleado que va a abandonar.

¿Dónde encaja la delegación? La delegación es la forma principal de librarse de la sensación de tener demasiados platos girando a la vez. A medida que se le presenten las tareas, pregúntese: ¿necesito ser yo la persona que complete este trabajo? La respuesta puede depender de algunos factores: El grado de complejidad y la frecuencia de la tarea pueden servir de guía para determinar si debe delegar y cómo.

Delegue tareas sencillas y frecuentes

Si la tarea es sencilla y frecuente, busque a alguien a quien pueda pasársela. Ejemplos de tareas sencillas y frecuentes pueden ser la realización de reuniones diarias, la redacción de un resumen de los progresos del equipo cada semana o la realización de pequeñas revisiones del código. Sus jefes técnicos u otros ingenieros superiores pueden responsabilizarse de estas tareas y probablemente ni siquiera necesiten formación para hacerlo.

Encárguese usted mismo de las tareas sencillas y poco frecuentes

Si es más rápido hacer algo usted mismo que explicárselo a otra persona y rara vez hay que hacerlo, arremánguese y hágalo, aunque considere que la tarea es indigna de usted. Puede tratarse de cualquier cosa, desde reservar una entrada ocasional para una conferencia de su equipo hasta ejecutar el script que genera los informes trimestrales.

Utilice las tareas complejas e infrecuentes como oportunidades de formación para los líderes en ascenso

Tareas como la redacción de evaluaciones de rendimiento y la elaboración de planes de contratación son sólo suyas. Sin embargo, éstas son también las habilidades que querrá transmitir a los directivos en ascenso. Puede hacer que un jefe técnico se siente con usted para redactar la evaluación del rendimiento de un becario, o que un ingeniero senior le dé su opinión sobre cuántas personas nuevas cree que se necesitarían para apoyar un proyecto el año que viene. Pida ayuda a los de arriba para estas tareas hasta que se sienta cómodo haciéndolas, pero una vez que se sienta cómodo, empiece a recurrir a los líderes ascendentes para que aprendan cómo se hacen.

Delegue tareas complejas y frecuentes para desarrollar su equipo

Tareas como la planificación de proyectos, el diseño de sistemas o ser la persona clave durante una interrupción del servicio son la mayor oportunidad que tiene para hacer crecer el talento en su equipo y, al mismo tiempo, hacer que el equipo funcione mejor. Los directivos fuertes dedican gran parte de su tiempo a desarrollar a los miembros de sus equipos en estas áreas. Su objetivo es hacer que sus equipos sean capaces de funcionar a un alto nivel sin mucha aportación por su parte, y eso significa que necesitarán personas que puedan hacerse cargo de estas tareas complejas y ejecutarlas sin que usted esté presente.

¿Están aprendiendo sus equipos a funcionar de forma independiente, o los mantiene dependientes de usted para las funciones críticas? Enumere las tareas que usted y sólo usted sabe hacer realmente para el equipo. Algunas de ellas pueden ser apropiadas, como la redacción de evaluaciones de rendimiento o la elaboración de planes de contratación, pero muchas de ellas son importantes para enseñar a sus equipos a realizarlas por sí mismos. Gestión de proyectos. Incorporación de nuevos miembros al equipo. Trabajar con el equipo de producto para desglosar los objetivos de la hoja de ruta del producto en entregables técnicos. Apoyo a la producción. Todas estas son habilidades que los miembros de su equipo necesitan aprender. Enseñarles puede llevar tiempo al principio, pero a la larga le ahorrará tiempo. No sólo eso, sino que enseñar a su equipo a hacer estas cosas forma parte de su trabajo. Es su responsabilidad, como directivo, desarrollar el talento en su organización, y ayudar a su gente a aprender nuevas habilidades que necesitarán para las siguientes etapas de sus carreras.

La delegación es un proceso que empieza despacio pero se convierte en el elemento esencial para el crecimiento profesional. Si sus equipos no pueden funcionar bien sin usted cerca, le resultará difícil ascender. Desarrolle su talento y delegue las decisiones en ese talento para que pueda encontrar nuevos e interesantes platos que aprender a hacer girar.

Situaciones Desafiantes: Estrategias para decir No

El trabajo de un directivo consiste en facilitar que sus empleados hagan las cosas creando entornos fértiles en los que se pueda trabajar. Centra a su equipo para que puedan hacer lo que mejor saben hacer. Cultiva la camaradería y la amistad en el equipo, y ayuda a la gente a aprender nuevas habilidades. En todas estas cosas, es una facilitadora, una entrenadora y una campeona.

Pero para crear este ambiente, a veces debe decir no. Debe decir no al equipo. Debe decir no a sus compañeros. Incluso debe decir no a su jefe. Cada uno de estos “noes” es duro, a su manera, y un directivo fuerte debe desarrollar estrategias eficaces para decir que no. He aquí algunas de las que he identificado.

“Sí, y”

Decir que no a su jefe rara vez se parece a un simple “no” cuando se es directivo. En su lugar, se parece a la técnica del “sí, y” de la comedia de improvisación. “Sí, podemos hacer ese proyecto, y lo único que tendremos que hacer es retrasar el inicio de este otro proyecto que está actualmente en la hoja de ruta”. Responder con positividad sin dejar de articular los límites de la realidad le llevará a las ligas mayores de la alta dirección. Este tipo de no positivo es una habilidad bastante difícil de dominar para la mayoría de los ingenieros. Estamos acostumbrados a articular los inconvenientes de los proyectos, y salir del hábito visceral del “no, eso no puede suceder” es difícil. Empiece a dominar la estrategia del “sí, y” para decir que no, sobre todo cuando interactúe con su jefe y sus compañeros, y verá cómo a menudo transforma los desacuerdos polémicos en negociaciones realistas sobre la prioridad.

Cree políticas

Cuando se trata de su equipo, usted quiere ayudarles a entender lo que se necesita para llegar al “sí”. Tal vez esté tratando con un ingeniero que quiere cambiar a un nuevo lenguaje de programación para un proyecto, uno que su equipo no utiliza. Él tiene grandes argumentos sobre por qué este lenguaje es la herramienta perfecta para el trabajo, pero usted es reacio a añadir una nueva herramienta sólo porque es perfecta. Puede verse tentado a decir simplemente que no, dar el razonamiento y dejarlo, y a veces eso funcionará. Pero puede que se encuentre diciendo el mismo “no” una y otra vez, dando las mismas razones. “No, necesitamos contar con más personas que conozcan esa lengua; necesitamos entender lo que significa poner esa lengua en producción”. “No, necesitamos tener normas para el registro; tenemos que pensar en cómo serían las pruebas”. Cuando empiece a repetirse, tendrá la base para una política razonable. Esa política consiste en los requisitos duros que deben cumplirse para decir que sí, y algunas directrices para pensar en la decisión. Elaborar una política ayuda a su equipo a conocer de antemano el coste de llegar al “sí”.

“Ayúdeme a decir sí”

Las políticas son útiles, pero no cubren todos los casos. La siguiente estrategia, “ayúdeme a decir que sí”, es similar a la redacción de políticas, pero funciona mejor para los casos puntuales en los que no existe una política clara. A veces escuchará ideas que parecen muy poco meditadas. “Ayúdeme a decir que sí” significa que usted hace preguntas y profundiza en los elementos que le parecen tan cuestionables. A menudo, esta línea de interrogatorio ayuda a las personas a darse cuenta por sí mismas de que su plan no es una buena idea, pero a veces le sorprenderán con su línea de pensamiento. En cualquier caso, el interrogatorio curioso de las ideas puede ayudarle a decir que no y a enseñar al mismo tiempo.

Apele al presupuesto

Cuando se trata tanto de su equipo como de sus compañeros, una táctica que puede utilizar es apelar al tiempo y al presupuesto. Exponga la carga de trabajo actual en términos claros y muestre cómo hay poco margen de maniobra. A veces esto se acompaña de un “ahora no”, otra forma un tanto pasivo-agresiva de decir que no. “Ahora mismo no” implica que usted podría estar de acuerdo con la idea pero no puede hacerlo en este momento, así que tal vez se ponga a ello en el futuro. Esto es cierto con frecuencia, por lo que es fácil volver a caer en el “ahora no”. Pero como he comentado antes, cuando hace una promesa implícita de que “ahora no” significa que hará algo en serio “más adelante”, tiene que estar seguro de que ese más adelante puede ocurrir realmente.

Trabaje en equipo

Hablando de sus compañeros, habrá ocasiones en las que usted y sus compañeros (especialmente entre funciones, es decir, sus compañeros de producto o de negocio) tendrán que actuar juntos para decir que no. Esto puede aplicarse a un no a cualquier nivel. A veces utilizará su autoridad técnica para decir que no de forma que beneficie al equipo de producto. A veces apelará al departamento financiero para que le ayude a decir no a ciertos excesos presupuestarios. Jugar al poli bueno/poli malo puede ser un poco deshonesto, así que utilícelo con moderación, pero puede ser útil para prestar su autoridad a un no y luego poder pedir el favor cuando necesite apoyo para su propio no en el futuro.

No prevarique

Cuando sepa que tiene que decir no, es mejor decirlo rápidamente que retrasar y alargar el proceso. Si tiene autoridad para decir que no y cree que algo no debe suceder, hágase un favor y no agonice en el proceso. A veces se equivocará, así que cuando descubra que se precipitó al decir que no, discúlpese por haber cometido ese error. No podrá permitirse el lujo de investigar y analizar detenidamente cada decisión, así que practique hasta sentirse cómodo con el no rápido (¡y el sí rápido!) para las decisiones de bajo riesgo y bajo impacto.

Elementos técnicos más allá del código

La gestión a este nivel resulta confusa. Contratamos a gestores basándonos parcialmente en sus habilidades técnicas, pero muchos de nosotros pensamos que este trabajo no es realmente “técnico”. Después de todo, el gestor probablemente no esté redactando mucho código ni haciendo mucho diseño de sistemas, ¿verdad?
Suponer que el trabajo a este nivel pasa a ser esencialmente no técnico es un error. Resulta que dirigir equipos de ingeniería eficaces es mucho más que puras habilidades de gestión, y la gestión a este nivel requerirá que aprenda algunas habilidades nuevas que son más fáciles de aprender si comprende la práctica y la disciplina de la ingeniería de software. Ahora va a centrar su atención técnica en observar y mejorar los sistemas de trabajo en los que operan sus desarrolladores. En particular, ahora necesita desarrollar un ojo para las señales de salud técnica del equipo en general. Pero, ¿cuáles son esas señales de salud?

El popular libro de gestión “Primero, rompa todas las reglas”, de Marcus y Curt, analiza varias preguntas que puede responder para ayudar a predecir la productividad y la satisfacción del equipo. Entre ellas se encuentran:

• ¿Sé lo que se espera de mí en el trabajo?
• ¿Tengo los materiales y el equipo que necesito para hacer bien mi trabajo?
• ¿Tengo la oportunidad de hacer lo que mejor sé hacer cada día?

Para la mayoría de los ingenieros, la respuesta a estas preguntas puede discernirse por la velocidad y la frecuencia con la que impulsan el código. Si el trabajo que tienen que hacer está claro, saben qué código tienen que redactar. Si las herramientas, los tickets, la automatización y el proceso están disponibles y son fáciles de usar, son capaces de conseguir la redacción del código. Y si no están distraídos por un exceso de reuniones o ahogados en el soporte y la gestión de incidencias, tendrán la oportunidad de escribir código todos los días. Estas señales de salud -frecuencia de las publicaciones de código, frecuencia de las revisiones del código y poca frecuencia de los incidentes- son los indicadores clave de un equipo que sabe lo que tiene que hacer, dispone de las herramientas para hacerlo y tiene tiempo para hacerlo todos los días.

Medir la salud de su equipo de desarrollo

Cuando se centre en la salud de sus equipos de desarrollo, póngase el sombrero técnico para diseñar sistemas y procesos que mantengan las cosas en movimiento. Cree las herramientas que los desarrolladores necesitan para hacer su trabajo. Ayúdeles a centrarse para que puedan averiguar fácilmente lo que tiene que ocurrir a continuación. Interrogue a cada proceso para determinar el valor que debe aportar y pregúntese siempre si puede automatizarse más. Considere estas formas de medir la salud de su equipo.

Frecuencia de lanzamientos

Una disfunción común de los equipos técnicos es no enviar código, y la frecuencia de publicación es la medida más directa de ello. Si su empresa no aprecia el valor de liberar código con frecuencia, lo siento. En esta era moderna, la frecuencia de cambio de código es uno de los principales indicadores de un equipo de ingeniería saludable. Los grandes directores de ingeniería de equipos centrados en el producto saben cómo crear entornos en los que sus equipos puedan moverse con rapidez, y parte de moverse con rapidez requiere dividir el trabajo en pequeños trozos. Aunque su empresa no lo aprecie, debe trabajar para ayudar a su equipo a lograr la mejor frecuencia de publicación posible para su producto. Para que no piense que esto no se aplica a usted porque está construyendo un producto (digamos, una base de datos) que no puede liberar con frecuencia, estoy seguro de que hay un artefacto completo empujado a un entorno de pruebas beta/desarrollador que proporciona una medida igualmente valiosa en términos de frecuencia y estabilidad.

¿Por qué no libera con más frecuencia? Eche un vistazo a su equipo. Si no liberan continuamente, o diariamente, ¿cómo es el proceso de liberación? ¿Cuánto tiempo lleva? ¿Con qué frecuencia ha salido algo mal en los últimos meses en relación con los lanzamientos? ¿Qué aspecto tiene cuando las cosas van mal? ¿Con qué frecuencia ha tenido que retrasar o anular un lanzamiento debido a problemas? ¿Cuáles fueron las repercusiones de ese retraso o retroceso? ¿Cómo determina si el código está listo para pasar a producción? ¿Cuánto tiempo lleva? ¿Quién es el principal responsable de determinarlo?

Apuesto a que si echa un vistazo honestamente a un equipo que no libera con frecuencia, verá grietas. El proceso de realizar una liberación lleva mucho tiempo. Los ingenieros no se sienten dueños de la calidad de su código y dejan todo ese trabajo en manos de un equipo de control de calidad, lo que genera muchos retrasos en la comunicación de ida y vuelta. Revertir el código en caso de una mala versión lleva mucho tiempo. Las cosas van mal en el proceso de liberación que conducen a incidentes en la producción (o construcciones de desarrollo rotas). Toda una serie de males en un equipo se derivan de no poder liberar con frecuencia.

Ahora, usted podría decir: “Gracias por el consejo, pero no tengo tiempo para trabajar en esto con la hoja de ruta del producto que tenemos que entregar”. O, “Nuestros sistemas no están diseñados para ser lanzados con frecuencia”. O, “Simplemente no es tan importante que cambiemos las cosas con tanta frecuencia”.

He aquí la cuestión. ¿Está trabajando su equipo a pleno rendimiento? ¿Están sus ingenieros desafiados y creciendo? ¿Está su equipo de producto entusiasmado con los progresos que está haciendo? ¿Son capaces de dedicar la mayor parte de su tiempo a la redacción de nuevo código y a la evolución de los sistemas? Si es así, estupendo. Ignóreme. Lo tiene todo bajo control. Si no es así, tiene un problema, y está ignorando ese problema por su cuenta y riesgo.

Es importante recordar que, como líder técnico, aunque no redacte mucho código, sigue siendo responsable de la parte técnica de la realización del trabajo. También es responsable de mantener a su equipo contento y productivo, y a menudo la solución a esto no es animarles o pagarles mejor o elogiarles más, sino permitirles ser más productivos, desafiarles a ir más rápido y hacer un trabajo mejor, y ayudarles a encontrar el tiempo que necesitan para hacer su trabajo más interesante. Tiene que ser el defensor y presionar para que se introduzcan mejoras en los procesos técnicos que puedan conducir a un aumento de la productividad de los ingenieros, aunque no las aplique todas usted mismo.

Lo bueno de presionar para que se realicen lanzamientos más frecuentes es que a menudo se descubre una serie de retos interesantes. No hay una única forma verdadera de aumentar la frecuencia de las versiones porque los problemas de frecuencia serán algo único de un equipo a otro. Es casi seguro que tendrá que resolver algunos elementos de automatización. La creación de herramientas de desarrollo para permitir cambios de características que tengan sentido para sus bases de código es otro reto frecuente. Pensar en la arquitectura del código para avanzar sin romper la compatibilidad con versiones anteriores, las actualizaciones continuas de los sistemas y la aplicación de pequeños cambios en lugar de parches gigantescos: todas estas cosas pueden necesitar solución. Usted es responsable de liderar el esfuerzo aquí, incluso si no hace el trabajo. Pida tiempo fuera de la hoja de ruta del producto para apoyar el aumento de la productividad de ingeniería, y establezca objetivos para el equipo que les inspiren a avanzar más rápido.

Frecuencia de las revisiones del código

Es difícil tener un equipo ágil que no entienda el valor de dividir su trabajo en pequeños trozos. Es probable que tenga que enseñar esta habilidad a los recién contratados que salen de la universidad, pero incluso los desarrolladores senior a veces necesitan un empujón en este sentido. No voy a abogar por ninguna metodología de desarrollo de software en particular, pero me parece que los ingenieros que no redactan pruebas a menudo tienen más dificultades para dividir su trabajo, y aprender a hacer un desarrollo basado en pruebas (aunque no lo practiquen realmente a diario) puede ayudarles a mejorar en esta habilidad.

Me centro en este tema porque puede resultar muy incómodo para usted, como nuevo responsable, decirles a personas que pueden llevar escribiendo código tanto o más tiempo que usted que su estilo necesita actualizarse. La evitación de conflictos está muy arraigada en la mayoría de nosotros, y las cuestiones de lo que parece un estilo personal pueden resultar especialmente difíciles. Si su empresa espera un desarrollo de productos rápido, los ingenieros que quieran ausentarse durante semanas y redactar código en solitario sin pasarlo al control de versiones compartido ralentizarán a su equipo y causarán problemas. Usted no dirige un equipo de investigación. (¿Lo está? ¡Pues sáltese esta sección!) Está bien que tenga la expectativa de que el trabajo en curso se actualice regularmente.

Frecuencia de las incidencias

¿Hasta qué punto es estable el software que produce el equipo? ¿La calidad está mejorando, empeorando o se mantiene igual? Determinar el nivel de calidad del software que necesita para el producto que está construyendo y ajustar esa medida a lo largo del tiempo es un reto técnico que usted, el director, debe ayudar a abordar. Si está construyendo un producto nuevo para una empresa pequeña pero en crecimiento, puede que sea más importante centrarse en las características que en la estabilidad. Por otro lado, si posee sistemas de misión crítica, la estabilidad y la minimización de incidentes pueden ser su máxima prioridad. El objetivo aquí es equilibrar el riesgo de forma que ni la frecuencia de incidentes ni su prevención se conviertan en un trabajo que aleje a los desarrolladores de la redacción de código durante días.

Puede que trabaje para una empresa que hace que los desarrolladores den soporte al código o a los sistemas que redactan. Este proceso tiene algunos inconvenientes; significativamente, esperar que los miembros de un equipo estén frecuentemente de guardia noches y fines de semana contribuye enormemente al agotamiento. A pesar de ese riesgo, tiene la ventaja de poner a las mejores personas para ayudar a solucionar un problema en el papel de responder a él. Como gestor, puede que ahora sienta la tentación de apartarse usted mismo de este papel. Lo comprendo, pero si su equipo está configurado para hacer su propia gestión de incidentes, debería pasar usted mismo al papel de apoyo a la escalada. No necesariamente gestionará los incidentes con tanta frecuencia, pero se esperará de usted que esté disponible más a menudo en caso de que la persona que da soporte a los sistemas le necesite.

El análisis en torno a la gestión de incidencias debería incluir la pregunta: “¿Está permitiendo nuestra configuración actual que mi equipo haga lo que mejor sabe hacer cada día?” La gestión de incidentes, cuando se convierte en una mera reacción ante los incidentes en lugar de trabajar para reducirlos, puede convertirse en una tarea que merme la capacidad de su equipo para hacer lo que mejor sabe hacer. Los ingenieros van de guardia, se queman y agotan de manejar el diluvio de problemas y de no conseguir hacer nada más que arreglar las consecuencias de los incidentes, y luego pasan el trabajo al siguiente pobre incauto de la rotación. Si eso describe el enfoque de su equipo respecto a la gestión de incidentes y las guardias, su equipo no es capaz de hacer lo que mejor sabe hacer cada día, y cada vez que van de guardia probablemente odian su trabajo un poco más. En este caso, como líder probablemente quiera centrarse en dedicar tiempo a diseñar realmente sistemas que sean más estables, o a redactar código para solucionar las incidencias recurrentes a medida que surjan.

Un énfasis excesivo en la prevención de incidentes también puede reducir la capacidad de su equipo para hacer lo que mejor saben hacer cada día. Centrarse en exceso en la construcción de sistemas libres de defectos, o presionar para prevenir errores ralentizando el proceso de desarrollo, es a menudo casi tan malo como moverse demasiado rápido y liberar código inestable. Cuando la reducción de riesgos se convierte en semanas de control de calidad manual, revisiones de código excesivas y lentas, lanzamientos poco frecuentes o un proceso de planificación interminable, el aumento del análisis puede dejar a los desarrolladores ociosos e inquietos, sin reducir necesariamente el riesgo de incidentes.

Buen gestor, mal gestor: Nosotros contra ellos, jugador de equipo

Ejemplo: X acaba de incorporarse a una startup mediana para dirigir el equipo móvil, descuidado durante mucho tiempo. Al llegar le dijeron que el equipo era un desastre, así que su primer paso es contratar rápidamente a un grupo de personas nuevas que trabajaron para ella en BigCo. No acaban de encajar en la cultura y el equipo se convierte rápidamente en una camarilla de desarrolladores que se consideran mejores que el resto de la organización. Aunque la tecnología ha mejorado, parecen chocar mucho con el equipo de producto y, en definitiva, las aplicaciones no evolucionan muy rápidamente. Al cabo de un año, Diana se harta de la empresa y dimite. El resto de su nuevo equipo no tarda en seguirla, dejando la empresa justo donde empezó.

Puede resultar difícil para los nuevos directivos crear una identidad de equipo compartida. Muchos de ellos recurren por defecto a una identidad construida en torno a las especificidades de su función laboral o de su tecnología. Unen al equipo haciendo hincapié en cómo esta identidad es especial en comparación con otros equipos. Cuando van demasiado lejos, esta identidad se utiliza para que el equipo se sienta superior al resto de la empresa, y el equipo se interesa más por su superioridad que por los objetivos de la empresa.

Agrupar a un equipo de esta manera es una unión poco profunda que es vulnerable a muchas disfunciones:

• Frágil ante la pérdida del líder. Los equipos en grupo tienden a ser muy frágiles ante la pérdida de su líder. Cuando se contrata a un directivo que crea una camarilla, es probable que esa camarilla se disuelva y abandone la empresa si el directivo la abandona. Este problema hace que sea mucho más difícil abordar los problemas que el directivo está causando al crear una camarilla en primer lugar.
• Resistentes a las ideas ajenas. Las camarillas tienden a ser resistentes a las ideas que no proceden de los miembros del grupo. Esto significa que pierden oportunidades de aprender y crecer. La falta de crecimiento de los miembros del equipo suele provocar que los mejores miembros del equipo abandonen no sólo el grupo, sino la empresa. Como creen que están en el mejor grupo pero siguen aburriéndose, no aprecian el crecimiento que podrían encontrar con sólo cambiar a un nuevo equipo.
• Construcción del imperio. Los líderes que favorecen un estilo de nosotros contra ellos tienden a ser constructores de imperios, buscando oportunidades para hacer crecer sus equipos y sus mandatos sin preocuparse por lo que es mejor para la organización en general. Esto suele dar lugar a una competencia con otros líderes por el número de personas y el control de los proyectos.
• Inflexibilidad. Estos grupos tienden a luchar contra el cambio que viene de fuera del grupo. Las reorganizaciones, los proyectos cancelados y los cambios de enfoque pueden provocar rupturas en las partes fundamentales de su identidad. Ya se trate de pasar de grupos funcionales a equipos interfuncionales, de retrasar la aplicación del iPad o de dar prioridad a un nuevo producto, el cambio puede devastar los frágiles vínculos del equipo con la empresa.

Como directivo, tenga cuidado con centrarse en sus equipos excluyendo al grupo en general. Incluso cuando le hayan contratado para arreglar un equipo, recuerde que la empresa ha llegado hasta aquí gracias a algunos puntos fuertes fundamentales. Antes de intentar cambiarlo todo para que se adapte a su visión, tómese el tiempo necesario para comprender los puntos fuertes y la cultura de la empresa, y piense en cómo va a crear un equipo que funcione bien con esta cultura, no contra ella. El truco no consiste en centrarse en lo que está roto, sino en identificar los puntos fuertes existentes y cultivarlos.

Basado en la experiencia de varios autores, mis opiniones, perspectivas y recomendaciones se expresarán a continuación (o en otros lugares de esta plataforma, respecto a las características en 2026 o antes, y el futuro de esta cuestión):

Ejemplo: X también se ha unido a una startup en la que las cosas son caóticas. Aunque puede ver que necesita cambiar el equipo, se mueve con cautela a la hora de despedir a gente y se toma el tiempo necesario para asegurarse de que las nuevas contrataciones sean siempre investigadas por alguien que lleve tiempo en la empresa. Dedica mucho tiempo a trabajar estrechamente con sus compañeros de producto y propone un camino a seguir que hace hincapié en la colaboración interfuncional. Se centra en establecer objetivos claros y en comunicárselos a su equipo. Las cosas empiezan despacio, pero con el tiempo toda la organización se siente más fuerte y tanto la tecnología como el producto han mejorado espectacularmente.

Los equipos duraderos se basan en un propósito compartido que procede de la propia empresa, y se alinean con los valores de ésta (para más información sobre este tema, véase acerca de la aplicación de los valores fundamentales en esta plataforma digital). Tienen una comprensión clara de la misión de la empresa, y ven cómo encaja su equipo en esta misión. Pueden ver que la misión requiere muchos tipos diferentes de equipos, pero todos los equipos comparten un conjunto de valores.

Al crear una alineación fuerte y duradera entre el equipo, sus individuos y la empresa en general, esta vinculación basada en el propósito hace que los equipos sean:

• Resistentes a la pérdida de individuos. Mientras que la camarilla es frágil, especialmente ante la pérdida del líder, el equipo impulsado por un propósito tiende a ser muy resistente a la pérdida de individuos y de liderazgo. Como son leales a la misión de la organización más amplia, pueden ver un camino a seguir incluso a través de la pérdida.
• Impulsados a encontrar mejores formas de alcanzar su propósito. Los equipos impulsados por un propósito están más abiertos a nuevas ideas y valoran los cambios que pueden ayudarles a servir mejor a su propósito. Les importa menos el origen de una idea que su mérito para alcanzar sus objetivos. Los miembros de estos equipos están interesados en aprender de otros ajenos a su función y buscan activamente oportunidades de colaborar más ampliamente para crear los mejores resultados.
• Centrados en el primer equipo. Los líderes que son fuertes jugadores de equipo entienden que las personas que dependen de ellos no son su primer equipo. En su lugar, su primer equipo son sus compañeros de toda la empresa. Este enfoque de primer equipo les ayuda a tomar decisiones que tienen en cuenta las necesidades de la empresa en su conjunto antes de centrarse en las necesidades de su equipo.
• Abierto a los cambios que sirvan a su propósito. El líder colaborador comprende que se producirán cambios para servir a un propósito más amplio. Los equipos cambiarán de estructura y las personas tendrán que desplazarse hacia donde estén las necesidades de la empresa. Con ese conocimiento, estos líderes crean equipos que son más flexibles y comprensivos con los cambios frecuentes al servicio de la visión más amplia.

Conseguir claridad sobre el propósito de su equipo y de su empresa puede llevar tiempo. Especialmente en las nuevas empresas, suele haber cierta confusión sobre los objetivos actuales e incluso a veces sobre la misión subyacente.

En el caso de que los objetivos sean difusos y la misión no esté clara, haga todo lo posible por comprender la cultura de la empresa y piense en cómo puede configurar sus equipos para que trabajen bien dentro de esa cultura. Colaborando entre equipos y entre funciones empresariales, sus equipos llegarán a comprender el panorama general y a apreciar su misión como parte de ese panorama.

Las virtudes de la pereza y la impaciencia

A menudo, se podría decir que la pereza, la impaciencia y la arrogancia son virtudes de los ingenieros y otros equipos técnicos. Estas virtudes persisten en el liderazgo, y aprender a canalizar estos rasgos para convertirlos en ventajas es algo que animo a hacer a todos los directivos.

Como directivo, cuando trata con personas de tú a tú probablemente no quiera ser impaciente, por supuesto. La impaciencia puede ser grosera si se dirige a las personas. Y no querrá parecer perezoso, porque no hay nada peor que trabajar para un directivo que parece tomárselo con calma mientras usted se mata a entregar proyectos. Pero la impaciencia unida a la pereza es maravillosa cuando la dirige a los procesos y las decisiones. La impaciencia y la pereza, aplicadas a los procesos, son los elementos clave para centrarse.

A medida que vaya ocupando puestos de liderazgo, la gente le buscará para que les guíe en su comportamiento. Lo que usted quiere enseñarles es a centrarse. Para ello, hay dos áreas que le animo a que practique modelar, ahora mismo: averiguar lo que es importante y volver a casa.

Es duro ver a la gente malgastar su energía abordando los problemas con fuerza bruta y gastando tiempo en lugar de pensar. Y, sin embargo, cualquier cultura en la que se anime a trabajar horas excesivas todo el tiempo es casi seguro que está haciendo precisamente eso. ¿Qué valor tiene la automatización si no se utiliza para facilitar el trabajo? Los ingenieros automatizamos para poder centrarnos en lo divertido, y lo divertido es el trabajo que utiliza la mayor parte de su cerebro, y no suele ser algo que pueda hacer durante horas y horas, día tras día.

Así que sea impaciente para descubrir la nuez de lo importante. Como líder, cada vez que vea que se está haciendo algo que le parece ineficiente, cuestiónelo: ¿Por qué me parece ineficiente? ¿Qué valor tiene lo que estamos haciendo? ¿Podemos aportar ese valor más rápidamente? ¿Podemos reducir este proyecto a algo más sencillo y hacerlo más rápidamente?

El problema de esta línea de preguntas es que, a menudo, cuando los directivos preguntan si algo puede hacerse más rápido, lo que quieren saber explícita o implícitamente es si el equipo puede trabajar más o más horas para entregarlo en menos días. Por eso le animo a que desarrolle y muestre el valor de la pereza. Porque “más rápido” no tiene que ver con “el mismo número de horas pero menos días totales”. “Más rápido” se trata de “el mismo valor para la empresa en menos tiempo total”. Si el equipo trabaja 60 horas en una semana para entregar algo que de otro modo le habría llevado una semana y media, no han trabajado más rápido, sólo han dado a la empresa más de su tiempo libre.

Aquí es donde entra en juego el irse a casa. Váyase a casa. ¡Y deje de enviar correos electrónicos a todas horas de la noche y a todas horas del fin de semana! Obligarse a desconectar es esencial para su salud mental, créame. El agotamiento es un problema real en la mano de obra estadounidense en estos días, y casi todas las personas que conozco que han trabajado un exceso de horas sostenido lo han experimentado en algún grado. Es terrible para los individuos, terrible para sus familias y terrible para los equipos. Pero no se trata sólo de prevenir su propio agotamiento: se trata de prevenir el agotamiento de su equipo. Cuando usted trabaja más tarde que los demás, cuando envía esos correos electrónicos a todas horas, aunque no espere que su equipo responda a esos correos o trabaje esas horas, ellos le ven hacerlo y creen que es importante. Y ese exceso de trabajo les hace menos eficaces, especialmente en el trabajo de conocimiento detallado que deben realizar los ingenieros.

Cuando usted es un directivo novato y no ha descubierto los trucos para hacer su trabajo con eficacia, es posible que se vea en la necesidad de trabajar más horas para poder hacerlo todo. Eso está bien durante un tiempo. Pero le animo a que encuentre la manera de trabajar esas horas sin animar a su equipo a hacerlo ni hacerles sentir obligados a estar en su horario. Ponga en cola los correos electrónicos del fin de semana y de la noche para el siguiente día laborable. Ponga su estado de chat como “ausente” en horas no laborables. Tómese unas vacaciones y no responda al correo electrónico durante ese tiempo. Y hágase constantemente las mismas preguntas que hace a su equipo: ¿Puedo hacer esto más rápido? ¿Necesito estar haciendo esto? ¿Qué valor estoy aportando con este trabajo?

Pereza e impaciencia

Nos centramos para poder irnos a casa, y fomentamos el irnos a casa porque nos obliga a centrarnos constantemente. Así es como escalan los grandes equipos.

Evaluar su propia experiencia

Algunas preguntas clave:

• ¿Cuándo fue la última vez que revisó su agenda en busca de cosas que está haciendo pero que no le están aportando mucho valor a usted o a su equipo? Mire hacia atrás, hacia las últimas dos semanas.
• Mire hacia delante, hacia las próximas dos semanas. ¿Qué ha conseguido y qué espera conseguir?
• Si sigue redactando código, ¿cómo encaja esto con el resto de su horario? ¿Lo hace a deshoras? ¿Qué le impulsa a seguir dedicando este tiempo?
• ¿Cuál fue la última tarea que delegó en un miembro de uno de sus equipos? ¿Era sencilla o compleja? ¿Cómo está gestionando la nueva tarea la persona en la que delegó?
• ¿Quiénes son los líderes ascendentes de sus equipos? ¿Cuál es su plan para prepararlos para que asuman mayores funciones de liderazgo? ¿Qué tareas les está encomendando para prepararles para una mayor responsabilidad?
• ¿Parece que el proceso de redacción, liberación y soporte de código funciona sin problemas en sus equipos? ¿Cuándo fue la última vez que hubo un incidente notable con parte de este proceso? ¿Qué ocurrió y cómo respondió a ello el equipo? ¿Con qué frecuencia se encuentra el proceso con estas condiciones excepcionales?
• ¿Cuándo fue la última vez que presionó a su equipo para que recortara el alcance de un proyecto?
• Cuando recorta el alcance, ¿recorta características, calidad técnica o ambas? ¿Cómo lo decide?
• ¿Cuándo fue la última vez que envió un correo electrónico después de las 8 de la tarde o durante el fin de semana? ¿Respondió la persona a la que envió el correo electrónico? ¿Necesitaba que él o ella respondiera?

Revisor de hechos: Dannielson

Recursos

Véase También

• Gestión de Equipo
• Gestión de Equipos de Alta Dirección
• Gestión de Equipos
• Roles de Gestión del Equipo Directivo
• Historia de Gestión de Equipos
• Gestión del Personal Público
• Gestión de Recursos Humanos
• Gestión de la Remuneración
• Futuro de la Gestión de Equipos de Alta Dirección
• Recursos sobre Desarrollo Profesional
• Recursos Humanos para la Salud
• Recursos Humanos en la Administración Pública
• Recursos Humanos en China
• Recursos Humanos
• Recursos Empresariales Digitales

▷ Esperamos que haya sido de utilidad. Si conoces a alguien que pueda estar interesado en este tema, por favor comparte con él/ella este contenido. Es la mejor forma de ayudar al Proyecto Lawi.