¿El "modelo Spotify" existe?

Qué decían realmente los famosos vídeos y papeles

En 2012, Henrik Kniberg y Anders Ivarsson publicaron un documento que se volvería legendario, titulado Scaling Agile @ Spotify. Poco después llegaron dos vídeos animados sobre la cultura de ingeniería de la compañía que acumularon millones de visualizaciones. De ahí salieron los términos que hoy repetimos sin pensar.

Conviene releer aquel documento con atención, porque dice cosas que la mayoría de quienes lo citan parecen haber olvidado. Sus autores advertían de forma explícita que estaban describiendo una fotografía de un momento concreto, no una fórmula terminada. Reconocían que la propia Spotify estaba en evolución constante, que muchas de esas prácticas todavía no funcionaban bien del todo, y que para cuando alguien leyera el texto probablemente ya habrían cambiado de forma de trabajar. En otras palabras, nunca presentaron aquello como un modelo replicable. Lo presentaron como una instantánea honesta y provisional de una organización que experimentaba.

La distinción no es un matiz menor. Un modelo es algo que se diseña para ser reproducido. Una fotografía es el registro de un instante que ya pasó. Hemos pasado más de una década tratando como manual de instrucciones lo que sus propios autores describieron como una postal.

De la instantánea al dogma

¿Cómo se convierte una descripción provisional en un dogma organizacional? El mecanismo es conocido y no es exclusivo de Spotify. Las organizaciones buscan certidumbre, y un modelo con nombre propio, vocabulario pegadizo y el aval de una empresa admirada ofrece exactamente eso. Copiar la estructura de alguien que ha tenido éxito parece un atajo hacia ese mismo éxito.

El problema es que ese razonamiento confunde correlación con causa. Spotify creció y triunfó, y al mismo tiempo se organizaba en squads y tribus. De ahí a concluir que se organizó así y por eso triunfó hay un salto lógico enorme. Puede que la estructura ayudara, puede que fuera irrelevante, puede incluso que triunfara a pesar de ciertos aspectos de ella. Lo que sabemos, porque la propia compañía lo ha reconocido después, es que aquel diseño generó problemas serios de coordinación y de responsabilidad que tuvieron que corregir con el tiempo.

Jeremiah Lee, que trabajó dentro de Spotify, escribió en 2020 un análisis muy citado en inglés y casi ausente en español, donde relataba que el modelo tal como se popularizó nunca llegó a funcionar plenamente ni siquiera dentro de la propia empresa. Describía dificultades reales en la colaboración entre squads, una matriz confusa entre autonomía y alineación, y una brecha entre la teoría difundida y la práctica cotidiana. La conclusión incómoda es que muchas empresas adoptaron con entusiasmo una versión idealizada de algo que su creador ya estaba desmontando.

El error de copiar estructuras en lugar de resolver problemas

Detrás de la fascinación por el modelo Spotify late un error más profundo y más general, uno que afecta a casi todos los intentos de imitar a organizaciones de éxito. Copiamos la solución visible de otro sin entender el problema que esa solución venía a resolver en su contexto.

Una estructura organizativa no es una plantilla neutral que se pueda trasplantar. Es una respuesta a un conjunto concreto de circunstancias: un producto determinado, un mercado, una historia, un talento disponible, una cultura previa, un momento de crecimiento. Los squads de Spotify tenían sentido dentro de una empresa de producto digital, con ingenieros de un perfil concreto, en una fase de expansión específica y con una cultura que ya valoraba la autonomía. Trasladar esa carcasa a un banco, una aseguradora o una administración pública, con otra historia, otros incentivos y otra cultura, y esperar el mismo resultado, es como ponerse la camiseta de un atleta esperando correr igual de rápido.

Melvin Conway formuló en 1968 una observación que ilumina bien este punto. Las organizaciones tienden a diseñar sistemas que reproducen su propia estructura de comunicación. Cambiar el organigrama sin cambiar cómo se comunica y colabora la gente produce, en el mejor de los casos, un cambio cosmético. Los nombres nuevos se superponen a las viejas dinámicas, y la tribu no es más que el antiguo departamento con una etiqueta más moderna.

Lo que la copia deja fuera

Cuando una organización adopta la jerga de Spotify, suele importar lo visible y dejar fuera lo esencial, que casualmente es lo más difícil de copiar.

Lo visible son las cajas del organigrama: squads, tribus, capítulos, gremios. Es lo que se puede dibujar en una diapositiva el lunes por la mañana. Lo esencial, en cambio, es todo lo que hacía que aquellas cajas funcionaran en su contexto original. Hablamos de un nivel alto de confianza, de una tolerancia real al error, de autonomía verdadera respaldada por quien tenía el poder de concederla, de un perfil profesional acostumbrado a decidir, y de una cultura construida durante años. Nada de eso cabe en una diapositiva ni se implanta por decreto.

