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.

Tu equipo acaba de entregar. Otra vez. Mientras otros equipos se estancan, vosotros cumplís. Mientras otros se quejan, vosotros resolvéis.

El lunes a las 9:00, un mensaje de tu director:

“Necesitamos que os hagáis cargo de esto también. Vosotros siempre sacáis las cosas adelante”.

Y ahí está.

El premio por hacer bien tu trabajo: más trabajo.

Un bucle que se autorefuerza

En terminología de sistemas, un bucle de retroalimentación positiva (o bucle positivo) es un motor de amplificación.

Cuanto más ocurre algo, más probable es que siga ocurriendo.

Cuanto más dinero tienes, más intereses generas, más dinero obtienes.

Cuanto más éxito tiene un producto, más usuarios llegan, más visibilidad obtiene, más éxito acumula.

Y, por supuesto, cuanto más trabajo asume un equipo competente, más trabajo le dan.

Los bucles positivos son motores del crecimiento, pero también pueden ser las semillas del colapso.

El equipo estrella que absorbe todos los proyectos termina agotado.

La empresa que crece sin procesos se vuelve inmanejable.

Tu organización está llena de bucles positivos disfrazados de mérito

En sistemas existe un patrón llamado success to the successful: los ganadores reciben recursos que les permiten ganar todavía más la próxima vez.

En economía es evidente:

• Cuanto más rico eres, más intereses cobras.

• Cuanto más rico eres, más expertos puedes contratar para ganar más dinero y pagar menos impuestos.

En tu organización ocurre lo mismo:

• Equipos competentes que reciben más tareas hasta saturarse.

• Managers eficientes que heredan todos los problemas porque “saben resolverlos”.

• Culturas que premian la visibilidad sobre el aprendizaje, amplificando el ruido y castigando la pausa.

Un ejemplo conocido

En Google, durante años, los lanzamientos de nuevos productos se han premiado con visibilidad y progresión interna. El resultado no fue calidad sostenida, sino un cementerio de productos iniciados y abandonados (Reader, Google+, Wave, Inbox, Stadia…).

A nivel individual, lanzar algo nuevo era una estrategia racional.

A nivel sistémico, el bucle premiaba el inicio, no el mantenimiento.

Y la compañía acabó pagando el precio.

En todos estos casos, el sistema se acelera más rápido de lo que sus bucles compensadores pueden corregir.

Y entonces aparece el caos.

Cómo detectar que el bucle positivo ya está en marcha

Meadows advirtió que cuando un bucle positivo gira demasiado rápido, el sistema entra en un estado caótico: comportamiento impredecible, oscilaciones violentas y pérdida de control.

Eso pasa con epidemias, burbujas financieras… y con equipos.

Las señales suelen ser estas.

1. Concentración en los mismos

Si siempre son las mismas personas o equipos quienes reciben proyectos críticos, visibilidad o reconocimiento, el bucle ya está activo.

La lógica parece impecable:

“Démosle esto a Ana, que sabemos que lo hará bien”.

Pero cada vez que pasa, Ana acumula más experiencia, más credibilidad y más confianza organizativa.

La próxima vez, darle el siguiente proyecto crítico parece todavía más obvio.

Mientras tanto, otras personas nunca llegan a tener la oportunidad.

2. La velocidad se vuelve adictiva

El equipo entrega rápido.

Eso genera más demanda.

La demanda genera presión.

La presión lleva a atajos.

Los atajos crean deuda técnica.

La deuda hace que la siguiente entrega sea más difícil.

Y entonces la única respuesta que parece viable es ir todavía más rápido.

Llega un punto en el que nadie recuerda cuándo fue la última vez que hicisteis algo bien, en lugar de simplemente hacerlo deprisa.

3. No hay tiempo para frenar

Cuando propones mejorar procesos, documentar o formar a alguien nuevo, la respuesta es siempre la misma:

“Ahora no, hay demasiado trabajo urgente”.

Pero precisamente porque nunca hay tiempo para esas inversiones, el trabajo urgente no deja de crecer.

Cuanto más urgente es todo, menos capacidad tienes de reducir la urgencia.

El bucle se refuerza.

4. El sistema oscila

El sistema deja de crecer de forma estable y empieza a oscilar. Un pequeño empujón más y todo entra en caos.

En equipos, a veces se ve así:

• Euforia tras una gran entrega

• Todo el equipo al 100 %

• Agotamiento, errores, crisis

• Esfuerzo sobrehumano para recuperar

• Euforia temporal

• Y vuelta a empezar

