Cómo definir roles en un equipo de 5 personas sin organigramas ridículos

Tu startup tiene cinco personas. Lleváis meses funcionando. El producto avanza, los primeros clientes están ahí, y el equipo es lo suficientemente pequeño como para que todo el mundo sepa más o menos lo que hace el resto.

Más o menos.

Porque cuando algo falla, o cuando aparece una tarea nueva que nadie esperaba, empieza el baile: miradas cruzadas, "yo pensaba que lo hacías tú", decisiones que se toman dos veces o no se toman ninguna. Y entonces alguien propone hacer un organigrama.

El organigrama no va a resolver tu problema.

Lo que vas a aprender en este artículo:

• Por qué los organigramas tradicionales no funcionan en equipos de 5 personas y qué hacen en su lugar los equipos que sí operan bien

• Cómo construir un mapa de responsabilidades simple: quién decide, quién ejecuta, quién revisa

• Cómo manejar los solapamientos de rol sin generar conflictos ni fricciones

• Cuándo redefinir roles (y qué señales te avisan de que ya toca)

• Una estructura básica que puedes montar en Notion esta misma semana

Por qué el organigrama es la respuesta equivocada

Un organigrama es una herramienta para representar jerarquía. Quién reporta a quién. Líneas de mando. Niveles de autoridad.

En una startup de cinco personas, eso no es lo que necesitas. Necesitas saber quién es responsable de qué, quién toma qué decisiones y quién tiene que estar en el loop cuando algo afecta a su área. Son tres preguntas distintas y ninguna de ellas la responde un organigrama.

El problema no es que los organigramas sean malos. Es que están diseñados para organizaciones donde la estructura ya existe y solo hay que representarla. En un equipo pequeño y en crecimiento, la estructura todavía se está formando. Lo que necesitas no es un dibujo de la jerarquía que tienes, sino un sistema claro de quién hace qué.

"Si nadie en tu equipo sabe quién es responsable de una tarea concreta, no tienes un problema de personas. Tienes un problema de procesos."

Lo vemos constantemente al entrar en startups early-stage: el founder tiene en la cabeza quién lidera cada área, pero ese conocimiento no está escrito en ningún sitio. Cuando hay cinco personas, puede funcionar un tiempo. Cuando llegáis a ocho o diez, empieza a romperse. Y entonces hay que reconstruirlo con más deuda operativa acumulada.

Mejor hacerlo ahora.

El mapa de responsabilidades: quién decide, quién ejecuta, quién revisa

La alternativa al organigrama no es más complejidad. Es una tabla sencilla con tres columnas.

Cada área de la startup tiene tres tipos de personas involucradas:

Quien decide (D): tiene la última palabra. No necesita consultar a nadie para tomar la decisión. Si hay un bloqueo, esta persona lo desbloquea.

Quien ejecuta (E): hace el trabajo. Puede ser la misma persona que decide, pero no siempre. En equipos pequeños, lo habitual es que la misma persona decida y ejecute en su área, pero conviene separarlo conceptualmente.

Quien revisa o valida (R): necesita estar informado antes de que algo salga o se implemente. No tiene poder de veto si el que decide ya ha decidido, pero su input importa. Si no está en el loop, pueden aparecer problemas.

Esta estructura es una versión simplificada del modelo RACI (Responsible, Accountable, Consulted, Informed), adaptada a la realidad de un equipo de 5 personas donde no tiene sentido llenar una matriz de 40 filas. En startups con las que trabajamos, solemos reducirlo a estas tres columnas porque son las que generan fricción real cuando no están definidas.

El output es un documento de una página. Algo así:

Esto es un ejemplo genérico. El tuyo va a tener otras áreas y otras personas. Lo importante es el principio: cada área tiene una persona que decide, siempre. No un comité. No "entre todos".

Un equipo donde las decisiones las toma un comité de cinco es un equipo que no toma decisiones.

Cómo manejáis los solapamientos: todos hacemos de todo, pero alguien lidera cada cosa

