Esta startup imaginaria creció por equipos autónomos: pasó de cinco a cincuenta personas en un escenario diseñado por MEE. El caso es hipotético y sus cifras no documentan una empresa real. Sirve para examinar decisiones, dependencias y reglas de coordinación, incluyendo problemas que un relato de crecimiento exitoso podría dejar fuera.
Creció por equipos autónomos: cómo leer este caso
Imaginemos una empresa que desarrolla software de reservas para pequeños negocios. Al comienzo trabajan cinco personas. Comparten conversaciones con clientes, desarrollo y atención de incidencias. La fundadora conoce casi todos los compromisos. Cuando el escenario alcanza quince personas, algunas consultas y autorizaciones siguen esperando su respuesta aunque otras personas ya conocen el problema.
Los tamaños elegidos permiten recorrer una historia; no son umbrales científicos de organización. La empresa y sus decisiones son inventadas. Tampoco suponemos que contratar más personas haya causado una mejora económica. Aquí el crecimiento de plantilla es una condición del ejercicio, cuyo objetivo consiste en discutir cómo organizar el trabajo.
Como referencia delimitada, Henrik Kniberg y Anders Ivarsson describieron en 2012 equipos con misiones y capacidad para elegir métodos de trabajo en Spotify. Advirtieron que su documento era una instantánea de una organización en evolución. Consultamos páginas seleccionadas, no tratamos aquella descripción como el organigrama actual ni como prueba de que copiarla garantice resultados.
De cinco a quince: dar un objetivo a cada equipo
En nuestro caso, la empresa imaginaria agrupa trabajo alrededor de necesidades del usuario. Un equipo atiende el alta de negocios; otro, los cambios de una reserva; otro, las incidencias que bloquean el servicio. Antes de repartir personas, sus integrantes aclaran qué resultado esperan y qué conocimientos necesitan para entregarlo.
Ejemplo hipotético: el equipo de altas puede modificar una pantalla y comprobar con usuarios si comprenden el siguiente paso. Si el cambio requiere alterar el acceso a datos compartidos, debe coordinarlo con quienes mantienen esa parte del sistema. El ejemplo pertenece al escenario inventado y no describe un procedimiento de Spotify.
La fundadora deja por escrito qué decisiones conserva y cuáles puede resolver cada equipo. Si recibe una consulta ya delegada, ayuda a encontrar la información necesaria y revisa después el resultado. El ejercicio plantea una dificultad: delegar exige permitir decisiones que podrían hacerse de otra manera, dentro de los límites acordados.
De quince a cincuenta: información y coordinación
Al llegar a cincuenta personas en el escenario, aparecen más dependencias. Un equipo promete una función que necesita trabajo de otro; dos grupos interpretan de forma distinta una prioridad. Sus integrantes deciden mantener visibles los compromisos y los bloqueos, de modo que quienes reciben una promesa puedan entender de qué depende.
Proponemos que la empresa ficticia use una lista compartida de decisiones pendientes: qué falta, a quién afecta y quién puede resolverlo. La lista no necesita contar cada conversación. Debe permitir detectar un compromiso incompatible antes de comunicarlo como seguro. Su utilidad se revisaría observando si el equipo encuentra respuestas y puede corregir errores.
También acuerdan encuentros de coordinación con una finalidad concreta: resolver una dependencia, revisar un problema repetido o compartir una decisión que afecta a otros. No se fija aquí una duración universal ni una frecuencia obligatoria. La reunión merece mantenerse si quienes participan pueden explicar qué trabajo permitió resolver.
Qué se decidió en común y qué quedó en cada equipo
La organización imaginaria conserva decisiones comunes sobre presupuesto general, compromisos que afectan al servicio completo y responsabilidades sobre recursos compartidos. Cada equipo elige cómo abordar sus tareas dentro de esos límites. Esta distribución es una propuesta del ejercicio y necesitaría revisión técnica y legal para una actividad real.
Ejemplo hipotético: dos equipos quieren cambiar simultáneamente una parte compartida del producto. En lugar de prometer ambas entregas sin consultar, anotan la incompatibilidad, acuerdan un orden y explican a quienes esperan qué cambia. El escenario no aporta cifras de productividad; muestra la pregunta que deben resolver para poder cumplir una promesa.
Un límite debe ser comprensible y tener un motivo. Quien recibe una negativa debería poder saber qué compromiso se protege y qué alternativa puede explorar. Si toda propuesta vuelve a necesitar la aprobación de la fundadora, el grupo tendría que revisar si ha distribuido autoridad suficiente o solo ha cambiado los nombres.
El mejor argumento en contra: multiplicar dependencias
Kniberg e Ivarsson señalaban la autonomía sin dependencias bloqueantes como un ideal todavía difícil de alcanzar en su descripción. Esa advertencia invita a formular una objeción al ejercicio: dividir el trabajo podría crear nuevas esperas si los equipos no pueden terminar una tarea sin negociar cada paso con los demás.
En nuestra empresa ficticia aparece ese problema cuando tres grupos necesitan la misma ayuda técnica. Añadir otra reunión no resuelve automáticamente la escasez. La propuesta de MEE sería identificar el recurso que falta, revisar prioridades y estudiar si hace falta compartir conocimiento, cambiar responsabilidades o limitar los compromisos asumidos.
Otra dificultad del escenario surge cuando cada equipo mejora su tarea y nadie revisa el recorrido completo del cliente. Por eso el ejercicio incluye observar una reserva desde el alta hasta una incidencia. Esa revisión podría revelar un problema entre equipos aunque cada grupo considere correcto su propio resultado.
La lectura de MEE: adaptar después de observar
La tesis de MEE es que un equipo necesita información, facultades y recursos para responder por un resultado. El reparto debe revisarse desde las dependencias reales del trabajo. Un esquema atractivo puede servir para abrir preguntas, pero la decisión exige comprender qué sucede cuando llega un pedido, falla una entrega o cambia una prioridad.
- Recorre una tarea completa e identifica esperas, decisiones y recursos compartidos.
- Aclara el objetivo del equipo y los límites de su autoridad.
- Haz visibles las promesas que dependen del trabajo de otras personas.
- Revisa un incumplimiento y una entrega lograda antes de ampliar el reparto.
Este caso ofrece una conversación de diseño, sin demostrar una trayectoria empresarial. Las personas del negocio real tendrán que aportar su conocimiento, contrastar los costes del cambio y reconocer los desacuerdos. Mantener esa revisión forma parte del trabajo de organizarse con autonomía.
Preguntas frecuentes
¿La empresa del caso existe?
No. Es un escenario hipotético creado por MEE para discutir decisiones de organización. Sus tamaños de plantilla, equipos y problemas son condiciones del ejercicio, sin clientes, ingresos o resultados reales detrás. Las referencias documentadas se identifican aparte y no convierten esta historia en un testimonio de éxito ni en una investigación empresarial.
¿Hay que dividir equipos al llegar a quince personas?
Esa cifra forma parte del escenario y no establece una regla. Un negocio debería estudiar qué tareas necesitan coordinación, qué decisiones se retrasan y qué recursos se comparten. MEE propone comenzar por esas observaciones. El número de personas puede aportar contexto, pero no determina por sí solo un reparto correcto de responsabilidades.
¿Conviene copiar el modelo descrito sobre Spotify?
El documento citado refleja una experiencia situada en 2012 y sus autores señalan que estaba evolucionando. MEE lo usa como referencia para preguntar por misiones y dependencias. Una aplicación actual necesita examinar el trabajo propio, sus capacidades y sus restricciones. Copiar nombres o diagramas no garantiza que los equipos puedan entregar resultados.
Para seguir aprendiendo
- El número de Dunbar y el tamaño de los equipos
- Las crisis del crecimiento: el modelo de Greiner
- Autogestión en la práctica: Morning Star
Fuentes y alcance
Consulta y revisión: 04/11/2026. Los ejemplos hipotéticos y las pautas prácticas son propuestas de MEE. Se indica el alcance de las fuentes consultadas.
- Kniberg e Ivarsson · Scaling Agile @ Spotify · 2012. Páginas1–4 y14; experiencia situada en2012, sin describir la organización actual. Consulta: 04/11/2026.
- Anders Ivarsson · presentación del documento · 2012. Presentación del coautor en2012; se conserva el alcance histórico. Consulta: 04/11/2026.
