El culto a la urgencia: cuando todo es para ayer y mañana también

Publicado el 8 de junio de 2026  •  17 minutos  • 3479 palabras

En una empresa de software que no voy a nombrar (pero que existe), un desarrollador recibió el mismo mensaje tres viernes seguidos a las 17:45: “Es crítico, necesito esto hoy.” El tercer viernes, terminó el fix, lo desplegó, y no lo abrió nadie hasta el martes siguiente. El desarrollador sigue en terapia. El manager lleva dos meses con el mismo email sin leer en el backlog.

Existe una religión en las empresas tecnológicas que no tiene templos, ni velas, ni texto sagrado, pero tiene millones de fieles incondicionales que se levantan cada mañana dispuestos a venerar su único dogma: hoy es más urgente que ayer, y mañana lo será más todavía.

Se llama el culto a la urgencia.

No tiene fecha de fundación conocida, pero proliferó con especial virulencia a partir del momento en que Slack hizo posible interrumpir a alguien cada cuatro minutos con la misma naturalidad con la que antes le habrías tirado un papel arrugado a la cabeza.

La tecnología que iba a liberarnos terminó siendo el mejor sistema de distribución de pánico corporativo que ha inventado la humanidad. Usamos inteligencia artificial para predecir el churn de clientes pero no conseguimos predecir que convocando una reunión un jueves a las seis de la tarde la gente va a estar mentalmente en otro sitio.

El mandamiento de esta religión es simple y no admite matices: todo lo que ocurre en esta empresa es una emergencia de máxima prioridad. Todo. Siempre. Sin excepción. Incluso la reunión de “alineamiento de cultura de equipo” que llevas tres semanas aplazando porque, francamente, nadie ha conseguido explicar qué es exactamente lo que se va a alinear.

El santo grial del “para ayer”

Hay un momento exacto en que sabes que has entrado en una organización infectada por este culto.

No aparece en la descripción del puesto, claro. Tampoco lo mencionan en las entrevistas, donde todo el mundo habla de “cultura de trabajo sana” y “autonomía del equipo” con la convicción de quien lleva ensayando el monólogo desde el domingo por la noche. Lo descubres tú solo, en carne propia, el día que preguntas inocentemente cuáles son las prioridades del sprint y alguien — con la cara de quien acaba de detectar humo en el edificio — te responde, sin pestañear: “Todo es prioritario.”

Esta frase es técnicamente equivalente a decir que nada lo es. La diferencia es que “nada es prioritario” haría que te levantases de la silla con preocupación, mientras que “todo es prioritario” se pronuncia con tanta solemnidad que da la impresión de que si no lo entiendes eres tú quien tiene un problema de comprensión lectora . A veces viene acompañada de un gesto con la mano que sugiere que el asunto es demasiado complejo para explicarlo en una frase y que quizás lo mejor es que lo vayas asimilando con el tiempo.

Y lo curioso es que la urgencia real existe, y nadie lo niega. Hay momentos que de verdad requieren reacción inmediata: un sistema caído en producción, un fallo de seguridad con datos de clientes en la calle, ese momento específico en que la base de datos decide hacer un streaking a las tres de la tarde de un viernes. Todo eso merece la alarma roja, el canal de crisis y el despliegue de todo lo disponible.

El problema es cuando la urgencia deja de ser una excepción y se convierte en el estado base de la organización. Cuando el modo pánico no es una respuesta a un incidente sino, sencillamente, el modo de funcionamiento habitual. Cuando el incendio permanente no es un accidente sino la decoración de la oficina y nadie recuerda ya cómo era el sitio antes de que ardiera. En ese punto la urgencia ya no es una señal de que algo va mal: es solo el ruido de fondo del trabajo, tan inevitable como la música del ascensor pero bastante más cara en términos de salud mental y bastante menos agradable en cualquier otro sentido.

Anatomía del manager urgenciólogo

El culto a la urgencia necesita sacerdotes, y los tiene en abundancia.