Si tu equipo alterna entre “lo estamos petando” y “estamos al límite”, es un bucle positivo fuera de control.

Qué puedes hacer como manager

La intervención clave en un bucle positivo no es reforzarlo.

No hacerlo más fuerte, sino más lento.

1. Detecta los bucles de “éxito al exitoso”

Pregúntate:

• ¿Quién siempre recibe los proyectos críticos?

• ¿Quién nunca los recibe?

• ¿A quién pedimos ayuda cuando hay problemas?

• ¿Quién tiene visibilidad con dirección?

• ¿Quién no?

Si las respuestas se repiten, el bucle está activo.

2. Reduce la ganancia del bucle

Di “no”. Limita la expansión. Distribuye mejor la carga.

Sé que suena irrealista. Tu jefe te pide más velocidad, no menos.

Pero aquí está la trampa: si el bucle sigue acelerándose, acabará colapsando de todas formas.

Solo que entonces no decidirás tú cuándo ni cómo.

Reducir ahora es elegir una desaceleración controlada en lugar de esperar a que explote.

3. Refuerza los bucles compensadores

Los bucles negativos no son malos. Son elementos de compensación. Ya hablé de esto aquí.

Sin ellos, el crecimiento se convierte en una pendiente sin retorno.

Protege espacios de:

• Descanso: slack real en la planificación

• Formación: aprender, no solo ejecutar

• Revisión: parar y pensar

Parecen lujos cuando todo va rápido.

En realidad, son los únicos mecanismos que evitan que el sistema se descontrole.

4. Redistribuye oportunidades

Diseña el sistema para que el éxito no se concentre siempre en las mismas personas.

Algunas formas concretas:

• Rotación de proyectos críticos

• Mentoría o pairing: quien siempre resuelve, enseña a otro

• Visibilidad distribuida en demos y presentaciones

Si siempre ganan los mismos, el sistema se polariza.

5. Cuestiona la narrativa del crecimiento continuo

En muchos equipos, el mantra es "scale or die". Y eso no siempre tiene sentido (ojo, que, como todo, hay contextos puntuales en los que sí lo tiene).

A veces crecer más despacio es una forma más inteligente de sobrevivir. Es permitir que los mecanismos de regulación alcancen al sistema.

Si te lo puedes permitir, es mejor frenar el coche cuando vas demasiado rápido que pedir frenos más potentes después de chocar.

En conclusión

Los bucles positivos te dan impulso, son necesarios, pero sin bucles negativos que los regulen, te pueden llevar al caos.

Nos leemos.

P.D.: Este post forma parte de una serie sobre los puntos de apalancamiento de Donella Meadows aplicados al management. Ya hemos visto 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.

Convocas una reunión de emergencia con tu equipo.

—¿Qué hacemos?

Opción A: Decidir rápido. Comunicar en 24 horas. Actuar ya.

Opción B: Frenar. Analizar. Tomarte una semana para “entender bien el problema”.

¿Cuál es la correcta?

Antes de responder, conviene notar algo.

Cuando pasa algo así, la presión no viene solo del negocio.
Viene de una incomodidad más básica: no saber qué está pasando.

En psicología se llama need for cognitive closure: la necesidad de tener una respuesta cuanto antes para dejar de sentir la incomodidad de no saber, aunque esa respuesta sea mala.

Muchas decisiones en crisis no nacen de claridad, sino de esa urgencia por cerrar.

No todas las crisis son iguales

En cada crisis hay muchas variables.
Tu trabajo es identificar cuál domina, porque eso determina la velocidad correcta.

El problema es que el need for cognitive closure empuja siempre en la misma dirección: hacer algo ya, sea lo que sea.

Y no todas las crisis castigan el mismo error.

Crisis de supervivencia

La variable dominante es el tiempo

Marzo de 2020.

Airbnb pierde el 80 % de su negocio en ocho semanas.

Muchos advisors le dicen:

“Tómate tu tiempo.”

Brian Chesky hace lo contrario.
Acelera.

¿Por qué?

Porque cada día sin decisión era un día en el que:

• el equipo especulaba,

• la gente con más opciones miraba fuera,

• y la empresa perdía margen de maniobra.

Aquí acelerar no era cerrar por ansiedad.
Era preservar margen de maniobra.

En una crisis de supervivencia no puedes permitirte el tiempo de “recopilar la información completa”.
Esperar no reduce el riesgo. Lo aumenta.

En este contexto, parar para decidir mejor tiene más coste que actuar.

Crisis de claridad

La variable dominante es el entendimiento

Aquí es donde más managers fallan.

