La conversación más difícil: gestionar a alguien que rinde por debajo
Un Tech Lead tiene a un ingeniero senior que hace seis meses cerraba tickets complejos sin supervisión. Ahora entrega tarde, con bugs que antes no cometía, y evita las reuniones de diseño donde antes era la voz que ordenaba el caos. El calendario de performance review cierra en dos semanas. El Tech Lead tiene que escribir algo. Y antes de escribirlo, tiene que decidir qué conversación va a tener.
La tentación es obvia: sentarlo, mostrarle los datos, pedirle que mejore. Es lo que el proceso de RRHH espera. Es lo que el manager del Tech Lead le va a preguntar. Es lo defendible.
Y es, casi siempre, la conversación equivocada.
Dos formas de entrar a la misma sala
La primera forma la conoces bien porque es la que el sistema premia. Se llama gestión del rendimiento y funciona así: defines el estándar, mides la brecha, comunicas la brecha, acuerdas un plan de mejora con fechas. Es limpia. Es auditable. Si el ingeniero no mejora, tienes el papel que justifica la decisión difícil que viene después. Kim Scott, en Radical Candor, documenta por qué los managers evitan esta conversación durante meses — pero cuando por fin la tienen, la tienen así: como un expediente.
La segunda forma parte de una sospecha incómoda. Que el número que mides —tickets tarde, bugs, ausencias— no es el problema. Es el síntoma. Y que si tratas el síntoma como si fuera la causa, vas a diseñar una intervención perfecta para un problema que el ingeniero no tiene.
Ambas formas funcionan en algún caso. Ahí está la trampa.
La gestión por brecha funciona cuando el bajo rendimiento tiene una causa que el propio ingeniero conoce y puede corregir con un empujón y expectativas claras. La gestión por diagnóstico funciona cuando la causa está fuera de su control o fuera de su conciencia. Elegir mal no es un error de estilo. Si aplicas gestión por brecha a alguien cuyo rendimiento cayó porque su hija está en el hospital, no obtienes mejora: obtienes a alguien que ahora sabe que a nadie le importa por qué. Y lo pierdes.
Entonces la decisión real no es cómo tener la conversación. Es qué conversación tener. Y eso no lo puedes saber antes de entrar.
El número miente sobre su propia causa
Richard Rumelt tiene una frase que debería colgar en la pared de todo Tech Lead: cuando un líder define el desafío como "bajo rendimiento", ya empezó con mala estrategia. El bajo rendimiento es un resultado. El desafío real son las razones del resultado. Y las razones no están en tu cabeza.
Aquí es donde la mayoría de los protocolos de gestión fallan. Asumen que el manager tiene la información para diagnosticar. No la tiene. El conocimiento de por qué alguien rinde por debajo está distribuido: parte en la cabeza del ingeniero, parte en su vida fuera del trabajo, parte en las condiciones del sistema en el que trabaja —el código, el equipo, las dependencias que nadie te reporta. Tu trabajo no es diagnosticar desde arriba. Es diseñar una conversación que haga aflorar el conocimiento que tú no tienes.
Para eso necesitas una hipótesis de trabajo. No una respuesta — una lente que ordene lo que vas a escuchar. Tres causas posibles, y cada una exige una conversación distinta.
La primera es habilidad. El ingeniero quiere hacer el trabajo, entiende que se espera de él, pero le falta capacidad para el trabajo que tiene delante ahora. Ocurre más de lo que parece cuando el sistema evoluciona bajo los pies de alguien: el senior que dominaba el monolito de repente tiene que razonar sobre consistencia eventual en un sistema distribuido, y nadie le dio el tiempo ni el andamiaje para hacer esa transición. Su rendimiento cae. No porque no quiera. Porque el trabajo cambió y él no.
La segunda es voluntad. La capacidad está intacta. Lo que cambió es la valoración interna del ingeniero sobre el trabajo. Y aquí viene lo que casi todos los sistemas de gestión se niegan a aceptar: las personas no actúan según las categorías de tu tabla de talento. Actúan según lo que valoran, y lo que valoran es subjetivo y se mueve. El ingeniero que hace seis meses cerraba tickets complejos quizás descubrió que llevaba dos años pidiendo trabajar en la parte de arquitectura y nunca pasó nada. La capacidad no se fue. Se fue la razón para usarla.
La tercera es contexto. Ni habilidad ni voluntad. Algo en el entorno hace imposible el rendimiento que antes era posible. Una dependencia con otro equipo que bloquea la mitad de sus tareas. Un cambio en casa que consume el ancho de banda que antes dedicaba al trabajo. Un compañero con el que el conflicto silencioso hace tóxica cada reunión de diseño —y por eso las evita.
Fíjate en algo. Los tres producen exactamente el mismo número. Tickets tarde, bugs, ausencias. El síntoma es idéntico. La causa, opuesta. Y no hay dato en tu dashboard que las distinga.
Por qué no puedes diagnosticar antes de entrar
La pregunta natural aquí es: ¿cómo sé cuál de las tres es antes de la conversación? La respuesta incómoda es que no puedes. Y que intentarlo es el error.
Si entras habiendo decidido que es voluntad —"se ha desconectado, hay que motivarlo"— vas a interpretar cada cosa que diga como confirmación. El sesgo de confirmación no es un defecto de carácter. Es cómo funciona la atención cuando ya tienes una conclusión. Vas a oír excusas donde hay causas reales.
Douglas Stone y sus coautores, en Difficult Conversations, describen esto con precisión quirúrgica: toda conversación difícil contiene en realidad tres conversaciones simultáneas. La del "qué pasó" —los hechos, quién hizo qué. La de las emociones —cómo se ha sentido tratado cada uno. Y la de la identidad —qué dice esta situación sobre quién soy yo. El manager que entra con el expediente solo juega la primera. Y la primera, sola, casi nunca contiene la causa.
Porque la causa —habilidad, voluntad o contexto— casi siempre vive en las otras dos. La caída de habilidad duele en la identidad: "creía que era bueno en esto y ya no lo soy". La caída de voluntad vive en la emoción: "estoy resentido y no lo he dicho". La caída por contexto vive en lo que el ingeniero no cuenta porque no cree que sea asunto tuyo. Si tu conversación solo tiene espacio para hechos, las tres causas se te quedan fuera de la sala.
Entonces la conversación no es el momento de comunicar tu diagnóstico. Es el instrumento con el que lo construyes. Cambia todo sobre cómo entras.
La conversación que hace aflorar la causa
Marshall Rosenberg, en Nonviolent Communication, separa dos cosas que casi todo manager mezcla: la observación y la evaluación. "Has entregado tarde las últimas tres tareas" es observación. "Te has desconectado del equipo" es evaluación. La primera invita a explicar. La segunda invita a defenderse. Y alguien que se defiende no te da información — te da coartadas.
Abre por la observación, sin la evaluación pegada detrás. "En los últimos dos meses he visto tres entregas que llegaron después de la fecha, y en la última reunión de diseño no estuviste. Hace seis meses eso no pasaba. Quiero entender qué cambió." No hay acusación. No hay diagnóstico. Hay un hecho y una pregunta genuina. Y el silencio que dejas después es la parte más importante de la conversación, porque es donde el ingeniero decide si esto es un juicio o una investigación conjunta.
Lo que digas después depende enteramente de lo que oigas. Y lo que oigas rara vez llega en palabras limpias.
Aquí importa algo que los protocolos de conversación ignoran: gran parte de la causa se filtra por canales que no son verbales. Joe Navarro, que pasó décadas leyendo comportamiento no verbal en el FBI y lo condensó en What Every Body Is Saying, describe cómo el cuerpo revela incomodidad, bloqueo o ocultamiento antes de que la persona lo formule. No para que juegues a detective —eso es una forma peor del mismo error de diagnosticar desde fuera. Sino para que sepas dónde falta información. Si al mencionar la reunión de diseño el ingeniero se cierra físicamente, ahí hay algo que las palabras no están diciendo. No es prueba de nada. Es una señal de dónde preguntar más despacio.
¿Cómo distingues entonces las tres causas dentro de la conversación?
Si es habilidad, lo vas a oír como un intento de justificar la dificultad técnica que suena a excusa pero no lo es. "El sistema nuevo es distinto", "no acabo de ver cómo encajar esto". La tentación es leerlo como desmotivación. La pregunta que lo revela es concreta: "¿Qué necesitarías para que esto dejara de costarte lo que te está costando?". Si la respuesta es aprendizaje, tiempo, un compañero de par —es habilidad. Y la conversación se convierte en un plan de crecimiento, no en un expediente.
Si es voluntad, la señal es distinta. La capacidad se nota intacta en cómo habla del problema —lo entiende perfectamente— pero hay una distancia, una desinversión. La pregunta que lo abre no es sobre el trabajo. Es sobre lo que quiere: "¿Dónde querrías estar dentro de un año, y cuánto de lo que haces hoy te acerca ahí?". Si la brecha entre lo que valora y lo que hace es grande, encontraste la causa. Y ninguna gestión por fechas la arregla. Solo se arregla renegociando qué hace y por qué.
Si es contexto, lo más probable es que no llegue solo. Que tengas que crear seguridad suficiente para que aparezca. Aquí es donde Crucial Conversations pone el dedo: cuando alguien percibe que la conversación es peligrosa para él, se retira o ataca, y en ambos casos deja de fluir la información. Tu trabajo es hacer segura la sala. "Nada de lo que me digas aquí va contra ti. Estoy tratando de entender, no de construir un caso." Si la causa es una dependencia bloqueada, un conflicto con un compañero, algo en casa —solo sale si el ingeniero cree que sale sin costo.
La kindness que Fournier defiende no es blandura
Hay un contraargumento válido que merece respuesta. Todo este diagnóstico cuidadoso, ¿no es una forma elaborada de evitar la conversación dura? ¿De ser blando cuando el trabajo exige firmeza?
No. Camille Fournier lo formula mejor que nadie en The Manager's Path: es amable decirle a alguien que no está listo, y respaldarlo con el trabajo que necesita hacer para estarlo. Es cruel darle largas, dejar que crea que va bien, y verlo fallar. La amabilidad no es evitar el mensaje duro. Es asegurarte de que el mensaje duro sea el correcto antes de darlo.
El manager que aplica el expediente sin diagnosticar cree que está siendo firme. En realidad está siendo perezoso. Está usando el proceso para no hacer el trabajo difícil de entender. Y si diagnostica mal —si trata como voluntad lo que era contexto— no solo pierde al ingeniero. Enseña a todo el equipo que aquí no importa por qué fallas, solo que fallaste. Eso no genera rendimiento. Genera gente que oculta sus problemas hasta que explotan.
Lo que esto generaliza
El principio va más allá de la conversación de bajo rendimiento. Aplica a cada momento en que un Tech Lead ve un resultado que no le gusta y siente la urgencia de corregirlo: un equipo que no cumple estimaciones, una arquitectura que la gente esquiva, un proceso que nadie sigue.
El resultado que ves nunca es la causa. Es el número al final de una cadena de valoraciones subjetivas, condiciones y capacidades que viven distribuidas entre las personas del sistema —y ninguna de ellas está en tu dashboard. Tu tarea antes de intervenir no es decidir la solución. Es diseñar la conversación —o la observación, o el experimento— que haga aflorar la causa que no puedes ver desde tu silla. La intervención correcta es la que llega después del diagnóstico. Nunca antes.
Para la conversación en sí, esta semana preparé un recurso descargable: la guía de diagnóstico de las tres causas, con las preguntas que abren cada una y las señales que las distinguen dentro de la conversación. Está abierto para suscriptores. Si tienes esa conversación pendiente —y si estás leyendo esto, probablemente la tienes— empieza por ahí antes de escribir una sola línea del review.
Cada semana analizo un problema real de liderazgo técnico. Con el mismo nivel de profundidad.