Conversaciones de Ascenso y Desempeño que los Ingenieros Respetan

Un ingeniero senior en un equipo con el que trabajé renunció la semana siguiente a su evaluación de "supera expectativas." No por la calificación. Porque el expediente de ascenso fue rechazado en la calibración dos días después, y nadie (ni su EM, ni su skip-level) le había advertido que era una situación incierta. Había pasado dieciocho meses escuchando "lo estás haciendo de manera excelente." La historia que le contó a su red de contactos al irse fue simple: mi gerente o no sabía, o sabía y no me dijo. Ambas versiones son malas para la contratación.

Los ciclos semestrales comprimen seis meses de señales no expresadas en una conversación de 45 minutos. Lo que no se escribió no ocurrió. Lo que no se nombró en mayo no puede contar en octubre solo porque lo recordó durante la preparación de la calibración. Este playbook es para los EM que quieren que sus ingenieros salgan de cada evaluación capaces de predecir el resultado por sí mismos, a partir de artefactos que ya están escritos.

Criterios de ascenso como lista de evidencias, no de opiniones

La manera más rápida de perder la confianza de un ingeniero es defender una decisión de ascenso con adjetivos. "Sólido liderazgo técnico." "Gran impacto entre equipos." "Ownership excepcional." Ninguna de esas palabras significa nada para un ingeniero con un expediente rechazado. Quieren el artefacto.

Gestione los ascensos con una rúbrica de cuatro columnas vinculada al trabajo entregado:

Note lo que no está en la rúbrica: percepciones subjetivas, antigüedad por tiempo en el puesto, "se sentía como un Staff engineer en la sala." Así es como se pierde un argumento en la calibración. Las columnas anteriores son cómo se gana.

Cuando se sienta a escribir un expediente, la pregunta deja de ser "¿está Priya lista para Staff?" y pasa a ser "¿tiene Priya tres documentos de diseño adoptados en toda la organización, dos servicios con ownership completo y un trimestre desbloqueando a un mínimo de cinco ingenieros?" Si tiene dos documentos de diseño, todavía no está listo para presentarla. Si tiene cuatro y lideró el comando de incidente en producción de un P0, tiene un caso.

Muestre el nivel con ejemplos con nombre. "En Staff, esperamos trabajo como el RFC de reescritura de pagos de Marco o el framework de retry-budget de Lin." Los niveles genéricos en una wiki no son evidencia. Los expedientes reales que fueron aprobados sí lo son.

El artículo complementario a este es la descripción de cargo de Staff Software Engineer. El lenguaje de alcance, impacto y apalancamiento en su rúbrica de ascenso debe reflejar esa descripción de cargo de manera literal. Si su rúbrica dice "impulsa decisiones de arquitectura" pero su descripción de cargo dice "tiene el ownership del diseño de sistemas de múltiples servicios," sus ingenieros están calibrando contra dos barras distintas.

El plan de visibilidad de 6 meses

La razón por la que la mayoría de los expedientes de ascenso fracasan no es que el ingeniero no haya crecido. Es que nadie sabía que había crecido. Un candidato a Staff que entregó un trabajo excelente en tres tickets internos que nadie fuera del equipo puede nombrar es un candidato a Staff cuyo expediente se hunde en la calibración. La visibilidad es un entregable.

En el mes 1 de cada medio ciclo, siéntese con cada ingeniero que sea candidato a ascenso dentro de los próximos 12 meses y escriba juntos un plan de visibilidad de 6 meses. Cuatro artefactos, firmados y con fecha:

1. Un proyecto de expansión con un patrocinador ejecutivo identificado y una superficie de entrega tangible (más sobre la trampa a continuación).
2. Un artefacto entre equipos: un RFC que consume otro equipo, una integración que otro EM puede nombrar, una migración que cerró un ticket de deuda técnica en dos organizaciones diferentes.
3. Un resultado de mentoring: un junior que es ascendido, un nuevo empleado que se incorpora en 30 días en lugar de 90, un proceso de selección que lideró.
4. Un documento de diseño escrito que supera la revisión y es citado por alguien fuera del equipo inmediato dentro de los 6 meses.

Ese documento va a una carpeta compartida. Ambos lo firman. Ahora no hay ambigüedad sobre qué se juzgará en el próximo ciclo, y el ingeniero puede hacer una autoauditoría en el mes 3 y el mes 5 en lugar de enterarse en la mesa de calibración.