Se reconocen a cierta distancia, con algo de práctica. Son los managers que llegan a cualquier reunión ya corriendo, aunque vengan del baño que está a doce metros; que abren los mensajes de Slack con la misma energía con la que se abriría un sobre del juzgado; y que tienen el don sobrenatural de convertir cualquier cosa, absolutamente cualquier cosa, en una emergencia corporativa de primer orden.

Una migración de base de datos planificada desde hace tres meses: urgente. La renovación de un certificado SSL que expira la semana que viene: urgente. Elegir la paleta de colores para la presentación de dirección del trimestre: urgente y, encima, “estratégico”. Si les preguntas cuándo algo no es urgente, la pregunta les resulta genuinamente desconcertante, como si les hubieras preguntado en qué idioma piensan los peces o si una empresa debería tener un proceso de onboarding escrito.

Lo que normalmente no dicen en voz alta — y aquí viene el matiz que duele — es que, según los estudios de Harvard Business Review sobre urgencia falsa en el trabajo , este fenómeno “no surge de la realidad del negocio, sino de una mala planificación, prioridades poco claras o ansiedad en los niveles directivos.”

Resumido sin eufemismos: el incendio lo enciende, con mucha frecuencia, el mismo tipo que aparece con el extintor y cara de superhéroe.

No es que sean malos profesionales necesariamente. Muchos son personas inteligentes con años de experiencia y buenas intenciones sinceras. Pero aprendieron, en algún momento de su carrera, que la urgencia es un atajo eficaz para que las cosas se muevan sin tener que convencer a nadie, sin tener que priorizar explícitamente y, sobre todo, sin tener que asumir que priorizar implica, por definición, renunciar a otras cosas. Decir “esto es urgente” evita la conversación incómoda de “entonces qué dejamos de hacer”.

Y como nadie les ha dicho nunca que no, siguen usando la urgencia como si fuera el único modo de comunicación disponible en el edificio.

Por qué el cerebro se niega a colaborar

Hay una razón fisiológica muy clara por la que vivir en modo urgencia permanente es una idea espantosa, y no es “el burnout” como concepto etéreo que aparece en presentaciones de bienestar corporativo con fotos de personas meditando en playas.

Es bastante más sucio que eso.

Cuando tu cerebro percibe una amenaza urgente, activa exactamente el mismo sistema que activaría si un depredador prehistórico te persiguiese por el bosque: cortisol, adrenalina, toda la atención concentrada en la supervivencia inmediata.

El sistema es una obra maestra de la evolución y funciona de maravilla para escapar del oso. Es, sin embargo, pésimo para diseñar una arquitectura de microservicios, revisar un pull request con la cabeza despejada, o tomar cualquier decisión técnica que tenga consecuencias más allá de las próximas cuarenta y ocho horas.

El oso no entiende de sistemas distribuidos y el cortisol tampoco.

El resultado es previsible y ha sido documentado con tanta minuciosidad que ya resulta casi aburrido citarlo: equipos permanentemente acelerados que avanzan cada vez menos. Que hacen muchísimas cosas y terminan muy pocas. Que entregan rápido y con suficientes parches como para que el siguiente sprint empiece ya con tres incendios nuevos heredados, que serán las próximas urgencias, que requerirán las próximas interrupciones, que impedirán el trabajo que habría evitado los próximos incendios.

El círculo es tan perfectamente cerrado que merece un diagrama de flujo propio, con flechas rojas y un emoji de fuego en cada nodo , enmarcado junto a la matriz de Eisenhower en la pared de la sala de reuniones.

Los datos no son ambiguos. El 42% de los profesionales del sector tecnológico tiene un riesgo alto de burnout , y entre las causas que aparecen de forma consistente en todos los estudios no está “el trabajo es demasiado complicado técnicamente” ni “los problemas que tenemos que resolver son muy difíciles”.

Aparece, repetidamente, la presión constante sin distinción entre lo que es importante y lo que simplemente tiene una fecha inventada en una presentación de PowerPoint . No es una coincidencia estadística. Es el coste exacto, medible y documentado, de haber etiquetado de “crítico” todo lo que tiene un plazo, real o fabricado.

La matriz de Eisenhower: ese póster que nadie mira

