Mantenerme cerca sin convertirme en el cuello de botella

Un cuello de botella puede sentirse como control de calidad desde dentro. Aprendí lo fácil que era convertirme en uno.

Durante gran parte de mi carrera en ingeniería, ser útil significaba acercarme lo suficiente como para resolver el problema. Podía rastrear una ruta de datos rota, escribir las herramientas de despliegue que faltaban, llevar una migración hasta el final o convertir un requisito ambiguo en software funcional. Cuando algo importante estaba atascado, acercarme solía ser el instinto correcto.

Ese instinto me ayudó a convertirme en ingeniera principal. No me enseñó automáticamente a dirigir a quienes dirigían equipos.

A medida que crecía mi alcance, la gente seguía trayéndome problemas difíciles y yo seguía ayudando de la manera que mejor conocía: me acercaba lo suficiente como para cargar con parte del trabajo. En comentarios sobre mi liderazgo, me animaron a delegar más trabajo de proyectos y a distinguir mejor entre apoyar a una persona a mi cargo e intervenir en su lugar. Entendí que una fortaleza se estaba convirtiendo en una restricción.

Llamo a ese patrón el instinto de rescate: ver un problema que podía resolver y confundir capacidad con responsabilidad. Me había ayudado a tener éxito antes en mi carrera. A escala de Dirección, podía quitarles la responsabilidad a otras personas líderes.

Más recientemente, lideré una estructura jerárquica de ingeniería de 22 personas mediante cinco personas a mi cargo directo, incluidas tres en puestos de Dirección de Ingeniería. Pasar de ingeniera principal a dirigir a quienes dirigían equipos no exigía que dejara de ser técnica. Exigía que cambiara para qué servía mi profundidad técnica. Todavía necesitaba entender la arquitectura, contrastar una explicación cómoda con la evidencia y reconocer cuándo un riesgo había cruzado un límite. No podía convertirme en la ruta obligatoria de cada decisión importante.

La diferencia puede ser difícil de ver en el momento. Si le quito un problema a una persona en Dirección de Ingeniería, quizá esté enseñándole a su equipo dónde reside realmente la autoridad. El problema inmediato se resuelve, pero la cola de decisiones se alarga y la capacidad de liderazgo se debilita. Mantener la responsabilidad significa seguir disponible sin trasladar silenciosamente el trabajo a mi alrededor.

Primero hay que identificar qué tipo de ayuda se necesita

La lección más duradera que extraje de esos comentarios es sencilla: apoyar no es lo mismo que recuperar la responsabilidad.

1. Escuchar. Necesitan espacio para describir lo que ocurre, poner a prueba su propia comprensión o decir algo difícil sin que la conversación se convierta de inmediato en mi solución.
2. Acompañar. La decisión les pertenece y quieren ayuda para examinar supuestos, alternativas, consecuencias o la recomendación que están formando.
3. Una decisión. La elección corresponde realmente a mi nivel porque cruza equipos, cambia una restricción compartida, compromete recursos fuera de su autoridad o requiere que alguien responsable desempate.
4. Intervenir. Existe un riesgo activo para residentes o para la seguridad, un riesgo material para el servicio o una consecuencia entre equipos, una responsabilidad peligrosamente poco clara o una expectativa incumplida repetidamente que ahora exige acción directa.

El modo puede cambiar durante la conversación. Escuchar puede revelar un riesgo activo. Acompañar puede mostrar que dos equipos llevan tiempo esperando una decisión que solo yo puedo tomar. Una decisión solicitada puede resultar ser una elección local y reversible que debe permanecer con la persona más cercana a ella.

Ayuda ponerle nombre al modo. «¿Quieres que escuche, que te ayude a pensarlo, que tome la decisión o que intervenga?» puede evitar muchas apropiaciones accidentales. También ayuda decir lo que creo que estoy haciendo: «Voy a hacer preguntas, pero esta sigue siendo tu decisión» o «Esto ya cruza un límite de seguridad, así que asumo la responsabilidad de la respuesta inmediata».

No elaboré este ordenado modelo de cuatro partes en el momento en que recibí esos comentarios. Es el marco que uso ahora para conservar la lección. Esa distinción me importa. Una reflexión retrospectiva puede ser útil sin fingir que entonces ya era un proceso operativo completamente formado.

La responsabilidad técnica no es control técnico

Las decisiones técnicas determinan el costo, la seguridad, la accesibilidad, la velocidad de entrega y lo que un equipo podrá cambiar el próximo año. Una persona líder responsable de esos resultados necesita suficiente profundidad para examinar el razonamiento que los sustenta. La responsabilidad técnica sigue dejando la implementación y el criterio local en manos de responsables identificados.

