El equipo que vive del problema

El principio de Shirky dice que las instituciones intentan preservar el problema del que son la solución. La frase es de Clay Shirky, el nombre se lo puso Kevin Kelly en 2010 y se suele explicar con sindicatos, periódicos y ministerios. En una empresa de software pasa lo mismo y sale más caro, porque muchos de sus problemas sí tienen arreglo, y hay comités, equipos y herramientas cuyo presupuesto depende de que el problema siga ahí. No hace falta mala fe para que ocurra, y por eso cuesta tanto verlo desde dentro.

Nadie se propone conservar un problema

Llevas una semana con un ticket abierto en el equipo de plataforma y el comité de cambios no se reúne hasta el jueves. Ni unos ni otros quieren frenarte. Pero su presupuesto, su plantilla y su hueco en el organigrama están ahí porque tú tienes que esperar, y a nadie le pagan por preguntarse qué sería de ellos si dejaras de esperar. Eso es lo que describe el principio. Kelly, al bautizarlo en 2010, lo dijo mejor: una empresa o una industria puede acabar tan volcada en el problema que resuelve que, sin querer, lo mantiene vivo.

Upton Sinclair ya lo había dicho de las personas en 1934: es difícil que alguien entienda algo cuando su sueldo depende de no entenderlo.

La industria que vive de la declaración

El caso más claro en software es Intuit, la empresa de TurboTax. En Dinamarca, Suecia o España, Hacienda ya sabe lo que has ganado porque se lo cuentan tu empresa y tu banco, te manda un borrador y tú lo confirmas o lo corriges; en España lo hace desde la campaña de 2004. El IRS, la Hacienda de Estados Unidos, tiene los mismos datos, y aun así hacer allí la declaración lleva horas y, muchas veces, obliga a pagar un programa. ProPublica contó en 2013 que en cinco años Intuit se había gastado unos 11,5 millones de dólares en hacer lobby en Washington, más que Apple o Amazon, y que en su informe anual a la SEC figuraba entre los riesgos del negocio que el Estado preparara las declaraciones gratis.

El pacto que mantuvo quieto al fisco desde 2003 era que las empresas darían una versión gratuita a la mayoría y, a cambio, el IRS no haría la suya; en 2019 ProPublica descubrió que TurboTax escondía esa versión de los buscadores. Cuando el IRS montó por fin Direct File, su propio programa, duró dos campañas. En octubre de 2025 el Tesoro anunció que el IRS lo suspendía por su baja participación, menos del 0,5 % de los cerca de 146 millones de declaraciones, y por su coste, al menos 138 dólares cada una. En el mismo informe recomendó reforzar el programa de las empresas. Intuit defiende su negocio, que es lo que le piden sus accionistas.

El comité que cuida del riesgo

Dentro de una empresa el principio no necesita lobby, le basta con el presupuesto. El ejemplo mejor medido es el comité de aprobación de cambios, el CAB de ITIL, que revisa cada cambio importante antes de que llegue a producción. Se crea para reducir el riesgo y existe mientras desplegar sea arriesgado. Según el informe Accelerate State of DevOps de 2019, de DORA, las organizaciones que exigían la aprobación de un comité o de un directivo ajeno al equipo tenían 2,6 veces más probabilidades de estar entre las de peor rendimiento, y nada indicaba que sus cambios fallaran menos. Las de peor rendimiento tardaban de uno a seis meses en llevar un cambio a producción; las mejores, menos de un día. Las organizaciones, dice el informe, responden a los problemas de sus despliegues añadiendo trámites y aprobaciones, y «el análisis sugiere que ese enfoque empeora las cosas». Un comité que consiguiera que desplegar fuese seguro se quedaría sin cambios que aprobar, y no se sabe de ninguno que se haya disuelto por eso.

El equipo de plataforma puede acabar en el mismo sitio. Esta semana Teiva Harsanyi contaba en The Coder Cafe el caso de uno que se montó para que los demás equipos se las arreglaran solos y terminó siendo su cuello de botella: los entornos, la CI y cada ajuste del framework pasaban por él, y una petición de infraestructura algo rara tardó cuatro semanas y retrasó un lanzamiento. No eran vagos ni incompetentes. «Nada les premiaba por hacerse menos necesarios», y «cuanto más imprescindibles eran, más recursos recibían». Si tu empresa mide a un equipo interno por los tickets que atiende, le está pagando por que haya tickets.

