Por qué tu IT es lento (y no es por falta de gente)

Hay una frase que aparece siempre, tarde o temprano, en cualquier organización donde IT dejó de acompañar al negocio:

"Eso no es mi función."

Se dice sin agresividad. A veces con alivio. Y casi nunca es mentira: el que la dice suele tener razón en el sentido estricto — formalmente, no es su función.

El error está en leerla como un problema de actitud. No lo es. Es un dato de diagnóstico, y bastante preciso: te está diciendo que en esa organización el costo de meterse donde no te llamaron es más alto que el costo de que el problema no se resuelva.

Nadie decidió eso. Nadie lo escribió. Pero es la regla que todos aprendieron.

Tres culturas, no dos

En 2004 Ron Westrum, sociólogo que estudiaba seguridad en aviación y medicina, propuso una tipología para clasificar cómo circula la información en una organización. Se volvió una de las herramientas de diagnóstico más útiles que existen, y casi nadie en IT la usa.

Westrum describe tres tipos:

Patológica. La información se acumula porque es poder. Los mensajeros de malas noticias se castigan. Las fallas se usan para buscar culpables. La organización opera con miedo.

Burocrática. La información circula por los canales formales, y solo por ahí. Las responsabilidades están rígidamente compartimentadas. Las fallas llevan a justicia — es decir, a determinar quién incumplió qué procedimiento. La organización opera con reglas.

Generativa. La información se busca activamente. Los mensajeros se entrenan, no se castigan. Las fallas llevan a indagación: qué del sistema permitió que esto pasara. La organización opera con misión compartida.

La trampa está en el medio. Casi nadie cree tener una cultura patológica — es demasiado visible, demasiado incómoda de sostener. Lo que abunda es la burocrática, y su síntoma distintivo es exactamente ese: cada persona hace correctamente lo que le corresponde, todo el mundo cumple, y nada avanza.

Es el modo de falla más difícil de diagnosticar porque no parece una falla. Parece orden.

El síntoma no es la lentitud, es la forma de la lentitud

Una organización burocrática no es lenta al azar. Es lenta de manera reconocible:

Time-to-burocracia. El tiempo entre "necesitamos esto" y "alguien tiene autoridad para decidirlo" es mayor que el tiempo de implementarlo. Comités que se reúnen para acordar la próxima reunión.
La deuda técnica como escudo. La deuda es real — casi siempre lo es. Pero deja de ser un problema a resolver y pasa a ser un argumento permanente para no cambiar nada.
"Eso nunca se hizo acá." El precedente funciona como criterio técnico. Lo conocido es seguro, no porque sea mejor, sino porque ya nadie tiene que defenderlo.
Nadie miente, nadie está equivocado, y el proyecto lleva ocho meses. Cada área puede demostrar que hizo lo suyo. El problema vive en los espacios entre áreas, que son de nadie.

Si esto describe tu organización, el problema no se arregla contratando más gente. Vas a tener más personas ejecutando correctamente la misma estructura.

La evidencia: la cultura no es un tema blando

La objeción habitual es que esto es "gestión del cambio", algo suave, difícil de medir, que se atiende cuando se apaguen los incendios.

La investigación de DORA — el programa que estudia performance de entrega de software desde 2014, con decenas de miles de respuestas acumuladas — dice lo contrario. Aplicaron el modelo de Westrum a organizaciones tecnológicas y midieron el resultado:

Una cultura organizacional generativa se correlaciona con un 30% más de performance organizacional.
Los equipos de alto desempeño que cumplen sus objetivos de confiabilidad tienen 2,9 veces más probabilidad de tener una cultura de equipo generativa que los de bajo desempeño.
En prácticas de seguridad, el mayor predictor de adopción no fue técnico sino cultural: las organizaciones de alta confianza y baja culpa adoptaron prácticas emergentes de seguridad significativamente más que las de baja confianza y alta culpa.

