Tiempo medio de primera respuesta a tickets: 40 minutos. El objetivo era de menos de 1 hora. Check.

El lunes un cliente te escribe. Furioso. Buscas su ticket con la mosca detrás de la oreja y ahí está, respondido en 10 minutos, dentro de plazo. Piensas…

—¿Cuál es el problema? La gente se queja de todo.

Abres la respuesta.

“Hemos recibido su solicitud y estamos trabajando en ella.”

Eso fue todo. La métrica contó el ticket como respondido.

Pero el problema del cliente siguió exactamente donde estaba.

Nadie lo ocultó. Nadie falseó el dato.

El que escribió esa respuesta se dio cuenta de que “responder” y “resolver” son dos cosas distintas, y de que tú solo mides una. A partir de ahí empezó a hacer lo “razonable” cuando no llegaba a todo.

No hace falta que nadie mienta para que tus números te cuenten una bonita película.

Vamos a explorar cómo detectar estos casos, por si ya te están pasando, y qué hacer diferente para que no te pasen.

Pero antes, igual piensas que mi ejemplo es muy simplista, así que te explico un caso real documentado.

El hospital que no mintió

En el sistema público de salud inglés pusieron un objetivo de mejora, algo razonable:

Atender a los pacientes en menos de cuatro horas.

Difícil de discutir. Cualquiera que haya pasado una noche esperando en un hospital lo firmaría sin leer la letra pequeña.

El hospital no tuvo más remedio que aceptar el objetivo.

Lo que pasó después era una escena curiosa.

Si te paseabas por las afueras del hospital, veías colas de ambulancias en el aparcamiento. Ambulancias con el paciente que llevaban al hospital dentro, esperando.

El hospital no aceptaba pacientes de ambulancias hasta estar razonablemente seguro de poder atender en plazo al que llevaban dentro, porque el reloj empezaba a contar justo cuando el paciente cruzaba la puerta del hospital.

El dato que reportaba el hospital era verdad. Rigurosamente cierto. El paciente que seguía en la ambulancia no estaba esperando en urgencias. Nadie mintió en el número, ni en la reunión donde se presentaba, ni en el informe que llegaba a la central en Londres.

Y no fue lo único

Esto lo estudiaron Gwyn Bevan y Christopher Hood en 20061. Lo que impresiona al leerlo no es el caso de la ambulancia. Es la cantidad de variantes de lo mismo, todas en el mismo sistema y en pocos años:

• Camillas convertidas en camas. Había un objetivo que prohibía tener a un paciente más de doce horas en camilla antes de darle cama. La adaptación fue meter las camillas en los pasillos y promocionarlas oficialmente a “camas”.

• El pico de los ocho minutos. Otro objetivo era que las ambulancias debían llegar al 75% de las emergencias graves en menos de ocho minutos. Al revisar los tiempos, en un tercio de los servicios se amontonaban justo en los ocho minutos. ¿Casualidad? En un reparto normal esa curva cae poco a poco, no hace una montaña clavada en el límite: los tiempos de entre ocho y nueve habían pasado a ser ocho.

• Bases de ambulancias que se mudaban de zona. Este te va a gustar por su elegancia. Movieron las bases desde las que salían las ambulancias de zonas rurales a zonas urbanas. El porcentaje global mejoró porque las zonas más pobladas (con más población) estuvieron mejor atendidas, pero nadie midió que las zonas rurales empeoraron significativamente porque ese dato no salia en la media.

Quizá eran unas pocas manzanas podridas

Los autores calcularon que esto lo hacía entre un 7% y un 33% de los centros. No eran “unos pocos”: una parte grande del sistema nacional de hospitales se comportaba de forma “razonable” dadas las reglas que le imponían.

Y claro, como estamos hablando de salud, eso tuvo consecuencias.

Un hospital grande tenía que cumplir el tiempo de espera para primeras consultas de oftalmología. La forma de cumplirlo fue cancelar y retrasar las consultas de revisión, que no estaban medidas en el objetivo. 25 pacientes perdieron la visión en dos años.

Cuando se empezaron a publicar los datos de mortalidad por cirujano (transparencia), algunos cirujanos se volvieron reticentes a operar a los pacientes de mayor riesgo para que no empeoraran sus estadísticas. Justamente los pacientes que más necesitaban una operación.

La gente puentea los objetivos que no siente suyos o que pueden ir en su contra. No es una intuición de gurú, está estudiado2.

¿Quieres saber si te está pasando? 4 tests

Ve a mirar tus objetivos (OKRs o lo que sea).

1. El test de la mala fe.

Juega a cómo timarías tu propio objetivo. Dedícale treinta segundos con toda la mala fe de la que seas capaz a esta pregunta:

¿Cómo cumpliría yo este número sin cumplir el objetivo que se supone que busca?

Si a ti se te ocurre una manera en treinta segundos, a quien lo tiene delante ocho horas al día se le van a ocurrir unas cuantas más. Escríbelas. Esa lista no dice que el objetivo sea malo ni que tu equipo esté intentando timar tu métrica, pero te avisa de maneras en las que las cosas podrían salir mal.

2. Piensa en las cosas que no están en el objetivo y que podrían sufrir.

Cada objetivo pone foco en una cosa y olvida el resto.

Si estoy pidiendo un 200% de esfuerzo en nuevos clientes... ¿Qué pasa con los actuales?

Los sospechosos habituales suelen sufrir: la calidad, la salud, otras áreas...

3. Mira la forma de los datos, no solo la media.

La media es la gran mentira de la estadística. Solo cuenta una historia parcial. Igual la media de facturación por cliente sube, pero quizá el cliente que supone un 50% del total está más descontento que nunca.

Y busca los cortes abruptos, que son la firma de que alguien está jugando: casos amontonados justo por debajo del umbral que marca el objetivo y casi ninguno por encima. Es el pico de los ocho minutos de las ambulancias. Si tu umbral es de 24 horas y casi todo se cierra a las 23, míralo bien que igual no es azar.

4. Haz la pregunta que lo destapa

Coge la métrica del objetivo que vaya mejor y pregunta:

¿Qué hemos dejado de hacer para que esto esté tan bien?

Prepárate, porque si las respuestas no te gustan, casi todo lo que escuches es responsabilidad tuya.

Entonces... ¿Cómo hago para poner objetivos sin fastidiarlo todo?

Ah... la madre del cordero.

Yo empezaría por esto:

¿El grupo que lo va a hacer lo ve alcanzable?

Que digan que no, no lo estropea todo: ir a la luna tampoco parecía posible y hubo gente dispuesta a dejarse la piel e intentarlo.

Pero si lo ven imposible y, además, no tienen ganas de intentarlo… mejor cambia el objetivo3. Descubre a qué sí está dispuesto ese grupo (no lo descubrirás nunca si no estás dispuesto a escuchar cosas que no te gusten sin que haya represalias ni caras raras por tu parte).

¿Hay una recompensa ligada a pasar una frontera?

Si cruzar el umbral cambia un bonus, una evaluación o una reputación, ese umbral va a ser un terreno de juego. Nos alargaríamos mucho hablando de esto, pero te iría mejor ligar esa recompensa a algo que suba de manera continua, no discreta. A mayor consecución del objetivo, mayor recompensa es menos propenso a ser trucado. Si alguien consigue un 67% y la recompensa es cuando pasa la frontera del 70%, o trucará la medición o pensará que es injusto no recibirla por un 67%. En los dos casos pierdes. Mejor dale un 67% de la recompensa4.

El truco está en cómo planteas el objetivo

Cambia las instrucciones que das con el objetivo5.

No digas:

Este trimestre el objetivo es arreglar todos los bugs en menos de 24h

Di:

El objetivo del trimestre es que cada vez que nos reporten un bug, que el que lo reporte sienta que alguien se está haciendo cargo de él y que estamos trabajando rápido y fuerte para resolverlo. Vamos a medirlo a partir del tiempo de resolución, que sé que es una métrica imperfecta. Si en algún momento vemos que no es la forma adecuada porque se pierde el objetivo prefiero que hablemos del caso concreto para mejorar cómo lo medimos o entender la excepción, pero no perdamos de vista el propósito original.

Si lo quieres en formato plantilla, ahí va:

Lo que quiero conseguir es [propósito]. Lo vamos a medir con [métrica X], que no es perfecta [explica dónde crees que se puede quedar corta X (si lo intuyes)]. Cuando X y el propósito choquen, gana el propósito, y prefiero que hablemos de cómo ha fallado X en ese caso.

Con el objetivo que pongas va a jugar mucha gente: tú, tu jefe, tu equipo, algunos stakeholders, a veces otros equipos (si es compartido) y tus clientes.

Y ya te digo que tu objetivo no va a ser perfecto (ninguno lo es). El truco es entender que no lo es, y que tu equipo (y el resto, si puede ser) entienda tu intención, el propósito, y que la medición no deja de ser una manera imperfecta de acercarse a saber cómo de cerca estamos de él.

Una última cosa. El ejemplo de los pacientes en las ambulancias es uno de mis ejemplos favoritos de métrica que se corrompió al convertirse en objetivo, y seguro que tú conoces otro, de tu sector (o histórico). Cuéntamelo, que los colecciono.

Nos leemos

P.D. La encuesta sobre el estado del management sigue abierta. Ya hay respuestas que no me esperaba. Si la respondes, puedes ver los datos agrupados al final. Son cinco minutos y es anónima. Puedes responder tanto si eres manager como si no.

Cada vez que hablo de estudios y números sobre el trabajo del manager, lo que encuentro está medido en el mundo anglosajón.

En español no tenemos casi nada, y eso tiene una consecuencia para ti.

Si te preguntas si a estas alturas ya deberías estar en otra situación, o si dedicar media semana a reuniones es mucho o poco, no hay ninguna cifra con la que compararte ni un “normal” contra el que medirte.

Sólo anécdotas.

Todos tocamos de oído en la comunidad del management en español

Así que vamos a medirlo aquí. Tú y yo.

He preparado una encuesta de cinco minutos para recopilar esos datos

Y incluye algo para ti.

En cuanto la envías, verás el resumen de lo que han respondido los demás, así que sales sabiendo dónde estás tú.

Responde la encuesta anónima (y descubre dónde estás respecto al resto).

¿Y si no soy manager?

Si no eres manager pero tienes uno, hay una versión para ti.

La parte que más me interesa del informe es la distancia entre cómo se ve un manager y cómo lo ve la gente que trabaja con él.

Responde la encuesta anónima (y descubre cómo ven el resto a su manager).

Lo que salga de todo esto se publica entero aquí, con su margen de error y sus límites. Solo resultados agregados.

Dejemos de tocar de oído.

Nos leemos

Ya te has dado cuenta de que la reunión de los martes no sirve para nada. Un proceso tiene varios pasos manuales que en tu empresa anterior estaban automatizados desde hace años. Hay una hoja de cálculo que alguien actualiza a mano cada viernes y que no mira nadie. Y el equipo de al lado te pide las cosas por tres canales distintos.

Sabes arreglar todo eso. Lo has hecho antes.

Pero... ¿es mejor hacerlo o es una trampa?

Cuando cambias de sitio no llegas vacío. Llegas con un manual debajo del brazo. Uno que has ido construyendo con toda tu experiencia anterior, particularmente en tu último trabajo.

El problema es que es difícil recordar que mucho de lo que está escrito en ese manual es contextual. Una parte te servirá y otra solo era válida en tu antiguo contexto. No es fácil saber qué parte es cada una.

Y cuanta más experiencia tengas, más fuerte y convincente es la señal que te envía tu cerebro de que eso ya lo has visto y sabes la solución, y más difícil es no hacerle caso.

Fred Brooks le puso nombre a esto en 1975, hablando de arquitectos de software: The second system effect. Te llevas las lecciones aprendidas de tu primer sistema al segundo y acabas con un sistema más complicado porque en el nuevo contexto mucho no se aplica.

Brooks hablaba de software y no de cambiar de trabajo, así que tómalo como una imagen y no como una ley.

¿Qué funciona si son tus primeras semanas?

Algo aburrido: observar y esperar.

Y eso es horrible, porque te han fichado para hacer algo, y quieres demostrar por qué te pusieron ahí, y quedarte quieto se parece mucho a “no estoy aportando”.

No tengo una solución elegante para esa incomodidad. Solo la constatación de que las veces que la he ignorado me ha salido caro.

¿Qué puedes hacer en ese tiempo?

Apunta en lugar de arreglar

Abre una lista con las cosas que no entiendes y las que cambiarías. Junto a cada una, trata de averiguar por qué en esta organización se hace así.

¿Qué problema trataba de resolver esto el día que se puso?

¿Cómo es que ha sobrevivido todo este tiempo?

Sé curioso, pregunta. Casi siempre hay una respuesta, y casi nunca es “ah, es que aquí somos tontos”.

Pregunta en todas direcciones

Ve teniendo conversaciones con cada persona de tu equipo. Pregunta sobre esas cosas de la lista, y añade alguna que te permita descubrir lo que no sabes que no sabes:

¿Qué funciona bien aquí que más vale que yo no toque?