En una startup de cinco personas, todos acabáis tocando cosas que técnicamente no son vuestra área. El que lleva producto a veces cierra una demo. El CTO opina sobre el roadmap comercial. El founder ejecuta soporte cuando hace falta.

Eso no es un problema. Es la realidad de operar con recursos limitados.

El problema es cuando esa fluidez informal se convierte en ambigüedad estructural: nadie sabe quién tiene la última palabra, cualquiera puede redirigir o bloquear una decisión, y el trabajo se duplica o se cae entre las grietas.

La distinción que funciona es esta: todos podéis contribuir a cualquier área, pero cada área tiene un líder que es quien decide y quien rinde cuentas.

Contribuir es diferente de decidir. El CTO puede y debe tener opinión sobre la estrategia de ventas. Pero si la persona que lidera ventas ya ha decidido cómo enfocar una negociación, el CTO no lo bloquea. Puede señalar riesgos, puede pedir que se le mantenga informado si hay implicaciones técnicas, pero no tiene poder de veto sobre una decisión que no es suya.

Esto requiere una conversación explícita en el equipo. No basta con escribirlo en un documento que nadie lee. Hay que decirlo en voz alta, con nombres y áreas concretas: "Tú lideras esto. Yo lidero aquello. Cuando trabajamos juntos, yo decido en mi área y tú en la tuya."

Esa conversación es incómoda la primera vez. Después, todo es más rápido.

Si quieres entender cómo diagnosticar exactamente dónde están los solapamientos de tu equipo antes de definir nada, el test del "quién hace qué" en tu startup es el primer paso que hacemos con cualquier equipo con el que trabajamos. Te da el mapa real de cómo está funcionando ahora, antes de diseñar cómo debería funcionar.

Cómo montarlo en Notion (sin complicarlo)

No necesitas una herramienta de RRHH. No necesitas un software de gestión de organigramas. Una página en Notion con tres secciones hace el trabajo.

Sección 1: Áreas de responsabilidad

Una tabla como la del ejemplo anterior. Cada fila es un área. Las columnas son D, E, R. Nombres de personas reales, no cargos. En una startup de cinco personas, los cargos son intercambiables; las personas, no.

Sección 2: Reglas de decisión

Tres o cuatro principios escritos en texto plano. Ejemplos reales de lo que funciona:

• "Las decisiones que afectan a más de una área requieren que los dos líderes de área estén de acuerdo. Si no hay acuerdo en 48 horas, decide el founder."

• "Las decisiones dentro de un área las toma el líder del área sin necesidad de consultar. Si tiene dudas, consulta, pero no necesita permiso."

• "Cualquier decisión que comprometa más de X€ o que cambie la dirección del producto necesita que el founder esté en el loop antes de ejecutar."

Escribe los principios que reflejan cómo queréis funcionar vosotros, no los que lees en un post americano sobre empresas de 500 personas.

Sección 3: Log de cambios

Una tabla simple con fecha, qué cambió y por qué. Cuando redefinís roles, dejáis constancia. Esto tiene más valor del que parece: dentro de seis meses, cuando alguien pregunte "¿por qué funciona así?", hay una respuesta.

El documento completo no debería superar dos páginas en Notion. Si supera las dos páginas, estáis documentando demasiado para una startup de cinco personas.

"El stack perfecto no existe. Existe el stack que tu equipo usa de verdad."

Lo mismo aplica a los documentos de roles: el mejor no es el más detallado, es el que el equipo abre, entiende y actualiza.

Cuándo redefinir roles

Los roles en una startup de cinco personas no son permanentes. Son una foto del momento actual.

Hay dos momentos en los que conviene revisar y redefinir:

Cada tres meses, por defecto. No porque algo haya fallado, sino porque en tres meses en una startup early-stage el contexto ha cambiado lo suficiente como para que lo que definiste en enero ya no refleje la realidad de abril. Hacedlo breve: una reunión de una hora donde cada persona confirma o actualiza su mapa de responsabilidades.