Si entrega los cuatro, el expediente se escribe solo. Si entrega dos de cuatro, sabe en el mes 4 (no el día de la evaluación) que el expediente no está listo, y tiene la oportunidad de corregir el rumbo o aceptar un retraso de 6 meses sin que se sienta como una traición.

La conversación de desempeño difícil: SBI + Petición + Compromiso

La mayoría de los EM usan la técnica del sándwich. Abren con un elogio, entregan la crítica en el medio, cierran con palabras de aliento. Los ingenieros no escuchan el medio. Escuchan "lo está haciendo bien, algunas cosas menores, lo está haciendo bien." Luego se sorprenden en octubre y se lo cuentan a sus amigos.

Deje el sándwich. Use SBI + Petición + Compromiso. Cuatro pasos, sin relleno.

Situación. El momento, lugar y contexto específico. "En la revisión de rediseño del servicio de autenticación el 12 de marzo."

Comportamiento. Lo que la persona hizo, de manera observable. No lo que usted infirió sobre su estado mental. "Declinó responder dos de las cuatro preguntas de los revisores y dijo 'ya lo resolveremos después.'"

Impacto. Lo que le costó al equipo o al trabajo. "Los revisores me escalaron el problema después. Retrasamos el lanzamiento una semana para rehacer el modelo de amenazas."

Petición. Qué quiere diferente, específicamente, la próxima vez. "Cuando un revisor marque una pregunta de seguridad en un documento de diseño, necesito que la responda en el documento dentro de las 48 horas, aunque la respuesta sea 'lo diferiremos y aquí está el motivo.'"

Compromiso. Una fecha y un punto de control. "Revisemos esto en nuestra reunión individual del 9 de abril y veamos cómo fueron las próximas dos revisiones de diseño."

Dos guiones de ejemplo que puede usar directamente:

Revisiones de código que bloquean al equipo. "En el sprint 23, tres de sus revisiones de código tardaron más de 4 días en completarse. Una de ellas bloqueó el lanzamiento del rediseño de checkout por un sprint completo. El equipo está comenzando a trabajar sin contar con usted, lo que significa que está perdiendo contexto sobre el código. Necesito que entregue las revisiones en 24 horas o las reasigne a alguien que pueda. Hagamos un seguimiento en nuestra reunión individual del 15."

Los documentos de diseño carecen de rigor. "Sus últimos dos documentos de diseño (la migración de cola y la reescritura del limitador de velocidad) no tenían sección de modos de fallo ni plan de rollback. El comité de revisión de arquitectura devolvió ambos para una segunda revisión, lo que le costó dos semanas en cada caso. En el nivel Staff, los documentos de diseño deben ser aprobados en la primera revisión al menos el 70% de las veces. Quiero que el próximo documento que redacte incluya una tabla de modos de fallo y una sección de rollback antes de enviarlo al ARC. Revisaremos el próximo documento juntos antes de enviarlo el día 22."

Note lo que falta. No hay "pero por lo demás ha estado haciendo un excelente trabajo." Esa frase es para su comodidad, no para la de ellos. Guárdela para el final de la reunión si la necesita, después del compromiso.

Señales de PIP: cuándo empezar, cuándo omitirlo

Un plan de mejora del desempeño es una herramienta, no un castigo. El mayor error que cometen los EM es iniciarlo demasiado tarde, lo que suele deberse a que estuvieron usando el sándwich durante seis meses. El segundo mayor error es iniciarlo cuando el problema real es de compatibilidad, no de desempeño.

Inicie un PIP cuando los tres puntos sean verdad:

1. El comportamiento ha sido nombrado al ingeniero por escrito (en notas de reuniones individuales que puede releer).
2. El comportamiento se ha repetido en al menos dos ciclos o dos meses.
3. El comportamiento no ha cambiado después de al menos dos notas escritas de reunión individual que lo señalen y al menos una conversación SBI.

Si no puede mostrar los tres puntos desde su historial de reuniones individuales, no tiene un caso para el PIP. Tiene un problema de retroalimentación, y el PIP será cuestionado por HR y sus pares EM en la calibración.

Omita el PIP cuando sea un problema de compatibilidad, no de desempeño.