Sal también de tu equipo. Entérate de qué esperan de él los stakeholders, los clientes y los otros equipos con los que hay fricción cada semana. ¿Se están cumpliendo esas expectativas? Ahí descubres la reputación que has heredado, que existe la mires o no.

“Ya, José Carlos, pero a mí me han fichado para cambiar cosas”

Ya... puedo oír tu objeción desde lejos. Voy a ello.

Hay situaciones donde observar cuatro semanas es exactamente lo peor que puedes hacer:

• Si algo está sangrando

• Si hay una persona haciendo daño al resto

• Si te han contratado con un mandato explícito y un plazo

• O si el equipo lleva meses esperando que alguien decida algo

Es el momento de actuar rápido. Arregla eso que quema y luego vuelve a lo aburrido: observa.

Y que quede claro que nada de esto va de quedarse quieto ni de parálisis por análisis.

Va de que tengas cuidado y no apliques en el contexto nuevo lo que funcionaba en el viejo.

Y hay una manera de saber si tu caso es el de observar primero o el de actuar ya.

Pregúntaselo a la persona que te puso ahí.

En serio, habla con tu jefe. ¿Qué espera de ti? ¿En cuánto tiempo? ¿Cómo va a saber si vas bien? ¿Cuánto margen tienes antes de que espere ver movimiento?

De todas las conversaciones de estas semanas, esa es la que más suele costar y la más rentable de todas.

Ya lo habrás notado: aquí no hay nada sorprendente. Una lista de preguntas y unas cuantas conversaciones. Eso es todo lo que tengo, y es exactamente lo que haría en los primeros compases si fuese “el nuevo”.

Nos leemos

P.D.: En el mini-curso gratuito de los primeros 90 días le dedico el día 3 entero a esa conversación con tu jefe. Ahí tienes el guion completo: cómo plantear la conversación y cómo salir de ella con algo útil y concreto.

Alguien de tu equipo está desmotivado y te empieza a contar. Pero… NO PASA NADA… porque tú ya tienes una lista de opciones para resolver que van desde cambiarlo de equipo hasta plantearle un reto nuevo. Y… se lo explicas.

Has entrado en el mundo preferido de quienes tenemos un background técnico: EL MUNDO DE LAS SOLUCIONES.

Por qué pasa

Casi todos los managers técnicos venimos de un sitio donde el trabajo era ese: ver un problema, entenderlo, resolverlo. Años haciéndolo. Y muchas veces esa habilidad es por la que te ascienden a manager.

El problema es que cuando entras en el mundo del management has cambiado un tipo de complejidad por otra. Y mucho de lo que sabías ya no se aplica.

Llevas años afilando una herramienta, y el primer día de manager esa herramienta se convierte en el problema.

Yo lo llamo el martillo de oro. Cuando solo tienes un martillo, todo parece un clavo. Y el tuyo no es uno cualquiera: lleva años puliéndose, es de oro.

El dicho no es enteramente mío. Yo sólo le he añadido la parte dorada. En 1964 Abraham Kaplan, filósofo de la ciencia, escribió que si le das un martillo a un niño, descubrirá que todo lo que encuentra necesita un martillazo. Lo llamó la ley del instrumento.

Por qué un martillo no basta

Hay otra ley que explica por qué ese cambio de complejidad se queda corto. En 1956 Ross Ashby formuló la ley de la variedad requerida: solo la variedad absorbe variedad. Para gobernar un sistema necesitas al menos tantas respuestas distintas como estados distintos puede presentar ese sistema.

Y, en mi opinión, el management presenta muchísimos más estados que un sistema técnico. Alguien que no entiende por qué algo es importante (o lo entiende pero no lo comparte). Un conflicto. Agendas ocultas. Política. Un equipo con miedo (y no sabes por qué). Mucha más incertidumbre que tu anterior trabajo.

Da igual lo bueno que seas con tu martillo: en este sistema nuevo, no compensa la falta de herramientas diferentes.

¿Qué se pierde?

Volviendo al ejemplo del inicio, cuando entras en una conversación, lo primero que quiere una persona que tiene un problema es saberse escuchada. La persona llega probablemente con sentimientos intensos (preocupación, miedo, cansancio…) y necesita saber que entiendes tanto cómo se siente (y por lo tanto lo importante que es para ella) como los detalles del problema. Sin eso, todas tus soluciones simplemente caen en saco roto. Es una precondición para solucionar que entiendas el estado emocional de la persona.

Cuando respondes con tu martillo (la solución), la persona se encuentra con algo con lo que todavía no está preparada para lidiar. Y es posible que lo más importante, que quizá no te ha contado todavía, ni siquiera llegue a aparecer en la conversación. Lo cortaste con tu afán de solucionar.

Cómo saber si te está pasando

Lo complicado de este reflejo es que tu impresión es que estás haciendo bien tu trabajo.

Si no sabes si es tu caso, tres señales que miraría:

1. Contestas antes de que la persona acabe de hablar.

2. Sales de los One on Ones con tareas asignadas, pero sin entender bien cómo piensa la persona y qué le preocupa.

3. Y la más seria: empiezan a traerte los problemas ya resueltos. O directamente dejan de traértelos.

Esa última puede ser interpretada como “mira, confían más en sí mismos y en su criterio”. Ya, pero también puede significar que ya saben lo que vas a decir y que prefieren ahorrárselo.

Lo que sí funciona

Funciona pararse a escuchar, tratar de entender, no juzgar lo que te dicen. No ponerte en modo “cómo es esto que escucho para mí”, sino “cómo es esto que escucho para la persona que me habla”. Bajarte un rato de creer que, como manager, tu función en la vida es devolver soluciones como Rafa Nadal devuelve pelotas.

¿Cómo empiezas a hacer algo así? Aquí van 3 tips si quieres empezar por algo concreto:

1. Abre con una pregunta abierta. Algo tipo “¿Hay algo que esté siendo más duro de lo normal?” Algo que no proponga nada concreto ni acote la respuesta.

2. Una pregunta hipotética. “Si un amigo tuyo estuviera en tu situación, ¿qué crees que le preocuparía?” Preguntar por otro deja decir cosas que sobre uno mismo cuestan más.

3. Y el más difícil de los tres: callarte. Empieza por no hablar de entrada y luego pasa a dejar cuatro segundos de silencio de vez en cuando. Cuatro. Si no estás acostumbrado, quizá se te hagan eternos. Pero en esos huecos es donde la persona quizá se lance a explicar lo que realmente le preocupa.

Lo incómodo del asunto de “no empezar resolviendo” es que igual es más largo de lo que tenías en la cabeza y que no sabes a dónde te va a llevar.

Pero, amigo/a… bienvenido/a al mundo del management, no controlas muchas de esas cosas, y si piensas que las controlas… te esperan unas cuantas sorpresas.

Nos leemos

PD: si estás en tus primeros meses como manager (o justo has cambiado de jefe, equipo o empresa), he montado un mini-curso gratuito de 5 días para montar tu plan de los primeros 90 días, con vídeos explicativos y una herramienta de IA cada día para aplicarlo a tu caso concreto. El día 1 va justo de lo que va este artículo.

El mejor técnico de tu equipo se te acerca con una sonrisa, tiene una noticia que darte: le han ofrecido ser manager.

Le felicitas, claro.

Pero tú ya sabes que ser muy buen técnico (incluso el mejor) no tiene mucha correlación con ser buen manager.

Hay una diferencia enorme entre un técnico malo y un manager malo.

El técnico malo dura poco en su trabajo. Pero un manager malo, puede estar años en el puesto.

¿Porqué?

La respuesta a esa pregunta no tiene que ver con la maldad ni con la inteligencia (o la falta de ella).

1. Ascendemos a la persona equivocada por los motivos equivocados

En 2018, tres profesores de MIT, Yale y la Universidad de Minnesota analizaron el rendimiento de más de 53.000 comerciales en 214 empresas durante 6 años. Querían saber qué pasaba cuando el mejor vendedor ascendía a manager de ventas.

El resultado: las empresas ascienden sistemáticamente a sus mejores comerciales aunque esos mismos empleados acaben siendo peores managers, y aunque existan otras señales observables que predicen mejor quién lo hará bien gestionando equipos1.

Cuanto mayor era el rango de ventas antes del ascenso, mayor era la caída en el rendimiento del equipo gestionado después.

2. El feedback llega tarde, mal y es difícil de atribuir

Un técnico toca el producto directamente. Un manager toca las condiciones en las que ese producto se hace. Y las condiciones dan un feedback diferente.

Cuando un técnico hace algo mal el error le persigue: un ascensor se vuelve a estropear por lo mismo justo después de haberlo reparado, un programa no hace lo que hemos pedido, tiene muchos errores o es difícil de seguir añadiendo funcionalidad… El feedback sobre su trabajo puede tardar minutos, horas o hasta unos días. Pero aparece y es fácilmente atribuible a su trabajo2.

Cuando un manager se equivoca, el daño puede tardar meses o años en hacerse visible. Y cuando aparece, casi nunca puedes atribuirlo a un solo factor (una sola conversación, una sola decisión, un solo momento..,).

Sin embargo, según Gallup, el 70% de la varianza en el compromiso de un equipo es atribuible directamente al manager. No al salario ni a la estrategia de empresa. Al manager.

3. Llegamos al rol sin preparación

El Chartered Management Institute encuestó a más de 4.500 trabajadores y managers junto con YouGov. El dato que encontraron:

El 82% de las personas que acceden a puestos de gestión no han recibido ninguna formación formal. Son managers por accidente.

Lo que hace especialmente difícil salir de este ciclo es lo siguiente: cuando los managers sin preparación ascienden, se crea una trampa. Los managers tienen miedo de reconocer sus carencias ante sus superiores y los colaboradores tienen miedo de señalarlas. Nadie habla y el sistema se perpetúa.

Por si fuera poco, como el trabajo no les da el feedback adecuado, la mayoría tampoco piensa que lo hace mal o que necesita aprender más.

Según Gallup3, la mitad de las personas que dejan un trabajo lo hacen para alejarse de su manager, no del trabajo en sí.

En conclusión

Ascendemos al más competente en el trabajo equivocado. El feedback llega tarde y sin atribución clara. Y llegamos al rol sin herramientas y sin criterio.

Lo raro es que haya algún manager bueno.

Nos leemos

Pusimos el foco en unas cuantas cosas:

• de cómo evoluciona el rol de manager con la IA y qué sigue exactamente igual

• de qué es importante, ahora que ejecutar es barato

• de qué hacer cuando te llegan propuestas trabajadas por la IA

• de las performance reviews basadas en IA

• de la “deriva del error”

• de la parte incómoda de la privacidad de los datos

• de cómo se redefine el career path de los juniors y de qué podemos hacer para ayudarles

• de en qué contextos no ha cambiado casi nada

• de las tendencias que vemos (sí, jugamos un poco a futurología)

Una conversación explorando los problemas y oportunidades del management hoy. Si te interesa, te dejo la grabación:

---

Tienes el café a medias, ocho personas alrededor de la mesa de reuniones. Alex presenta la nueva estrategia. Slides impecables, datos, benchmarks… y un plan detallado.

La sala asiente. Alguien comenta que es el mejor análisis que ha visto este trimestre. Alex sonríe.

Y tú, escuchando desde el otro lado de la mesa, tienes una sensación rara.

Algo no cuadra.

No es que esté mal. Quizá justamente está todo demasiado bien.

Frases redondas, datos perfectos… las conclusiones son razonables. Pero hay algo en la presentación que no te ha funcionado, como si Alex estuviera explicando algo que ha leído, no algo que ha pensado.

Sospechas que no se lo ha trabajado.

Pero no tienes pruebas. Solo intuición. Y la intuición no es suficiente.

Mentir es más común de lo que parece

Vivimos rodeados de personas que defienden cosas que no han pensado fuertemente.

A veces es deliberado. Otras veces, no. Pero el resultado es el mismo: decisiones importantes se toman sobre fundamentos poco sólidos.

• El candidato que dice haber liderado un proyecto grande, y resulta que hizo una parte pequeña.

• La persona que defiende una propuesta cargada de palabras rimbombantes, pero no sabe explicar por qué eligió un enfoque y no otro.

• El compañero que afirma que esto es una “best practice”, pero no puede decirte por qué es mejor esa y no otra estrategia.

La buena noticia es que detectar mentiras es una habilidad entrenable.

La técnica es vieja, y no la inventó Musk

Sócrates, hace dos mil quinientos años, preguntaba en las plazas de Atenas detalles concretos hasta que el interlocutor descubría que no sabía lo que creía saber. Platón, su alumno, bautizó la técnica como mayéutica: el arte de hacer parir ideas.

Richard Feynman decía que si no puedes explicar un concepto en lenguaje simple, es que no lo entiendes.

Y Daniel Kahneman, en Pensar rápido, pensar despacio, describió lo que ocurre cuando una persona no sabe la respuesta a una pregunta difícil: la sustituye por una más fácil sin avisar a nadie, ni siquiera a sí misma. A esto lo llamó sustitución de atributos. El que finge no es necesariamente un mentiroso consciente: muchas veces está sustituyendo automáticamente la pregunta que le hicieron por una versión más cómoda que puede responder mejor.

