Introducción
Un empleado descubre que el script de un compañero elimina archivos en lugar de moverlos. Lo corrige, añade verificaciones de errores y evita que todo el equipo pierda horas de trabajo. El resultado: es convocado por su responsable por haber "hecho el trabajo de otro". La historia ocurrió en los años 80, en un centro informático municipal. Lo llamativo es que sigue siendo perfectamente reconocible hoy.
El perímetro como línea de demarcación
En muchas organizaciones IT, la descripción de puesto se ha convertido en una frontera infranqueable. Cada equipo defiende su territorio, y cualquier intervención fuera del ámbito asignado —aunque bien intencionada— puede desencadenar una reacción defensiva. La lógica parece coherente: responsabilidades claras evitan redundancias y conflictos. Pero en la práctica genera una paradoja: los perfiles más comprometidos, quienes ven el sistema en su conjunto y quieren resolver problemas, se convierten en fuente de tensión en lugar de en un activo.
Las consecuencias son tangibles. Los incidentes que ocurren en la intersección de dos perímetros quedan sin resolver. Nadie los "posee" oficialmente, así que nadie interviene. Y cuando alguien toma la iniciativa de hacerlo, recibe un llamado de atención.
Una selección silenciosa hacia abajo
Los perfiles IT más competentes —desarrolladores, arquitectos, ingenieros DevOps— suelen compartir un rasgo común: no se limitan a ejecutar tareas, sino que observan, anticipan y buscan mejorar. Cuando una organización desincentiva sistemáticamente esa energía, envía un mensaje inequívoco: tu iniciativa no es bienvenida aquí.
Son precisamente estos perfiles quienes tienen más opciones en el mercado. Se van. Se incorporan a equipos donde su forma de trabajar es reconocida —y con frecuencia, es la competencia quien se beneficia directamente de su salida.
Retener talento IT ya es difícil en un contexto de escasez estructural y alta movilidad. Una cultura que penaliza la iniciativa agrava este problema de forma silenciosa, sin que ningún indicador de RRHH lo capture directamente. La rotación sube, las causas permanecen difusas y las entrevistas de salida producen respuestas educadas que no lo dicen todo.
Lo que DevOps y SRE entendieron
No es casual que las metodologías que han estructurado la modernización de las áreas de tecnología en los últimos quince años —DevOps, SRE, Platform Engineering— se sustenten en un principio común: los problemas no respetan los perímetros organizativos. Un ingeniero que detecta una anomalía en producción y la resuelve sin esperar a que el ticket correcto llegue a la cola correcta no se está extralimitando. Es exactamente lo que la resiliencia operativa exige.
Las organizaciones que logran su transformación digital no son las que tienen las descripciones de puesto más precisas. Son aquellas en las que los equipos se sienten autorizados a actuar —y donde la dirección refuerza ese comportamiento en lugar de sancionarlo.
Tres palancas para invertir la dinámica
La anécdota de los años 80 describe un mundo de mainframes y procesamiento por lotes. Pero el reflejo organizativo que ilustra sigue muy vivo. Algunas acciones concretas permiten revertirlo:
- Evaluar explícitamente la iniciativa transversal, no solo la ejecución dentro del perímetro asignado. Lo que se mide termina siendo valorado.
- Organizar post-mortems sin búsqueda de culpables (blameless post-mortem), para crear un espacio donde señalar un problema se perciba como una contribución, no como un riesgo.
- Evitar territorializar las responsabilidades cuando se detecta un incidente fuera del perímetro: la primera pregunta no debería ser «¿quién debería haberlo visto?», sino «¿cómo evitar que se repita?».
El objetivo no es eliminar las responsabilidades claramente asignadas —siguen siendo indispensables para la operación—. Se trata de lograr que cuando un colaborador detecta un problema fuera de su ámbito, su primer impulso sea señalarlo o resolverlo, no mirar hacia otro lado para evitar problemas.