La primera vez que pasé de ingeniero senior a dirigir un área de tecnología, el título que me dieron fue director. No querían entregar un VP, y nadie iba a ser CTO. Los desarrolladores dirigían el lugar según quien tuviera la opinión más fuerte ese mes. Ese era el trabajo: subirte a un auto en movimiento y encontrar el volante.

La mayor parte de mi experiencia es en empresas pequeñas con problemas técnicos y de producto profundos. En dos de las cinco, los fundadores eran farmacéuticos que se pusieron a montar una empresa de tecnología. Sale más o menos como te imaginas. Gente a la que le encanta ir a restaurantes abre un restaurante, descubre que es mala dirigiéndolo, y ya lleva dos años metida antes de que alguien lo diga en voz alta. La misma historia en farmacia.

Así que esto está sesgado hacia el lado desordenado del espectro. Si acabas de aceptar un rol de liderazgo en una empresa tranquila y bien dirigida, felicidades, y casi todo esto sigue aplicando, solo que vas a tener más tiempo para hacerlo.

Así dirijo los primeros 90 días.

Guarda los martillos

La parte más difícil de los primeros 30 días es no hacer casi nada.

Eres ingeniero. Quieres arreglar cosas. Como ejecutivo deberías rara vez estar arreglando algo, y probablemente nunca deberías escribir código. Si estás escribiendo código, estás cubriendo un hueco de personal, y el liderazgo tiene que enterarse.

Tu verdadero trabajo en el primer mes es observar y tomar notas. Siéntate en las reuniones, sigue el proceso que tengan, y aguanta las ganas de ofrecer soluciones hasta que alguien las pida. La forma más rápida de perder a la sala es que alguien diga “ni siquiera entiendes cómo hacemos las cosas aquí,” y tendrá razón, porque todavía no lo entiendes. Algún arreglo que parece obvio el día tres resulta imposible una vez que estás metido en el barro el día veinte.

También vas a conocer a la gente muy comprometida con su propio proceso. “Solo se rompió este sprint.” “Lo arreglaríamos si tuviéramos tiempo.” Después hablas con todos los demás y te enteras de que se rompe cada sprint y siempre lo ha hecho. Tu ventaja como la persona nueva es la perspectiva de afuera, y tiene fecha de caducidad. Úsala antes de volverte parte del paisaje.

La única piedra que sí volteas

Hay excepciones, y las reconocerás cuando las veas.

Una mañana estaba leyendo un pull request y vi a alguien escribir una inyección SQL directo en él. Puse el límite ahí mismo. No me importa si nos cuesta un millón de dólares, no puedes desplegar a sabiendas el vector de ataque más explotado de internet. Cualquier cosa que sea un agujero de seguridad activo o un incendio regulatorio se atiende ahora, no en tu informe de los 30 días.

Y después, de todos modos, se convierte en uno de tus puntos, porque “el equipo desplegó inyección SQL y ni se inmutó” te dice algo real sobre dónde estás parado de verdad.

Síntoma, causa, y luego el 80/20

A los 30 días le debes un informe al CEO. El mío siempre tiene la misma forma: mis cinco problemas principales, el síntoma que todos ya sienten, la causa que está por debajo, y el arreglo más pequeño que rinde más.

Nunca llegues con “el número uno es una reconstrucción de siete meses.” Así te ignoran. Llega con la cosa de una semana y la cosa de un mes que le mejoran la vida a todos, y guarda el trabajo estructural feo para después de haberte ganado algo de confianza.

El triunfo rápido al que recurro una y otra vez es la observabilidad. Mi empresa más reciente no tenía nada de monitoreo de rendimiento de aplicaciones. Cuando algo se rompía, la gente abría los archivos de log y se ponía a leer. Nunca eran los primeros en enterarse, y todo tardaba una eternidad en arreglarse. Hice la pregunta obvia, ¿no estaría genial saber exactamente qué está fallando y por qué?, y luego les dije que es una prueba de concepto de un día. Teníamos OpenTelemetry corriendo para el final de la semana.

Nadie celebra nunca una semana de trabajo que rinde tanto. Ese es el punto. Los triunfos rápidos son cómo compras el capital político que vas a gastar después en el trabajo aburrido e importante. Porque eventualmente los triunfos fáciles se acaban y solo queda lo poco glamoroso: un ciclo de vida de desarrollo de software de verdad, monitoreo de dependencias, las cosas que ningún cliente elogia jamás. Un equipo de seguridad te pedirá tu SDLC y lo archivará. Ninguno de ellos te va a decir que lo bordaste. Te toca a ti ser el campeón de ese trabajo.

Hay una frase en la que pienso mucho, y olvido quién la acuñó: cada tres años todo en tecnología se vuelve el doble de fácil. Una variación de la ley de Moore, pero cierta. El APM era prácticamente inalcanzable hace diez años. OpenTelemetry no existía, estabas mirando Datadog o New Relic y un presupuesto de verdad. Hoy estás loco si no lo tienes. Muchas de tus ventajas “secretas” son solo saber qué se abarató mientras nadie miraba.

Aprende cómo lee tu CEO

La mitad de este trabajo es traducción, así que aprende el formato antes de escribir el informe.

