Sus Primeros 30/60/90 Días como Nuevo EM

Hace tres semanas usted era un IC senior. Hoy su calendario tiene 14 horas de reuniones, 26 horas de "tiempo libre" y un DM en Slack de su skip-level que dice "avíseme si quiere tomar un café esta semana." Todavía tiene acceso a hacer merge. Todavía sabe exactamente qué archivo abrir para corregir el bug que acaba de despertar al ingeniero on-call. Y eso, precisamente, es la trampa.

La mayoría de los nuevos EM recurren a programar porque es más seguro que hacer coaching. El ticket en Jira tiene una definición de hecho. La reunión individual con el staff engineer que en silencio está buscando otro trabajo no la tiene. Entonces el nuevo EM entrega una funcionalidad en la segunda semana, se siente productivo y falla en el trabajo real durante seis meses, hasta que su skip-level pregunta por qué la velocidad de entrega del equipo no ha mejorado y dos personas han renunciado.

Si todavía mide su semana en PR merged, ha tomado el título sin asumir el cargo.

Por Qué Importa el Plan 30/60/90

La ventana en la que su equipo forma una opinión sobre usted es estrecha. Para el día 45 ya han decidido si usted es un gerente que sigue fingiendo ser un IC, o un IC que está convirtiéndose en gerente. Notan qué reuniones cancela, a qué reuniones individuales les cambia la fecha, de qué habla cuando sí aparece. No le dicen qué decidieron. Solo empiezan a ajustar su comportamiento en consecuencia.

El plan que sigue está diseñado para forzar el segundo resultado. Cada bloque de 30 días tiene de tres a cinco entregables concretos, y todos son cosas que no puede hacer desde su IDE.

Días 1 a 30: Escuche, Audite, Preséntese

Este primer mes es de recopilación de información. Tendrá la tentación de arreglar cosas. No lo haga. Todavía no sabe qué está realmente roto en comparación con lo que simplemente parece roto desde su antiguo lugar.

10 reuniones individuales con subordinados directos en las primeras dos semanas

Si tiene ocho subordinados directos, eso equivale a aproximadamente una reunión individual por día durante dos semanas más un par de seguimientos de 30 minutos. Las mismas tres preguntas cada vez:

1. ¿Cuál es lo mejor de trabajar aquí ahora mismo?
2. ¿Cuál es lo peor?
3. Si usted fuera yo, ¿qué cambiaría en los primeros 90 días?

Tome notas a mano. No resuelva problemas en la reunión. El mayor error que cometen los nuevos EM en las primeras reuniones individuales es escuchar una queja y comprometerse a resolverla en el momento, para luego arreglar la cosa equivocada o incumplir la promesa tres semanas después. "Cuénteme más" y "quiero reflexionar sobre eso" son respuestas completas.

Al final de la segunda semana tendrá entre 30 y 50 observaciones distintas. Surgirán patrones. Tres subordinados directos mencionarán el mismo problema en diferente lenguaje. Ese es su mapa.

Auditar la velocidad de entrega del equipo y la rotación de guardias

Revise los últimos 8 sprints. Busca dos cosas:

• Tendencia de rendimiento. ¿Los story points completados por sprint están estables, subiendo o bajando? Si están bajando, ¿cuándo empezó? Vincúlelo a eventos: una reorganización, un cambio de alcance, alguien de baja.
• Distribución on-call. Revise los registros de alertas y cuente los incidentes en producción por ingeniero en el último trimestre. Si tres personas están cargando el 70% de las alertas, tiene un problema de equidad y un riesgo de agotamiento, y no lo sabía la semana pasada porque nadie se quejó en voz alta.

Documente lo que encuentre. No lo arregle todavía. La auditoría es una línea base que usará en los días 31 a 60 cuando realice su primer retro.

Asistir a 5 reuniones interfuncionales

Planificación de producto. Revisión de diseño. Sales enablement (sí, ventas, porque su equipo probablemente entrega funcionalidades que el equipo de AE tiene que demostrar en un Demo). Sincronización de escalaciones de soporte. La reunión semanal que su skip-level realiza con su par en otra área.

No va a hablar. Va a aprender cómo se ve su equipo desde afuera. El product manager que elogia a su equipo en el standup puede poner los ojos en blanco al hablar de ellos en la reunión interfuncional de planificación. El líder de soporte puede mencionar tres escalaciones de clientes de las que usted nunca oyó hablar. La reputación de su equipo vive en salas a las que antes no lo invitaban.

Tome notas en esas reuniones específicamente sobre su equipo. Comparta las observaciones con sus subordinados directos en las reuniones individuales sin nombrar quién dijo qué.

CERO commits de código

Regla estricta. Si un bug crítico necesita sus manos, trabaje en pareja con un ingeniero y deje que él haga el merge.

Cada commit que entregue en el primer mes es una señal para su equipo de que el trabajo anterior todavía está disponible para usted. Empezarán a trabajar sin contar con usted para entregar más rápido. Dejarán de traerle los problemas humanos difíciles porque pueden ver que preferiría estar en el código. Usted se sentirá productivo y se estará engañando.

