En ingeniería de software, el proceso de gestión de incidentes se diseñó para responder a emergencias reales, pero con el tiempo tiende a usarse como atajo para todo lo demás. Un gestor declara un Sev-2 para colocar el problema de su equipo al principio de la cola de prioridades de otro; un product manager lo usa para que la dirección mire un asunto estancado en el backlog; un equipo de cuentas lo invoca para conseguir ingenieros para una demo importante; un desarrollador lo prefiere a navegar el proceso formal de excepciones durante una congelación de despliegues. Cada declaración aislada parece inofensiva, pero el efecto acumulado degrada la señal de urgencia: cuando llega un Sev-1 genuino, los equipos responden con menos rapidez porque están condicionados a esperar otro falso aviso. Además, quienes burlan el sistema obtienen antes lo que necesitan, lo que enseña al resto que esa es la forma de conseguir cosas. Y todo ello con la sobrecarga completa de un incidente real: responders desviados, commanders designados, partes interesadas que cambian de contexto. La respuesta instintiva de añadir gatekeeping —aprobaciones previas, checklists, revisiones a posteriori— suele ser contraproducente, porque añade fricción también a las emergencias legítimas y desalienta declaraciones necesarias. El artículo propone, en cambio, atacar la causa: crear procesos ligeros de excepción para cambios urgentes, mecanismos de escalado de prioridad entre equipos y canales formales de coordinación no emergente. Cita los mecanismos de Code Yellow y Code Red de la organización SRE de Google como ejemplo. Termina con una pregunta diagnóstica: revisar las últimas doce o más declaraciones y distinguir cuáles respondieron a emergencias reales de cuáles fueron atajos. La conclusión es clara: si la gente declara incidentes falsos es porque los procesos normales son demasiado rígidos, lentos o sordos, y el proceso de incidentes funciona; arreglar eso, y no endurecer las puertas, es lo que restablece la señal de urgencia.