No porque sean imprudentes, sino porque no soportan quedarse demasiado tiempo sin respuesta.

El negocio no se hunde mañana.
Hay recursos. Hay margen.
Pero algo no funciona… y no sabes bien qué.

En este contexto, acelerar no te salva.
Te hace fallar más rápido.

Ir deprisa hacia un sitio que no sabes si es el correcto no es ejecución.
Es necesidad de cierre cognitivo disfrazado de acción.

Necesidad de cierre cognitivo

Un concepto psicológico desarrollado por Arie Kruglanski. 

Describe la motivación por obtener una respuesta definitiva (cualquier respuesta) en lugar de permanecer en la incertidumbre. 

Las personas con alta necesidad de cierre tienden a cerrar decisiones más rápidamente, buscar menos información alternativa y resistirse a cambiar de opinión una vez formada una explicación.

No se trata de buscar la respuesta correcta, sino de escapar del estado de ambigüedad, especialmente bajo presión temporal o fatiga mental.

Decidir rápido aquí no es “liderazgo”.
Es una forma elegante de huir de la incomodidad de no entender todavía.

Crisis de cohesión

La variable dominante es la alineación

También hay crisis donde el problema no es externo.

Es interno.

Todo el mundo tiene datos.
Todos quieren ir rápido.
Pero cada cual empuja en una dirección distinta.

Sin una visión compartida, acelerar la ejecución no resuelve nada.
Amplifica el problema.

Este no es un modelo para clasificar la realidad.

Es un modelo para decidir a qué velocidad moverte sin empeorar el problema.

Para eso, estos tres tipos son suficientes.

¿Y si hay varias a la vez?

Entonces la pregunta no es qué opción suena mejor.

Es esta:

¿Cuál, si la ignoro, tendrá un impacto importante primero?

Esa es tu variable dominante.

La pregunta correcta

La próxima vez que enfrentes una crisis, no te preguntes:

“¿Debo ir rápido o despacio?”

Pregúntate:

• ¿Qué tipo de crisis tengo delante?

• ¿Cuánto de mi prisa viene del problema y cuánto de mi necesidad de cierre cognitivo?

En una crisis, la velocidad incorrecta es peor que no decidir.

Nos leemos.

Un miembro de tu equipo te interrumpe delante de todo el equipo:

—Espera, ¿cuándo cambiaron esto? Llevo tres días trabajando en lo que dijimos el viernes.

Silencio incómodo. Ocho personas te miran esperando tu respuesta.

—Quería esperar a tener más claridad antes de preocuparos.

Todos asienten sin decir nada. Acabas de perder credibilidad.

Habrás oído eso de que un manager tiene que hacer de paraguas. Parar los golpes para proteger al equipo.

Pero… ¿Es realmente así?

Qué pasa cuándo haces de paraguas

Anton tiene 9 años de experiencia como Engineering Manager. Cuenta algo que pocos admiten en público:

—En mi primer rol me dijeron que mi trabajo era ser el “shit umbrella” del equipo. Mi misión era protegerlos del caos de la organización.

Así que hizo lo que le dijeron:

• Peleaba con Product Management a puerta cerrada.

• Ocultaba malas noticias.

• Vendía cada cambio como “el último”.

• Ponía buena cara aunque todo estuviese ardiendo a su alrededor.

El resultado fue predecible:

—Creé una falsa sensación de estabilidad. Cuando la realidad se coló, mi equipo no estaba preparado. Y yo perdí credibilidad.

La metáfora del paraguas suena noble. Pero es fácil caer en el paternalismo y construir un equipo débil, que se rompe ante la primera presión.

“El trabajo del líder no es hacer que la gente se sienta cómoda. Es hacer que la gente sea capaz.”

—Brené Brown, investigadora de liderazgo

Los dos extremos (y por qué ambos fallan)

Los dos extremos entre los la mayoría de managers pendulan son:

El protector

Filtra todo. El equipo vive en una burbuja. Hasta que un día descubre que la empresa lleva meses en problemas.

El transparente

Comparte todo el caos sin filtro. Cada rumor, cada duda del CEO, cada borrador de cambio. El equipo vive en una montaña rusa perpetua.

Ninguno de los dos funciona.

El espectro de protección

Imagina un espectro con cinco niveles:

Nivel 1 - Abandono

—Que se enteren por LinkedIn de la reestructuración.

Si esto pasa te arriesgas a perder mucha confianza.

Nivel 2 - Información en bruto

—Os cuento todo lo que sé, sin filtrar ni interpretar.