He tenido CEOs visuales que quieren un mapa de la aplicación: así encajan las piezas, aquí están los cuellos de botella, aquí es donde se está incendiando. He tenido CEOs que quieren exactamente seis viñetas, y si escribes una séptima, el correo no se lee. Suena quisquilloso. No lo es. Son personas ocupadas que no quieren una pila de problemas encima, y descubrir su formato temprano es la mayor parte de hacerte escuchar.

Una cosa más que a los ejecutivos no les importa: problemas que todavía no puedes nombrar. Decirle a un CEO “hay deuda técnica en algún lado que no hemos encontrado” solo le entrega una preocupación para cargar. Siempre hay suficientes problemas conocidos como para que nadie tenga paciencia para los hipotéticos. Sigue cavando hasta que la preocupación se vuelva algo específico y accionable.

Día 60: lanza los triunfos baratos

El segundo mes es para implementar de verdad. A estas alturas ya le entregaste al CEO tus soluciones y tus triunfos rápidos, y la regla del 80/20 toma el control. Si un arreglo es el 20% del esfuerzo y resuelve el 80% del dolor, eso es lo que se va a hacer. Intentar forzar primero la solución más rigurosa es pelear contra la gravedad.

Mantén tus cambios en arreglos técnicos y proceso ligero. ¿No hay plan de respuesta a incidentes? Escribe uno. ¿No hay alarmas ni monitoreo? Agrégalos. Lo que no haces en el segundo mes es entrar marchando a anunciar que vas a convertir a toda la empresa de cascada a ágil. Si vas a tocar el proceso, átalo directamente al dolor que está causando, nunca a tus preferencias.

Aquí también es donde empiezas a guardar capital para después. Avísale al CEO con anticipación: lo haremos a tu manera, y como estamos usando cascada sin observabilidad, esto va a tardar dos meses en vez de uno, y aquí está exactamente por qué. Dilo con hechos, sin quejarte. Después sigue su proceso en público. Cuando la cosa tarde los dos meses que predijiste, apuntas al registro. Así te ganas el derecho a empujar por la decisión más grande después.

No necesitas una metodología en particular. Necesitas una cadencia. Kanban, scrum, notas adhesivas en una pizarra, me da igual, mientras las cosas se entreguen en un calendario ajustado y predecible, semanal o quincenal a más tardar. Elige una y mantenla.

Y el calendario de releases rara vez es del todo tuyo. En farmacia no puedes desplegar en diciembre, porque el seguro de todos cambia el 1 de enero y el 10 de enero. Si despliegas un cambio que rompe algo esa primera semana de enero, has creado un caos dentro de los reclamos y la dispensación. Por eso los congelamientos de código en empresas de salud empiezan en diciembre. Quieres un mes entero de que nada cambie y nada se rompa.

Día 90: todos tienen un plan hasta que les pegan

Para el tercer mes deberías tener unos cuantos triunfos implementados y un control real sobre la lista de problemas. También vas a tener una pila de problemas nuevos, porque la mitad de tu prolijo plan de 30/60/90 no sobrevivió al contacto.

Mike Tyson tenía razón. Todos tienen un plan hasta que les pegan en la boca. He redactado planes de 30/60/90 y los he mantenido casi del todo. También los he redactado y nunca más he vuelto a mencionarlos, porque la empresa tenía tantas caídas que el único plan real era apagar incendios y poco a poco adelantarse a ellos. Si tu empresa no puede prometer honestamente qué va a estar haciendo dentro de un mes, tu plan de 30/60/90 es decoración. Una empresa que puede entregarte una hoja de ruta de tres meses y de verdad cumplir hasta el 80% es una empresa estable, y llevar una hasta ahí suele tomar unos dos años y mucho compromiso de todos.

Aquí está la parte que nadie te cuenta a la entrada. La mayoría de lo que parece un problema de tecnología es un problema de producto, un problema de priorización, y un problema de liderazgo disfrazado de tecnología. La tecnología está en el fondo de la empresa. Cada mala decisión que se toma más arriba rueda cuesta abajo y aterriza sobre tu equipo, y no hay forma de escapar, es gravedad. Un equipo de liderazgo anterior claramente se dejó engatusar con un mal proveedor de redacción de datos, lo firmó en noviembre con una fecha límite de fin de año, y la cuenta cayó sobre ingeniería. A mí no me tocó nada de la comisión, y el producto encima era malo. Gracias por eso. (Escribí más sobre las ideas que ruedan cuesta abajo aquí.)

Así que cuando algo que debería tomar dos semanas toma tres meses, la causa casi siempre es proceso o priorización, y esa es la pelea que de verdad tienes que ganar. Sigues su proceso en público y le dices la verdad al CEO en privado. Cuando te dan la razón, y te la van a dar, a veces eso fuerza una decisión difícil, y a veces esa decisión termina con el puesto de alguien. Esa es la parte genuinamente incómoda del trabajo.

Pero el equipo de tecnología es aplastado por todo lo demás de la empresa por defecto, porque todo rueda cuesta abajo. Alguien no cumple una fecha, alguien cierra una venta, alguien firma un proveedor, y todo aterriza sobre ti, y eres tú quien queda mal aunque todos los demás se hayan portado mal. Si no peleas por tu equipo, lo aplastan.

Ese es todo el trabajo en los primeros 90 días. Observa más de lo que arreglas, lanza los triunfos baratos, aprende cómo lee tu CEO, y empieza a construir el argumento para las cosas que de verdad importan antes de que alguien esté listo para escucharlo.