Las cuatro preguntas que pillan a cualquier mentiroso

Una persona que se ha trabajado el tema responderá a las cuatro sin esfuerzo. Una persona que está repitiendo algo que no entiende del todo o fingiendo suele caer antes de la tercera.

1. Pregunta por el detalle

“Cuéntame por qué decidiste X en concreto. Cómo funciona.”

Las preguntas generales admiten respuestas generales y vagas.

Las preguntas específicas son más difíciles de esquivar.

Si Alex dice que su estrategia se basa en tres canales, pregunta por el segundo. Incluso por los detalles del segundo.

Quien lo trabajó tiene una historia de desafíos que ha superado y podrá responder fácilmente con una historia sobre su viaje. Si la persona simplemente lo sabe de oídas, está presentando la idea de otro (o de ChatGPT)... verás que hay respuestas cortas y generalistas.

2. Pregunta por lo descartado

“¿Qué alternativas valoraste antes de elegir esto?”

Esta es probablemente la más reveladora de las cuatro.

Quien piensa una propuesta a fondo no llega a la conclusión directamente: pasa por opciones, las valora, las prueba, las descarta. Cuando le preguntas qué descartó, puede contártelo perfectamente. De hecho, verás cómo sus ojos se iluminan para explicarle lo que considera un “descubrimiento” de su viaje.

Si no trabajó el tema, si no hizo ese viaje, solo tiene la conclusión. Las alternativas no existen para esa persona, porque nunca llegó a pasar por ellas.

3. Pregunta por el caso límite

“¿En qué escenario esto no funcionaría?”

Al igual que las alternativas, saber dónde se rompe tu idea forma parte de haberla trabajado. Igual la persona no expresa certidumbre, pero seguro que en su viaje de construcción de la propuesta ha imaginado dónde la cosa no podría ir tan bien.

Si no la ha trabajado, quizá piensa, optimistamente, que siempre va a funcionar y que su propuesta no tiene puntos ciegos.

Todas las ideas tienen límites, casos dónde no aplica tanto, conocerlos (o al menos imaginarlos) es señal de haber trabajado en profundidad en la idea.

4. Pregunta por el lenguaje técnico

“¿Cómo le explicarías X a alguien que no sabe del tema?”

Esta es la técnica de Feynman.

El lenguaje técnico, las palabras clave, las palabras de moda pueden esconder desconocimiento.

Si alguien defiende una solución “flux-driven” con “quantum consistency”, pídele que explique en qué consiste. Si la respuesta son más palabras mágicas, quizá no sabe realmente lo que se trae entre manos.

Dos tipos de mentirosos

“El problema con el bullshit no es que sea falso. Es que a quien lo dice no le importa si es falso o verdadero. Solo le importa el efecto que produce en quien la escucha.”

— Harry Frankfurt, On Bullshit

No todos los “mentirosos” son iguales.

El mentiroso inconsciente

Es el más común.

Es la persona que cree que sabe, pero no. Que repitió un patrón que vio funcionar en otra empresa sin entender por qué funcionaba. Que aceptó la primera respuesta que generó la IA sin pensarla. Que defiende una posición porque la oyó decir a alguien que admira.

No está intentando engañarte. Se ha engañado primero a sí misma.

La mayoría de nosotros caemos en esta categoría de “mentiroso”.

El mentiroso consciente

Es menos común, pero existe.

Es la persona que sabe que no ha hecho el trabajo y trata de aparentar que sí. El candidato que infla su CV. El consultor que vende un framework que no entiende porque “hay que vender”. El compañero que se atribuye una idea que no es suya.

¿Cómo distinguirlos? La señal más fiable es lo que ocurre después de que les pillas. El inconsciente suele reconocer el hueco de conocimiento y se interesa por llenarlo. El consciente se defiende, busca excusas o intenta cambiar de tema.

Cuándo no usar esta técnica

No todo momento es buen momento para hacer preguntas detalladas.

Esta técnica genera incomodidad. Pone a la otra persona en una situación de exposición. Si la usas mal, en el momento equivocado, o con la persona equivocada, te conviertes en el manager que todos temen. Conviertes las reuniones en una caza de brujas y te cargas la seguridad psicológica.

Tres situaciones donde merece la pena tirar de ella:

• Cuando hay mucho en juego. Cuando el coste de equivocarte justifica la incomodidad de preguntar.

• Cuando algo no cuadra. Confía en tu intuición. Si llevas veinte minutos escuchando una propuesta y tienes esa sensación de que falta algo, probablemente falta algo.

• Cuando hay un patrón. Si la misma persona aparece repetidamente con propuestas que se caen al rascarlas, igual es momento de dar feedback.

Y dos situaciones donde es mejor no aplicarla:

• Cuando la persona te pide ayuda. Si alguien viene a pedirte ayuda con un problema que le supera, no le hagas el examen. Ayúdale.

• En público, salvo casos extremos. El test del discurso aplicado en una reunión con audiencia puede ser visto por la otra persona como una humillación, incluso si la intención era buena. Mejor llevar la conversación a un entorno privado y darle feedback allí.

Nos leemos.

P.D.: Una pregunta para ti… ¿Qué pasa si el mentiroso es tu jefe?

Es un trabajo que me gusta. Pero en ese tiempo he echado de menos algo que no esperaba: el contacto con las personas cuando enseño.

Ese momento en que alguien me cuenta su situación concreta y discutimos qué hacer exactamente en ese caso. El “espera, entonces, si la otra persona dice X, ¿qué hago?”. El matiz que en un vídeo no cabe porque sería infinito explorar todos los casos.

Me pasa con gente que ha leído lo que escribo, que ha hecho el curso, que conoce la teoría. Y aun así, algo no termina de hacer clic del todo hasta que no trabajan su caso específico con alguien. Hasta que no lo practican.

No le pasa a todo el mundo. Pero si te ha pasado, sabes exactamente de lo que hablo.

De la confluencia de esas dos cosas, mi necesidad de conexión y la de algunas personas de practicar en vivo, vienen los workshops.

Hoy abrimos las primeras plazas de dos workshops en directo:

• Fundamentos de Management: para managers que llevan menos de tres años en el rol, o que llevan más pero sienten que van improvisando. Feedback, one-on-ones, bajo rendimiento, managing up... Primera sesión el 17 de junio.

• Resolución de Conflictos: para managers que necesitan entender cómo resolver conflictos. Primera sesión el 16 de junio.

Grupo pequeño en los dos. Máximo 15 personas. Practicamos situaciones realistas. Si tienes una pregunta sobre tu caso concreto, la trabajamos en el momento.

Las primeras plazas son Early Bird. Si tienes dudas sobre si alguno es para ti, responde a este email y te contesto directamente.

Nos leemos.

José Carlos

El primero, Javier, según tu herramienta de seguimiento, ha cerrado el 60% del trabajo del equipo en el último trimestre. Delivery consistente. Hay argumentos sólidos para recibir un aumento, es fácil de defender.

La segunda, Marta, según tu herramienta de seguimiento, ha cerrado un tercio del trabajo que hace Javier. Pero mantiene la deuda técnica a raya, organiza el proyecto y todos sus artefactos, mentorizó a los tres nuevos hasta que empezaron a entregar solos, medió en un conflicto de tres meses entre desarrollo y producto, es la primera que aparece cuando hay un incidente y sistematizó el proceso de onboarding que usáis ahora. Sabes que puedes enviarla a una reunión con otros equipos y no solo no volverá con un conflicto (como muchas veces pasa) sino que traerá un acuerdo razonable y bien explicado.

Cuando propongas a Javier, tu director sonreirá, es su preferido. Su nombre va asociado a entregas. Si propones a Marta, vas a tener que defender bien por qué, porque su nombre no sale en la foto habitualmente y el tipo de trabajo que hace no está valorado.

¿Qué mide tu sistema?

Los sistemas de performance miden bien el output fácilmente contabilizable (código, diseño, características nuevas) y miden muy mal el trabajo de pegamento que mantiene a los equipos funcionando.

Un tipo de output es fácil de medir y el otro no.

¿Cómo mides que una persona fue a una reunión complicada y salió de allí con una decisión y cero conflictos? ¿Y lo que habría pasado si hubiese ido otra que sí volviera con un conflicto sin resolver? Lo que no pasó porque alguien lo evitó nunca aparece en un dashboard.

Las tareas que no suelen llevar a promociones se concentran sistemáticamente en quienes tienen mayor disposición a aceptarlas. La voluntariedad, como mecanismo de asignación, es la causa. Y el resultado es predecible: ciclo a ciclo, los mismos perfiles absorben el trabajo que no cuenta para una subida salarial o una promoción. Muchos lo hacen incluso sin que nadie lo pida explícitamente, y eso hace aún más difícil que ese trabajo se vea como trabajo “real”.

Si siempre promocionas a Javier, tu equipo se convierte, ciclo a ciclo, en una fábrica de output individual cada vez con más roces y problemas. Y las Martas se van.

La meritocracia puede ser una trampa

Casi toda empresa tech dice practicar una meritocracia basada en el valor entregado. La frase suena bien y es impecable en el papel. Pero hay un hallazgo académico incómodo al respecto: un estudio1 encontró que las organizaciones que se presentan explícitamente como “meritocráticas” muestran más sesgo en sus evaluaciones y decisiones de compensación, no menos. La narrativa de “premiar el trabajo real” hace que los evaluadores se sientan objetivos y bajen la vigilancia sobre qué están midiendo realmente.

En la práctica, esa trampa esconde tres problemas:

1. Qué se puede medir ≠ qué tiene valor.

La entrega individual de trabajo se mide fácil. El valor generado por el trabajo “pegamento” es más complicado. Eso hace que el sistema tenga grandes puntos ciegos.

2. El trabajo de pegamento es un prerrequisito invisible del output ajeno.

El 60% de tickets cerrados por Javier descansa en que Marta ha ido a una reunión que salió bien y se pudo definir qué esperaba el otro equipo. Los futuros “Javier” fueron mentorizados por ella. ¿Cuál será la producción del equipo en unos meses cuando Marta se vaya? ¿Sabremos atribuirlo a ella cuando ya no esté? ¿O... lo más probable... simplemente será el nuevo normal entregar menos?

3. El sistema crea un sistema de incentivos perverso.

Las personas de tu equipo aprenden rápido que el trabajo de pegamento no se reconoce. La consecuencia es que los mejores empiezan a evitarlo. Pasado un tiempo, en tu equipo solo hacen trabajo de pegamento los que aún no lo han aprendido. Cuando esas personas aprendan, dejarán de hacerlo o se agotarán y se irán, dejándote un sistema que siempre funcionará por debajo de su nivel óptimo.

¿Qué hacer?

Si tienes que decir AHORA, súbele el salario a Javier.

¿Por qué?

Porque si propones a Marta sin haber trabajado nada de lo que luego te plantearé, tu superior no entenderá tu decisión. Y hará la lectura de que estás equivocado. Y eso te resta poder.

Y necesitarás poder para cambiar las cosas.

Al promocionar a Javier sin reconocer a Marta, has iniciado una carrera que tendrás que parar lo antes posible:

• Es una señal para Marta: su trabajo no cuenta.

• Es una señal para el equipo: esto es lo que se premia.

Tres cambios pequeños para empezar a salir de la trampa

Lo ideal sería rediseñar cómo tu empresa toma decisiones sobre salarios y promociones, pero vamos a suponer, por lo que sea, que eso te resulta difícil.

Hay tres cambios que puedes introducir en tu equipo, con coste muy bajo, que empiezan a corregir el sesgo.

1. Empezar a contabilizar el trabajo de pegamento

Haz una lista, cada mes, de los cinco “trabajos pegamento” más relevantes que han sostenido al proyecto o al equipo. Ejemplos reales: “onboarding de 3 personas que ahora entregan autónomamente”, “creación de una skill que redujo el tiempo de onboarding en un 40%”, “mediación continuada con producto que bajó el retrabajo un 25%”. Pon nombre y apellido al lado de cada ítem. Esta lista la incluyes, por escrito, dentro del resto de reportes de output que envías o comentas.

2. Redistribuir activamente.

El próximo trabajo de pegamento (onboarding, documentación, tooling, mediación) asígnalo deliberadamente a un Javier del equipo. Si lo dejas a la voluntariedad, siempre será la misma persona que se inclina a ello la que lo hará. Asígnalo y evalúa el resultado de esa tarea, da feedback como haces con el resto de trabajos.

Si el Javier de turno lo rechaza explícitamente o tiene oportunidad de mejorar, tienes una conversación interesante. Y, en todo caso, has hecho visible en el equipo que ese trabajo es tan necesario como el resto. Y, si siempre recae en Marta, le has quitado un peso para que pueda hacer cosas diferentes.

3. Introduce el trabajo de pegamento en la performance review.

Si tu plantilla corporativa solo tiene casillas para “output individual medible”, añade el trabajo pegamento ahí:

• Contribuciones al crecimiento de otros.

