Imagen ilustrativa sobre roles y responsabilidades startup

Cómo hacer el test del 'quién hace qué' en tu startup (y qué hacer con los resultados)

El test del 'quién hace qué': pregunta a 3 personas quién es responsable de una tarea. Si dan 3 respuestas, tienes un problema de procesos.

·roles y responsabilidades startup·por Ebägurin

Analizar con IA — elige tu favorita

Obtén un resumen del artículo al instante

Pregúntale a tres personas de tu equipo quién es responsable de las renovaciones de clientes.

Si te dan tres respuestas distintas, tienes un problema de procesos. Si se miran entre ellos antes de contestar, tienes un problema urgente de procesos. Y si ninguno sabe de qué le estás hablando, el problema lleva meses acumulándose.

Este es el test del "quién hace qué". Y en el 80% de las startups con las que trabajamos, suspende al menos una área crítica del negocio.

Lo que vas a aprender en este artículo:

  • Cómo ejecutar el test del "quién hace qué" con tu equipo en menos de 30 minutos

  • Cómo interpretar los resultados según tres escenarios distintos

  • Qué plan de acción aplicar según lo que descubras

  • Cómo adaptar una versión simplificada del RACI a equipos de menos de 15 personas sin que se convierta en burocracia


Por qué este problema existe (y por qué nadie lo ve hasta que explota)

En una startup de 5 personas, los roles son implícitos. Todo el mundo sabe que Ana lleva el producto, que Javi cierra ventas y que la infraestructura la toca Carlos. No hace falta documentarlo porque la información cabe en la cabeza de todos.

Cuando el equipo llega a 10, 12, 15 personas, esa lógica se rompe. Los nuevos incorporan no tienen el contexto de los fundadores. Las responsabilidades que "alguien" llevaba informalmente quedan en tierra de nadie. Y las decisiones que antes se tomaban en una conversación de pasillo ahora se quedan sin tomar porque nadie sabe si es su turno.

Según los datos de State of Startups 2023 de First Round Capital, la falta de claridad en roles y responsabilidades es uno de los cinco factores que más impactan en la productividad de equipos early-stage. No es el único factor, pero es uno de los más ignorados porque no duele hasta que hay un error gordo o una persona buena que se va.

"Si nadie en tu equipo sabe quién hace qué, no tienes un problema de personas. Tienes un problema de procesos."

El test que describiremos aquí es la primera herramienta que usa Ebägurin al entrar en una startup. No porque sea complicado, sino porque en 30 minutos te da más información sobre el estado operativo de tu empresa que semanas de observación.


El test del "quién hace qué": qué es y cómo funciona

El test es un ejercicio de auditoría de responsabilidades. La idea es simple: identifica las tareas y decisiones críticas de tu startup, pregunta a varios miembros del equipo quién es el responsable de cada una, y compara las respuestas.

Donde haya discrepancia, hay deuda operativa. Donde nadie sepa la respuesta, hay un hueco que en algún momento va a costar dinero o una relación.

No necesitas herramientas especiales. Necesitas 30 minutos, un documento compartido y honestidad.

Paso 1: Haz una lista de las 15-20 tareas y decisiones críticas de tu startup

No intentes cubrir todo. Coge las áreas que más importan en tu fase actual: ventas, atención al cliente, producto, finanzas, operaciones internas, contratación. Dentro de cada área, identifica 2-4 tareas concretas que se ejecutan de forma recurrente o que implican una decisión relevante.

Ejemplos concretos:

  • ¿Quién decide aprobar un descuento por encima del 20%?

  • ¿Quién hace el seguimiento de los leads que no cerraron?

  • ¿Quién revisa que las facturas se emiten correctamente cada mes?

  • ¿Quién decide cuándo una funcionalidad está lista para salir a producción?

  • ¿Quién gestiona las renovaciones de contratos anuales?

  • ¿Quién incorpora a un nuevo empleado el primer día?

El nivel de concreción importa. "Gestión de clientes" es demasiado vago. "Responder incidencias de clientes en menos de 4 horas" ya se puede asignar a una persona.

Paso 2: Pide respuestas individuales, sin consenso previo

Aquí está la clave del test: las respuestas deben ser independientes. No hagas esto en una reunión donde todo el mundo se mira y llega a un acuerdo en tiempo real. Eso no mide el estado actual; mide la capacidad del equipo para improvisar una respuesta coherente.

Comparte el documento a cada persona del equipo de forma individual y pídeles que rellenen, sin consultar con nadie: nombre de la persona responsable de cada tarea. Si no saben, que escriban "no sé" o dejen el campo en blanco. Eso también es información.

Tiempo estimado por persona: 10-15 minutos. Tiempo total de análisis: 30 minutos.

Paso 3: Cruza las respuestas y mapea las discrepancias