Ese último punto merece detenerse. La pregunta "¿por qué no implementamos las prácticas de seguridad que sabemos que hay que implementar?" tiene una respuesta que no está en el stack. Está en si alguien puede levantar la mano y decir "esto está mal" sin pagar un costo por decirlo.

La cultura no es el tema blando. Es la variable que determina si lo técnico llega a ejecutarse.

Del diagnóstico al gobierno: ISO/IEC 38500

Acá es donde la mayoría de los diagnósticos culturales se cae. Producen una lectura correcta y ninguna acción. "Tenemos una cultura burocrática" no es un plan.

El puente es más viejo de lo que parece y es una norma internacional: ISO/IEC 38500, gobierno corporativo de las tecnologías de la información. Su aporte central es distinguir dos cosas que las organizaciones confunden todo el tiempo:

Gobernar no es gestionar. Gestionar es operar el sistema. Gobernar es decidir qué debe hacer el sistema, dirigir para que lo haga, y verificar que lo esté haciendo. Cuando IT se queda solo con la gestión, la dirección nunca se ejerce: se delega implícitamente en quien tiene la agenda más ordenada.

La norma propone un ciclo de tres movimientos que se repite:

Evaluate — evaluar el uso actual y futuro de la tecnología. No "¿está funcionando?" sino "¿esto sirve para donde va el negocio?". Es una lectura del estado real, con criterio externo al de quien lo construyó.

Direct — asignar responsabilidad y dirigir la preparación e implementación de planes y políticas. Acá muere el "no es mi función": si la responsabilidad está asignada explícitamente, la frase deja de tener dónde apoyarse. No porque alguien se esfuerce más, sino porque la estructura cambió.

Monitor — monitorear el cumplimiento contra las políticas y el desempeño contra los planes. No un informe anual. Una medición sostenida que hace visible la desviación mientras todavía es corregible.

El ciclo es deliberadamente aburrido. Su valor no está en la sofisticación conceptual, está en que se cierra: cada vuelta produce evidencia que alimenta la siguiente evaluación. Sin ese cierre, "Direct" es una reunión, y "Monitor" un tablero que nadie mira.

Por qué esto se rompe en la práctica — y qué cambió

El ciclo Evaluate–Direct–Monitor tiene un problema conocido: es caro de sostener. Evaluar en serio requiere criterio senior. Monitorear en serio requiere continuidad. La mayoría de las organizaciones puede pagar una de las dos, y casi ninguna puede pagar un arquitecto senior mirando su infraestructura todos los meses.

Entonces hacen lo posible: contratan una consultoría, reciben un informe, y a los seis meses el informe describe una organización que ya no existe. El ciclo se abrió en el primer movimiento y nunca se cerró.

Lo que cambió es la economía de los dos extremos. Monitor es hoy en gran medida automatizable: la recolección de evidencia, la correlación de señales, la detección de desviación contra una línea base. Evaluate y Direct siguen requiriendo criterio humano — decidir qué importa, qué riesgo se acepta, a quién se le asigna qué. No son delegables a una herramienta, y quien diga lo contrario está vendiendo otra cosa.

Eso es exactamente lo que hacemos: la IA sostiene el monitoreo continuo que antes era económicamente imposible, y un arquitecto con criterio hace la evaluación y la dirección. El ciclo se cierra porque cada parte la hace quien puede hacerla.

Y hay un cuarto elemento que ninguna norma menciona pero que en la práctica decide el resultado: quien evalúa no puede tener agenda interna. Un diagnóstico hecho por alguien que después tiene que convivir con las conclusiones no es un diagnóstico. Es una negociación.

Si al leer "eso no es mi función" te vino a la cabeza una cara y una reunión concreta, eso no es un problema de esa persona. Es un dato sobre la estructura, y es medible.

El pre-diagnóstico de IAops no tiene costo. En 5 días te decimos en qué estado real está tu infraestructura, cuáles son los 3 riesgos más críticos, y qué haríamos primero.

No sirve para convencer a nadie internamente. Sirve para que dejes de discutir sobre percepciones y empieces a discutir sobre evidencia.