• Trabajo cross-team (mediaciones, formaciones, coordinaciones...).

• Infraestructura no técnica del equipo (documentación, procesos, ayuda).

• Resolución de conflictos o bloqueos recurrentes.

Haz que sea imposible no ver ese trabajo. Documenta no solo qué hizo, sino qué dejó de pasar gracias a ello: postmortems, conflictos no escalados, onboardings de tres meses en vez de seis.

Quizá no puedas cambiar todos los procesos y la cultura de tu organización desde tu rol, pero puedes empezar a hacer que ese tipo de trabajo salga en la foto.

Nos leemos.

P.D. Para complementar el tema puedes leer “Being Glue”, de Tanya Reilly.

A mediados de mes, tu mayor cliente enterprise cambió de CTO. La nueva CTO canceló la integración en la que llevabais tres meses trabajando. Un email de dos párrafos. Sin disculpas.

A finales de mes, la empresa anunció una reestructuración. Tu equipo perdió dos personas. 7 iniciativas canceladas.

El Gantt ya no daba gusto de mirar.

Y, además, tuviste que escuchar “Es que no podíamos haberlo previsto”.

Es verdad. Pero podrías haberte preparado.

La adicción a predecir

Nos encanta predecir. Los roadmaps, los OKRs trimestrales... Muchos de nuestros sistemas se basan en la creencia de que podemos anticipar lo que va a pasar.

Y funciona. Mientras estás en la reunión1.

En el momento en que sales de la sala, el mundo real™ empieza a ponerse en marcha y ya no es un tema de si tu plan va a caducar… sino cuándo.

• La persona más senior del equipo se va a otra compañía.

• Aparece un cambio regulatorio que invalida tu característica estrella.

• La IA (o Google) convierte en commodity lo que tu equipo llevaba 6 meses desarrollando.

• El proveedor que triplica el pricing con un email a las 8 de la tarde del viernes.

Cada uno de estos eventos destruye tu roadmap. Y cada vez que ocurre, la respuesta es la misma: “no podíamos preverlo”.

Entonces… ¿no planificamos?

La alternativa no es dejar de planificar. Es planificar para lo imprevisto en vez de planificar asumiendo que no los habrá. Tener opciones cuando pase lo que nadie espera.

1. Redundancia

El equipo que tiene una sola persona que entiende partes del sistema… no está gestionando el riesgo… está apostando. Si una persona se va de vacaciones, se va de la empresa o simplemente se pone enferma, la apuesta se pierde2.

No necesitas que dos personas hagan el mismo trabajo. Necesitas que más de una persona pueda hacer el trabajo si las circunstancias cambian. Eso se traduce en cosas muy concretas: trabajar en parejas en partes críticas, rotación de on-call, code reviews donde el revisor tenga que entender de verdad (no solo aprobar). Todo eso parece overhead. Hasta que es necesario.

2. Capacidad de “undo”

Cada decisión que tomas abre unas puertas y cierra otras. El manager preparado prefiere las decisiones que mantienen más puertas abiertas el mayor tiempo posible.

¿Nos atamos a este proveedor ahora? ¿Migramos todo al sistema nuevo o solo una parte? ¿Adoptamos este estándar corporativo o lo dejamos para un experimento?

En cada una de esas decisiones, la pregunta no es únicamente cuál es la opción técnicamente mejor hoy. Es cuánto te cuesta deshacerla si te equivocas.

3. Exposición, no probabilidad

La preparación no es proporcional únicamente a la probabilidad. Es proporcional a la combinación de probabilidad e impacto. Los eventos raros pero catastróficos pesan más que los eventos frecuentes pero manejables.

Un evento menor que tiene un 40% de probabilidad de ocurrir y cuyo impacto es bajo: no te prepares, asúmelo. Un evento que tiene un 2% de probabilidad pero que si ocurre paraliza tu equipo durante un mes: prepárate como si tuviera un 50%.

La IA no ayuda (¿o sí?)

La promesa de la IA aplicada a planificación es seductora: más datos, mejores predicciones, roadmaps más precisos.

Como herramienta de predicción, la IA tiene el mismo problema que cualquier modelo entrenado con datos del pasado: no sabe lo que no ha visto. La IA no cambia que el futuro no es predecible.

De hecho, si algo hace la IA es ciclos de cambio. Los cambios llegan antes, y tu roadmap caduca más rápido que nunca.

Pero quizá sí puedes usar la IA para aumentar tu capacidad de undo. Hacer más prototipos, explorar más opciones antes de comprometerte con una. Documentar y compartir decisiones con menos esfuerzo, facilitar el onboarding para entrar en un proyecto que no conoces…

El roadmap fallará

Si tu respuesta a un roadmap que salta por los aires es “hacemos otro roadmap”, no has entendido el problema.

Un roadmap es una predicción de futuro. Preparar opciones es asumir que esa predicción va a fallar de una manera u otra.

Si esta edición te ha aportado algo, considera reenviársela a alguien que esté discutiendo un roadmap esta semana.

Nos leemos.

P.D. Antifrágil de Nassim Nicholas Taleb es denso y provocador, pero el concepto de Cisne negro es interesante para complementar lo que hemos visto aquí.

No hacía falta el asunto.

Te preguntas cuándo te tocará a ti.

¿Es que a los managers no los echan en una reestructuración? De eso vamos a hablar hoy.

Cómo está el mercado

Las ofertas tech suben: engineering +34%, Data Science/ML +90%. Las de middle management han caído más del 40% desde 2022. En España, la Guía Salarial de Manfred 2026 clasifica al engineering manager como rol “despriorizado”. El mercado se recupera en algunos casos pero nadie cree que volvamos a los niveles de 2022.

“The Great Flattening”

Lo que hicieron las grandes antes de los layoffs asociados a la IA no fueron recortes normales. Fueron rediseños del organigrama.

• Amazon eliminó 14.000 posiciones de management entre 2024 y 2025. Su CEO, Andy Jassy, fijó el objetivo de aumentar el ratio de ingenieros por manager en un 15%. Lo superó.

• Google eliminó el 35% de sus managers que gestionaban equipos de menos de tres personas.

• Microsoft declaró que el objetivo de sus layoffs de 2025, 15.000 personas, era, literalmente, “reducir capas de management.”

• Meta creó su nueva organización de IA con un ratio de 50 ingenieros por cada manager.

El 30% de todos los despidos en tech fueron middle managers, cuando históricamente la cifra era un ~20%.

Pero… se despide menos a managers

“Donde yo trabajo parece que se despide menos managers que al resto.”

Claro. Es que hay menos managers. Si tu departamento tiene 50 ingenieros y 5 managers y echan a 10 personas, es fácil que las 9 sean ingenieros. No porque los managers estén protegidos, sino por pura estadística.

Cómo caen y sobreviven los managers

No es más fácil ni más difícil echar a un manager que a otra persona. Es distinto.

1. El ratio

Muchas empresas mantienen un ratio de managers por cada X personas. Si hay despidos masivos, los managers sobran automáticamente. No te echan por rendimiento. Te echan porque tu equipo ya no existe o porque dos equipos se van a fusionar.

2. El “blast radius”

Despedir a cualquier persona duele. Pero despedir a un manager provoca una pequeña detonación que tiene un poco más de radio de efecto.

Un manager tiene relaciones con todo su equipo, con otros equipos, con otros managers, con stakeholders... Conoce el contexto, las dinámicas, los problemas que ni siquiera se discuten a nivel de equipo. Si es un manager valioso, quitarlo puede desestabilizar más de lo que quieres. Por eso las empresas no lo hacen a la ligera.

Esto puede explicar una parte de la percepción de que “los managers nunca caen.” No es que no caigan. Es que las empresas retrasan la detonación todo lo que pueden.

Pero esto solo se aplica a managers que realmente añaden valor. Si tu único valor es pasar órdenes de arriba y explicar los problemas del equipo a tu jefe, tu “blast radius” es mínimo.

3. Cuanto más arriba… menos seguro

Si no es el caso de un layoff masivo... si una persona rinde poco, suele haber avisos; en algunas empresas hasta se inicia un proceso que suele durar 3 meses. Es un proceso gradual de despido.

Con un manager senior no funciona así. Cuanto más arriba estás, menos capacidad tiene tu superior de entrar en un proceso en el que cuida de tu rendimiento. Entonces, la decisión se vuelve binaria: o funcionas o no. Y si no funcionas, suele haber una conversación y luego estás fuera.

4. La dificultad de la atribución

¿Tu equipo entregó a tiempo porque has hecho un buen trabajo como manager o porque es un equipo que funciona?

Medir el rendimiento siempre es complicado, pero es más sencillo si tu trabajo es técnico que si eres manager.

En un manager senior, los resultados se confunden con factores del mercado, con la inercia del equipo, con historias bien contadas... Esto añade un problema adicional: ¿cómo hace alguien el cálculo de qué aportas cuando tiene que decidir quién sobra en un layoff?

El error que casi todos están cometiendo

Hay una lectura peligrosa de todo esto:

“Como quieren menos managers… tengo que proteger mi puesto.”

Y eso suele traducirse en comportamientos bastante predecibles:

• Controlar más

• Justificar tu existencia

• Estar en todas las decisiones

• Convertirte en el cuello de botella… pero con PowerPoint

Vamos, exactamente lo contrario de lo que necesitan las empresas que están “aplanando” la organización.

Porque si algo está claro en este movimiento es esto:

Las empresas no están “quitando managers”.

Están quitando capas que consideran inútiles.

El test de las vacaciones

Si desapareces 1 mes... ¿qué pasa?

• Si todo sigue igual → tienes un problema. No va a ser sencillo para otros ver cómo añades valor.

• Si hay ruido pero se aguanta → estás en el límite.

• Si el sistema se resiente → es fácil ver el valor que aportas desde fuera.

Y ojo, esto no es un test del valor que aportas. Lo que mide es cómo de fácil es para otros ver el “valor” que aportas (o el riesgo de eliminar tu puesto).

Desde un punto de vista sistémico, es una forma mala de verlo porque favorece a aquellos managers que generan dependencia de ellos. Pero no por eso deja de ser una realidad.

Y aquí está la parte que nadie dice en voz alta:

Cuanto más necesario pareces, peor estás diseñando el sistema.

El manager que es imprescindible porque todo pasa por él no es un buen manager. Es un cuello de botella con buenas intenciones. Pero en un layoff, ese cuello de botella sobrevive. Y el que construyó un equipo autónomo, el que hizo bien su trabajo, es el que parece prescindible.

La paradoja del buen manager: cuanto mejor lo haces, más fácil parece eliminarte.

Entonces… ¿qué valor deberías aportar?

1. Reduces complejidad

Tu equipo y tu organización funcionan mejor porque tú estás.

No porque haces más cosas.

Sino porque haces que las cosas sean más claras.

Menos ruido.

Menos fricción.

Menos decisiones innecesarias.

2. Tomas decisiones que otros no pueden tomar

No las obvias. No las cómodas. Las que implican:

• conflicto

• incertidumbre

• costes ocultos

• efectos de segundo orden

3. Cambias el sistema (no solo el output)

Un manager difícil de reemplazar no solo optimiza lo que hay que hacer, lo evidente. También cambia cómo funciona el sistema.

Ejemplos:

• elimina o reduce dependencias entre equipos

• redefine prioridades

• cambia dinámicas de decisión

• evita problemas que aún no existen

Esto es lo que hace que tu “blast radius” sea real.

Tus opciones

No se trata de vivir paranoico por si te echan. Creo que hay que jugar a dos niveles:

Nivel 1: dentro de la empresa

• Aporta valor sistémico.

• No seas una capa más que transporta datos de un sitio a otro.

Nivel 2: fuera de la empresa

• Mantén opciones abiertas: conocimientos, contactos, side projects...

• No pierdas tu empleabilidad.

Y aún así, debes entender que puedes hacerlo todo “bien” como manager y que, aún así, te despidan. Porque hay decisiones que no tienen nada que ver contigo ni con tu valor. No confundas tu valor con tu puesto de trabajo.

Nos leemos.

El tráfico mataba a más de 1.500 personas al año. Se habían probado multas más altas, más policías, más señales. Nada funcionaba.

Cuando Antanas Mockus se convirtió en alcalde, hizo dos cosas que nadie entendió.

Primero, despidió a 1.800 policías de tráfico.

Después, contrató a 20 mimos, que pronto acabaron siendo 420.

Los distribuyó por las intersecciones más peligrosas. Su trabajo: señalar y ridiculizar a quien cruzase en rojo, condujese de forma agresiva o ignorase a los peatones. Sin multas. Sin policía. Sin castigos formales.

En los siguientes años, las muertes por tráfico se redujeron más de un 50%.

Mockus no cambió las leyes. No cambió las multas. No cambió la infraestructura.

Cambió la regla informal: pasó a “si haces algo mal, la comunidad te lo va a señalar.”

La ley escrita era la misma. La regla real había cambiado por completo.

Las dos “constituciones” de tu organización

Toda organización tiene dos conjuntos de reglas.