Un "problema de compatibilidad" se ve así: el ingeniero está técnicamente bien, entrega su trabajo, pero hay una incompatibilidad con el dominio del equipo (una persona muy orientada a infraestructura en un equipo de producto, una persona muy orientada a producto en un equipo de plataforma) o con la etapa de la empresa (le gustan los entornos ágiles de 10 personas, fue contratado cuando la empresa tiene 800). El ingeniero no está fallando. El puesto es incorrecto.

Forzar un PIP en un problema de compatibilidad genera una salida enojada. El ingeniero disputa, gana técnicamente, se va de todas formas y le dice a todos que intentó gestionarlo de manera injusta. Costo: 6 meses de moral del equipo y su reputación en el mercado en general.

Ofrezca una transición gestionada en su lugar. Directa, amable, con fecha. "Creo que encajarías mejor en el equipo de plataforma. Hablé con María y tiene una vacante. Me gustaría apoyarte en la transición durante las próximas 4 semanas. Si prefiere buscar fuera, puedo darle 6 semanas de margen y una referencia sólida." Los ingenieros respetan esto. Sus amigos respetan esto. Su proceso de contratación se beneficia.

El árbol de decisión para el PIP, simplificado:

Un PIP bien gestionado se resuelve en 60 días, ya sea con una mejora real o con una salida limpia. Si el suyo se prolonga hasta el mes 4, está gestionando su propia incomodidad, no el desempeño del ingeniero.

Calibración de ascensos con pares EM

La calibración es la reunión donde en realidad se toman las decisiones de ascenso. El expediente que escribió es el ticket de entrada. Los 90 minutos en una sala con 4 a 6 pares EM y su director son donde las dinámicas de defensor y detractor deciden el resultado.

Lleve una lectura previa de una página. Dos días antes de la calibración, envíe a sus pares EM una sola página por candidato:

• Nombre, nivel actual, nivel objetivo
• Los 3 principales artefactos (con enlaces al documento de diseño, RFC, retro de incidente en producción)
• Evidencia de alcance, impacto y apalancamiento en tres bullets breves cada uno
• Un párrafo sobre el contraargumento más sólido y su respuesta al mismo

Ese último punto es lo que separa a un EM que sale de la reunión con su ingeniero ascendido de uno que no lo logra. Anticipar el argumento del detractor en la lectura previa significa que el cuestionamiento en la sala es algo que ya ha abordado por escrito. Si no lo anticipa, su par que está en contra tiene la oportunidad de plantearlo primero.

Defienda un caso límite sin sobrevenderlo. Caso límite significa que el ingeniero está al nivel en dos de las tres dimensiones y se acerca en la tercera. No diga "definitivamente es Staff." Diga "está al nivel en alcance y apalancamiento, acercándose en impacto, y aquí está el trabajo en curso que cierra la brecha para el Q3." Ese es el tipo de lenguaje que supera el escrutinio de un director. Sobrevender un caso límite arruina su credibilidad para los próximos dos ciclos.

Cuando un par EM bloquea a su ingeniero para proteger al suyo propio (ocurre, especialmente cuando las calificaciones son comparativas o el presupuesto es limitado), no lo dispute en la sala. Perderá y deteriorará la relación. En cambio, trátelo de manera privada. "Quiero asegurarme de entender su preocupación sobre el nivel de los documentos de diseño de Priya. ¿Podemos revisar sus tres RFC juntos esta semana?" En nueve de cada diez casos, la resistencia se disuelve cuando saca la conversación del escenario de la calibración.

La trampa del "proyecto de expansión"

La mitad de los expedientes de ascenso fallidos que he visto fueron rechazados por un proyecto de expansión que nunca iba a entregar trabajo visible. El patrón siempre es el mismo. El EM asigna un proyecto de expansión que suena excelente sobre el papel. El ingeniero pasa 4 meses en él. El proyecto pierde prioridad, se reduce en alcance, o el patrocinador ejecutivo cambia de equipo. El ingeniero no entrega nada visible externamente. En la calibración, se pregunta "¿qué hizo Priya este semestre?" y el EM no tiene nada a qué apuntar.

Valide el alcance de expansión antes de asignarlo. Tres verificaciones, todas obligatorias:

1. Presupuesto real. Hay una partida presupuestaria o una asignación de plantilla, no un "ya lo resolveremos después." Si finanzas no puede nombrarlo, no existe.
2. Patrocinador ejecutivo identificado. Un Director o VP específico que ha dicho, por escrito o en una reunión grabada, "esto es una de mis 3 prioridades del semestre." No un CC en un correo de lanzamiento. Una declaración.
3. Superficie de entrega tangible. Un usuario, cliente o equipo interno que usará el resultado y puede confirmar que llegó. Si las únicas personas que lo verán son los compañeros de equipo del propio ingeniero, es un proyecto normal, no un proyecto de expansión.

Si alguno de los tres falta, el proyecto es una trampa profesional. Resista, aunque el ingeniero esté entusiasmado. "Me encanta esta idea. Antes de asignarla como su proyecto de expansión, necesito saber quién es el patrocinador ejecutivo y qué usuario lo usará. Sin esas dos cosas, invertirá 4 meses en algo que no ayudará a su expediente." Los buenos ingenieros le agradecen esto en el mes 5. Los excelentes, en el mes 1.

Cadencia del documento de crecimiento escrito

Un documento. El mismo documento. Existe durante toda la permanencia del ingeniero en su equipo. No tres documentos separados en tres lugares diferentes.

Tres cadencias lo alimentan:

La actualización mensual de bullets es la que más se subestima. Cinco minutos. El ingeniero escribe lo que entregó, lo que lo bloqueó, lo que aprendió y lo que le solicita a usted. Usted lo lee antes de la próxima reunión individual y responde por escrito. Seis meses después, cuando empieza la preparación de la calibración, tiene 6 meses de bullets que se comprimen en el expediente formal sin ningún esfuerzo heroico de memoria.

La regla principal: el ingeniero puede leer su propia trayectoria en cualquier momento. Si su ingeniero pregunta "¿en qué punto estoy?", la respuesta es "abra el documento, desplácese hasta la última revisión trimestral, puede ver exactamente dónde se encuentra." Sin sorpresas. Sin "programemos un tiempo para conversarlo." El documento es la respuesta.

Así es también como se recupera cuando un ingeniero cambia de equipo o usted deja la empresa. El próximo EM hereda un documento real. No un historial de DMs en Slack.

Errores comunes que evitar

• Guardar la retroalimentación real para el día de la evaluación. Si su ingeniero la escucha por primera vez en octubre, usted falló en mayo.
• Promover basándose en potencial en lugar de evidencia. El potencial es lo que apuesta al contratar, no al ascender. El ascenso se basa en artefactos entregados.
• Lenguaje vago que el ingeniero interpreta como "sin problema." "Me gustaría ver un poco más de cuidado en sus documentos de diseño" no es retroalimentación. Es una insinuación que se ignora. Use SBI.
• Calibrar sin artefactos en la sala. Si no puede enlazar el documento de diseño, no tiene argumento.
• Confundir horas trabajadas con impacto entregado. Un ingeniero que trabaja 60 horas y entregó dos funcionalidades no supera a uno que trabaja 40 horas y entregó cuatro.

Cómo Medir el Éxito

Sabrá que este playbook está funcionando cuando:

• Ningún ingeniero se sorprende por su calificación el día de la evaluación, porque ha estado leyendo el mismo documento de crecimiento que usted.
• Los expedientes de ascenso son aprobados en la primera ronda de calibración el 70% de las veces, porque dejó de presentar casos límite como apuestas arriesgadas.
• Los PIP se resuelven en 60 días (ya sea con una mejora real o una transición limpia) en lugar de prolongarse hasta el mes 6 y deteriorar el ambiente del equipo.
• Los ingenieros pueden citar de memoria sus propios criterios para el siguiente nivel, porque usted escribió la rúbrica y la revisó con un artefacto real.

El nivel es simple. El ingeniero con un expediente rechazado debe poder señalar los criterios, señalar su trabajo y estar de acuerdo con la brecha. Si no puede, el fallo fue suyo, no de ellos.

Aprenda Más

• Descripción de Cargo: Staff Software Engineer
• Cómo Llevar Reuniones Individuales con Ingenieros que Mueven las Cosas
• Cómo Contratar Ingenieros Senior que se Queden
• Reuniones Skip-Level que Realmente Revelan la Verdad