Dwight D. Eisenhower coordinó el desembarco de Normandía, planificó el final de la Segunda Guerra Mundial y luego gobernó el país más poderoso del mundo durante ocho años, gestionando simultáneamente la Guerra Fría, la carrera espacial y los primeros años de la televisión en color. En algún momento, entre todo eso, encontró tiempo para formular el principio que desde entonces lleva su nombre: lo urgente raramente es lo importante, y lo importante raramente es urgente .

Un hombre que tenía que decidir si lanzar una invasión anfibia de cien mil personas con condiciones meteorológicas adversas y consecuencias geopolíticas para las décadas siguientes todavía encontró claridad conceptual suficiente para separar las dos cosas. Esto debería darnos información útil sobre si el lanzamiento de la nueva funcionalidad de filtros de búsqueda merece realmente el tratamiento de incidente P0.

Décadas después, alguien convirtió aquel principio en una matriz 2x2 que es, a estas alturas, posiblemente el póster de productividad más impreso en la historia de las oficinas abiertas. La han publicado en miles de artículos, la han plastificado, la han colgado junto a frases motivacionales sobre el poder del equipo, y ha sido completamente ignorada en todas y cada una de las organizaciones donde el manager de turno entra por la puerta con cara de catástrofe cada cuarenta y cinco minutos.

No es un problema de herramientas. Nadie en la historia del trabajo en equipo ha resuelto un problema cultural con un póster.

La cultura la establece quien tiene el poder de decidir qué es urgente y qué no, y si esa persona tiene el concepto de la urgencia calibrado con la precisión de una alarma de coche en un aparcamiento subterráneo — disparándose constantemente sin que nadie entienda por qué ni a nadie le importe ya demasiado — ninguna matriz 2x2, por cuidada que sea su tipografía, va a cambiar nada de nada.

El desarrollador como bombero de guardia

En los equipos que llevan suficiente tiempo bajo el régimen de la urgencia crónica aparece, casi inevitablemente, un perfil muy reconocible: el superhéroe del incidente.

Ese desarrollador que siempre está disponible a cualquier hora, que arregla lo que sea sin preguntar demasiado, que nunca dice “eso no entra en el sprint” porque en este contexto los sprints son más bien una sugerencia lírica, y que aparece cada vez que la cosa se rompe como si tuviera instalada una alarma interna sincronizada con los logs de producción.

En muchas empresas este perfil está glorificado de una forma que, si te paras a pensarlo con frialdad, resulta bastante perturbadora (o patética, según el día).

Es el perfil “que se implica de verdad”, “el que da la cara cuando las cosas se complican”, “el que hay que retener cueste lo que cueste porque sin él no sabemos qué haríamos.” Y todo eso puede ser sincero.

El problema es lo que nadie menciona en la revisión de desempeño ni en el email de agradecimiento de dirección: ese desarrollador está tapando, literalmente con su propio cuerpo, los agujeros de una planificación que ha sido catastrófica de forma sistemática y deliberada.

Los incendios que apaga con tanto mérito no surgieron del vacío ni de la mala suerte.

Los generó un proceso donde alguien decidió que una arquitectura sobre la que varios técnicos habían expresado reservas “tenía que funcionar” porque el plazo ya se había comprometido con el cliente y reabrir esa conversación era incómodo.

Y ese desarrollador — que estadísticamente lleva meses durmiendo mal, tiene el perfil de LinkedIn actualizado y en visible para los recruiters aunque no lo admita en las dailies, y piensa en irse con más frecuencia de la que reconocería en una conversación con su manager — está prestando un servicio inmenso a la organización mientras la organización lo interpreta, con serena indiferencia, como señal de que el sistema funciona bien.

Una empresa que necesita héroes permanentes no tiene un equipo de ingeniería. Tiene un sistema de soporte vital que funciona exclusivamente porque hay personas que aún no se han dado cuenta de que deberían cobrar el doble o marcharse. Probablemente ambas cosas.

La vida de una urgencia: del miércoles por la tarde al lunes por la mañana

Para entender cómo se fabrica industrialmente una urgencia desde cero, no hace falta inventar un escenario hipotético. Basta con describir lo que ocurre, en versiones casi idénticas, en cientos de empresas todos los jueves a la misma hora.