1. Las formales: el “manual del empleado”, las políticas de RRHH, los criterios de promoción documentados, los objetivos, el proceso de aprobación de gastos… Las que están en el sistema de la empresa y que casi nadie mira.

2. Las informales: cómo se asciende realmente, quién tiene voz y quién no, qué comportamientos se toleran aunque contradigan los “valores oficiales”, qué pasa cuando alguien comete un error…

Las informales son las que gobiernan el sistema. Siempre.

Por qué las reglas informales son tan resistentes

Una persona nueva llega a tu equipo. Lee la documentación. Ve que “valoramos la experimentación.” Propone un experimento y sale mal.

Lo que dice el manual del empleado: “Aprendemos de los errores.”

Lo que pasa en la práctica: silencio incómodo en la siguiente reunión. Su manager le dice en la One on One que “quizás la próxima vez mejor consultar antes.” En la calibración de performance, ese incidente pesa. Seis meses después, la persona ya ha aprendido la lección: nada de experimentos.

Nadie cambió ninguna regla formal. La regla informal se transmitió sin que nadie la escribiera, sin que nadie la aprobara, y sin que nadie pueda señalar el momento exacto en que se estableció. Así funcionan las reglas informales: se transmiten por imitación y las consecuencias las refuerzan.

Y eso es precisamente lo que las hace tan difíciles de cambiar. No se puede eliminar algo que “oficialmente” nadie reconoce que existe.

El error que puedes cometer

Muchos managers operan asumiendo que las reglas formales son las que gobiernan. Diseñan procesos, definen criterios, comunican valores. Y luego se frustran porque la gente no se comporta como esperan.

No es que la gente sea “difícil”. Es que la gente sigue las reglas que ve, no las que lee.

Y la prueba es sencilla: mira qué pasa cuando alguien rompe una regla formal. Si no pasa nada, no era una regla. Era un deseo: un póster bonito en una pared. Un pdf preciosamente diseñado y colgado en el sistema interno de la organización.

Qué puedes hacer

1. Encuentra la regla que mueve todo lo demás

No todas las reglas informales pesan igual. Hay una que condiciona más decisiones que todas las demás juntas. El test es sencillo: pregúntate “si esta regla cambiara, ¿cuántas decisiones cambiarían con ella?”

Si la respuesta es “muchas” (o la menos: “las importantes”), ahí está tu palanca. Y, si cambiarla, genera resistencia inmediata, probablemente es una señal más de que es la correcta.

Mockus no cambió cincuenta normas de tráfico. Cambió una sola cosa: quién señala las infracciones. Pasó de la policía a la comunidad. Y eso reconfiguró todo lo demás.

En tu equipo puede ser algo como:

• “Las decisiones técnicas las toma quien más cargo tiene.” Si cambias eso a “las toma quien más contexto tiene”, se reconfiguran reuniones, ownership, priorización, quién habla...

• “Los errores se esconden.” Si cambias eso a “los errores se comparten”, cambia cómo se planifica, cómo se estima, cómo se pide ayuda.

No busques cambiar diez reglas. Cambia la que arrastra a las demás.

2. Cámbiala con algo más que palabras

Las reglas informales no se cambian anunciándolas. Se cambian alterando lo que pasa cuando alguien las sigue o las rompe.

Tienes tres mecanismos. Siempre son estos:

Consecuencias. Lo que tiene consecuencias visibles es lo que la gente repite. Lo demás es ruido. Si dices que valoras la colaboración pero solo promocionas a quien brilla individualmente, la regla real es: competir importa más que colaborar. No cambias eso con un mensaje en Slack. Lo cambias cuando colaborar aparece en las evaluaciones y en las promociones.

Fricción. Lo que es fácil de hacer, ocurre. Lo que es difícil, desaparece. Si quieres que la gente documente, puedes pedirlo... o puedes hacer que sin documentación no se pueda cerrar una tarea (o que sea tan fácil que sea casi gratis). Si quieres fomentar algo, reduce pasos, aprobaciones, riesgo percibido. Si quieres frenarlo, añade revisión, coste o exposición.

Visibilidad. Lo que se ve, se copia. Si en cada review destacas a quien “salvó el sprint a última hora”, estás reforzando el comportamiento heroico. Si destacas a quien evitó el problema semanas antes, estás cambiando la regla. Las historias que cuentas, los ejemplos que usas… todo eso define qué es “lo normal aquí.”

Los mimos de Bogotá usaban los tres mecanismos a la vez: hacían visible la infracción (visibilidad), la convertían en ridículo social (consecuencias) y creaban una barrera de incomodidad antes de saltarse un semáforo (fricción). Sin multas. Sin policía. Sin cambiar una sola ley.

3. Protege tu espacio de reglas

Puede que no controles las reglas de toda la organización. Pero siempre hay un espacio donde tienes poder e influencia.

Las micro-reglas que controlas tienen un efecto desproporcionado. Si decides que en tu equipo los errores se comparten abiertamente, acabas de crear un espacio donde la experimentación es posible. Aunque el resto de la empresa funcione al revés.

Pero esto tiene un coste. Si el sistema global va en otra dirección, tú te conviertes en el buffer entre las reglas de fuera y las de dentro. Si no lo defiendes, el sistema lo corrige hasta que vuelva a ser como antes. Es el trabajo invisible del manager que nadie reconoce.

4. Mantén la coherencia o no empieces

Una regla informal necesita veinte confirmaciones para establecerse y una sola contradicción para destruirse.

Si decides que tu equipo premia la colaboración, entonces la colaboración tiene que aparecer en las evaluaciones, en las celebraciones, en cómo asignas proyectos. Todo el rato. Sin excepciones visibles.

Porque la gente no escucha lo que dices. Observa lo que haces. Y sobre todo, observa lo que haces cuando es incómodo.

La coherencia no es un valor. Es el mecanismo por el cual una regla informal se convierte en “así se hacen las cosas aquí.”

Este post forma parte de una serie sobre los puntos de apalancamiento de Donella Meadows aplicados al management.

1. El éxito del equipo puede convertirse en su condena

2. Cambiar parámetros no arregla nada

3. Los buffers son esenciales

4. La estructura de los flujos importa más que los números

5. Los bucles de feedback te mantienen vivo

6. Los retrasos pueden matarte

7. Ahorrar en la factura de la luz (flujos de información)

8. Las reglas del sistema ← este texto.

Nos leemos.

P.D.: Si quieres profundizar:

• Pensar en sistemas de Donella Meadows. Para mí, el mejor libro sobre el tema. Corto, claro y con más ideas por página que en la mayoría de los libros de management.

• Leverage Points: Places to Intervene in a System, el paper original de Meadows. 19 páginas que pueden cambiar la forma en la que ves cualquier organización.

“No sé si mis one on ones sirven para algo. Las hago. Cada semana. Religiosamente. Pero si me preguntas para qué... no sabría responderte.”

(Era algo así, mi memoria no me permite recordar las palabras exactas)

Si tus One on Ones desaparecieran mañana, ¿protestaría alguien?

La mayoría de managers hacen One on Ones que son status meetings. La persona te cuenta lo que ya está en tu sistema de seguimiento.

Hasta que un día la One on One sí sirve:

“He aceptado una oferta en otro sitio”.

3 errores que están matando tus One on Ones

1. Hablas más que la otra persona

“Aprovecho para comentar un par de cosas ya que te tengo aquí...”

“De la manera en la que yo lo veo...”

“Lo que tienes que entender...”

La One on One se convierte en un espacio para ti. Y, por tanto, la otra persona aprende que la reunión no va sobre ella.

2. Entras a “arreglar” a la mínima

“¿Has probado a...?”

“Bueno, pero eso tiene fácil solución.”

“Lo que tienes que hacer es...”

La persona deja de pensar en voz alta. Porque cada vez que lo hace, alguien le corrige, le dirige o matiza lo que dice.

3. Conviertes la conversación en un interrogatorio

“¿Es que no tienes claras las prioridades?”

“¿Es un tema personal tuyo o qué?”

“¿Tú crees que esto es aceptable?”

Hemos creado un curso

Hacer One on Ones útiles no es tan complicado si sabes cómo, pero es fácil… MUY fácil hacerlas y no sacarles utilidad.

Si te interesa el tema, acabamos de publicar dentro de ManagerPro el curso de “One on Ones”. Como siempre, no un curso de recetas ni preguntas mágicas que lo resuelven todo automáticamente. Pero sí que exploramos:

• Una estructura mínima que funciona

• Para qué sirve y qué hacer en las One on Ones

• Cómo detectar problemas latentes

• Qué hacer cuando alguien dice “todo bien” y no todo está bien

• Qué hacer cuando alguien no habla

• Qué hacer cuando alguien te suelta una bomba

• Y, por supuesto, el antipatrón Steve Jobs

Todo con ejemplos reales, análisis de conversaciones, ejercicios y recursos que puedes usar en tus One on Ones mañana.

Si estás dentro de ManagerPro, ya tienes el curso completo en la plataforma.

Nos leemos.

P.D. Si conoces a alguien cuyas One on Ones terminan con “pues nada, cualquier cosa me dices”... le puedes enviar este correo.

Tu jefe toma la palabra. Despliega una propuesta para reestructurar la arquitectura de vuestros servicios. Montones de keywords. Diagramas detallados.

Habla con confianza. Los términos son correctos. La narrativa es coherente.

La propuesta está bien estructurada. Cubre los puntos que debería cubrir.

Pero hay algo que no encaja. No menciona las dependencias con sistemas que no son evidentes. No tiene en cuenta que medio equipo de infraestructura está de baja y que el equipo ya está en medio de otro cambio grande. No tiene en cuenta cuántas personas de tu equipo podrían gestionar esa complejidad.

Es una respuesta correcta a un problema que no es exactamente el vuestro.

Entonces reconoces el patrón: es el mismo que aparece en tus conversaciones con tu IA.

Tu jefe tiene un McKinsey privado, gratuito, sin accountability y sin contexto. Y tú tienes que gestionar los entregables de ese consultor.

Más madera

Antes de la IA, generar una propuesta estratégica costaba tiempo. Tu jefe tenía que pensar, investigar, consultar, escribir... Ese proceso era lento, pero tenía una virtud: le obligaba a masticar la idea. A descubrir los agujeros durante el camino. A descartar cosas que parecían buenas en teoría pero no sobrevivían al “papel”.

Ahora, generar esa propuesta le cuesta un prompt y unos minutos.

Tu jefe puede producir ideas al ritmo que quiera (en realidad siempre pudo, pero ahora están trabajadas).

El resultado es una presión constante: una lluvia de propuestas, estrategias, “¿habéis considerado...?” y “he estado pensando que...” que llegan más rápido de lo que tu o tu equipo puede procesarlas. Es micromanagement pero amplificado por la capacidad infinita de generar ideas que suenan razonables y están documentadas.

Tu jefe ahora “entiende” de todo

Tu jefe ahora tiene opiniones sobre cosas que antes delegaba en ti. Ahora le ha preguntado a su IA de confianza y tiene una opinión formada. O, más exactamente, tiene una opinión prestada que siente como propia.

El problema no es que las opiniones sean malas. A veces son razonables. A veces son buenas. El problema es que vienen sin contexto y con una confianza que las hace peligrosas.

Un directivo que no sabe de arquitectura y lo admite es fácil de gestionar. Un directivo que no sabe de arquitectura pero cree que sabe es un problema de otra magnitud.

Y a veces tiene razón

A veces la idea que generó con su IA es genuinamente buena. A veces la perspectiva de alguien que no está metido en los detalles del día a día, combinada con una herramienta que ha procesado patrones de miles de empresas, produce algo valioso.

Si rechazas una idea de tu jefe, ¿la rechazas porque es mala? ¿O porque sabes que la generó una IA y eso te molesta? ¿O porque no la pensaste tú? ¿O porque aceptarla implicaría admitir que alguien de fuera de tu dominio ha visto algo que tú no?

Separar el origen de la idea de la calidad de la idea es más difícil de lo que parece. Y si no tienes cuidado, puedes acabar rechazando buenas ideas por las razones equivocadas.

Entonces, ¿qué haces?

No puedes pedirle a tu jefe que deje de usar la IA. Ni deberías. Tampoco puedes ignorar todo lo que propone porque sospechas que viene de una IA. No sería inteligente.

Probablemente eso no ha cambiado tanto, antes también tenías que filtrar ruido, sólo que ahora el ruido está amplificado.

Se me ocurren tres cosas. Que no son muy diferentes de las que habría hecho antes de la IA.

1. Pregunta el “por qué” detrás del “qué”.

Cuando tu jefe te traiga una propuesta, evalúala como una conversación. Pregunta qué problema intenta resolver. Pregunta qué alternativas consideró. Pregunta qué pasa si no hacemos nada. Si las respuestas son vagas o genéricas, es probable que la reflexión haya sido superficial, independientemente de si usó IA o no.

No se trata de “pillarle”. Se trata de elevar la conversación del “qué” al “por qué.”

2. Añade el contexto que falta.

La IA no conoce tu contexto. Tú sí. Ese es tu valor diferencial ahora. Cuando llegue una propuesta sin contexto, tu trabajo es ponerlo.