La primera vez que le dije a un ingeniero senior que haría pareja con él en una migración compleja pero no iba a hacer el commit, se molestó unos diez minutos y luego se notó notablemente más cómodo durante el resto del trimestre. No quería que yo escribiera en su repositorio. Quería que yo pensara en todo lo demás.

Días 31 a 60: Dirija Algo, Arregle Algo, Diga Algo Difícil

El segundo mes es cuando pasa de recibir información a producir resultados. Tres entregables, todos suficientemente pequeños para entregarlos en 30 días.

Facilitar 1 retrospectiva

Su primera como facilitador, no como participante. Use los datos de la auditoría de velocidad de entrega. El formato importa poco (empezar-parar-continuar, enojado-triste-contento, lo que use su equipo). Lo que importa es que saque a la luz un patrón incómodo y deje que el grupo lo asimile.

Por ejemplo: "Estamos cerrando tickets pero reabriendo el 22% de ellos en dos sprints. ¿A qué se debe eso?" Luego cállese. Los primeros 90 segundos serán silenciosos o llenos de evasivas. Espere. Los ingenieros eventualmente dirán cosas verdaderas si usted no llena el silencio con su propia teoría.

La primera vez que facilité un retro como gerente, hablé 18 de los 30 minutos. Esa fue la lección. Su trabajo en un retro es preguntar, resumir y asignar uno o dos puntos de seguimiento. No conducir la conversación.

Arreglar 1 proceso roto

La cosa más pequeña de la que los subordinados directos se quejaron en las reuniones individuales y para la que usted pueda entregar una solución en dos semanas. No la reforma organizativa monumental. La cosa que ha estado molestando a todos durante meses y que nadie ha sido lo suficientemente senior o organizado como para simplemente eliminar.

Ejemplos reales que han funcionado:

• Standup que dura 45 minutos: reducido a 15, con formato asíncrono como base y una sincronización de 10 minutos en vivo solo cuando existen bloqueos.
• SLA de revisión de código de PR de tres días, frecuentemente incumplido: se publicó un documento de expectativas de una página, se agregó un bot de recordatorio en Slack y se designó un revisor de respaldo por área.
• Handoff on-call sin runbook escrito: se exigió una reunión de handoff de 20 minutos al final de cada rotación de guardias, con notas en un documento compartido.

Elija uno. Entregue la solución. Dígale al equipo que los escuchó. El punto no es la mejora del proceso (aunque eso es bueno). El punto es que querían ver si usted realmente escucha, y la respuesta ahora es sí.

Sostener 1 conversación de retroalimentación difícil

La que ha estado evitando.

El ingeniero senior que es brillante pero arrolla a los juniors en la revisión de código. El nivel medio que sigue errando en las estimaciones por un factor de 3. El tech lead que está desconectado y el equipo trabaja silenciosamente a su alrededor.

Prepárela antes de la reunión. Use la estructura situación-comportamiento-impacto-petición:

• Situación: "En la revisión de diseño de ayer, cuando Priya propuso el enfoque basado en cola..."
• Comportamiento: "...la interrumpió dos veces y luego dijo que el diseño 'no funcionaría' sin explicar por qué."
• Impacto: "Dos ingenieros me han dicho que ya no llevan ideas tempranas al canal del equipo porque esperan ser ignorados. Estamos perdiendo aportes que necesitamos."
• Petición: "Necesito que deje que las personas terminen su idea y que, si está en desacuerdo, haga una pregunta antes de contradecir. ¿Puede hacer eso?"

Practíquela en voz alta. Dígala en una reunión individual, nunca en grupo. Permita el silencio después. La conversación se sentirá terrible mientras la sostiene y notablemente más fácil la segunda vez. Esta es la conversación que le demuestra a usted mismo que puede hacer el trabajo.

Días 61 a 90: Asuma Resultados, Planifique hacia Adelante

El tercer mes es cuando deja de ser "el nuevo EM" y empieza a ser "el EM." Tres entregables, todos visibles para su skip-level.

Asumir un OKR del equipo

No "apoyar la iniciativa de plataforma." Un resultado específico y medible por el que será evaluado al final del trimestre.

Malo: "Mejorar la experiencia del desarrollador." Bueno: "Reducir el tiempo medio de revisión de código de PR de 38 horas a 12 horas para finales del Q3, medido a través del panel de métricas de GitHub existente."

Escríbalo. Obtenga el visto bueno de su skip-level. Dígale al equipo que es suyo, no de ellos. Usted defenderá el número; ellos harán el trabajo. Esta distinción importa porque el equipo ha visto a demasiados gerentes transferir un OKR a sus espaldas y luego desaparecer cuando los resultados se tambalean.

Presentar un informe de 90 días a su skip-level

Tres diapositivas como máximo. La estructura que funciona:

• Diapositiva 1, lo que heredé. Línea base de velocidad de entrega, distribución on-call, los tres principales riesgos que encontré, los tres principales puntos fuertes. Dos oraciones cada uno.
• Diapositiva 2, lo que entregué. El retro que facilité, el proceso que mejoré, el OKR que asumí. Artefactos concretos que el skip-level puede verificar.
• Diapositiva 3, lo que solicito. El plan de contratación del segundo semestre y la propuesta de deuda técnica (siguiente punto). Solicitudes específicas, costos específicos, resultados esperados específicos.

Este es el artefacto que le gana un segundo período de 90 días de confianza. También es lo que su skip-level citará a su propio jefe al explicar por qué lo promovió. Hágaselo fácil.

Proponer plan de contratación del S2 y deuda técnica

Una vacante con una descripción de cargo que usted redactó (vincule la plantilla de descripción de cargo de staff software engineer) y una lista priorizada de los 3 principales ítems de deuda técnica con estimaciones de costo aproximadas.

El plan de contratación debe responder: qué rol, por qué este rol y no otro, qué queda desbloqueado cuando esa persona empieza, cuál es el costo de oportunidad si no obtiene la plantilla. Una página.

La lista de deuda técnica debe responder, por cada ítem: qué falla hoy por su causa, costo aproximado de ingeniería para corregirlo (en persona-semanas), mejora esperada (en términos medibles como 30% menos alertas, 2 semanas más rápido en incorporación, lo que corresponda). Priorice las tres. Defienda el orden cuando le sea cuestionado.

Preséntela. Defiéndala. Aunque no obtenga la plantilla ni el presupuesto de deuda técnica, el acto de escribir y defender el plan es lo que lo mueve de "nuevo EM" a "EM con punto de vista."

Los Modos de Fallo del Mundo Real

Tres formas predecibles en que este plan se descarrila.

La atracción del ex-IC hacia el código

Cuando las manos le duelen de no escribir código, eso es abstinencia, no debilidad. Reserve 90 minutos a la semana para "tiempo de ingeniería" (revisión de arquitectura, leer PR sin hacer merge, depurar un problema difícil con un junior) y llámelo así. No lo llame programar. La etiqueta importa porque lo obliga a preguntarse, cada vez, si lo que está a punto de hacer es mentoring u ocultamiento.

La crisis de identidad del "en realidad no soy gerente"

Si todavía dice esto en la semana seis, su equipo ya lo notó. Lo escuchan como "tengo planeado volver a ser IC en cuanto esto se ponga difícil," lo que los hace menos propensos a traerle las cosas difíciles.

Reemplácelo con: "Soy un gerente que antes entregaba código. Ahora entrego personas que entregan código." Dígalo en voz alta la primera vez que se sienta raro. Para la semana diez ya no lo será.

La sobrecorrección

El EM que lee tres libros de gestión en la primera semana y llega el lunes con un nuevo marco de trabajo, un nuevo ritual y un standup renombrado. A los subordinados directos les desagrada esto. No pidieron un nuevo sistema operativo. Pidieron un gerente que escuche.

Escuche primero. Cambie después. La auditoría de 30 días existe exactamente para que no haga esto.

Plantillas y Herramientas que Realmente Usará

Cuatro artefactos que vale la pena construir una vez y reutilizar siempre:

• Guión de preguntas para la primera reunión individual. Las tres preguntas anteriores, más tres de seguimiento: "¿Cómo se ve una gran semana para usted?" "¿A quién del equipo debo asegurarme de dedicarle tiempo extra?" "¿Qué debería saber que nadie me va a decir?"
• Plantilla de registro de observaciones de 30 días. Tres columnas: lo que escuché, lo que vi, lo que no estoy cambiando todavía y por qué. La tercera columna es la disciplina.
• Plantilla de informe de 90 días. Tres diapositivas, estructura anterior, límite estricto de palabras por diapositiva para que no lo rellene.
• Guión de conversación de retroalimentación difícil. Situación, comportamiento, impacto, petición. Imprímalo. Complételo antes de cada reunión individual difícil durante los primeros seis meses.

Cómo Medir el Éxito al Día 90

Sabrá que los 90 días funcionaron si los cinco puntos siguientes son verdad en el último día:

1. Cada subordinado directo ha tenido al menos 6 reuniones individuales con usted y puede decir en qué está trabajando para ellos.
2. La velocidad de entrega del equipo está medida y tiene una tendencia. Aunque la tendencia sea plana, usted sabe exactamente por qué.
3. Un proceso es visiblemente mejor y el equipo le da crédito por ello.
4. Su skip-level puede describir el mayor riesgo de su equipo en una oración porque usted se lo dijo.
5. No ha hecho merge de código en 90 días y el equipo está bien.

Ese último es la prueba real. Los 90 días no son para demostrar que todavía sabe programar. Son para demostrar que puede parar.

Aprenda Más

• Cómo Llevar Reuniones Individuales que Sus Subordinados Esperan
• El Cambio de Hacer a Liderar
• Gestionar a Antiguos Colegas
• Plantilla de Descripción de Cargo: Staff Software Engineer