🎖️Ley de Gall
Cómo escalar sistemas en tu empresa sin que colapsen
Hola 👋 bienvenido a la Newsletter de 🎖️Team Hackers.
Soy Felipe Polo y escribo esta newsletter para ayudar a fundadores y operadores de compañías a generar autonomía y equipos más fuertes.
Llevo años viendo el mismo patrón (y ahora en tiempos de IA se repite aún más): empresas decidiendo "rediseñar todo desde cero."
Contratan consultores, crean comités, escriben documentos de 80 páginas. Seis meses después, todo el mundo usa el sistema antiguo.
Y es que el problema nunca fue la ejecución, sino la premisa.
John Gall era pediatra. Ni consultor, ni ingeniero de sistemas, ni académico de management.
Pero en 1975 publicó Systemantics, un libro con humor seco e incómodo sobre cómo funcionan los sistemas. Y especialmente, cómo fallan.
Su observación más famosa terminó convertida en ley:
"Un sistema complejo que funciona es, invariablemente, producto de la evolución de un sistema simple que funcionaba."
Si la entiendes bien, cambia cómo construyes cualquier cosa: empresas, equipos, procesos, productos.
Y para quienes dirigimos empresas, tiene una implicación directa: la forma en que diseñamos nuestras organizaciones probablemente esté al revés.
Los sistemas se oponen a su propia función
Todo es un sistema. Tu empresa, tu proceso de ventas, tu onboarding, tu cultura.
Y cada uno tiene la misma tendencia natural: expandirse, perder foco, volverse opaco. Esto ocurre de manera sistemática en el momento en el que dejas de inyectarle energía.
(Es lo mismo que te pasa a ti cuando dejas tu rutina de deporte durante una semana).
Con el tiempo, se oponen a los objetivos para los que justamente fueron creados.
Gall lo formuló con mucha claridad: "Los sistemas tienden a oponerse a su propia función."
Un evento con doble significado para mí
Si eres fundador de una empresa de servicios digitales B2B, esto te interesa.
Por un lado, desde la comunidad de Escalando Agencias (que lidero junto a Corti y Miguel Sanz) organizamos el próximo 21 de Abril una cena para hacer networking y compartir experiencias con otros emprendedores del sector.
Por otro lado, el lugar donde se celebrará será LUK1, el restaurante de LUK (la marca de cerveza de la que soy co-fundador).
Este evento está diseñado para fundadores, líderes de agencias y consultoras e incluye una cena-coctel, donde las conversaciones trascienden el networking habitual.
Todos los detalles de la cena han sido cuidadosamente preparados: desde el menú hasta la atmósfera en el nuevo espacio de LUK1, un entorno cómodo con un ambiente cuidado.
Ofrecemos una experiencia exclusiva, donde buscamos crear espacios para conversaciones y conexiones con sentido entre el círculo reducido de líderes invitados top que nos acompañarán.
Puedes apuntarte aquí: https://luma.com/bv2yn901
Continuamos con sistemas que se oponen a su propia función con un ejemplo que cualquier fundador reconoce: el onboarding corporativo. Se diseñó para integrar personas de forma rápida y clara.
Pero evolucionó hasta convertirse en un laberinto de 14 plataformas, presentaciones genéricas y documentación redundante. El nuevo empleado termina aprendiendo más en Slack que en toda la formación oficial.
El sistema que debía acelerar la integración la convierte en una carrera de obstáculos. Y lo peor: la empresa ni se entera, porque nadie lo revisa como un sistema vivo. Solo como un checklist estático.
Esto aplica a todo. Facebook se creó para conectar personas; hoy optimiza para engagement, aunque eso genere polarización. La TSA en EE.UU. fue creada para detectar amenazas en aeropuertos; tests internos muestran que falla en el 95% de las simulaciones. Pero sigue ahí, porque los sistemas persisten incluso cuando sus resultados son nulos.
La complejidad funcional no se diseña. Se cultiva.
Aquí está el punto central de Gall.
No dice que todo sistema simple funcione. Dice algo más preciso: la única complejidad que sobrevive es la que creció desde algo que ya funcionaba en la práctica.
Tres razones estructurales explican esto:
Los sistemas generan interacciones impredecibles. Cada pieza nueva que sumas crea conexiones que no anticipaste. Y esas conexiones no son lineales. El comportamiento real del sistema es producto de sus interacciones internas, no de las intenciones de quien lo diseñó.
La complejidad útil solo sobrevive al uso real. Los sistemas exitosos crecen como organismos: prueba, error, poda, expansión. La evolución implica selección por desempeño. El diseño en papel no tiene esa presión selectiva.
Los diseños "desde arriba" generan fragilidad. HealthCare.gov lo demostró en 2013. El gobierno de EE.UU. invirtió cientos de millones en una plataforma de salud pública. Especificación de mil páginas, cero validaciones parciales y lanzamiento nacional de golpe.
El día 1, el sistema colapsó. Errores, caídas, formularios que no se enviaban. Escándalo técnico, mediático y político.
¿Cómo lo arreglaron? Un equipo de respuesta dividió el sistema en módulos funcionales, implementó telemetría y probó con usuarios reales en fases controladas. El mismo sistema, pero esta vez construido desde algo pequeño que sí funcionaba.
Eso es la Ley de Gall en acción. Y no es un caso aislado: TCP/IP, UNIX, la propia Web, todos siguieron el mismo patrón. Lo que funciona a gran escala siempre empezó funcionando a pequeña escala.
Cómo aplicar esto en tu empresa
La traducción operativa tiene cinco principios:
1. Empieza con algo que funcione de verdad. No un prototipo decorativo ni un MVP sin métricas. Una versión mínima que entrega valor real y mide su impacto. Gall distingue entre "simple" y "funcional": lo simple sin uso real no genera aprendizaje.
2. Interfaces estables, interior cambiante. Define contratos claros entre las partes del sistema (quién entrega qué, en qué formato, con qué plazo). Dentro de esos límites, cada equipo tiene libertad para iterar. Amazon lleva esto al extremo con equipos de "dos pizzas" y APIs internas obligatorias.
3. Mide desde el día 1. Lo que no se mide, no se mejora. Pero cuidado: lo que se mide mal, se deforma. Gall acuñó el acrónimo F.L.A.W. para describir esto: "Las cosas son lo que se reporta que son." Si tus métricas no reflejan la realidad operativa, el sistema optimiza para el informe.
4. Escala por replicación, no por agregación. No sumes capas. Replica estructuras que ya funcionan. Los datos del Efecto Ringelmann lo confirman: con 2 personas, cada una rinde al 93% de su potencial. Con 8, cae al 49% por individuo. Equipos pequeños y autónomos escalan mejor que organigramas gigantes.
5. Introduce caos controlado. Netflix lo hizo literal con Chaos Monkey: simulan fallos deliberados para forzar resiliencia. La robustez de un sistema no se prueba evitando problemas, sino inyectándolos de forma controlada.
Si alguien en tu equipo propone "hacerlo todo de una vez", recuerda la Ley de Gall. La historia está llena de sistemas que colapsaron por ambición prematura y de sistemas que escalaron por empezar pequeño.
Conclusión
TCP/IP derrotó al modelo OSI. HTTP empezó con un solo comando. UNIX nació pequeño y portable. La NASA llegó a la Luna construyendo Mercury primero, después Gemini, después Apollo.
Escalones, no saltos.
Si lideras un equipo o una empresa, la tentación constante es diseñar la solución perfecta desde el principio. Resiste. Construye algo pequeño que funcione. Ponlo en manos reales. Mide. Itera. Deja que la complejidad se gane su lugar.
Los sistemas complejos que funcionan no se diseñan. Evolucionan.
¿Alguna vez intentaste rediseñar algo "desde cero" y terminó peor que el original?
Por último, te invito a disfrutar del último capítulo que hemos grabado en Playbooks, donde entrevistamos a Nacho Tejero (fundador de Webel).
Su historia es realmente alucinante, merece la pena.
👏👏