Con las respuestas individuales en mano, crea una tabla de cruces. Para cada tarea, anota cuántas personas dieron la misma respuesta. El resultado se agrupa en tres tipos:

  • Consenso claro: 80% o más del equipo nombra a la misma persona. Esta responsabilidad está razonablemente clara.

  • Dispersión parcial: las respuestas se dividen entre dos o tres personas, o hay varias respuestas con "no sé". Esta área necesita clarificación.

  • Hueco completo: la mayoría no sabe o nadie nombra a nadie. Esto es una responsabilidad huérfana. En algún momento alguien la está haciendo, pero de forma reactiva y sin accountability.


Cómo interpretar los resultados: tres escenarios

Los resultados del test casi siempre encajan en uno de estos tres escenarios. Cada uno tiene un diagnóstico distinto y un plan de acción diferente.

Escenario 1: El fundador aparece en casi todas las respuestas

Esto pasa en startups de menos de 10 personas donde el founder sigue siendo el cuello de botella operativo. El equipo sabe que "cualquier cosa importante la decide" él o ella, así que en la duda, apuntan ahí.

El problema no es que el founder esté implicado en muchas cosas. El problema es que el equipo ha aprendido a no tomar decisiones sin su validación, lo que crea una dependencia estructural que frena la velocidad de todo.

Lo que hay que montar aquí no es un organigrama. Es un sistema de delegación con criterios claros: qué puede decidir cada persona sin escalar, hasta qué límite económico, y en qué situaciones sí necesita aprobación. Las operaciones para startups bien montadas incluyen este mapa de delegación como uno de los primeros entregables porque sin él, el equipo crece pero la autonomía no.

Escenario 2: Las responsabilidades están repartidas, pero sin propietario claro

Aquí las respuestas del test son fragmentadas. Tres personas creen que la tarea es parcialmente suya. Nadie cree que sea completamente suya. El resultado práctico es que o la hacen tres personas duplicando esfuerzo, o no la hace nadie porque cada uno asume que otro la cubrirá.

Este escenario es el más común en startups que han crecido rápido sin pausar a estructurar. Contratan bien, tienen gente capaz, pero los roles se han ido definiendo por inercia y conversaciones informales, no por criterio.

Lo que necesitas aquí es asignar un "owner" único por tarea, aunque eso signifique tener conversaciones incómodas sobre quién lleva qué.

Escenario 3: Hay áreas enteras que nadie cubre

Esto aparece habitualmente en funciones que "nadie quiere" pero que son críticas: gestión de impagados, seguimiento post-venta, documentación interna, cumplimiento RGPD. Tareas que no son glamurosas pero que si nadie las hace, en algún momento hacen ruido.

El diagnóstico aquí es deuda operativa pura. Cada semana que esa área no tiene propietario, el coste de ponerla en orden crece. No siempre hay que crear un rol nuevo: a veces es redistribuir responsabilidades existentes o automatizar parte del proceso.


Plan de acción: qué montar según lo que hayas encontrado

El test no sirve de nada si no hay un siguiente paso concreto. Aquí está el plan básico según los resultados.

Si el problema es concentración en el founder

Haz una lista de las 10 decisiones más frecuentes que escalan hasta ti. Para cada una, pregúntate: ¿qué información necesitaría tener otra persona para tomar esta decisión sin mí? Eso es exactamente lo que tienes que documentar y traspasar.

No delegues de golpe. Delega con contexto: "A partir de ahora, X aprueba descuentos hasta el 15% sin consultarme. Por encima de eso, me escala con esta información mínima." Pon una fecha de revisión a 30 días.

Si el problema es responsabilidades compartidas sin propietario

Aplica la regla de la silla: para cada tarea crítica, debe haber exactamente una persona sentada en esa silla. Puede tener colaboradores, puede tener apoyo, pero solo una persona es accountable si algo falla.

Haz una reunión breve (no más de 60 minutos) con el equipo afectado y asigna propietarios. Escribe los acuerdos. No en un documento de 20 páginas: en una tabla simple de Notion con tarea, propietario, frecuencia y criterio de éxito.

Si el problema son huecos completos

Prioriza por impacto en cliente o en negocio. No todos los huecos son igual de urgentes. Un hueco en el proceso de renovaciones de contratos duele más que un hueco en la documentación interna de sprints.

Para los huecos de alto impacto, asigna un propietario provisional en las próximas 48 horas aunque no sea la solución definitiva. El objetivo es que deje de ser tierra de nadie mientras diseñas la solución correcta.


El RACI simplificado para equipos de menos de 15 personas

El RACI es un framework clásico de gestión de responsabilidades. En su versión corporativa, tiene cuatro roles por tarea: Responsible (quien ejecuta), Accountable (quien responde), Consulted (quien da input) e Informed (quien se entera del resultado).

En una startup de 12 personas, eso es demasiado. Cuatro roles por tarea en un equipo pequeño genera más overhead de coordinación del que elimina.

"Automatizar el caos solo te da caos más rápido. Documentar burocracia solo te da burocracia más rápida."

La versión que funciona en equipos early-stage tiene dos roles, no cuatro:

  • Owner: la persona que es accountable del resultado. Si sale mal, es su problema. Si hay que decidir algo, decide ella.

  • Ejecutor: la persona o personas que hacen el trabajo. Puede ser la misma que el owner o no.