“Esto tiene sentido en general, pero en nuestro caso hay tres factores que cambian la ecuación.”

Esa frase es más poderosa que un “no”.

3. Protege al resto del exceso de ideas.

Cada idea que baja de arriba consume energía. En tus compañeros, en tu equipo, en ti.

Aunque sea solo el coste de evaluarlas.

Hacer de filtro puede tener sentido. No todas las ideas merecen ser discutidas. No todas las propuestas merecen un análisis. A veces, la mejor contribución que puedes hacer es absorber el impacto de una idea mediocre para que tus compañeros y tu equipo pueda seguir enfocado en lo que importa.

Puede que eso fuese siempre parte del trabajo. Pero ahora el volumen se ha multiplicado.

La conversación

Si estás en esta situación, probablemente lo mejor es hablarlo con tu jefe.

No como una confrontación. No como

“sé que usas la IA para crear estas propuestas tan detalladas”

sino como una conversación honesta sobre cómo estáis trabajando juntos.

“He notado que estas generando más ideas y propuestas que antes. Necesito que hablemos de cómo las priorizamos, porque mi equipo y yo tenemos una capacidad finita de ejecución y energia y me gustaría que la gastemos en lo importante.

Eso es todo. No estás cuestionando la herramienta. Estás poniendo sobre la mesa una realidad operativa.

Si tu jefe es razonable, esa conversación os va a ayudar a los dos. Si no lo es... bueno, ese era un problema que existía antes de la IA.

Para terminar

Tu jefe usa la IA. Tu equipo usa la IA. Tú usas IA. Todo el mundo tiene ahora un consultor privado en el bolsillo.

La diferencia está en quién es consciente de las limitaciones de ese consultor y quién no.

La peor versión de esta historia es un directivo que genera estrategias sin contexto, un manager que no se atreve a cuestionarlas y un equipo que ejecuta cosas que nadie ha pensado en profundidad. Cada capa confiando en que la otra ha hecho el trabajo de pensar.

La mejor versión es una cadena donde cada persona añade lo que la IA no puede: contexto, juicio, honestidad y la valentía de decir “esto suena muy bien, pero no aplica a nosotros.”

Eso no es “resistirse a la IA”. Es usarla bien.

Si esta edición te ha resonado, considera reenviársela a alguien que también esté lidiando con esto. Cada nuevo lector nos acerca a una comunidad de managers más preparada.

Nos leemos.

P.D.: Si quieres profundizar:

• Ruido: Un fallo en el juicio humano, de Daniel Kahneman y otros. Para entender cómo el exceso de información y opiniones puede degradar la calidad de las decisiones en una organización, algo que la IA está amplificando sin que nos demos cuenta.

• The Advice Trap, de Michael Bungay Stanier. Sobre la tendencia compulsiva de los líderes a dar soluciones en lugar de hacer preguntas. La IA amplifica esa tendencia.

• Pensar en sistemas, de Donella Meadows. Para ver tu organización como un sistema donde cada nueva herramienta, incluida la IA, cambia los flujos de información, los incentivos y los bucles de feedback de formas que no siempre son obvias.

La entrega es la mejor que has visto nunca. Documentación impecable. Diagramas de arquitectura que parecen sacados de un libro de Martin Fowler. Tests de integración. Manejo de errores. Hasta hay un README con instrucciones de despliegue.

Miras a tu compañera de entrevistas. Ella te devuelve la mirada. Estáis impresionados.

Entonces empezáis a preguntar.

¿Por qué X en lugar de Y? Silencio.

¿Qué pasa si el token expira durante una operación crítica? Silencio.

¿Por qué la API devuelve un 200 con un body de error en vez de un 4xx? Mirada de ¿de qué hablas?

Cada pregunta es un pinchazo en un globo que se va desinflando despacio.

Os volvéis a mirar, esta vez sin saber qué hacer con lo que acabáis de ver.

El mapa ya no coincide con el territorio

Durante décadas, la industria del software construyó sus procesos de selección sobre una premisa implícita: la capacidad de producir código era un proxy razonable de la capacidad de pensar sobre el desarrollo de software.

Si alguien entregaba una prueba técnica bien resuelta, probablemente entendía los fundamentos.

La premisa nunca fue perfecta, siempre hubo gente brillante que fallaba en las entrevistas y gente mediocre que las aprobaba. No era un proxy que yo comprase, pero, desde luego, era un proxy habitual

La IA ha terminado de romper esa premisa.

Hoy, la capacidad de producir código no correlaciona con casi nada. Cualquier persona con acceso a un LLM puede generar código que parece competente.

Es como si llevases treinta años contratando pilotos pidiéndoles que hagan maquetas de aviones. Las maquetas eran un proxy razonable cuando solo las podía hacer alguien que entendía de aerodinámica. Pero si de repente cualquiera puede producir maquetas perfectas con una impresora 3D, tu proceso de selección ya no selecciona pilotos. Selecciona gente con acceso a una impresora.

Lo que se ha roto en cada nivel

Juniors

El cambio más dramático está aquí. Un junior con acceso a herramientas de IA puede producir output que, en la superficie, es indistinguible del de un desarrollador mid de hace tres años.

Esto genera dos problemas simultáneos:

Problema 1: no puedes distinguir al que entiende del que copia. Ambos te entregan el mismo código. La diferencia es que uno sabe por qué funciona y el otro no. Y esa diferencia solo se manifiesta cuando algo se rompe, que es exactamente cuando más necesitas que alguien entienda lo que hizo.

Problema 2: los buenos juniors se devalúan. Si no puedes distinguirlos de los que simplemente copian el output de IA, el mercado los trata igual. El junior que ha invertido meses en entender cómo funciona algo técnico compite con el que aprendió a promptear ayer. En el proceso de selección tradicional, ambos se ven igual.

Esto tiene una consecuencia perversa: desincentivas exactamente el tipo de aprendizaje profundo que necesitas que exista en tu organización.

Mids

Con IA, un mid puede ahora producir a un ritmo que antes era imposible. Genial.

El problema es que la capacidad de generar ha crecido mucho más rápido que la capacidad de pensar sobre el problema. Tu mid puede producir tres veces más código en un día. Pero, ¿puede revisar que todo esté como debería? ¿Puede reducir la complejidad? ¿Puede razonar sobre a dónde va el sistema a esa velocidad?

Eso no se acelera con IA.

Resultado: generas más código que nadie entiende del todo.

Siempre fue importante cuestionar las soluciones propuestas; hoy es más importante todavía que ayer.

Seniors

Aquí el problema es más sutil. Un buen senior siempre se definió por su juicio: la capacidad de tomar decisiones a todos los niveles, de saber cuándo una solución “correcta” es la solución equivocada en tu contexto, de oler los problemas antes de que aparezcan.

Hasta ahora ese juicio no se desarrollaba pidiéndole a un LLM cosas. Se desarrollaba escribiendo código, rompiéndolo, debuggeándolo, manteniendo sistemas en producción durante años. Se desarrollaba sufriendo las consecuencias de tus propias decisiones.

Los futuros seniors de tu organización que se forman ahora delegando la escritura de código a la IA, ¿habrán desarrollado ese juicio? No sabemos cómo será el proceso para ser senior en este nuevo escenario.

Seguro que surjirán nuevas formas de desarrollar ese juicio que aún no vemos. Pero si tengo que entrevistar hoy, todavía es la única forma que tengo de saber si alguien es senior. Medir su experiencia en la forma “antigua” de desarrollar software.

Lo que no ha cambiado

Hay cosas que ninguna herramienta de IA cambia en una contratación:

• La capacidad de comunicar ideas complejas. Esto sigue siendo igual de raro e igual de valioso.

• La disposición a decir “no sé, pero lo podemos averiguar”. Paradójicamente, más importante ahora que la IA te da la ilusión de saberlo todo.

• El instinto de simplificar. Cualquiera puede generar complejidad. Ahora es todavía más fácil que antes. Reducirla sigue siendo un arte humano.

• La capacidad de trabajar con otros seres humanos. Obviedad que seguimos evaluando mal porque no es una “hard skill”.

Si tu proceso de selección ya evaluaba bien estas cosas, enhorabuena. Estás mejor preparado que la mayoría para contratar en la era de la IA.

Pistas para el nuevo mapa

No tengo un framework de contratación perfecto para este nuevo momento. Creo que nadie lo puede tener todavía.

Lo que sí tengo son pistas. Cosas que parecen funcionar mejor que lo que teníamos. Y, que, si lo miro, no son tan diferentes de lo que me gustaba usar para reclutar antes de la IA.

1. Evaluar el razonamiento, no el artefacto.

Dejar de mirar lo que entregan. Mira cómo piensan sobre lo que entregan.

Que alguien sepa explicar sus decisiones, justificar los trade-offs, identificar problemas futuros. Si alguien te entrega una solución perfecta pero no puede explicar por qué descartó las alternativas, eso te dice todo lo que necesitas.

2. Evaluar con ambigüedad deliberada.

Los problemas bien definidos son los más fáciles de resolver con IA. Es más útil evaluar problemas donde no está claro ni qué hay que hacer. ¿La persona hace suposiciones y avanza sin validarlas? ¿Pide clarificación? ¿Identifica que hay información que falta? La capacidad de navegar la ambigüedad siempre fue importante. Hoy más.

3. La honestidad intelectual.

Haz preguntas cuya respuesta correcta es “depende” o “no lo sé”. Si alguien te da una respuesta contundente a algo que genuinamente no tiene respuesta clara, eso es una señal. En un mundo donde la IA te da respuestas con confianza absoluta sobre todo, necesitas gente que ponga más en duda lo que haces.

4. Observa cómo usan la IA, no si la usan.

No tiene sentido prohibir herramientas de IA en las pruebas técnicas. Ya forman parte del stack que usamos. Lo importante nunca fue qué herramientas usamos. Sino cómo las usamos, qué hacemos con ellas…

Pero… ¿Alguien está contratando?

Es posible que para ciertos roles, en ciertos contextos, necesites menos gente de la que necesitabas antes. Ya hablé sobre algo de esto en mi anterior newsletter.

También es posible que necesites contratar justo debido a este cambio de paradigma. Y, si lo haces, no puedes usar un Playbook de 2019.

Para terminar

Los procesos de selección siempre fueron imperfectos. La única forma real de saber si alguien funciona es trabajar con esa persona.

Lo que ha cambiado es que las imperfecciones que antes solíamos tolerar, evaluar la producción como proxy del conocimiento, ahora son inútiles.

No creo que nadie tenga todavía “la” respuesta de cómo contratar bien en este contexto.

Sí creo que los managers que empiecen a experimentar ahora, que ajusten sus procesos, que prueben cosas distintas, que se equivoquen y aprendan, van a tener una ventaja enorme sobre los que sigan usando el antiguo sistema.

Si esta edición te ha hecho replantearte algo sobre cómo contratas en esta nueva era, considera reenviársela a alguien que también esté lidiando con esto. Cada nuevo lector nos acerca a una comunidad de managers más preparada.

Nos leemos.

P.D.: Si quieres profundizar, te voy a recomendar libros que no van directamente sobre contratación pero que me han influido más que otros en cómo pienso sobre ello.

• Thinking in Bets, de Annie Duke. Contratar siempre es una apuesta, y evaluarla por el resultado (funcionó/no funcionó) en lugar de por el proceso es justo el error que la mayoría comete.

• Range: Why Generalists Triumph in a Specialized World, de David Epstein. Para entender por qué en un entorno cambiante como en el que estamos, la amplitud de conocimiento puede ser más valiosa que la profundidad en una herramienta concreta.

No han trabajado más horas. No han contratado a nadie nuevo. Simplemente han integrado herramientas de IA en su flujo de trabajo.

La demo fue impecable. La CEO está encantada. Y entonces, al final de la reunión, alguien suelta la pregunta:

“Si ahora podemos hacer lo mismo con menos gente... ¿necesitamos a toda esta gente?”

Y ahí se te congela la sonrisa.

Aritmética simple

La tentación es obvia: si un equipo de 8 hace ahora el trabajo de 20, ¿para qué necesitas 8?

Es irresistible para quien tiene que defender un presupuesto.

Hay un relato reconfortante que dice: “Tranquilos, esto ya ha pasado antes y siempre salió bien.” Y se apoya en ejemplos reales:

Cuando aparecieron los cajeros automáticos en los 80, cada sucursal bancaria redujo personal. Pero el menor coste de operar una sucursal hizo que los bancos abrieran más. El economista James Bessen documentó que el número total de empleados de banca en EE.UU. aumentó durante las dos décadas siguientes.

Cuando aparecieron las hojas de cálculo, muchos predijeron el fin de los contables. Hoy hay más que nunca.

Estas historias son reales. Pero hay que ser honesto con lo que no cuentan.

Lo que esas historias no cuentan

El empleo bancario subió tras los cajeros automáticos, sí. Pero a partir del año 2000 empezó a caer. La paradoja funcionó... durante un tiempo. Eventualmente, la tecnología sí redujo empleo. El relato optimista simplemente elige dónde cortar la película.

