
De 5 a 50 personas: cuándo se rompen los procesos y qué hacer antes de que pase
Los 3 puntos de quiebre operativos al escalar de 5 a 50 personas y cómo prepararlos antes de que todo se rompa.
Analizar con IA — elige tu favorita
Obtén un resumen del artículo al instante
Tu startup tiene 8 personas. Todo el mundo sabe lo que hace, más o menos. Las decisiones se toman en una conversación de Slack o en la mesa de la oficina. El founder sigue siendo el centro de gravedad de todo.
Tres meses después tienes 14. Y de repente nada funciona igual.
Los clientes esperan respuestas que nadie sabe quién tiene que dar. Los sprints se planifican pero nadie los cierra. Hay tres versiones de la propuesta comercial en Google Drive y ninguna es la buena. El equipo no está roto. Los procesos, sencillamente, no existen.
Este es el artículo que debiste leer antes de que eso pasara.
Lo que vas a aprender en este artículo:
Por qué crecer y escalar no son lo mismo, y cuándo esa diferencia empieza a costarte dinero
Los tres puntos de quiebre concretos donde los procesos de una startup se rompen (en torno a la persona 8-10, la 15-20 y la 30-50)
Qué sistematizar en cada punto antes de que el caos se instale
Qué es la deuda operativa y cómo calcular si ya la tienes
Cómo decidir si externalizar operaciones o contratar a alguien interno
Crecer no es escalar. La diferencia que nadie te explica hasta que duele
Crecer es facturar más, tener más clientes, contratar más gente. Escalar es hacer todo eso sin que el sistema interno se rompa por dentro.
Una startup puede crecer a toda velocidad y estar, al mismo tiempo, destruyendo valor. Cada cliente nuevo que entra genera más caos en el equipo. Cada contratación añade más confusión sobre roles y responsabilidades. Cada nueva herramienta que se incorpora al stack multiplica los silos de información.
Eso no es escalar. Es crecer con deuda operativa.
La diferencia entre una startup que escala y una que simplemente crece son las operaciones. Y las operaciones no se montan solas: alguien tiene que decidir, antes de que sea urgente, cómo va a funcionar la máquina cuando haya el doble de personas.
"Escalar no es crecer. Crecer es facturar más. Escalar es facturar más sin que todo se rompa por dentro. La diferencia, siempre, son las operaciones."
Lo que vemos cuando entramos en startups españolas en fase seed o Serie A es casi siempre lo mismo: equipos inteligentes, producto que funciona, clientes que pagan... y una cocina interna que no puede aguantar el ritmo. No porque la gente sea mala. Sino porque nadie montó la cocina antes de que el restaurante se llenara.
Si quieres entender en profundidad qué significa tener una infraestructura operativa real para una startup en fases tempranas, la guía de operaciones para startups de 2 a 50 personas cubre el territorio completo. Lo que vas a leer aquí es más específico: los momentos exactos en que los procesos se quiebran y qué hacer en cada uno.
Los tres puntos de quiebre. Dónde se rompen los procesos de verdad
No todos los momentos de crecimiento son igual de peligrosos. Hay tres umbrales donde el sistema operativo de una startup se rompe de forma predecible. No son teoría: son lo que vemos en proyecto tras proyecto.
Primer quiebre: de 5 a 10 personas
Hasta 7 u 8 personas, una startup puede funcionar con comunicación oral, documentación mínima y el founder como nodo central. No porque sea lo ideal, sino porque el tamaño lo permite. Hay suficiente contexto compartido para que todo el mundo sepa, más o menos, qué está pasando.
En torno a la persona 8 o 10, ese sistema se cae.
El problema no es la gente nueva: es que el contexto ya no se puede transmitir por osmosis. Las personas que llevan seis meses en la startup tienen una cabeza llena de decisiones implícitas, convenciones no escritas y formas de hacer las cosas que nunca se documentaron porque "todo el mundo lo sabe". Las personas que llevan seis semanas no tienen acceso a ese conocimiento. Y tampoco saben que no lo tienen.
Esto es lo que ocurre en la práctica:
La persona nueva envía una propuesta a un cliente usando una plantilla desactualizada.
El equipo de producto toma decisiones de roadmap sin comunicarlo al equipo comercial.
Tres personas distintas responden al mismo cliente con información inconsistente.
El founder sigue siendo el desatascador de todo, pero ahora hay más cosas atascadas que horas en su día.
Este es el momento donde nace la deuda operativa. Y si no se ataja aquí, crece con el equipo.
Qué sistematizar en este punto:
Antes de llegar a 12 personas, necesitas tener resueltos tres problemas básicos:
Primero, la definición de roles. No un organigrama formal con cajas y flechas: una respuesta clara a la pregunta "¿quién decide qué?". En cada área crítica del negocio (comercial, producto, operaciones, finanzas), tiene que haber una persona que sea el responsable final. Si hay ambigüedad, hay deuda.
Segundo, el protocolo de onboarding. Cómo incorporas a alguien nuevo en menos de una semana. Qué accesos tiene, qué lee, con quién habla, qué tiene que poder hacer solo al final de la primera semana. Si este proceso vive solo en la cabeza del founder, tienes un problema que escala mal.
Tercero, dónde vive la información. Una decisión única sobre dónde se documenta cada tipo de información. No "Notion para unas cosas y Google Drive para otras y Slack para lo que no cabe en ninguno de los dos". Una convención clara que el equipo siga de verdad.
En esta fase, el stack operativo mínimo viable es sencillo: Notion o Google Workspace para documentación, Slack para comunicación, y nada más que no se use todos los días. La complejidad no es tu amigo cuando tienes 10 personas y ningún proceso documentado.
Segundo quiebre: de 15 a 20 personas
Si el primer quiebre es de caos invisible, el segundo es de coordinación rota.
Entre 15 y 20 personas, una startup empieza a tener departamentos o áreas funcionales diferenciadas: hay un equipo de producto, un equipo comercial, quizás ya hay alguien de marketing, alguien de customer success. Y ahí es donde aparece el problema de la alineación.
Cada área empieza a optimizar para sus propios objetivos. El equipo comercial cierra clientes que producto no puede implementar en el plazo prometido. El equipo de customer success resuelve problemas que debería estar solucionando producto. Marketing lanza campañas sin coordinar con ventas. No es mala voluntad: es que no hay un sistema que mantenga a todo el mundo orientado hacia los mismos objetivos.
En startups españolas que han pasado por una aceleradora como Lanzadera o han cerrado una ronda seed con un fondo como K Fund o Samaipata, este momento suele coincidir con el primer año post-inversión. El dinero está en el banco, el equipo crece rápido, y la presión para demostrar tracción es alta. Es exactamente el momento donde menos tiempo hay para montar procesos... y donde más falta hacen.
El síntoma más claro de este quiebre es que el founder empieza a enterarse de los problemas demasiado tarde. No porque el equipo los oculte: sino porque no hay un sistema para que esa información fluya hacia arriba de forma estructurada.
"Si nadie en tu equipo sabe quién hace qué, no tienes un problema de personas. Tienes un problema de procesos."
Qué sistematizar en este punto:
Tres áreas críticas que no pueden estar sin estructura cuando llegas a 20 personas:
Métricas de negocio compartidas. No puede haber equipos distintos mirando métricas distintas y llegando a conclusiones distintas. A partir de 15 personas, necesitas un cuadro de mando único con las métricas que importan: MRR (Monthly Recurring Revenue, es decir, ingresos recurrentes mensuales), churn (tasa de cancelación), CAC (coste de adquisición por cliente), runway (meses de caja disponibles al ritmo actual de gasto) y una métrica de activación específica de tu producto. Cinco números que todo el equipo entiende y mira con la misma frecuencia.
Si quieres profundizar en cómo seleccionar esas métricas y qué hacer con ellas, el artículo sobre KPIs para startups en fase early-stage entra en el detalle de qué medir y qué ignorar según tu modelo de negocio.
Ciclo de planificación. Un ritmo de trabajo compartido entre equipos: qué se planifica, cuándo y quién participa. Puede ser un sprint quincenal con reunión de arranque y retrospectiva, o algo más ligero. Lo importante es que exista y que sea consistente. Sin ritmo, cada equipo opera en su propia frecuencia y la coordinación se convierte en una reunión improvisada cada vez que algo choca.
Procesos de los flujos críticos. No todos los procesos. Los críticos: el ciclo de ventas completo (desde lead hasta firma), el proceso de onboarding de cliente, el proceso de reporte de problemas de producto. Tres o cuatro flujos que concentran la mayoría de las fricciones. Cada uno documentado en una página de Notion: quién hace qué, en qué orden, con qué herramientas.
Un matiz importante: documentar no es crear burocracia. Un proceso bien diseñado elimina fricción y libera tiempo. La burocracia es lo que pasa cuando alguien confunde documentar con controlar. En este artículo de Ebägurin sobre procesos versus burocracia en startups se explica en detalle esa distinción, porque es el error más común que vemos en startups que intentan sistematizar por primera vez.
Tercer quiebre: de 30 a 50 personas
Este es el más serio. Y el más caro si no se anticipa.
Entre 30 y 50 personas, una startup deja de ser una startup en el sentido estricto del término. Es una organización con múltiples capas de gestión, con procesos que ya existen (aunque sean imperfectos) y con una cultura que ya está formada (aunque no sea la que querías). Es el momento de la transición real hacia scaleup.
Lo que suele romperse aquí no es un proceso concreto: es el sistema de toma de decisiones completo.
El founder ya no puede estar en todas las decisiones importantes. Pero los mandos intermedios (si los hay) no tienen los criterios claros para tomar esas decisiones por su cuenta. El resultado: o todo sube al founder y se crea un cuello de botella, o la gente toma decisiones sin suficiente contexto y la dirección estratégica se fragmenta.
Hay otro problema que aparece en este punto con mucha frecuencia: el stack de herramientas que funcionó hasta los 20 empieza a crujir. Notion se ha convertido en un cajón de sastre donde nadie encuentra nada. HubSpot Free ya no es suficiente para el volumen de deals y el equipo comercial lo parchea con hojas de cálculo. Hay cuatro integraciones de Make que nadie recuerda cómo funcionan. Y alguien acaba de proponer implementar Salesforce.
La solución no es Salesforce. La solución es claridad sobre qué necesitas y por qué.
Qué sistematizar en este punto:
Estructura de decisiones. Una matriz de delegación que deje claro qué tipo de decisiones puede tomar cada nivel de la organización sin escalar. No un documento corporativo de cien páginas: tres o cuatro categorías de decisiones con criterios claros. El founder toma las que afectan a estrategia o a gasto por encima de X euros. Los managers toman las que afectan a su área dentro de un perímetro definido. El equipo toma las operativas del día a día.
Stack operativo revisado. Auditoría completa de herramientas: qué se usa de verdad, qué se instaló y nadie toca, qué duplica funcionalidades. En casi todas las startups con las que trabajamos que llegan a este punto, hay entre dos y cuatro herramientas de pago activas que el equipo ha dejado de usar. Es dinero quemado y ruido cognitivo.
En esta fase, Notion deja de ser suficiente como herramienta central de gestión de proyectos para equipos de producto. Linear o Jira empiezan a tener sentido si el equipo técnico supera las 10 personas. HubSpot en versión de pago o un CRM más robusto empieza a ser necesario si el equipo comercial supera 5-6 personas. Son decisiones que dependen del modelo de negocio y del ritmo de crecimiento, no de una fórmula universal.
Operaciones como función, no como tarea accesoria. A los 30-50 personas, las operaciones ya no pueden ser una responsabilidad flotante que nadie tiene del todo. Alguien tiene que ser dueño de la cocina interna: procesos, métricas, herramientas, onboarding, eficiencia operativa. Puede ser un COO, un Head of Ops, o un equipo externo como Ebägurin mientras la startup decide si y cuándo contratar esa función internamente.
Deuda operativa: el concepto que tu startup no puede ignorar más
La deuda operativa es el equivalente a la deuda técnica, pero en procesos y estructura organizativa.
Cada vez que tomas una decisión de rol sin documentarla, tienes deuda operativa. Cada proceso que ejecutas de memoria porque "todo el mundo sabe cómo funciona", tienes deuda operativa. Cada métrica que no defines formalmente, cada herramienta que añades sin un propósito claro, cada onboarding que improvisas: deuda operativa.
El problema de la deuda operativa, igual que la técnica, es que no duele cuando se acumula. Duele cuando hay que pagarla.
Se paga de tres formas: con tiempo (alguien tiene que parar el crecimiento para poner orden), con errores (un proceso mal definido que produce un fallo con un cliente importante), o con personas (un miembro clave del equipo que se quema porque trabaja en el caos y decide irse).
Según nuestra experiencia trabajando con startups en distintas fases, el momento más habitual para pagar la deuda operativa forzosamente es justo después de una ronda de financiación. El equipo crece rápido, el caos previo se amplifica con las nuevas incorporaciones, y el founder se encuentra gestionando un incendio en lugar de usando el capital para crecer. Lo que parecía sostenible con 8 personas explota con 18.
Hay una forma de calcular, de forma aproximada, cuánta deuda operativa tiene tu startup. Hazte tres preguntas:
Si le pregunto a tres personas distintas de mi equipo quién es responsable de un proceso concreto (por ejemplo, el proceso de renovación de cliente), ¿me darán la misma respuesta?
Si mi persona más reciente en la empresa necesita saber cómo hacer algo que se hace habitualmente, ¿puede encontrar esa información sin preguntarle a alguien?
¿Tengo un cuadro de mando con las 5-7 métricas más importantes del negocio que todo el equipo mira con la misma frecuencia?
Si la respuesta a las tres es no, tienes deuda operativa significativa. No es un diagnóstico catastrófico: es una señal clara de que hay trabajo por hacer antes de que el crecimiento lo amplifique.
"La deuda operativa no duele cuando se acumula. Duele cuando hay que pagarla: con tiempo, con errores, o con personas que se van."
Externalizar vs. contratar: la decisión que la mayoría de startups toma mal
Cuando una startup llega a los puntos de quiebre que describíamos antes, hay una decisión que aparece inevitablemente: ¿contratamos a alguien interno para gestionar esto o trabajamos con alguien externo?
Es una decisión que muchos founders toman basándose en la intuición o en lo que han visto hacer a otras startups. Hay una forma más ordenada de pensarla.
Cuándo tiene sentido contratar internamente
Contratar un perfil interno de operaciones (COO, Head of Ops, o un Operations Manager) tiene sentido cuando se dan estas condiciones:
La startup lleva más de 12-18 meses en fase operativa activa con equipo.
Hay más de 25 personas y los procesos son suficientemente complejos como para necesitar atención continua.
El modelo de negocio ya está suficientemente validado (PMF, Product-Market Fit, confirmado) como para saber que las operaciones que se monten van a escalar en la misma dirección durante los próximos 12-18 meses.
El perfil que se necesita es alguien que ejecute de forma continua dentro de la empresa, no solo que monte la estructura.
El error más habitual es contratar un perfil de operaciones demasiado pronto: cuando el modelo de negocio aún está evolucionando rápido y los procesos que se monten hoy necesitarán rehacerse en seis meses. En ese momento, contratar a alguien fijo para montar procesos que van a cambiar es quemar runway en la dirección equivocada.
Cuándo tiene sentido externalizar
Trabajar con un equipo externo de operaciones tiene sentido cuando:
Estás en un punto de quiebre claro (persona 8-10, 15-20 o 30-50) y necesitas resolver el caos rápido, no en el tiempo que tardarías en contratar y onboardear a alguien.
El modelo de negocio aún está evolucionando y no tiene sentido contratar una función fija hasta tener más claridad.
Necesitas un diagnóstico externo sin sesgos internos: alguien que vea la startup desde fuera y diga lo que nadie dentro se atreve a decir.
El coste de un perfil senior de operaciones a jornada completa (un Head of Ops en España con experiencia en startups puede estar en un rango de 50.000 a 80.000 euros anuales en función de la ciudad y la seniority) no está justificado en la fase actual.
Un equipo operativo externo entra, diagnostica, monta los procesos y herramientas que la startup necesita en ese momento, y transfiere el conocimiento al equipo interno. No es una solución permanente: es lo que permite que la startup llegue en buena forma al momento donde sí tiene sentido contratar internamente.
"No necesitas un COO a jornada completa. Necesitas que alguien monte la cocina antes de que se queme el restaurante."
Lo que no funciona es no decidir: el founder asumiendo funciones de operaciones además de todo lo demás, o distribuyendo la responsabilidad operativa entre varias personas que tienen otras prioridades. Eso no es una solución: es aplazar la deuda operativa hasta que el interés sea impagable.
Cómo empezar: el diagnóstico antes del plan
Antes de lanzarte a documentar procesos, migrar herramientas o redefinir roles, hay un paso previo que la mayoría de startups se salta: saber exactamente cuál es el estado real de sus operaciones.
No el estado que el founder cree que tienen. El estado real.
Un diagnóstico operativo honesto cubre cuatro áreas:
Procesos. ¿Cuáles existen documentados? ¿Cuáles existen solo en la cabeza de alguien? ¿Cuáles directamente no existen? ¿En cuáles hay inconsistencia entre cómo se supone que funciona y cómo funciona de verdad?
Herramientas. ¿Qué hay en el stack actualmente? ¿Qué se usa de verdad versus qué se instaló y quedó olvidado? ¿Hay duplicidades? ¿Hay flujos críticos que se gestionan con hojas de cálculo o WhatsApp porque ninguna herramienta los cubre bien?
Métricas. ¿Qué se mide? ¿Quién lo mira y con qué frecuencia? ¿Hay un cuadro de mando único o cada equipo tiene el suyo? ¿Las métricas que se miran son las que realmente reflejan la salud del negocio?
Roles y responsabilidades. ¿Para cada proceso crítico hay una persona claramente responsable? ¿El equipo tiene claridad sobre quién decide qué? ¿Los roles están definidos de forma que escalan cuando el equipo crece, o están diseñados alrededor de las personas actuales?
El output de este diagnóstico es un mapa claro: qué funciona (y por tanto no hay que tocar), qué falla (y hay que priorizar), y qué hay que montar desde cero. Sin ese mapa, cualquier intervención operativa corre el riesgo de optimizar lo que no importa o de crear más complejidad donde se necesita simplicidad.
En Ebägurin, el diagnóstico operativo es la primera fase de cualquier proyecto. Dedicamos una o dos semanas a hacer ese mapa con el equipo antes de tocar nada. No porque nos guste la burocracia: sino porque sin ese mapa, la probabilidad de priorizar mal es muy alta.
El momento de actuar no es cuando ya duele
Hay una trampa en la que caen la mayoría de founders: esperar a que los problemas operativos sean insostenibles para actuar.
El problema es que cuando ya duele, el coste de arreglarlo es mucho más alto. Hay deuda acumulada. Hay hábitos instalados en el equipo. Hay clientes que ya han notado los síntomas. Y hay un founder que tiene que gestionar el incendio al mismo tiempo que intenta crecer.
El momento para montar la cocina no es cuando el restaurante ya está lleno y hay fuego en la cocina. Es justo antes del siguiente pico de crecimiento.
Si estás en el primer quiebre (alrededor de 8-10 personas), tienes una ventana estrecha pero real para sentar las bases antes de que el siguiente sprint de contrataciones amplifique el caos.
Si estás en el segundo (15-20 personas), probablemente ya sientes la fricción. La pregunta no es si hay un problema: es si vas a resolverlo ahora o vas a esperar a que sea más caro.
Si estás en el tercero (30-50 personas), el diagnóstico es urgente. No porque todo esté roto, sino porque a partir de aquí cada mes sin estructura operativa cuesta más en tiempo, en dinero y en talento.
La pregunta no es si tu startup necesita operaciones. Es cuánto tiempo más puedes permitirte no tenerlas.
Si esto describe lo que está pasando en tu startup, empezamos con un diagnóstico de 1-2 semanas donde mapeamos exactamente qué funciona, qué falla y qué hay que montar. Sin soluciones genéricas, sin frameworks copiados de un blog americano. Con lo que necesita tu startup en el punto donde está ahora. Conoce el Plan Diagnóstico Express →
Preguntas frecuentes
¿A partir de cuántas personas necesita una startup procesos documentados?
Los primeros procesos críticos deben existir antes de llegar a 10 personas, no después. El umbral más habitual es entre la persona 7 y la 10, cuando el contexto ya no se transmite por osmosis y las incorporaciones nuevas no tienen acceso al conocimiento implícito del equipo fundador. Esperar a que el equipo tenga 15 o 20 personas para empezar a documentar significa empezar con deuda operativa acumulada.
¿Qué es la deuda operativa en una startup y cómo se acumula?
La deuda operativa es el conjunto de procesos no documentados, roles ambiguos, métricas no definidas y decisiones no registradas que se acumulan cuando una startup crece sin sistematizar. Es el equivalente a la deuda técnica, pero en la organización. Se acumula silenciosamente y se paga de forma forzosa: con tiempo de liderazgo perdido, con errores que llegan a los clientes o con personas clave que se agotan y se van.
¿Cuándo tiene sentido contratar un COO en una startup española?
Contratar un COO o Head of Ops internamente tiene sentido cuando la startup tiene más de 25 personas, el modelo de negocio está suficientemente validado para saber que los procesos que se monten van a escalar en la misma dirección, y la complejidad operativa justifica una dedicación continua. Por debajo de ese punto, o mientras el modelo aún evoluciona rápido, trabajar con un equipo externo de operaciones suele ser más eficiente y consume menos runway.
¿Cuáles son las métricas operativas mínimas que debe seguir una startup en fase seed?
En fase seed, con 10-20 personas, las métricas que importan son: MRR (ingresos recurrentes mensuales), churn (tasa de cancelación mensual), CAC (coste de adquisición por cliente), runway (meses de caja disponibles al ritmo actual de gasto) y una métrica de activación específica del producto. Medir más de 7 indicadores con un equipo pequeño es, en la práctica, no medir ninguno: hay demasiado ruido para extraer señal útil.
¿Qué diferencia hay entre una startup que escala bien y una que solo crece?
Una startup que crece aumenta facturación y equipo. Una startup que escala hace lo mismo sin que los procesos internos, la calidad del servicio o la capacidad de decisión se deterioren en proporción. La diferencia son las operaciones: los sistemas, procesos y métricas que permiten que el crecimiento sea sostenible y no destruya más valor del que crea.
¿Por qué fallan los procesos cuando una startup pasa de 15 a 20 personas?
Porque en ese rango aparecen por primera vez departamentos diferenciados con objetivos propios. Sin un sistema de métricas compartidas y un ciclo de planificación común, cada área empieza a optimizar para sus propios resultados. El equipo comercial promete plazos que producto no puede cumplir. Marketing lanza campañas sin alinear con ventas. La coordinación deja de ser automática y necesita estructura para funcionar.
¿Qué herramientas necesita una startup de 15-20 personas para gestionar sus operaciones?
En esa fase, el stack operativo mínimo viable suele ser: Notion o una herramienta equivalente para documentación y gestión del conocimiento, Slack para comunicación interna, HubSpot (versión gratuita o Starter) para CRM, Google Workspace para colaboración documental, y Make o Zapier para automatizaciones puntuales. Antes de añadir cualquier herramienta nueva, la pregunta correcta es: ¿qué proceso concreto resuelve esto y quién del equipo lo va a usar todos los días?