Cuando contratas a alguien nuevo. Este es el momento más crítico y el que más startups gestionan mal. Cuando llega una persona nueva, las responsabilidades no solo se añaden: se redistribuyen. El problema es que esa redistribución pocas veces se hace explícita. La persona nueva asume cosas que nadie le ha confirmado, y la persona que estaba haciendo esa tarea antes no sabe si debe seguir haciéndola o si puede soltarla.

El resultado es duplicación, confusión o ambos.

La regla es simple: antes de que una persona nueva empiece a trabajar, actualizáis el mapa de responsabilidades. No después de las primeras semanas cuando "ya se haya asentado". Antes. Con el nuevo en la sala.

Hay otras señales que indican que toca redefinir sin esperar a la revisión trimestral:

• Una tarea importante falló y nadie se sintió responsable de haberla gestionado

• Dos personas tomaron la misma decisión de forma independiente y llegaron a conclusiones distintas

• Alguien del equipo tiene la sensación de que está haciendo trabajo que no le corresponde o, al contrario, de que hay trabajo que debería estar haciendo pero no llega

• El founder está tomando decisiones que podría (y debería) estar tomando otra persona del equipo

Si reconoces alguna de estas señales, no esperes al trimestre. Una revisión puntual de dos horas ahora te ahorra semanas de fricción después.

Montar el mapa de responsabilidades es una pieza del sistema operativo de una startup, no el sistema completo. Si quieres entender cómo encaja con el resto de procesos, herramientas y métricas que necesita un equipo de 2 a 50 personas para operar con control, la guía de operaciones para startups te da el marco completo.

Los errores que más vemos al definir roles

Definirlos por cargo, no por área real. "El CTO es responsable de tecnología" no dice nada útil. ¿Qué decisiones concretas toma el CTO? ¿Qué necesita del founder para ejecutar? ¿Qué áreas de negocio le afectan y en cuáles puede opinar pero no decidir? El cargo es el título. El área de responsabilidad es lo que hace el trabajo.

No escribirlos. Muchos equipos tienen los roles claros en la cabeza del founder. Eso funciona hasta que el founder tiene demasiadas cosas en la cabeza, o hasta que alguien nuevo llega y no tiene acceso a esa cabeza. Lo que no está escrito no existe como sistema.

Escribirlos y no revisarlos nunca. Un documento de roles que tiene seis meses de antigüedad en una startup que ha contratado tres personas nuevas y ha pivotado el modelo de negocio es peor que no tener nada. Genera falsa seguridad.

Confundir "todos decidimos" con "equipo horizontal". Un equipo donde todos deciden es un equipo donde nadie decide. La horizontalidad no es ausencia de responsabilidad individual: es ausencia de jerarquía innecesaria. Puedes tener un equipo completamente horizontal en tono y cultura, y aun así tener claridad total sobre quién decide qué.

Evitar la conversación porque es incómoda. Decirle a alguien "tú decides esto y yo no me meto" puede sentirse como delegar demasiado. Decirle "en tu área, yo solo reviso, no decido" puede sentirse como perder control. Las dos incomodidades son normales. Y las dos desaparecen rápido cuando el equipo comprueba que trabajar con claridad es mucho más eficiente que trabajar con ambigüedad.

"Una startup no muere por falta de ideas. Muere por falta de operaciones."

Los roles no definidos son deuda operativa. Se acumula silenciosamente y explota cuando llegas a diez personas y ya no puedes gestionar la ambigüedad a base de buena voluntad y reuniones improvisadas.

La pregunta no es si tu startup de cinco personas necesita claridad de roles. Es cuánto tiempo más puedes permitirte operar sin ella.

Si al leer esto reconoces el patrón y quieres que lo revisemos contigo, empezamos con un diagnóstico de 1-2 semanas donde mapeamos exactamente qué funciona, qué falla y qué hay que montar. Sin organigramas ridículos.

Agendar una llamada →