El equipo tiene que interpretar información para la que, en ocasiones, no tiene todo el contexto. Puede llevar a interpretaciones erróneas.

Nivel 3 - Traducción con contexto

Compartes lo que afecta su trabajo. Y das el contexto del negocio, la estrategia y el producto.

Comunicas el nivel de certeza que tienes:

—Hay un 70% de probabilidad de que esto pase.

Y eres explícito sobre qué controlas y qué no.

Compartir lo que está pasando, aunque sea incierto, siendo claro sobre dónde tienes agencia y dónde no.

Nivel 4 - Filtro selectivo sin explicar

—Confiad en mí, esto es lo que hay que hacer.

Es fácil y rápido. Y te hace sentir bien. Pero construyes dependencia hacia ti.

Nivel 5 - Burbuja total

—Todo está bien. No os preocupéis.

El peligro aquí es crear un equipo frágil, que no sabe reaccionar cuando la realidad se desvela.

Por qué muchos managers se quedan atascados en los niveles superiores

No suele ser mala intención.

Por qué ocultar genera más problemas

—Si cuento que el board cuestiona a nuestro equipo, se deprimirán o se irán.

Lo que pasa en realidad: el equipo nota que algo no encaja, especula sin información y construye su propia explicación. Que puede ser perfectamente peor que la verdad.

Tu equipo puede procesar información difícil.

Al no compartir esta información no únicamente no les das claridad, sino que les quitas la posibilidad de actuar de maneras que arreglen el problema.

“La gente puede gestionar la verdad. Lo que no pueden gestionar es la sensación de que les están ocultando algo.”

—Ed Catmull (cofundador de Pixar, autor de Creativity, Inc.)

Creer que tu valor está en resolverlo todo

Esta es extremadamente común.

—Me pagan para que el equipo no tenga que lidiar con esto.

Error.

Te pagan para conseguir resultados. Y es más difícil si ocultas la realidad.

La trampa del “este es el último cambio”

Reid Hoffman explica que PayPal pivotó cinco veces en quince meses.

Cada vez, algunos managers intentaban proteger a sus equipos diciendo:

—Ahora sí. Este es el cambio definitivo.

Dos semanas después: otro cambio.

Y ahí moría su credibilidad.

No puedes prometer lo que no está en tu control.

En situaciones difíciles igual pierdes gente del equipo que no quiere pasar por esa situación. Quizá no todo el mundo se queda. Pero los que se queden, se quedarán para construir contigo.

Intentar “proteger” ocultando un cambio importante solo retrasa lo inevitable

Y convierte una separación profesional en un divorcio amargo.

“La planificación a largo plazo es una contradicción en términos. La planificación es para el corto plazo. La estrategia es para el largo plazo.”

—Peter Thiel (cofundador de PayPal)

Cómo bajar del nivel 5 al 3

Antes de filtrar algo, pregúntate dos cosas:

1. ¿Cuál es la probabilidad o confianza de que realmente pase?

2. Si el equipo supiera esto, ¿tomaría decisiones muy diferentes?

Si hay una probabilidad pequeña de que pase, puedes generar más ruido que señal. Pero si la probabilidad es suficiente y el cambio sobre cómo toman decisiones no es trivial, merece la pena comunicar.

Ejemplo:

—Hoy se ha hablado de la posibilidad de cambiar las fechas de entrega.

(No es una decisión firme. No consideras que la posibilidad de que realmente pase sea alta.)

—Hoy hemos estado hablando del roadmap de Q2 y tiene pinta de que lo cambiaremos; creo que deberíamos considerar priorizar el trabajo que podamos cerrar en dos semanas.

(Hay una alta probabilidad de que pase y cambia qué decisiones se toman.)

Comunica tu nivel de incertidumbre

Usa una secuencia como esta:

• lo que sabemos, da el contexto completo,

• reconoce lo que no sabes,

• invita al equipo a pensar contigo,

• qué cambia para nosotros,

• cuándo sabremos más

La idea es generar claridad sobre cuál es el nivel de incertidumbre.

Los equipos que practican esto tienen más posibilidades de no romperse cuando las cosas se ponen difíciles.

Mañana, cuando tu equipo te pregunte:

—¿Por qué no nos dijiste nada?

Ya sabes qué responder.

—Creo que hay un 70% de probabilidad de que el roadmap de Q2 cambie. Si no llegamos a break even antes de fin de año, hay riesgo de no conseguir la siguiente ronda de financiación y eso lo cambia todo. Creo que tendríamos que priorizar el trabajo que podamos cerrar en dos semanas. Os cuento más después de la reunión con el VP.

