🎖️The bus factor
Aprendiendo del incidente de Crowdstrike
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 equipos más fuertes que funcionen sin ellos.
El bus factor nació en el mundo de la ingeniería de software, pero aplica a cualquier equipo que dependa demasiado de unas pocas personas. En pocas palabras: es el número mínimo de personas cuya ausencia paralizaría tu operación.
No mide talento, mide dependencia estructural.
🚍 Literalmente significa el “número de programadores que, si fueran atropellados por un autobús dejarían al proyecto sin capacidad de reacción ni continuación”.Cuanto más bajo es el bus factor, más frágil es tu sistema.
Si una persona clave se va (o simplemente se toma vacaciones) y todo se detiene… estás en zona de riesgo.
¿Cómo de distribuido está el conocimiento en tu equipo?
Un bus factor de 1 significa que hay una sola persona que concentra elementos críticos del negocio: código, accesos, decisiones, infraestructura, procesos… Si no está, el proyecto se detiene.
Y no importa su cargo. Lo que cuenta es su propiedad cognitiva:
¿Quién sabe cómo funciona?
¿Quién puede ejecutarlo?
¿Quién tiene acceso real?
¿Quién desbloquea cuando algo falla?
Esto no va de organigramas. Va de resiliencia operativa. Y un bus factor bajo te deja expuesto cuando menos te lo esperas.
¿Por qué ocurre esto?
No siempre es mala gestión. Muchas veces es consecuencia de:
Crecimiento acelerado sin estructura
Procesos que se improvisan sobre la marcha
Documentación que nunca llegó
Hiperespecialización acumulada sin redundancia
Pero da igual cómo llegaste ahí. Lo importante es que un conocimiento mal distribuido convierte cualquier imprevisto en una crisis innecesaria.
CrowdStrike: cuando un único fallo paraliza el planeta
El 19 de julio de 2024, una actualización defectuosa de CrowdStrike provocó la mayor caída tecnológica coordinada de la última década.
No fue un ciberataque. Ni un fallo de hardware. Fue un solo archivo, firmado y distribuido globalmente, que en minutos bloqueó millones de dispositivos Windows.
Lo relevante no fue el error. Fue la arquitectura que permitió que un único fallo se propagara sin fricción: hospitales, aerolíneas, bancos, gobiernos… todos cayeron en cadena.
Este es el bus factor aplicado a sistemas:
Un solo flujo validaba y propagaba reglas a nivel mundial
Sin revisión secundaria
Sin segmentación
Sin frenos ante anomalías
Todo dependía de que ese único archivo fuera perfecto.
Ese diseño, aunque eficiente, no toleraba errores.
Lo que reveló el incidente
La magnitud del colapso dejó algo claro:
La estabilidad no es cuestión de tamaño, sino de diseño.
Y ese diseño tiene que asumir que los errores son inevitables.
CrowdStrike optimizó la velocidad y la uniformidad del despliegue. Pero esa elección sacrificó la capacidad de contener fallos.
Y en sistemas complejos, no contener es amplificar.
Lo que todo líder debe aprender de CrowdStrike
1. Concentración operativa = fragilidad
Aunque funcione hoy, un sistema sin alternativas está expuesto.
2. El problema no es el error, es cómo se propaga
Un archivo erróneo no debería tener el poder de romperlo todo. Si lo tiene, hay un problema estructural.
3. Escalar no es ir más rápido, es tolerar errores sin colapsar
La rapidez sin control multiplica el riesgo.
4. El bus factor no es solo humano, es sistémico
Puedes tener 200 ingenieros, pero si todos dependen de un mismo pipeline o validador, sigues en riesgo.
5. El diseño debe esperar errores, no evitarlos
La resiliencia se construye asumiendo que algo fallará… y asegurándote de que no arrastre al resto.
6. Los riesgos invisibles son los más peligrosos
Sistemas, procesos, automatizaciones: lo que nadie mira suele ser lo que más impacto tiene.
7. Escalar = distribuir poder operativo
Un negocio crece de verdad cuando ningún componente puede frenarlo solo.
8. La resiliencia no es reacción, es previsión
CrowdStrike reaccionó rápido, pero la arquitectura no estaba preparada. Y eso marca la diferencia.
9. Tu proveedor crítico también es parte de tu bus factor
No se trata de tener un plan B, sino de diseñar un plan A que no dependa de una sola pieza.
10. La redundancia inteligente es más valiosa que el tamaño
CrowdStrike era enorme, pero su talón de Aquiles estaba en un solo punto. El problema no era su escala, era su concentración.
Conclusión: un fallo no debería tener permiso para escalar
El bus factor no es solo un concepto técnico. Es una alerta estratégica. Te dice dónde tu empresa es vulnerable de verdad.
Y para un fundador que quiere escalar sin perder el control, hay una regla clave:
Tu negocio debe seguir funcionando incluso si hoy falla lo indispensable.
Eso es escalar con cabeza. Eso es diseñar para durar.
Entrevistamos a TaxDown en Playbooks
¿Cómo ha pasado una empresa de 0 a 10M en un nicho tan aburrido como la declaración de la renta?
En este episodio de Playbooks, el CEO de Taxdown nos desvela su historia y los secretos fiscales de Hacienda.
📘 De operador a diseñador de equipos autónomos
He creado para ti el minicurso “De Operador a Diseñador de equipos autónomos”, en el que explico por qué los equipos dependen demasiado de sus líderes (y cómo hacer que el tuyo funcione sin ti).
¡Gran post, Felipe!
Me da que pensar, lo importante que es plantear estos dilemas desde todos los extremos de la compañía. Integrar la toma de decisiones. Desde la capacidad de maniobra que da un buen pricing, por ejemplo, hasta los ámbitos donde la personalización de las actividades es fundamental (por ejemplo las relaciones personales + estratégicas).
Algunos riesgos no son evitables pero sí son predecibles. De cara a tener un plan de mitigación.