Contratas a un ingeniero senior. El recruiter ya ha hecho sourcing, el tech lead ha validado parte del stack, el CTO quiere revisar el nivel arquitectónico y el founder pregunta cuándo sale la oferta. Todo parece avanzar hasta que llega el punto crítico: nadie sabe quién decide si la prueba técnica pasa, quién puede vetar al candidato y quién debe mover la oferta.
Ese atasco no suele venir por falta de talento en el equipo. Viene por falta de claridad operativa. En hiring técnico, eso se traduce en entrevistas duplicadas, feedback tardío, candidatos que se enfrían y decisiones que se alargan más de lo razonable.
Ahí es donde entra entender bien que es raci. No como teoría de project management, sino como una forma muy práctica de evitar que un proceso importante dependa de intuiciones, favores o mensajes sueltos en Slack.
El Coste de la Ambigüedad en tu Equipo
He visto este patrón muchas veces en startups en crecimiento. Se abre una vacante urgente para backend, todo el mundo está alineado en que hay que contratar rápido, pero cada fase depende de conversaciones ad hoc. El recruiter pregunta quién valida la JD. El tech lead cree que la última palabra la tiene el CTO. El CTO espera una recomendación cerrada del equipo. Nadie bloquea el proceso de forma explícita, pero el proceso se bloquea igual.
Cuando eso pasa, el problema no es solo de coordinación. También afecta a la experiencia del candidato y a la credibilidad interna del equipo. Si un proceso de selección parece improvisado, el candidato lo nota. Y si dentro del equipo nadie sabe quién responde por cada etapa, la contratación se convierte en una fuente constante de fricción.
Según la guía de Asana sobre la matriz RACI, esta matriz se consolidó en España para clarificar responsabilidades de forma visual, y su uso en startups y scaleups ayuda a ordenar procesos de selección o desarrollo de producto sin crear burocracia adicional. En ese mismo contexto, se destaca que resulta especialmente útil en equipos de hasta 10 personas, donde asignar con precisión quién responde por cada etapa evita confusiones.
Cómo se ve el caos en hiring
- La prueba técnica queda en el aire porque varios entrevistadores opinan, pero nadie cierra.
- La oferta se retrasa porque RR. HH., CTO y founder participan, pero ninguno tiene el ownership final.
- El recruiter persigue feedback en lugar de operar un proceso claro.
- El candidato recibe señales contradictorias sobre prioridades, tiempos y criterio de evaluación.
Cuando un proceso depende de que “alguien conteste”, ya no tienes proceso. Tienes improvisación.
Este problema no se arregla con más reuniones. Se arregla definiendo quién ejecuta, quién aprueba, a quién conviene consultar y quién solo necesita estar al tanto. Eso conecta directamente con la forma en que también se construye una cultura empresarial clara y funcional, donde las responsabilidades no dependen del contexto del día.
Los Cuatro Roles de la Matriz RACI Desglosados
Si buscas una definición simple de que es raci , quédate con esto: es una matriz para asignar responsabilidades por tarea y evitar ambigüedad. Funciona porque separa cuatro niveles de implicación que en muchos equipos se mezclan sin querer.
Piensa en una cocina de restaurante. Hay alguien que cocina el plato, alguien que responde por lo que sale al cliente, alguien a quien se consulta si hay una alergia o cambio especial, y alguien que solo necesita saber que una mesa va con retraso. Si mezclas esos papeles, el servicio se rompe. En hiring técnico pasa exactamente lo mismo.
Responsable
El Responsable es quien hace el trabajo. No opina desde fuera ni supervisa a distancia. Ejecuta.
En un proceso de contratación, puede ser el recruiter que hace sourcing, el entrevistador técnico que conduce la entrevista o la persona de People que emite la carta de oferta. Si la tarea no tiene Responsable, nadie la mueve.
Aprobador
El Aprobador responde por el resultado final. Aquí está la regla que mucha gente incumple: por cada tarea o entregable debe haber una sola persona con responsabilidad última.
Según la explicación de Wrike sobre la matriz RACI, separar Responsable, Aprobador, Consultado e Informado reduce la ambigüedad operativa, y forzar una única capa de accountability por entregable ayuda a disminuir cuellos de botella y mejorar la coordinación entre roles técnicos y stakeholders.
Si en la entrevista técnica hay dos personas con la última palabra, en realidad no hay ninguna. Solo hay política interna disfrazada de consenso.
Consultado
El Consultado aporta criterio antes de decidir. Este rol es valioso cuando hay conocimiento especializado o impacto transversal.
En hiring técnico, suele encajar aquí un senior engineer que valida profundidad técnica, un engineering manager que conoce el contexto del equipo, o People si hay dudas de encaje salarial o contractual. El error habitual es convertir a demasiada gente en Consultada. Ahí es donde un proceso deja de ganar calidad y empieza a perder velocidad.
Regla práctica: consulta a quien mejora la decisión. No a quien solo quiere opinar.
Informado
El Informado no decide ni ejecuta. Solo necesita visibilidad.
Un founder puede necesitar saber que la vacante entra en fase de oferta. Un finance manager puede necesitar enterarse de que una contratación ya está aprobada. Informar bien evita sorpresas, pero informar de más también añade ruido.
La diferencia que más importa
En muchos equipos, el problema real no está entre R y C. Está entre R y A. El responsable hace. El aprobador responde.
Si un recruiter coordina el proceso y el CTO tiene la decisión final, ambos están involucrados, pero no hacen lo mismo. Entender eso evita bloqueos y también mejora la relación entre recruiting y liderazgo técnico. Si quieres afinar esa capa de coordinación, ayuda revisar también las funciones de un jefe de proyectos, porque muchas tensiones de hiring se parecen bastante a las de cualquier iniciativa cross-functional.
Cuándo Usar RACI y Cuándo es Burocracia Innecesaria
No toda startup necesita una matriz RACI para todo. De hecho, usarla en exceso es una forma rápida de matar la agilidad que intentabas proteger.
La pregunta útil no es si RACI es buena o mala. La pregunta útil es esta: ¿hay varias personas implicadas y riesgo real de confusión sobre quién decide? Si la respuesta es sí, RACI suele compensar. Si la respuesta es no, probablemente sobra.
Cuándo sí merece la pena
RACI funciona bien cuando el proceso tiene handoffs claros, varios stakeholders y coste alto de coordinación. Ahí encajan bastante bien estos escenarios:
- Hiring técnico con varias entrevistas. Recruiter, tech lead, CTO y founder participan, pero no deberían pesar igual en cada fase.
- Lanzamientos internos de producto. Ingeniería, producto, operaciones y negocio tienen dependencias cruzadas.
- Onboarding de perfiles críticos. Si nadie responde por cada hito, el nuevo fichaje empieza con fricción.
- Equipos remotos o asíncronos. La claridad documental sustituye muchas conversaciones que antes pasaban en persona.
Cuándo no aporta suficiente valor
Hay equipos muy maduros que ya operan con ownership claro y pocos intermediarios. En esos casos, meter una RACI en cada microdecisión empeora el sistema.
No la usaría para tareas diarias de bajo impacto, para acciones obvias entre dos personas o para procesos que cambian cada semana sin una mínima estabilidad. Tampoco la usaría si el equipo no está dispuesto a mantenerla. Una matriz vieja es peor que no tener matriz, porque transmite una claridad falsa.
Si necesitas un documento para decidir quién responde por cada stand-up, el problema no es de RACI. Es de diseño organizativo.
El criterio que uso en equipos tech
Las guías más habituales en español no resuelven bien si RACI sigue siendo útil en entornos ágiles, remotos o con flujos modernos de trabajo. Interfacing lo plantea como el dilema entre “RACI vs. realidad operativa”, y esa formulación me parece acertada: a veces acelera decisiones y a veces genera burocracia.
Mi criterio es bastante simple:
- Úsala en decisiones repetibles y con fricción recurrente.
- Evítala en trabajo cotidiano que ya tiene dueño claro.
- Hazla ligera. Si nadie puede leerla en pocos minutos, está mal diseñada.
- Revísala cuando cambie el equipo o el proceso.
Un CTO no necesita más artefactos. Necesita menos dudas. Si RACI reduce dudas, sirve. Si añade una capa documental que nadie consulta, estorba.
Aplicando RACI al Proceso de Hiring Técnico
En recruiting técnico, la mejor forma de entender que es raci no es con definiciones. Es viendo cómo evita un proceso caótico.
Tomemos una vacante de Senior Backend Engineer en una startup con recruiter, tech lead, CTO y founder. La secuencia útil, según la explicación de Lemon Learning, consiste en listar tareas o hitos, asignar roles por ítem y validar con los implicados. Ese esquema encaja muy bien en un funnel de selección técnico.
Fase uno de definición y atracción
Definición de la Job Description
Aquí el error típico es dejar que la JD salga de un documento viejo o de una conversación informal. La JD debe tener un dueño claro.
- R : Recruiter redacta y estructura la oferta
- A : CTO o Hiring Manager valida que el perfil responde a una necesidad real
- C : Tech Lead aporta detalle sobre stack, retos y nivel esperado
- I : Founder queda al tanto si el rol afecta a presupuesto o prioridad de negocio
Sourcing y primer contacto
Si nadie decide el enfoque de búsqueda, el recruiter abre mucho volumen pero poco ajuste.
- R : Recruiter hace sourcing, outreach y primer filtro
- A : Recruiter o Hiring Manager, según cómo esté organizado el equipo
- C : Tech Lead si hace falta afinar señales técnicas
- I : CTO recibe visibilidad sobre pipeline y calidad de candidaturas
Para profundizar en cómo diseñar esta parte con menos fricción, ayuda revisar procesos de selección para perfiles tech.
Un recurso visual rápido puede servirte para aterrizar el flujo antes de documentarlo mejor:
Fase dos de evaluación
Entrevista técnica
Aquí es donde más procesos se rompen. Varias personas entrevistan, todos opinan, pero nadie sabe quién convierte el feedback en decisión.
- R : Interviewers técnicos ejecutan la entrevista y documentan feedback
- A : Tech Lead o CTO, pero solo uno
- C : Recruiter puede consultar sobre consistencia del proceso y candidate experience
- I : Founder queda informado solo si participa en decisiones finales
Entrevista con manager o cultural
No es una entrevista “soft”. Sirve para validar forma de trabajar, autonomía, comunicación y encaje con el contexto real del equipo.
- R : Hiring Manager conduce la conversación
- A : Hiring Manager o CTO
- C : People o recruiter si hay señales de riesgo relacional
- I : Resto del equipo solo si necesita preparar siguientes pasos
Si la entrevista cultural la hacen varias personas sin criterios comunes, no estás evaluando encaje. Estás acumulando impresiones.
Fase tres de decisión y oferta
Decisión final
Este paso no debería cerrarse en un hilo interminable de Slack. Necesita una recomendación estructurada y una autoridad clara.
- R : Recruiter consolida feedback y coordina cierre
- A : CTO o Hiring Manager
- C : Tech Lead y, si aplica, founder
- I : People y finance si deben preparar condiciones
Oferta
Aquí se pierde tiempo cuando todos validan a la vez o nadie sabe quién puede decir “sí”.
- R : Recruiter y People preparan la oferta
- A : CTO, founder o quien tenga la última palabra presupuestaria
- C : Hiring Manager
- I : Equipo que espera la incorporación
La ventaja de este enfoque no es estética. Es operativa. Cada fase responde a tres preguntas muy concretas: quién mueve la tarea, quién responde por el resultado y quién entra solo cuando aporta algo.
Plantilla Sencilla para Crear tu Matriz RACI
La mayoría de equipos complican RACI antes de empezar. No hace falta un software específico ni un framework pesado. Con un documento en Notion, Confluence, Google Docs o una hoja simple basta.
El proceso mínimo que sí funciona
IEBS resume una secuencia útil que encaja bien en entornos tech: analizar el proyecto, identificar tareas, designar responsables, detallar entregas y compartir la matriz con todos los involucrados. Además, subraya un punto clave: para cada tarea debe existir exactamente una persona con la responsabilidad última.
Traducido a hiring técnico, yo lo dejaría así:
Lista las decisiones o hitos reales
No pongas tareas irrelevantes. Pon solo lo que puede bloquear el proceso: aprobar JD, filtrar CVs, hacer entrevista técnica, consolidar feedback, aprobar oferta.Escribe roles, no nombres, si el equipo rota mucho
Mejor “CTO”, “Recruiter”, “Tech Lead”, “Founder” que nombres propios si cambian entrevistadores con frecuencia.Asigna letras con disciplina
Cada fila necesita al menos un Responsable y un único Aprobador. Los Consultados deben ser pocos. Los Informados, solo los necesarios.Compártela y revísala con el equipo
Si la gente no la ha validado, no la va a seguir. Y si nadie la entiende de un vistazo, está sobrecargada.
Plantilla para copiar y pegar
Puedes empezar con este formato en texto plano:
Proceso: Hiring Senior Backend Engineer
| Tarea o decisión | Recruiter | Tech Lead | CTO | Founder | People |
|---|---|---|---|---|---|
| Definir perfil y stack | C | C | A | I | I |
| Redactar JD | R | C | A | I | I |
| Publicar oferta y sourcing | A/R | I | I | I | I |
| Filtrado inicial | R | C | A | I | I |
| Entrevista técnica | I | R | A | I | I |
| Entrevista manager | C | C | A/R | I | I |
| Decisión final | R | C | A | C | I |
| Oferta | R | I | A | C | R |
Revisión rápida antes de publicarla
- Busca varias A en la misma fila. Si existen, todavía no has decidido quién manda.
- Detecta filas sin R. Eso revela tareas que todos esperan que haga otro.
- Recorta C e I si aparecen por inercia.
- Añade el entregable esperado cuando una tarea sea ambigua, por ejemplo “feedback consolidado” en vez de “revisión”.
Una buena RACI no intenta capturar todo el proceso. Solo aclara los puntos donde suele romperse.
Errores Comunes que Anulan la Utilidad de RACI
RACI falla menos por el modelo que por cómo se aplica. Estos son los errores que más veo en procesos de hiring y coordinación técnica.
- Varios Aprobadores en una misma tarea. Si dos personas tienen la última palabra, nadie la tiene. Deja un solo A y el resto que pase a C o I.
- Demasiados Consultados. Querer consenso total ralentiza decisiones simples. Consulta solo a quien mejora de verdad el criterio.
- Tareas definidas con exceso de detalle. Si conviertes la matriz en un mapa de microacciones, nadie la mantendrá. Trabaja a nivel de hitos y decisiones.
- Documento creado y olvidado. Una RACI sin revisión se vuelve irrelevante rápido. Actualízala cuando cambie el proceso o los roles.
- No comunicarla al equipo. Guardarla en Notion no basta. Hay que explicarla y usarla como referencia operativa.
- Aplicarla a todo. No hace falta RACI para cada reunión, mensaje o tarea menor. Resérvala para procesos con dependencia real entre personas.
Si al leer tu matriz sigues necesitando preguntar “vale, pero al final quién decide”, entonces la matriz no está resuelta.
Si estás contratando perfiles de software, data, IA, cloud o ciberseguridad y tu proceso se bloquea por falta de ownership claro, en Kulturo ayudamos a equipos tech en España a estructurar procesos de selección que avanzan con criterio y sin caos.