Los que hicieron desaparecer su problema

Google puso un tope al trabajo de operaciones de sus SRE. El libro de SRE, de 2016, lo cuenta en el capítulo sobre el toil, el trabajo manual y repetitivo de mantener un servicio: el objetivo declarado es que ocupe menos del 50 % del tiempo de cada ingeniero, porque «tiende a crecer si no se controla y puede llenar enseguida el 100 % del tiempo de todos». Cuando un equipo pasa del tope, el trabajo sobrante vuelve a los equipos de producto, y el libro aclara que el 50 % es un máximo: un equipo de SRE, dejado a su aire, debería acabar casi sin carga operativa.

Team Topologies, el libro de Matthew Skelton y Manuel Pais de 2019, le pide lo mismo a la plataforma interna: la plataforma viable más pequeña, thinnest viable platform, lo bastante pequeña y, a la vez, capaz de acelerar y simplificar el trabajo de los equipos que la usan. Skelton dice que puede ser una página de wiki con los servicios del proveedor de nube que se usan y cómo, y que si con eso basta, no se construye nada más.

A veces el problema lo disuelve alguien de fuera. En 2015, un certificado TLS de un año para un dominio costaba de media 178 dólares en las cinco autoridades de certificación más grandes, según el artículo con el que el equipo de Let's Encrypt explicó su trabajo en 2019, y pedirlo e instalarlo era un trámite manual en el que era fácil equivocarse. Las autoridades de certificación vivían de ese trámite. Let's Encrypt, la autoridad de una organización sin ánimo de lucro que montaron entre otros Mozilla y la EFF, lo hizo gratis y automático, y a finales de 2025 servía 762 millones de sitios; en buena parte del mundo, más del 95 % de las páginas se cargan ya cifradas, frente al 39 % de cuando empezó.

Dónde no se cumple

El principio es una tendencia, y conviene no verlo en todas partes. Hay problemas que no desaparecen: alguien tiene que estar de guardia, revisar la seguridad y vigilar la factura de la nube, y ese equipo no vive del problema, vive de que no explote. Tampoco sirve de excusa para disolver equipos. Si la única salida de quien hace desaparecer su problema es la calle, lo esconderá, y con razón; Google lo resolvió dándoles a sus SRE trabajo de ingeniería cuando baja la carga operativa. La pregunta que sí vale es qué pasaría con cada equipo si su problema desapareciera mañana. Si la respuesta es que se quedaría sin nada que hacer, y nadie ha pensado a qué se dedicaría entonces, ese equipo tiene motivos para que el problema siga, aunque no lo busque.

Esa pregunta hay que hacérsela también a quien vende la solución, y eso me incluye. kubelatch vive de un problema, el acceso a los clusters de Kubernetes: quién entra, con qué permisos y hasta cuándo. El principio predice que a Picaporte Labs le conviene que entrar siga siendo un lío y que los permisos duren para siempre. Lo único que puedo oponer es cómo está hecho: un permiso lleva fecha de fin, de 30 días si no eliges otra; cluster-admin y cualquier otro acceso privilegiado no pasan de 8 horas, y «Nunca» existe para el resto. Eso no me hace inmune, y que un proveedor diga que él es distinto es justo lo que el principio espera de él. Si Kubernetes resolviera esto de serie, kubelatch tendría menos razón de ser, y me parecería bien.

Por dónde empezar

Elige un equipo interno, un comité o una herramienta de tu empresa y mira cómo se mide. Si cuenta tickets atendidos, cambios aprobados o peticiones gestionadas, prueba a contar lo contrario durante un trimestre: cuántas peticiones han dejado de hacer falta, cuántos cambios salen ya sin pasar por nadie y cuánto trabajo manual ha desaparecido. Ponle al trabajo operativo un tope como el de Google, y decide antes qué hará ese equipo con el tiempo que libere, porque sin eso el tope no se cumple.

Picaporte Labs es una sola persona, en España. Si en tu empresa hay un equipo que vive de su problema, o uno que ha conseguido hacerlo desaparecer, escríbeme y cuéntame cómo lo medís.