El resultado habitual es lo que algunos han llamado teatro de la agilidad. La empresa tiene squads que no deciden nada, capítulos que no comparten conocimiento real, y gremios que son listas de correo olvidadas. La estructura está, la sustancia no. Y como la estructura era lo que se prometió, cuesta reconocer que lo que faltaba era justamente lo que no se podía copiar.

Qué dice esto sobre nuestra relación con los marcos

La crítica al modelo Spotify sería incompleta si se quedara en Spotify, porque el fenómeno es más amplio. La comunidad ágil tiene una tendencia recurrente a buscar el marco definitivo, la fórmula que por fin resuelva la complejidad organizativa. Primero fue Scrum aplicado literalmente, luego SAFe con su promesa de escalar, después el modelo Spotify, y la lista sigue. Cada cierto tiempo aparece una nueva respuesta empaquetada que promete evitarnos el trabajo incómodo de pensar por nosotros mismos.

Dave Snowden, con su marco Cynefin, lleva años recordándonos algo que deberíamos tener más presente. Los problemas organizativos suelen pertenecer al dominio de lo complejo, donde no existen buenas prácticas universales porque la relación entre causa y efecto solo se entiende en retrospectiva. En ese terreno, copiar la solución de otro es especialmente arriesgado, porque lo que funcionó allí surgió de unas condiciones que no se repiten. Lo que toca no es replicar, sino experimentar, observar y adaptar.

Esto conecta con una idea que en Scrum Manager está en la base de cómo entendemos la agilidad organizacional. Herramientas como AgiLevel no proponen un modelo único que imitar, sino que ayudan a una organización a evaluar sus propias prácticas y valores culturales sin prescribir un marco concreto. La diferencia es de fondo. En lugar de preguntar "¿cómo se organiza la empresa admirada?", la pregunta útil es "¿qué problema real tenemos nosotros y qué diseño lo resolvería en nuestro contexto?".

El contexto de la IA: el nuevo modelo que copiar sin entender

Merece la pena señalar que este patrón no es cosa del pasado, sino que se está repitiendo ahora mismo con la inteligencia artificial. Empiezan a circular las historias de empresas que han "transformado su forma de trabajar con IA", y con ellas la tentación de copiar sus recetas: esta estructura de equipos, esta forma de integrar agentes, este nuevo rol.

El riesgo es idéntico al del modelo Spotify. Tomaremos la fotografía provisional de una organización que experimenta, la convertiremos en modelo, y la trasplantaremos a contextos que no tienen nada que ver, esperando el mismo resultado. Y como la IA evoluciona todavía más rápido que la agilidad de 2012, la foto quedará obsoleta aún antes. La lección que el modelo Spotify debería habernos enseñado se vuelve más urgente, no menos: no copies la estructura de nadie, entiende tu problema y diseña para él.

Quizá el mayor homenaje que podemos hacer a lo que Spotify compartió en 2012 no sea imitarlo, sino imitar su actitud. Aquella gente estaba experimentando, se equivocaba, ajustaba y tenía la honestidad de contarlo como un trabajo en curso. Lo que hicimos con su relato, congelarlo en un modelo y venderlo como fórmula, va justo en contra de lo que ellos hacían.

La agilidad nunca fue copiar la respuesta de otro. Fue desarrollar la capacidad de encontrar la propia. Y esa capacidad no se importa con un organigrama nuevo ni con un vocabulario de moda. Se construye despacio, en el contexto de cada organización, resolviendo los problemas que uno tiene y no los que tuvo otro.

¿Y en tu organización? ¿Habéis adoptado alguna vez un modelo ajeno por admiración más que por diagnóstico? ¿Qué pasó con la sustancia cuando llegó la estructura?

Bibliografía

• Cagan, M. (2024). Transformed: Moving to the Product Operating Model. Wiley.
• Conway, M. E. (1968). How Do Committees Invent?. Datamation, 14(4), 28-31.
• Denning, S. (2018). The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done. AMACOM.
• Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
• Kniberg, H., & Ivarsson, A. (2012). Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds.
• Lee, J. (2020). Failed #SquadGoals: Spotify doesn't use "the Spotify model" and neither should you.
• Reinertsen, D. G. (2009). The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing.
• Rigby, D. K., Sutherland, J., & Takeuchi, H. (2016). Embracing Agile. Harvard Business Review, 94(5), 40-50.
• Skelton, M., & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press.
• Snowden, D. J., & Boone, M. E. (2007). A Leader's Framework for Decision Making. Harvard Business Review, 85(11), 68-76.

Si quieres evaluar la agilidad real de tu organización sin partir de un modelo importado, AgiLevel (agilevel.com) es la herramienta de diagnóstico de Scrum Manager pensada para eso.