Y los contables: hay más hoy, cierto. Pero atribuirlo a las hojas de cálculo es confundir correlación con causalidad. El crecimiento económico, la complejidad fiscal creciente, la regulación... hay muchos factores que explican ese aumento. ¿Excel fue uno de ellos? Quizá ni el principal.

Estas analogías son útiles como punto de partida. Pero si las usamos como predicción, estamos asumiendo que el pasado predice el futuro.

El cambio es de otra naturaleza

Un cajero automático automatizaba una tarea mecánica concreta: dispensar billetes.

La IA no automatiza una tarea. Afecta a capacidades cognitivas transversales: escribir, razonar, sintetizar, programar, diseñar. Es como si en vez de inventar una máquina que hace una cosa, hubiésemos inventado un becario universal que hace muchas cosas de manera aceptable (aceptable por el momento, la calidad irá mejorando).

¿Significa eso que va a destruir empleo masivamente? No lo sé.

¿Significa que va a crear más empleo del que destruye? Tampoco lo sé.

Y quien te diga que lo sabe con certeza, probablemente miente o te intenta vende algo. Llevamos dos años viendo predicciones categóricas en ambas direcciones, y ninguna se ha cumplido todavía.

Lo que sí sé es que, como manager, no puedes esperar a que la academia y los economistas se pongan de acuerdo. Tienes que decidir ahora, con información incompleta. Como siempre.

La paradoja de Jevons

Antes de elegir, hay un patrón histórico que merece la pena tener en la cabeza.

Cuando la máquina de vapor se hizo más eficiente en el uso de carbón, el consumo total de carbón no bajó. Subió. La eficiencia hizo que usar carbón fuese rentable para muchas más aplicaciones. William Stanley Jevons documentó esta paradoja en 1865.

Es tentador aplicar esta lógica al trabajo cognitivo: si producir algo se vuelve dramáticamente más barato, la demanda debería explotar. Proyectos que antes no eran viables ahora lo son.

Pero ojo: Jevons hablaba de un recurso físico. Que la misma lógica aplique al trabajo del conocimiento es una hipótesis plausible, no un hecho demostrado. Podría pasar. O podría pasar que la demanda de ese trabajo tenga un techo que aún no vemos. O que la demanda crece pero se satisface con menos personas y más IA. No lo sabemos.

Lo que sí sabemos es que apostar todo a un solo escenario, ya sea “siempre se crea más empleo” o “esta vez todo se destruye”, es una mala estrategia. Las mejores decisiones en incertidumbre no intentan predecir el futuro. Intentan posicionarte bien en varios futuros posibles.

Con eso en mente, veamos las opciones (las que se me ocurren a mí, me encantaría saber las tuyas en los comentarios).

Las dos opciones

Opción A: Reducir equipo

Decides pasar de 8 a 5. Has “ahorrado” tres salarios. La dirección aplaude. Fin del trimestre, números bien.

Pero hay cosas que la hoja de Excel no captura:

• El conocimiento tácito se va. Las tres personas que salen se llevan contexto que nadie documentó. El equipo empieza a tomar decisiones sin entender por qué ciertas cosas se hicieron de cierta manera. Ya hablé sobre esto aquí.

• La diversidad cognitiva cae. Menos personas, menos perspectivas, menos capacidad para evaluar críticamente lo que la IA genera. Y la IA no te avisa cuando se equivoca.

• El miedo se instala. Los que se quedan miran a la IA y piensan: “Cuando siga mejorando, el siguiente soy yo.” Y tú, como manager, quizá estés pensando exactamente lo mismo sobre tu propio rol. Ese miedo no aparece en ningún informe, pero condiciona cada decisión.

• El incentivo que creas es perverso. El mensaje al resto de la organización es: “si te vuelves más productivo, te recompensan eliminando a tus compañeros (o a ti).” Buena suerte consiguiendo que el siguiente equipo adopte IA con entusiasmo.

¿Significa esto que reducir equipo es siempre un error? No. A veces es necesario. A veces es la decisión correcta. Pero deberías tomarla sabiendo lo que sacrificas, no solo lo que “ahorras”.

Opción B: Reinvertir la capacidad

Mantienes las 8 personas. Pero cambias lo que hacen.

Si tu equipo puede entregar en tres semanas lo que antes llevaba dos meses, tienes un excedente de capacidad enorme. La pregunta deja de ser “¿a quién sobra?” y pasa a ser “¿qué podemos hacer ahora que antes era imposible?”

• Atacar la deuda técnica que lleváis arrastrando tres años.

• Explorar ideas de producto que siempre se quedaban en el backlog eterno.

• Desarrollar nuevas capacidades en el equipo.

• Moverte más rápido que la competencia.

Suena bien, ¿verdad?

Pero también hay que ser honesto aquí: esta opción tiene sus riesgos. No todo equipo va a reinvertir bien esa capacidad. Mantener personas “por si acaso” sin un plan claro de reinversión no es estrategia, es miedo a decidir. Y justificar ante la dirección por qué no has reducido costes cuando podrías haberlo hecho requiere una narrativa sólida y resultados que la respalden. No va a ser fácil.

Pero... ¿y tu competencia?

Hay una dimensión que no puedes ignorar: no decides en el vacío. Tu competencia tiene acceso a las mismas herramientas que tú. Y también está tomando esta decisión ahora mismo.

Simplificando mucho, hay dos escenarios:

Si tu competencia recorta y tú no, tienes una ventana. Ellos tienen equipos más pequeños, más rápidos para lo que ya hacían, pero con menos capacidad para explorar, adaptarse o responder a lo inesperado. Tú tienes gente disponible para atacar lo que ellos han dejado de poder hacer: innovar, mejorar la calidad, entrar en segmentos que antes no eran viables. La capacidad que hoy parece “sobrante” puede ser exactamente lo que necesitas.

Si tu competencia reinvierte y tú recortas, tienes un problema. Ellos están usando el excedente de productividad para hacer más: más producto, más calidad, más velocidad de exploración. Tú has capturado un ahorro de costes a corto plazo, pero ahora estás compitiendo con un equipo más lean contra uno que tiene más capacidad de ataque. Y recuperar esa capacidad no es tan fácil como volver a contratar: el conocimiento perdido, la cultura rota, el tiempo de onboarding... reconstruir es siempre más caro que mantener.

No sabes qué va a hacer tu competencia. Es un dilema estratégico clásico, con un problema añadido: la decisión es difícilmente reversible. Recortar es rápido. Reconstruir, lento.

Eso no significa que la respuesta sea siempre “no recortes.” Significa que cuando calcules el “ahorro” de reducir equipo, deberías incluir en la ecuación el coste de equivocarte si el mercado se mueve hacia más, no hacia menos.

Para decidir, no para dormir tranquilo

No tengo una respuesta universal. Si la tuviese, desconfiaría de mí mismo.

Lo que sí creo:

• La decisión de reducir equipo es fácil de tomar y difícil de revertir. La de reinvertir capacidad es difícil de justificar y potencialmente transformadora. Las decisiones asimétricas merecen más reflexión.

• No tienes datos históricos para esta decisión. No hay benchmark. No hay “best practice.” No hay ningún sitio al que mirar. Las analogías con cajeros automáticos y hojas de cálculo ayudan a pensar, pero no son mapas del territorio que estás recorriendo.

• La honestidad sobre la incertidumbre me parece una ventaja. El manager que dice “no sé qué va a pasar, pero he aquí cómo me estoy preparando para varios escenarios” me genera más confianza que el que finge saber.

La paradoja de la productividad no tiene “solución”. Es una decisión con incertidumbre. Como casi todas.

Si esta edición te ha aportado algo o te ha dejado pensando, considera reenviársela a alguien a quien también le pueda interesar, o compártela en tu red social favorita. Cada nuevo lector nos acerca a una comunidad de managers más preparada.

Nos leemos.

P.D.: Si quieres profundizar:

• Learning by Doing, de James Bessen. Probablemente el análisis más riguroso de cómo la tecnología ha transformado el empleo históricamente. Útil para entender los precedentes, siempre que recuerdes que un precedente no es una profecía.

• The Jevons Paradox and the Myth of Resource Efficiency Improvements, de John M. Polimeni et al. Para entender por qué “más eficiente” no siempre significa “menos consumo”, y para preguntarte si eso aplica también aquí.

A las 11:03, Slack empezó a iluminarse.

Mensajes privados. Grupos paralelos. Conversaciones que empezaban con:

“¿viste lo que dijo?”

y terminaban con:

“mejor no decir nada”.

A las 11:15, todo el mundo sabía lo que todos realmente pensaban sobre la decisión que acababas de anunciar.

Excepto tú.

La reacción instintiva de la mayoría de managers es: “Tengo que conseguir que me lo digan a mí”. Entonces aparecen más 1:1s. Más “a mí podéis decirme lo que sea”. Más encuestas anónimas.

Y, adivina: no funciona.

Tu equipo ya te está dando información.

No con sus palabras. Con comportamientos.

Leyendo las “señales”

Hay tres tipos de señales que un equipo emite antes de que cualquier problema llegue a tu mesa. Las tres son visibles. Las tres suelen pasar desapercibidas.

1. La ausencia

Busca lo que desaparece.

La persona que solía proponer ideas y lleva tres semanas sin abrir la boca. El senior que antes cuestionaba las decisiones y ahora dice “vale, como queráis”. El que ahora responde con 👍.

Ninguna de estas cosas dispara una alarma. Pero cada una de ellas te está diciendo exactamente lo mismo: esa persona ya dejó de invertir energía.

La mayoría de managers detectan la desmotivación cuando ya es un problema de rendimiento. Pero la desmotivación puede empezar perfectamente con el silencio.

2. La velocidad de respuesta

Cuando le pides opinión a alguien de tu equipo sobre una decisión importante, cronometra mentalmente cuánto tarda en responder.

Si responde inmediatamente con “me parece bien”, probablemente no le parece bien. No ha tenido tiempo de pensarlo. Te está diciendo lo que quieres oír para que la conversación termine.

Si responde con preguntas: “¿qué opciones descartamos?” o “¿qué pasa si no funciona?”, está involucrado. Está pensando contigo. Muchas veces a las personas más involucradas las etiquetamos como “negativas” porque nos avisan de riesgos o nos ponen en duda. Pero traer preocupaciones es justo una señal de que la persona está invitiendo energía con nosotros.

3. El canal

Observa dónde habla tu equipo. No qué dice. Dónde lo dice.

Si las conversaciones relevantes ocurren en el canal público del equipo, hay confianza suficiente para pensar en voz alta. Si migran a DMs, la confianza está bajo mínimos. Si migran a WhatsApp o a la comida, la confianza no existe, tu equipo está buscando un espacio donde tú no estés.

No es que sean desleales. Es que tu canal oficial se convirtió en un espacio donde solo se dice lo seguro. Y cuando un canal solo tiene mensajes seguros, ya no tiene “información”.

Lo que no te he dicho

Estas tres señales no te dicen solo que algo pasa en tu equipo. Te dicen algo sobre ti.

Si tu equipo habla en canales donde tú no estás, no es porque sean tóxicos. Es porque aprendieron que hablar delante de ti tiene coste.

Quizá no un coste grande. Quizá no intencionado. Pero en algún momento, alguien dijo algo incómodo y el resultado no fue bueno. Y el equipo tomó nota.

No les preguntes qué piensan.

Pregúntate qué hiciste la última vez que te lo dijeron.

Esta semana

No montes una reunión para “mejorar la comunicación”. No mandes una encuesta. No digas “mi puerta está abierta” (por favor, no).

Haz una cosa:

Observa los últimos 30 días de tu canal de equipo o tus reuniones. Cuenta cuántas veces alguien cuestionó una decisión, propuso algo arriesgado o dijo “no estoy de acuerdo”.

Si el número es cero, ya sabes todo lo que necesitas saber.

Solo que hasta ahora no estabas mirando.

Nos leemos

Estaban analizando los datos de consumo de cientos de casas de una misma urbanización. Habían hecho eso miles de veces. Pero esta vez algo no cuadraba.

Después de unas horas, encontraron la anomalía.

La urbanización estaba separada en dos por un pequeño riachuelo. Las casas a un lado del arroyo gastaban un 30 % menos de electricidad de media que las del otro.

No tenía sentido. Las casas estaban muy cerca unas de otras, eran idénticas, construidas por la misma empresa y el mismo año.

Había que moverse rápido antes de que alguien de arriba se pusiese nervioso. Crearon todo tipo de hipótesis para explicar el fenómeno. Examinaron mapas geológicos, fotos de satélite, nacionalidad de los ocupantes. Ninguna funcionó. Bueno, una que implicaba una realidad con 15 dimensiones y unos alienígenas sí, pero no quisieron presentarla.

Se subieron a una de esas grandes rancheras que gastan más gasolina que un tanque y se dirigieron a la urbanización.

Empezaron a tocar puertas explicando que eran empleados de la compañía eléctrica y preguntando si podían visitar las casas. Las casas eran IGUALES.