Nos leemos.

No hubo email de IT.

No hubo aprobación de un comité.

No hubo debate estratégico.

Simplemente pasó.

Un manager copió datos de rendimiento del equipo en ChatGPT “para que sonara más profesional”.

Otra persona pegó resultados de una encuesta interna para “detectar patrones”.

Alguien subió un borrador de presupuesto “solo para revisar errores”.

Nada raro. Nada malintencionado. Todo práctico.

Y sin darse cuenta, la empresa empezó a contarle cosas a un tercero que no estaba en la conversación y que no tiene los mismos incentivos para cuidar de esos datos.

La conversación que nadie decidió tener

Nadie se saltó una norma.

Nadie ignoró una formación de seguridad.

Nadie hizo nada explícitamente incorrecto.

Porque no había reglas.

Así que la gente hizo lo que siempre hace: usar la herramienta que le ahorra tiempo y fricción.

Y estas herramientas son extraordinariamente buenas.

Redactan feedback en segundos.

Analizan encuestas.

Ayudan a encontrar el tono correcto en conversaciones delicadas.

Pero cada dato que se introduce sale del perímetro de la organización.

Esto ya pasó antes

Este debate no es nuevo.

Es el mismo que tuvimos con el cloud hace años.

Durante mucho tiempo, subir datos sensibles a servidores externos parecía una locura. Hoy nadie se pregunta si puede tener la facturación en un SaaS o el P&L en Google Drive.

¿Qué cambió?

No los datos.

El sistema.

Contratos. Responsables claros. Auditoría. Consecuencias legales.

La organización decidió qué herramientas merecían confianza.

Con los modelos de lenguaje, hoy, esa decisión todavía no la ha tomado la empresa.

La está tomando cada persona, en solitario.

Y ahí empieza el problema.

Tu posición no es cómoda

No decides la estrategia de ciberseguridad.

No defines la política de IA.

No eliges qué herramientas están aprobadas.

Pero sí lideras un equipo que gestiona información sensible.

Y eres responsable de lo que ese equipo hace con ella.

El problema es simple y desagradable: probablemente no sabes qué están usando.

Estas herramientas no requieren instalación.

No pasan por IT.

No dejan rastro visible.

No porque sean intrínsecamente peligrosas, sino porque no están institucionalizadas.

Alguien abre una pestaña, pega un texto, obtiene una respuesta y sigue con su día.

Mientras tú estás en otra reunión pensando que todo está bajo control.

Seamos honestos: tú también las has usado.

Estás redactando feedback y te bloqueas.

Necesitas decir que una actitud está afectando al equipo sin sonar acusatorio.

Una de esas herramientas te da tres versiones en diez segundos.

Funciona. Es rápido. Y nadie se entera.

Lo que realmente está en juego

Si te preguntan qué información no debería salir nunca de los sistemas bajo control de la empresa, dirías: estrategia, finanzas, datos personales.

Pero la información más dañina rara vez está en esa lista.

Está en:

• performance reviews

• conflictos no resueltos

• planes que aún no existen oficialmente

• análisis de quién está frustrado y por qué

• comparativas salariales

Esto no suele destruir la empresa.

Pero puede destruir la confianza.

Y la confianza no se recompone fácilmente.

¿Cómo le explicas a alguien de tu equipo que sus preocupaciones confidenciales han salido del sistema de la empresa porque necesitabas redactar más rápido?

El dilema

Desde arriba te piden eficiencia.

Desde abajo, tu equipo ha descubierto herramientas que ahorran horas.

Y tú estás en medio preguntándote:

• ¿Prohíbo algo que oficialmente no está prohibido?

• ¿Permito algo que sé que tiene riesgo?

• ¿Espero a que alguien de arriba decida?

Ninguna opción es cómoda.

La prohibición no funciona

“Queda prohibido usar ChatGPT o herramientas similares.”

Resultado previsible:

• Uso en la sombra

• Cero aprendizaje organizativo

• Falsa sensación de control

Prohibir es fácil. Gobernar sistemas es lo difícil.

Lo que puedes hacer hoy

No puedes esperar a la política perfecta de IT.

Lo que sí puedes hacer es tener una conversación explícita con tu equipo y crear un criterio compartido.

Tres preguntas para empezar:

• ¿Qué información gestionamos que no debería salir de nuestro ámbito?

• Si usamos herramientas externas, ¿qué precauciones tomamos?

• ¿Qué hacemos si alguien se equivoca?

Esto no resuelve el problema técnico.

Pero evita que el equipo opere con inconsciencia.