Empieza así: alguien en dirección tiene una idea.

El origen es lo de menos. Puede ser una reunión con un cliente importante, un artículo leído en LinkedIn a las once de la noche, o una conversación casual en un evento sectorial donde alguien mencionó que la competencia estaba haciendo algo parecido.

Lo que importa es que esa idea, en el momento exacto en que cruza el umbral mental de la persona con poder de decisión, experimenta una metamorfosis instantánea: deja de ser una idea y se convierte en una “iniciativa estratégica prioritaria”. Este proceso de elevación tarda aproximadamente dieciséis horas y no requiere ningún tipo de validación externa.

El viernes hay una reunión. Se convoca con pocas horas de antelación porque, evidentemente, es urgente. Se presenta la iniciativa con entusiasmo genuino y un plazo que, al examinarlo con atención, ya era ayer cuando se concibió.

El equipo técnico escucha con la expresión de quien reconoce el patrón pero sigue teniendo esperanza en la humanidad, y señala con toda la calma del mundo que eso requiere análisis, diseño, implementación y al menos una ronda de pruebas decentes, que dos semanas sería un plazo ajustado pero factible, y que arrancar sin ese tiempo implicará deuda técnica y problemas posteriores.

Esta información se recibe con la misma cara que se pondría ante alguien que afirma que el agua moja. La decisión final (adoptada con agilidad, eso sí) es que el equipo “ya verá cómo se organiza” y que “tenemos que ser más ágiles”.

Ser ágiles, en este contexto específico, significa hacer en dos días lo que necesita dos semanas, con toda la deuda técnica que eso genera, ninguna de la documentación que lo haría mantenible, y los tres bugs que se descubrirán el miércoles siguiente y que serán, sin ninguna sorpresa, las próximas urgencias del jueves .

El ciclo se repite con una eficiencia admirable hasta que el equipo dimite, el producto colapsa bajo el peso acumulado de sus propios parches, o ambas cosas simultáneamente, que es el desenlace estadísticamente más frecuente y el que más sorprende a dirección.

El antídoto: extraordinariamente aburrido

La solución a todo esto no es especialmente fotogénica, y eso es probablemente por qué nadie la adopta con entusiasmo. No hay un framework nuevo. No hay una metodología con nombre en inglés, acrónimo memorable y logo minimalista en tres colores que resuelva la situación con un taller de dos días y una certificación. No hay una app.

Lo que funciona, en los equipos donde funciona, es incómodamente simple: que alguien con autoridad real aprenda a decir “esto puede esperar” y lo diga en voz alta, con nombre y plazo concretos, sin que le tiemble la voz ni sienta la necesidad compulsiva de añadir “pero lo valoramos mucho y lo tendremos muy en cuenta en cuanto tengamos capacidad.”

En producción este problema lleva décadas resuelto mediante SLOs: criterios explícitos que definen qué nivel de degradación de un sistema constituye un incidente real que justifica despertar a alguien a las tres de la madrugada, y qué nivel es un problema que se mete en el backlog y se resuelve en horario razonable la semana siguiente.

La mayoría de las empresas tiene SLOs para sus sistemas técnicos. Casi ninguna tiene el equivalente para su proceso de toma de decisiones y priorización, que es exactamente donde la urgencia falsa vive, prospera y se reproduce sin control.

Proteger el trabajo de fondo es la otra pieza que siempre falta.

La deuda técnica, las mejoras de arquitectura, la documentación, los tests: nada de eso tiene jamás la urgencia de una demo del viernes ni el peso emocional de un cliente esperando. Pero es exactamente lo que determina si el año que viene habrá diez urgencias semanales o dos .

Los equipos que invierten tiempo sistemáticamente en ese trabajo invisible no van más rápido porque sean más inteligentes ni porque trabajen más horas. Van más rápido porque tienen el contexto, el foco y la arquitectura que les permite moverse sin tener que reiniciar el estado mental cada media hora por culpa de un mensaje de Slack marcado como crítico sobre algo que lleva semanas sin resolverse porque nadie ha querido tener la conversación incómoda de asignarle un plazo real.