En MyCareer.NJ.gov, ayudé a llevar una plataforma estatal de empleo desde un prototipo inicial hasta un servicio público en funcionamiento como parte de una colaboración más amplia entre gobierno, investigación, diseño, producto y entrega. Dentro de ese trabajo, construí personalmente partes importantes de la base de ingeniería: entrega continua, herramientas de lanzamiento, migraciones de bases de datos y middleware bilingüe. También diseñé la arquitectura y dirigí partes del sistema que otras personas ingenieras implementaron.

Esos verbos describen trabajos distintos. Construí no es un sinónimo más impresionante de diseñé la arquitectura. Diseñé la arquitectura no es un sinónimo más técnico de lideré. La atribución precisa facilita la comprensión del sistema y protege la autoridad de las personas que realmente llevaron cada decisión al código.

A medida que crecía el alcance de mi liderazgo, el uso más valioso de la profundidad técnica pasó cada vez más a ser examinar la recomendación que había debajo del diagrama. ¿Qué evidencia la respalda? ¿Qué modos de falla seguirían sin hacerse visibles? ¿La elección es reversible? ¿Afecta la implementación de un equipo o un contrato con el que todos los equipos tendrán que convivir? ¿Quién es responsable del resultado cuando termina la revisión y qué nos haría detenernos o escalar? La persona responsable debe salir de esa revisión con una autoridad más clara, no con una lista de mis preferencias por implementar.

A escala de portafolio, centralicé los contratos cuya inconsistencia podía crear riesgos para todos los equipos: patrones de seguridad y acceso, controles de entrega y lanzamiento, disciplina de esquemas, expectativas de accesibilidad y capacidad de auditoría. Las personas responsables del programa y de la parte técnica conservaron la autoridad sobre los resultados, las recomendaciones y la implementación de sus ámbitos.

Una decisión posterior hizo concreto ese límite. Una nueva aplicación de informes para CMS necesitaba capacidad enfocada y una primera versión acotada. Yo mantuve la responsabilidad por la concentración de capacidad y el límite de esa primera versión. Las personas responsables del programa y de la parte técnica, junto con el equipo dedicado, mantuvieron el diseño y la implementación. La aplicación alcanzó su primera versión en producción en unas ocho semanas mientras las aplicaciones existentes siguieron publicando versiones.

Ese es un resultado del equipo. No demuestra que mi modelo de gestión causara la entrega ni que hubieran desaparecido todas las dependencias. Sí muestra un caso importante en el que mantuve la responsabilidad por la capacidad y el alcance sin convertirme en la persona que implementaba.

Mantengo mi cercanía técnica mediante revisiones de arquitectura y riesgos, depuración de rutas de producción y trabajo acotado de aprendizaje, diagnóstico o desbloqueo bajo una persona responsable identificada. Cualquier código que escriba a ese nivel necesita una transferencia explícita. No puede convertirse en un canal privado de entrega que corra en paralelo al equipo.

El crecimiento exige autoridad real

Nueve profesionales de ingeniería dentro de la estructura que lideré recibieron ascensos; cuatro llegaron a puestos de Director o Principal. Esa cifra no demuestra que un marco causara su crecimiento, y yo no hice capaces a esas personas. Ellas aportaron el talento, el criterio, el trabajo y la ambición.

Mi responsabilidad era ayudar a crear las condiciones para que esa capacidad pudiera hacerse visible y tener consecuencias. Las personas necesitan acceso a trabajo importante y a decisiones cuya responsabilidad realmente se les permite asumir. También necesitan un límite legible: el resultado, las propiedades de seguridad no negociables, la evidencia esperada y la condición que devuelve una decisión al nivel superior.

Otra persona líder capaz puede elegir de manera distinta a como lo haría yo. Si solo mi respuesta preferida cuenta como preparación, estoy formando sustitutos.

No tengo una prueba formal de ausencia que demuestre que cada ámbito crítico podía funcionar sin mí, ni una medición limpia de antes y después que muestre que desaparecieron todas las dependencias. Apoyar sin recuperar el trabajo sigue siendo un área de crecimiento: una disciplina, no una lección que se aprende una sola vez.

El objetivo no es desaparecer

Quiero mantenerme lo bastante cerca como para entender los modos de falla, cuestionar un diseño con consecuencias, reconocer cuándo un panel impecable oculta un servicio poco saludable e intervenir cuando el riesgo cruza un límite. También quiero que las personas gerentes e ingenieras que lidero tengan suficiente contexto, autoridad y confianza para que mi presencia sea una ventaja y no un requisito.

La prueba no es si seguí involucrada. Es si la arquitectura quedó más clara, la persona responsable mantuvo la responsabilidad y la siguiente decisión sólida pudo tomarse sin esperar por mí.