Lo que las organizaciones que lo hacen mejor entienden

Parten de una premisa incómoda: cualquier dato puede filtrarse.

Y diseñan desde ahí.

• Infraestructura: Herramientas internas con garantías contractuales, instancias enterprise para datos críticos, APIs con control sobre qué se guarda y qué no, políticas de retención claras.

• Cultura: Clasificación explícita de información sensible, conversaciones reales, auditorías sin castigo.

• Legal: Acuerdos y responsabilidades bien definidos.

La mayoría de las empresas no está aquí.

Y no lo estará a corto plazo.

El problema no es la IA.

El problema es que la gente necesita estas capacidades y la empresa no se las ofrece todavía de forma segura.

Mientras tanto, tú sigues siendo responsable de lo que pasa en tu equipo.

La pregunta

Alguien de tu equipo está usando un modelo de lenguaje con información sensible.

Y tú no lo sabes.

No tienes un problema de IA.

Tienes un problema de visibilidad.

Y eso no lo soluciona una política que aún no existe.

Lo soluciona una conversación honesta sobre qué información gestionamos, qué sistemas merecen confianza y qué riesgos asumimos sin darnos cuenta.

El futuro no es con IA o sin IA.

Es con herramientas individuales o con sistemas gobernados por la organización.

Y eso es un problema de management, no de IA.

PD: Uso IA a diario. Me parece extraordinariamente útil. Precisamente por eso merece ser usada con criterio, no prohibida por miedo ni adoptada a ciegas.

PD2: Otro día hablamos de cómo estos modelos tienen el riesgo de homogeneizar decisiones de management.

PD3: Si esto te ha hecho pensar, probablemente le sirva a otro manager que conozcas.

Compartir

No fue un hackeo. No fue un desastre natural. Fue una actualización de software.

Habían eliminado una comprobación porque “ralentizaba los deploys”. El código defectuoso se desplegó directamente a producción y comenzó a ejecutar órdenes erráticas. En menos de una hora, la empresa estuvo al borde de la bancarrota.

Lo curioso es que tenían la defensa diseñada. Sabían que era necesaria. Pero alguien decidió que era prescindible.

Y probablemente tú estás eliminando algo similar ahora mismo.

El termostato de tu casa es más inteligente que tu organización

Un termostato es ridículamente simple. Tiene tres componentes:

• Un objetivo: la temperatura deseada (22 °C, por ejemplo)

• Un sensor: el termómetro que mide la temperatura real

• Un mecanismo de corrección: la caldera o el aire acondicionado que actúa

Cuando hace más frío de lo deseado, el termostato detecta la desviación y actúa. Cuando la temperatura sube demasiado, deja de hacerlo. El sistema se autorregula sin que tengas que hacer nada.

En dinámica de sistemas, a esto se le llama un bucle de retroalimentación negativa. No porque sea “malo”, sino porque corrige desviaciones y devuelve el sistema a su estado deseado.

Con ese bucle simple, tu casa mantiene una temperatura estable 24/7.

Tu equipo también necesita termostatos

En una organización, estos bucles de feedback son los mecanismos que detectan desviaciones y las corrigen antes de que el sistema colapse:

• Postmortems que identifican qué salió mal y cómo evitarlo

• One-on-ones que detectan tensiones antes de que exploten

• Tests automáticos que impiden que algo roto llegue a producción

• Revisiones de código que atrapan errores antes del deploy

No son burocracia. Son termostatos.

Y aquí viene el problema.

El error que comete todo el mundo (incluido tú)

Existe un patrón que se repite:

Alguien propone eliminar un proceso porque “ralentiza el trabajo” o “ya no es necesario”.

El razonamiento es tentador:

“Hace meses que no tenemos incidentes, ¿para qué mantener esto?”

o

“Los postmortems nos quitan tiempo de desarrollo real”.

Y tienes presión. Tu jefe pregunta por qué tu equipo va más lento que otros. Tu equipo se queja de las “reuniones inútiles”. Tú quieres demostrar que puedes mover las cosas rápido.

Así que lo elimináis.

En el corto plazo, todo parece ir mejor. El equipo celebra la victoria contra la burocracia. La velocidad aumenta. Te felicitas por “una decisión valiente”.

En el largo plazo, has desconectado el termostato.

Y cuando llega el verano (o el invierno), tu casa se vuelve inhabitable.

Es exactamente lo que le pasó a Knight Capital.

Cuando el termostato deja de funcionar (aunque nadie lo toque)

Un bucle de feedback puede fallar en cualquiera de sus tres componentes:

1. El objetivo no está claro

Si el equipo no sabe cuál es el estado deseado, no puede saber cuándo se desvía.

“Entregar software de calidad” no es un objetivo. Es una intención vaga.

“Mantener el tiempo de respuesta de la API por debajo de 200 ms en el percentil 95” sí lo es. Es medible, específico, verificable.

2. El sensor está bloqueado

Los sensores en tu equipo son conversaciones, métricas, reportes, one on ones…

Pero pueden fallar:

• Por miedo: Nadie reporta problemas porque temen ser culpados. Ya hablé sobre esto en Cómo crear un entorno donde cualquier persona de tu equipo se atreva a hablar.

• Por filtros: La información se maquilla antes de llegar arriba

• Por ruido: Hay tantas alertas que lo importante se pierde

• Por retraso: Cuando la información llega, el problema ya es crítico (escribí sobre esto aquí).

Un sensor roto es peor que no tener sensor. Te da una falsa sensación de control.

3. El mecanismo de corrección es débil

Puedes tener un objetivo claro y un sensor perfecto, pero si no hay forma de actuar capaz de corregir, el bucle no sirve.

Es como un termostato que detecta que hace frío pero tiene la caldera rota.

En los equipos pasa cuando se detectan problemas, pero nadie tiene tiempo, presupuesto o autoridad para solucionarlos. Así que el equipo aprende a callarse. Total, ¿para qué? Si nada va a cambiar…

Cuando desconectar tus termostatos

G.K. Chesterton lo explicó con una parábola: imagina que cruzas un campo y encuentras una valla en medio del camino. No sabes por qué está ahí. Tu primer impulso es quitarla porque parece innecesaria.

Chesterton decía: no la quites hasta que sepas por qué la pusieron.

Ese proceso extraño que te parece absurdo puede estar previniendo un problema que todavía no has experimentado. Esa reunión que parece innecesaria puede ser el único momento donde cierta información crítica fluye entre equipos.

Y esto es especialmente peligroso si eres nuevo en un equipo o sistema. No has vivido el problema que ese mecanismo previene, así que te parece inútil.

A veces el problema es cíclico: solo aparece una vez al año, en el cierre fiscal, cuando hay auditoría. Llevas seis meses, nunca lo has visto, el mecanismo te parece burocracia innecesaria. Lo eliminas.

Y seis meses después descubres exactamente por qué existía.

Antes de eliminar algo, entiende por qué existe. Y si nadie recuerda ya por qué existe, esa es precisamente la señal de que debes investigar más, no de que puedes borrarlo sin consecuencias.

Tres cosas que puedes hacer mañana

1. Audita tus termostatos

Haz una lista de los mecanismos de feedback que tiene tu equipo. Pregúntate:

• ¿Tenemos objetivos claros y medibles?

• ¿La información fluye rápido y es verdadera?

• ¿Cuándo detectamos problemas, tenemos formas de actuar?

Si alguno falla, tu sistema no funciona como debía.

2. Protege los mecanismos de emergencia

Hay defensas que se usan poco, pero son críticas cuando se necesitan.

Las comprobaciones antes de un deploy. Los postmortems después de incidentes. Las one on ones donde se puede hablar con honestidad.

Parecen lujos cuando todo va bien. Hasta que dejan de serlo.

3. Fortalece la honestidad del sistema

Un sistema se corrige mejor cuando la información es clara, rápida y honesta:

• Seguridad psicológica para reportar problemas sin miedo

• Menos capas que distorsionen la información

• Datos visibles para todo el mundo

• Menos tiempo entre el problema y su detección

Cuanto más clara , veraz y oportuna es la información, mejor funciona el termostato.

En conclusión

Tu casa tiene un termostato que funciona 24/7 sin supervisión. Idealmente, tu organización debería ser al menos igual de inteligente.

Los bucles de retroalimentación negativa son solo uno de los puntos de apalancamiento que identificó Donella Meadows.

En esta serie, ya hemos visto Por qué cambiar los números nunca arregla nada, El coste invisible de trabajar al 100%, El cuello de botella que está frenando tu equipo y Estás guiando a tu equipo mirando el retrovisor.

Cada nivel que subimos, el impacto potencial de cada punto de apalancamiento es mayor.

Nos leemos.

PD: Justo estamos grabando un curso en ManagerPro (disponible pronto) sobre una de las estrategias para tener un bucle de retroalimentación de los que regulan el sistema: las One on Ones.

Si esta edición te ha aportado algo o te ha dejado pensando, considera reenviársela a alguien a quien también le pueda servir.