Y una regla adicional: si hay más de dos personas en la columna de "ejecutor", vuelve a partir la tarea en subtareas hasta que cada una tenga un ejecutor claro.

El formato mínimo viable para esto en Notion es una tabla con cinco columnas: tarea, área, owner, ejecutor(es), frecuencia. Eso es todo. Una página, no un sistema.

Lo que diferencia este RACI simplificado de la versión corporativa no es solo el número de roles. Es que está pensado para ser leído y actualizado por el propio equipo en su día a día, no para ser auditado por un consultor cada año.

Un proceso bien diseñado en una startup de 10 personas cabe en una página de Notion y se ejecuta en menos de 5 minutos. Si tarda más, no es un proceso: es un obstáculo.

Cómo mantenerlo vivo (sin que se convierta en un documento abandonado)

El error más común no es no hacer este ejercicio. Es hacerlo, documentarlo y no volver a tocarlo hasta que hay un problema serio.

Dos hábitos concretos para que el mapa de responsabilidades no envejezca mal:

Primero, revísalo cada vez que incorpores a alguien nuevo al equipo. El onboarding es el mejor momento para validar que lo documentado refleja la realidad, y para que la persona nueva entienda exactamente qué lleva quién.

Segundo, añádelo a tu revisión trimestral de operaciones. No tiene que ser una sesión larga: 20 minutos para revisar si algún owner ha cambiado, si hay tareas nuevas que no están cubiertas y si algún hueco ha aparecido.


Si tu startup tiene entre 5 y 30 personas y este artículo ha descrito algo que reconoces, el problema no va a resolverse solo. Ebägurin entra a diagnosticar exactamente esto: qué funciona, qué falla y qué hay que montar. El Plan Diagnóstico Express dura 1-2 semanas y termina con un mapa claro de qué montar primero. Hablemos sobre tu startup →


Preguntas frecuentes

¿Cuándo es el momento adecuado para hacer el test del "quién hace qué" en una startup?

El mejor momento es antes de que aparezca un error importante por falta de claridad en roles. En la práctica, tiene mucho sentido hacerlo cuando el equipo supera las 8-10 personas, cuando se incorporan los primeros hires que no son los fundadores, o justo después de cerrar una ronda y antes de escalar contratación. Si ya hay problemas visibles de coordinación, hay que hacerlo esta semana.

¿Qué diferencia hay entre el RACI corporativo y el que describe Ebägurin para startups?

El RACI corporativo tiene cuatro roles por tarea (Responsible, Accountable, Consulted, Informed) y está pensado para organizaciones grandes con múltiples niveles de aprobación. En equipos de menos de 15 personas, ese nivel de detalle genera más overhead de gestión del que elimina. La versión de Ebägurin simplifica a dos roles (owner y ejecutor) y cabe en una tabla de Notion de una página que el equipo puede mantener actualizada solo.

¿Puede hacerse este test en una startup de 3 o 4 personas?

Sí, y merece la pena hacerlo aunque parezca prematuro. En equipos muy pequeños, el test suele revelar que el founder lleva responsabilidades que en algún momento necesitará delegar. Documentarlo ahora, aunque sea en versión mínima, hace que el traspaso sea mucho más fácil cuando llegue la primera contratación clave.

¿Qué pasa si el equipo se resiste a clarificar responsabilidades porque "ya se sabe entre todos"?

Esa percepción es la señal más clara de que hace falta el ejercicio. "Ya se sabe" funciona cuando el equipo no cambia y el contexto es estable. En una startup en crecimiento, las dos condiciones cambian constantemente. La resistencia suele disolverse cuando el equipo ve los resultados del test: normalmente hay más discrepancias de las que esperaban.

¿Con qué frecuencia hay que revisar el mapa de responsabilidades?

Mínimo una vez al trimestre y siempre que haya una incorporación nueva al equipo. En fases de crecimiento rápido (por ejemplo, después de una ronda seed con contratación acelerada), puede tener sentido revisarlo mensualmente durante los primeros tres meses hasta que los nuevos roles estén estabilizados.

¿Cómo gestionar el caso en que dos personas creen que son propietarias de la misma responsabilidad?

Es una situación frecuente y hay que resolverla explícitamente, no con un acuerdo tácito. El criterio es simple: ¿quién responde si algo sale mal? Esa es la persona que debe ser owner. Si la respuesta es ambigua, el problema no es de personas: es que la tarea no está bien definida y hay que partir en subtareas con propietario claro para cada una.

¿Es necesario usar Notion para documentar esto, o cualquier herramienta sirve?

Cualquier herramienta sirve mientras el equipo la use de verdad. Notion funciona bien en startups que ya lo tienen como hub de documentación interna. Si tu equipo vive en Google Workspace, una hoja de cálculo compartida cumple la misma función. El formato importa menos que la accesibilidad: el documento tiene que estar donde el equipo lo va a consultar, no donde tiene lógica teórica guardarlo.