Excepto por una pequeña cosa.

Una chiquitita.

Casi nada.

El contador de electricidad en las casas de un lado estaba instalado en el sótano. En las del otro, en el vestíbulo de la entrada.

Imagina a Mary o a John, propietarios de una casita blanca. Llegan del trabajo, abren la puerta y se topan con la medición de su gasto de electricidad. Cada día. Sin querer. In your face.

No habían cambiado los precios. No habían puesto multas. No habían lanzado campañas. Solo habían movido dónde estaba la información.

Y el comportamiento cambió un 30 %.

Uno de los puntos de apalancamiento más infravalorados de cualquier sistema es la estructura de los flujos de información.

No quién tiene la información.

No cuánta información hay.

Sino dónde está colocada y si llega a quien puede actuar.

Cuando la información se hace visible, aparece un bucle de retroalimentación.

Y cuando aparece el bucle, el comportamiento cambia.

Sin discursos. Sin incentivos. Sin castigos.

¿Dónde está el contador de tu organización?

Si tienes que pensarlo más de cinco segundos, está en el sótano.

El equivalente al contador en el sótano es esto: métricas que solo ve dirección. Feedback de clientes que llega tarde o filtrado. Datos “suavizados” para no molestar. Consecuencias que nunca vuelven al origen de la decisión.

Cuando la acción se separa de la consecuencia, el sistema deja de aprender. Y cuando el sistema no aprende, se degrada. Lo que aparece entonces no es casualidad, son síntomas estructurales: rumores, decisiones erráticas, desconfianza, agotamiento, política interna.

No basta con añadir más información. Hay que ponerla en el lugar correcto y de una forma que obligue a reaccionar.

El error que cometes como manager intermedio

Como manager intermedio, estás atrapado entre dos fuegos: arriba, gente que quiere resultados; abajo, gente que quiere contexto y sentido. Y en medio, información que se pierde, se maquilla o se frena “para no generar ruido”.

El error habitual es pensar que más transparencia genera caos. Que si enseñas ciertos datos, la gente se preocupará. Que “no es relevante para ellos”.

Así que escondes el contador.

Y luego te preguntas por qué la gente optimiza mal, las prioridades se confunden, se repiten los mismos errores y nadie asume responsabilidad real.

Has desconectado a la gente de las consecuencias de lo que hacen, y esperas que actúen como si las vieran.

Lo que puedes hacer

La buena noticia es que restaurar flujos de información es barato. Mucho más barato que cambiar estructuras, roles o jerarquías. No necesitas permiso para la mayoría de estos cambios.

1. Reconecta acción y consecuencia

Muestra impacto real: en usuarios, en producto, en costes, en carga del equipo. Que un desarrollador vea qué pasa con lo que construyó. Que quien diseñó el proceso vea cómo lo vive quien lo usa.

2. Lleva la información a quien puede actuar sobre ella

La pregunta no es “¿quién debería saber esto?” sino “¿quién puede hacer algo con esto?”. Ahí es donde tiene que llegar.

3. Haz visible el impacto

Tu equipo no necesita ver más dashboards. Necesita ver qué pasa cuando su trabajo llega al mundo.

Este post forma parte de una serie sobre los puntos de apalancamiento de Donella Meadows aplicados al management. Ya hemos visto que el éxito del equipo puede convertirse en su condena, que cambiar parámetros no arregla nada, que los buffers son esenciales, que la estructura de los flujos importa más que los números, que los bucles de feedback te mantienen vivo, y que los retrasos pueden matarte.

Nos leemos.

Hoy vamos a ver qué puedes hacer cuando sospechas que tu equipo ya está ahí.

Pero antes, algo importante.

Por qué experimentos (y no procesos)

Si tu equipo ya está saturado, un proceso nuevo es más carga. Aunque sea bueno, esté bien pensado o tenga sentido. Un proceso se vive como permanente.

Y cuando la energía está baja, genera dos reacciones muy humanas:

• resistencia pasiva, o

• cumplimiento mínimo sin compromiso.

Un experimento evoca prueba, test, marcha atrás posible. Y ese matiz lo cambia todo.

Porque:

• reduce el coste psicológico de la iniciativa,

• devuelve sensación de control a los implicados,

• y hace que el coste del fallo se viva como pequeño

Pero lo más importante es que estos experimentos están diseñados para hacer visible lo invisible. Buscan generar información sobre:

• cuánto se interrumpe,

• cuántos cambios están vivos a la vez,

• cuánta energía se está drenando

Con esto en mente, aquí van los cinco experimentos.

1. Inventario de cambios ocultos

Contexto

El equipo siente que “no para”, pero nadie sabría decir exactamente por qué.

Hipótesis

Si hacemos visibles todos los cambios activos, veremos que la carga real es mayor de lo que creemos.

Cómo funciona

Durante una semana, enumera todos los cambios activos, no solo los oficiales:

• cambios de prioridad,

• iniciativas “en preparación”,

• migraciones a medias,

• nuevas herramientas,

• cambios de rol,

• decisiones aún sin estabilizar.

Un cambio se considera activo desde que entra en preparación hasta que deja de generar fricción.

No se discute si “debería estar ahí”.

Solo se enumera.

Qué medir

• Número total de cambios activos.

• Sorpresa del equipo (“no sabía que esto contaba”).

Resultado esperado

Descubrir cuánto exceso de frentes abiertos invisibles tenías.

2. Coste explícito del cambio

Contexto

Todo parece asumible porque el coste nunca se pone encima de la mesa.

Hipótesis

Si cada cambio tiene que explicitar su coste, algunos dejarán de parecer tan obvios.

Cómo funciona

Cada nuevo cambio que entra debe responder, por escrito, a tres preguntas:

• ¿Qué dejamos de hacer para que esto entre?

• ¿Qué parte del equipo se verá más afectada?

• ¿Durante cuánto tiempo estará este cambio “vivo”?

No se bloquea todavía nada. Sólo se hace consciente.

Qué medir

• Conversaciones sobre posponer tras hacer explícito el coste.

• Conversaciones difíciles con stakeholders.

• Cambios que entran sin dueño claro.

Resultado esperado

Menos cambios por inercia.

Más decisiones reales.

Más conversaciones con stakeholders.

3. Rituales de cierre

Contexto

El equipo acumula trabajo abandonado que nunca se cierra del todo.

Hipótesis

Cerrar explícitamente el trabajo reduce la frustración, incluso si no se completa.

Cómo funciona

Cuando se abandona una iniciativa, se hace un cierre consciente, se da tiempo para:

• que el equipo hable de qué supone el cierre

• se documenten las decisiones clave tomadas,

• se deje el proyecto en un estado estable por si un día se retoma.

Y, en algunos casos, si crees que puede ser útil, crear un pequeño ritual de “cierre”. Puede ser enviar un mensaje de despedida (del proyecto) en un canal, dejar una marca en un mural o lo que se os ocurra.

No es lo importante el ritual. Lo importante es dar espacio al duelo de que ese trabajo no terminó como se esperaba.

Qué medir

• Percepción de “trabajo en vano”.

• Tiempo para retomar si se reactiva.

• Carga emocional del equipo.

Resultado esperado

El abandono deja de ser una herida abierta

y se convierte en una decisión asumida.

4. Triage de interrupciones

Contexto

Todo llega como urgente. El equipo vive en modo alarma.

Hipótesis

Si clasificamos las interrupciones, muchas dejarán de ser urgentes.

Cómo funciona

Durante 1–2 semanas, toda solicitud se clasifica como:

• Rojo: parar todo ahora

• Amarillo: evaluar en 24–48 h

• Verde: hacer en el próximo ciclo

Quien pide propone el color.

El manager (o una persona designada por el equipo) hace el triaje final.

Qué medir

• Trabajo completado.

• Emociones negativas del equipo.

Resultado esperado

El 60–70 % de las “urgencias” bajan de categoría

cuando hay que justificarlas.

5. La Semana de Blindaje

Contexto

El equipo no tiene nunca una semana limpia.

Hipótesis

Si aislamos al equipo de interrupciones durante cinco días, el rendimiento y la energía mejorarán.

Cómo funciona

Durante una semana:

• tú absorbes todas las interrupciones,

• el equipo solo trabaja en lo acordado el lunes,

• nada nuevo entra, lo pida quien lo pida.

Las urgencias se escuchan pero no interrumpen al equipo.

Qué medir

• Interrupciones bloqueadas.

• Trabajo completado.

• Emociones del equipo.

Resultado esperado

Aumento claro de output y descenso de estrés.

Para cerrar

Ninguno de estos experimentos arregla el problema por sí solo.

Pero todos hacen algo clave: hacen visible el daño.

Y esa es tu arma para levantar conversaciones y para proponer cambios.

Nos leemos.

El mensaje llegó un martes por la tarde.

“Mañana cambiamos prioridades. Nada grave, solo un pequeño ajuste.”

No era la primera vez.

De hecho, nadie recordaba la última semana sin uno.

El stand-up del miércoles duró poco.

Nadie discutió nada.

Alguien dijo “ok”.

Otra persona suspiró, apuntó algo en su libreta y siguió.

Un par de semanas después, alguien pidió una one-on-one.

No fue una sorpresa.

Tampoco la primera.

“He aceptado otra oferta. Me voy en un mes.”

La conversación fue correcta.

Agradable, incluso.

“No es nada concreto”, dijo.

“Simplemente siento que necesito algo distinto.”

Meses atrás ya había pasado algo parecido.

Otra persona.

Otro “no es nada personal”.

Seguimos trabajando, como antes.

Pero empezaron a repetirse las señales:

• tareas que se retrasaban cada vez más,

• decisiones que había que volver a discutir,

• retrospectivas cada vez más silenciosas.

Nada explotó.

Pero algo empezó a romperse.

El problema no son ni el cambio ni las personas

El colapso de equipos bajo cambio constante no es un problema de actitud.

Ni de falta de “resiliencia” individual.

Es el resultado de exceder la capacidad cognitiva y emocional humana.

El colapso ocurre cuando la tasa de cambio supera la capacidad de absorción del equipo durante suficiente tiempo.

No cuando hay un cambio. Ni siquiera cuando hay un pico.

Cuando hay demasiados cambios vivos a la vez durante un tiempo sostenido.

Cambios que requieren:

• aprender algo nuevo (hola IA),

• reorganizarse,

• asumir incertidumbre,

• rehacer trabajo,

• coordinarse de otra forma.

Un cambio puntual no rompe un equipo, pero la acumulación sostenida sí.

Lo peligroso no es lo visible

La “tasa de cambio” es cuántos cambios están activos al mismo tiempo.

Un cambio cuenta desde que:

• entra en preparación,

• se discute,

• se prueba,

• y se estabiliza.

La capacidad de absorción se manifiesta en algo muy concreto: la energía del equipo.

Cuando durante varias semanas seguidas:

• la energía baja,

• aparecen emociones como frustración, cansancio, miedo, tristeza o confusión

Es un signo de que el equipo ya está saturado.

Qué pasa cuando el equipo colapsa

Primero, el trabajo se degrada.

Llegan tarde las entregas. Baja la calidad. Aparecen errores nuevos.

Después, empieza la rotación.

Y cuando la ves, ya es tarde. Quien se va llevaba semanas desconectando en silencio.

Cada salida no solo resta capacidad.

Genera:

• vacío de conocimiento,

• más carga para los que se quedan,

• Y una pregunta que nadie dice en voz alta, pero que está en la cabeza de todos:

“Si esta persona se fue… ¿debería irme yo también?”

No necesitas motivación. Necesitas diseño.

Cuando un equipo está saturado, la respuesta habitual es empujar desde lo individual.

“Un último esfuerzo.”

“Esto es importante.”

“Hay que ser resilientes.”

“Es solo una temporada.”

Eso funciona una vez. Quizá dos.

Después, lo único que consigues es que la gente se desconecte emocionalmente para poder seguir funcionando.

Por eso hablar de resiliencia aquí es un error de diagnóstico.

La resiliencia individual sirve para absorber impactos puntuales.

No para vivir permanentemente por encima del límite.

Lo que sí funciona es diseñar explícitamente cómo el sistema absorbe el cambio.

Y aquí viene mi tesis:

No empiezas creando procesos nuevos. Empiezas haciendo visible el daño real que ya estás generando.

Nadie cambia nada que no siente como un problema.

Por eso los experimentos funcionan mejor que los procesos.

Mi propuesta aquí es que empieces con experimentos que te muestren:

• Cuánto interrumpes de verdad, no cuánto crees,

• Cuánto trabajo se abandona sin cerrar, y qué efecto tiene,

• Cuánto desgaste del equipo estás acumulando, aunque nadie lo diga en voz alta.

No arreglarán el problema por sí solos.

Pero harán visible lo que hasta ahora era invisible.

—

Los equipos no colapsan por cambiar.

Colapsan cuando los cambios son demasiados para ellos.

Y eso, casi siempre, se podría haber visto antes.

Nos leemos.

P.D: En la próxima entrega voy a compartir 5 experimentos muy concretos que puedes usar para detectar y frenar el colapso antes de que sea irreversible.