Y lo más importante, que es también lo más difícil de aceptar para quien lleva años dentro del sistema: si un manager descubre que puede resolver sus problemas de planificación convirtiendo todo en urgente, y nadie le dice que no, lo seguirá haciendo indefinidamente. No porque sea una persona terrible. Porque funciona. Siempre hay alguien que corre. Y mientras haya alguien dispuesto a correr, no hay ningún incentivo para aprender a caminar.

La próxima vez que alguien te diga “es para ayer”, respóndele con calma: “Ayer ya pasó. Dime qué tienes que dejar de hacer para que yo pueda hacer esto primero.”

La cara que ponga te dirá todo lo que necesitas saber sobre si la urgencia era real o si alguien sencillamente olvidó planificar con el tiempo suficiente y ahora necesita que su problema de gestión se convierta en tu problema de agenda.

Lo cual, en muchas empresas, también es urgente de resolver. Paradójicamente.

Glosario rápido

Algunos términos del artículo que merecen dos líneas de contexto, porque usarlos bien en una reunión es, como mínimo, un punto de partida.

• Burnout: estado de agotamiento físico, emocional y mental causado por estrés prolongado e intenso. En el sector tech aparece cuando el modo urgencia deja de ser una excepción y se convierte en la temperatura habitual del trabajo. Se diagnostica tarde y se trata todavía más tarde.

• Deuda técnica: decisiones de implementación tomadas con prisas o por descuido que resuelven el problema a corto plazo pero generan trabajo extra en el futuro. Es el coste diferido de “ya lo arreglamos luego”, que en muchas organizaciones se convierte en “ya lo arregla el que quede”.

• P0: nivel de prioridad máxima en la clasificación de incidentes. Técnicamente reservado para fallos que afectan a todos los usuarios o ponen en riesgo datos críticos. En la práctica, en muchas empresas, es el nivel al que llega cualquier cosa que lleva más de dos días en el backlog sin que nadie la haya mirado.

• SLO (Service Level Objective): objetivo de nivel de servicio que define qué rendimiento mínimo debe cumplir un sistema (disponibilidad, latencia, tasa de errores). Es la herramienta que distingue un incidente real de una alarma inventada.

Fuentes y referencias

Porque no todo puede ser urgente: estas lecturas las puedes procesar con cortisol en niveles normales.

• La cultura del “todo es urgente” - La República. Sobre la normalización de la urgencia falsa en entornos corporativos.
• The high cost of fake urgency in the workplace - Quartz. Resumen del estudio de Harvard Business Review sobre las causas de la falsa urgencia directiva.
• The False Urgency Trap: How to Spot and Fix the Busywork - Memtime. Análisis del ciclo de urgencia falsa y sus efectos en los equipos.
• Estado del burnout en profesionales de tecnología - Sage / Burnout Index (Yerbo). Datos sobre riesgo de burnout en el sector tech.
• Burnout en el sector IT - Mindgram. Análisis de las causas del burnout en perfiles IT.
• Lo urgente y lo importante en la productividad laboral - Kopen. Sobre el principio de Eisenhower aplicado al trabajo.
• Burnout en la industria tech - weare-dev. El perfil del desarrollador quemado y sus señales de aviso.
• Desvelando el misterio del burnout en IT - RRHH Digital. Burnout en perfiles técnicos: causas y consecuencias.
• 5 maneras en que la cultura de lo urgente nos está estresando - Ricardo Lloria. Cómo el ajetreo perpetuo destruye los equipos.
• Cómo priorizar tareas cuando todo es urgente - Doodle. Herramientas y criterios para gestionar la priorización.
• 5 Ways to Eliminate False Urgency on Your Team - PPAI. Estrategias prácticas para equipos de alto rendimiento.
• False Urgency in the Workplace - Insightful. Impacto de la falsa urgencia en la productividad y el bienestar.
• Prevención del burnout en la era digital - Bitrix24. Estrategias de prevención del agotamiento profesional.
• El culto a la urgencia (vídeo) - Instagram. Referencia audiovisual sobre la cultura de la urgencia.
• The False Sense of Urgency - Techtello. Cómo identificar y combatir la urgencia artificial en el trabajo.