2026-09 · 4 min de lectura
El trabajo que desaparece cuando funciona
DesignOps tiene éxito cuando la fricción desaparece. Pero si el trabajo que produce ese estado deja de ser observable, la organización pierde la evidencia necesaria para sostenerlo.
Existe un tipo particular de éxito que casi no produce evidencia de sí mismo.
La infraestructura tiene esta cualidad. Las carreteras pasan al fondo cuando el tráfico fluye. Rara vez hablamos del suministro de agua mientras el agua llega. Cuanto mejor funciona la infraestructura, menos atención exige de quienes la utilizan.
DesignOps suele funcionar de la misma manera.
Cuando el sistema operativo de la organización se sostiene, los archivos están donde las personas esperan encontrarlos. Las dependencias aparecen antes de convertirse en bloqueos. Las revisiones ocurren en el momento adecuado. Los equipos pueden encontrar el trabajo de los demás. El sistema de diseño mantiene su coherencia. Nadie pasa la mañana intentando averiguar quién es responsable del problema.
La fricción desaparece.
Eso es éxito.
Pero hay una distinción que me interesa cada vez más: la fricción puede volverse invisible. El sistema que crea esa condición no debería volverse incomprensible.
Las buenas operaciones deben ser silenciosas al usarlas, no imposibles de observar.
El trabajo preventivo crea un problema peculiar de evidencia.
Un diseñador puede señalar una interfaz. Research puede señalar hallazgos. El trabajo operativo suele producir un contrafactual: el retraso que no ocurrió, el trabajo duplicado que se evitó, la dependencia resuelta antes de convertirse en urgente, la inconsistencia que nunca llegó al producto.
Esos resultados son reales. También son difíciles de demostrar, porque la evidencia más fuerte suele ser una ausencia.
Eso crea un problema de legitimidad. Las organizaciones reconocen con facilidad el valor que deja artefactos. Funcionalidades. Informes. Prototipos. Frameworks. El valor operativo suele existir como una condición: el trabajo avanza con menos fricción, menos sorpresas y menos coordinación evitable.
Cuando esa condición se da por sentada durante suficiente tiempo, la infraestructura empieza a parecer opcional.
Normalmente hasta que falla.
La respuesta tentadora es hacer más visible el trabajo operativo.
Más presentaciones de estado. Más diagramas de procesos. Más reuniones explicando las reuniones. Más documentación que demuestre que la coordinación ocurrió.
No creo que la visibilidad sea el objetivo adecuado.
La idea más útil es la observabilidad.
En ingeniería, un sistema observable deja suficientes señales para entender cómo se comporta sin vigilar cada acción interna. DesignOps necesita algo parecido. No demostrar que alguien estuvo ocupado, sino dejar señales de si el entorno de trabajo está volviéndose más sano o más frágil.
¿Cuántas dependencias siguen sin resolver? ¿Dónde se duplica el trabajo? ¿Cuánto tiempo permanecen bloqueados los equipos esperando una decisión? ¿Qué patrones se fragmentan repetidamente entre squads? ¿Dónde reaparece el mismo problema de coordinación?
Ninguna de estas medidas captura DesignOps a la perfección. Ese no es el objetivo.
Juntas hacen legible el estado del sistema.
DesignOps no debería hacer visible su actividad. Debería hacer observable la condición que crea.
Esto cambia también mi forma de pensar sobre los artefactos operativos.
Una vista de portfolio no es valiosa porque demuestre que alguien mantuvo un tablero. Es valiosa cuando revela trabajo que de otro modo colisionaría.
Un ritual recurrente para compartir conceptos no es valioso porque exista otra reunión. Es valioso cuando las dependencias aparecen antes que antes.
Una revisión de calidad no es valiosa porque se haya completado una checklist. Es valiosa cuando la misma categoría de problema deja de repetirse aguas abajo.
El artefacto es evidencia. La condición es el resultado.
Esta distinción evita que DesignOps se vuelva performativo. El objetivo no es dejar más rastros del trabajo. Es dejar los rastros adecuados: suficientes para entender si el sistema operativo está haciendo aquello para lo que fue diseñado.
Hay aquí un principio de diseño más amplio.
Los mejores sistemas suelen reducir la atención que requieren. Pero reducir atención no significa reducir legibilidad. Un sistema puede ser tranquilo sin convertirse en opaco. Puede desaparecer de la tarea inmediata y seguir siendo inspeccionable para las personas responsables de mantenerlo.
Quizá esa sea también la ambición adecuada para DesignOps.
Que el proceso pase al fondo. Que coordinar sea más fácil. Que las personas olviden cuánta fricción había antes.
Pero que quede suficiente evidencia para que la organización siga entendiendo qué mantiene unido el trabajo — y pueda reconocer cuándo esa condición empieza a cambiar.
El trabajo puede desaparecer. La evidencia no.
Esta reflexión se apoya en el trabajo de Susan Leigh Star y Karen Ruhleder sobre la infraestructura que pasa al fondo cuando funciona, y en la idea de Site Reliability Engineering de que incluso los sistemas fiables deben seguir siendo observables.