Compartir

Tienes que estar disponible para tu equipo.

Seguro que lo has oído. Puede que hasta te lo haya dicho alguien en alguna formación de liderazgo. O lo hayas leído en algún libro de esos que venden en las librerías de los aeropuertos que prometen convertirte en el líder del año.

Estar disponible. Ser cercano. Tener la puerta abierta.

Suena razonable, ¿verdad? Humano. Empático.

Nadie quiere un manager distante, inaccesible o encerrado en su torre de marfil.

No tan rápido.

El problema es que este consejo está incompleto.

Peligrosamente incompleto.

El contrato que no firmaste

Llegas a tu rol de manager con las mejores intenciones. No quieres repetir los errores de otros managers que has tenido. Así que comunicas, implícita o explícitamente:

Estoy aquí para vosotros. Mi puerta está siempre abierta.

Bonito mensaje. Genera confianza. Pero lo que el equipo entiende es:

• Puedo preguntarte cualquier cosa, en cualquier momento.

• No tengo que pensar demasiado antes de escalarte algo.

• Si tengo una duda, la solución más rápida es pasar por ti.

• Tu tiempo es gratis.

Acabas de convertir tu disponibilidad en un recurso compartido sin límites.

Como el wifi público de un Starbucks.

La tragedia de los comunes

En economía existe el concepto de “tragedia de los comunes”: cuando un recurso está disponible para todos sin restricciones, tiende a sobreexplotarse hasta agotarse.

Tu atención funciona exactamente igual.

Cada persona o subgrupo del equipo, actuando racionalmente desde su perspectiva, optimiza su propio trabajo acudiendo a ti. Porque para cada uno, el coste de interrumpirte es bajo y el beneficio es alto: respuesta rápida, problema resuelto.

Pero cuando todos hacen lo mismo, el recurso colapsa. Tu capacidad de concentración y tu tiempo para pensar se esfuma.

Eres “más accesible” para el equipo, sí, pero no todo lo que tienes que hacer está relacionado con el equipo. ¿Qué pasa con el resto?

Las expectativas que construyes sin saberlo

Cada vez que respondes inmediatamente, estás entrenando una expectativa.

• La velocidad de respuesta esperada: si siempre contestas en 2 minutos, eso se convierte en la norma.

• El nivel de autonomía aceptable: si validas cada decisión pequeña, comunicas que no se espera que decidan solos.

• Qué es urgente y qué no: si todo recibe la misma inmediatez, todo acaba pareciendo igual de urgente.

Estás construyendo una cultura. Aunque puede que no sea la que quieres.

Lo que pierdes por el camino

Mientras mantienes esta disponibilidad total, hay cosas que no estás haciendo. Cosas que solo tú puedes hacer.

• No estás observando patrones.

• No estás construyendo relaciones con stakeholders.

• No estás desarrollando a otras personas (incluyendo a tu equipo).

• No estás defendiendo los intereses del equipo y los objetivos en otros foros.

• Vas a las reuniones clave sin habértelas preparado. Ya he hablado antes de este problema.

La accesibilidad es un privilegio, no un derecho

Si tienes 40 horas a la semana, cada cosa que atiendes tiene un coste de oportunidad. Otra cosa dejará de hacerse.

Por lo tanto, deberías tratar tu atención como tratas cualquier otro recurso finito.

Deberías priorizar qué atiendes y qué no.

Crisis, conversaciones de desarrollo, decisiones donde tu perspectiva añade valor, momentos de celebración y ocio…

Conversaciones difíciles

Cambiar estas dinámicas requiere conversaciones que, en ocasiones, son complicadas.

Oye, he notado que estoy respondiendo muchas consultas que podrías resolver sin mí. A partir de ahora, cuando me traigas un problema, me gustaría entender primero qué has intentado y qué opciones ves.

O:

Voy a proteger mis mañanas para trabajo de concentración. De 9 a 11 estaré menos disponible en Slack. Si es urgente, llámame. Si no, lo vemos después.

El equipo que quieres construir

No quieres un equipo que dependa de tu disponibilidad constante.

Quieres un equipo que:

• Piense antes de escalar.

• Tome decisiones con criterio.

• Te consulte lo importante.

Debes pensar si ese equipo se construye estando “siempre disponible”.

“La virtud es un término medio entre dos vicios: uno por exceso y otro por defecto.”

— Aristóteles, Ética a Nicómaco

Nos leemos.

PD: Si este texto te ha hecho pensar, quizá también le sirva a otro manager que conozcas. Hazle un favor y reenvíaselo.

Compartir