Matriz de responsabilidad: guía para equipos de ingeniería

Si tu equipo de ingeniería crece y cada semana aparece el mismo problema, ya sabes de qué hablo. Un despliegue falla y nadie tiene claro quién debía validar. En un proceso de selección, tres personas entrevistan lo mismo y nadie decide. En el onboarding de un nuevo developer, RR. HH. da por hecho que el manager ya preparó accesos, y el manager cree que eso lo llevaba IT o DevOps.

‍

Ese caos no suele venir de falta de talento. Viene de falta de asignación explícita. La gente trabaja, opina, ayuda y decide, pero los límites entre ejecutar, aprobar, consultar e informar están borrosos.

‍

La matriz de responsabilidad sirve para cortar ese ruido. No porque convierta a una startup en una máquina perfecta, sino porque obliga a responder una pregunta incómoda antes de que llegue el problema: quién hace qué, quién decide y quién solo necesita visibilidad.

‍

Qué es una matriz de responsabilidad y el modelo RACI

‍

La forma más útil de entender una matriz de responsabilidad no es como un documento de project management. Es como un mecanismo para evitar el clásico “pensaba que eso lo llevabas tú”.

‍

En español, la literatura académica y divulgativa describe la matriz RACI como una tabla de doble entrada en la que cruzas tareas con roles del equipo. Su utilidad está en separar cuatro funciones operativas: Responsible, Accountable, Consulted e Informed. Y la regla importante es esta: cada actividad debe tener un solo Accountable, aunque pueda haber varios Responsible, tal como recoge la documentación de la Universitat Politècnica de València sobre la matriz RACI.

Qué significa cada letra en un equipo de software

‍

R de Responsible. Es quien ejecuta el trabajo. Si hay que desplegar una feature, escribir la migración o preparar el entorno de onboarding, aquí están las personas que lo hacen de verdad.

‍

A de Accountable. Es quien responde por el resultado final. No tiene por qué tocar el teclado. Sí tiene que tener autoridad para aceptar, frenar o reconducir la tarea.

‍

C de Consulted. Aporta criterio o contexto antes de decidir o ejecutar. Un Security Engineer puede ser consultado en un cambio de arquitectura. Un recruiter puede ser consultado sobre la experiencia de candidato.

‍

I de Informed. Necesita enterarse, pero no bloquear ni participar activamente. Producto puede ir informado de un despliegue. Finanzas puede ir informada de una contratación cerrada.

‍

Regla práctica: si no sabes distinguir entre R y A, tu matriz todavía no sirve.

‍

La analogía que lo deja claro

‍

Piensa en un equipo de Fórmula 1. El piloto ejecuta en pista. El director de carrera decide la estrategia final. Los ingenieros aportan información. El resto del equipo necesita saber qué pasa.

‍

En una startup pasa lo mismo:

• El developer ejecuta una migración crítica.
• El tech lead aprueba que ese cambio está listo para producción.
• QA o seguridad consultan si hay riesgo funcional o técnico.
• Producto queda informado para coordinar comunicación o soporte.

‍

El fallo más común es mezclar ejecución con autoridad final. Cuando eso pasa, aparecen decisiones por consenso, validaciones en Slack a medias y reuniones donde todos opinan pero nadie cierra.

‍

Para qué sirve de verdad

‍

La matriz no está para decorar Notion. Está para bajar ambigüedad en procesos que se repiten. Si tu organización ya tiene alguien haciendo coordinación formal, conviene entender también qué funciones suele asumir un jefe de proyectos, porque muchas fricciones aparecen justo en esa frontera entre coordinación, ejecución y decisión.

‍

En la práctica, la matriz suele construirse siguiendo 4 pasos: identificar tareas, definir roles, asignar R/A/C/I y revisar incoherencias, según la referencia académica ya citada de la UPV. Algunas guías en español la amplían a 5 pasos añadiendo calendario y comunicación al equipo, pero el núcleo no cambia: si no nombras un dueño final por actividad, el trabajo se dispersa.

‍

Beneficios reales para equipos técnicos y de hiring

‍

En startups, la matriz de responsabilidad no aporta valor por “orden”. Aporta valor porque reduce fricción operativa en situaciones donde la velocidad importa.

‍

El primer beneficio real es que acelera decisiones. Cuando una actividad tiene al menos un Responsible y un solo Accountable, evitas dos cosas que destruyen el ritmo de un equipo: el vacío de ejecución y el atasco de aprobación. Esa regla operativa está recogida en la guía de INESDI sobre matriz RACI en proyectos digitales.

‍

Donde más se nota

‍

En ingeniería, se nota sobre todo en procesos con dependencias cruzadas:

• Despliegues a producción. Si Dev, QA y Tech Lead participan pero nadie tiene la aprobación final clara, el release se alarga o entra con dudas.
• Incidencias. Cuando hay un problema en producción, no puedes permitirte debatir quién lidera mientras el error sigue abierto.
• Cambios de arquitectura. Si todo el mundo opina y nadie decide, el equipo cae en parálisis elegante. Mucha conversación, poco avance.

‍

En hiring pasa lo mismo, solo que el coste se ve de otra forma. Un proceso de selección sin roles claros quema tiempo del equipo y genera mala experiencia para candidatos. Si estás definiendo ese proceso desde cero, conviene tener claro qué implica realmente el hiring en una empresa tecnológica.

‍

Si dos personas creen que tienen la última palabra, en realidad no la tiene nadie.

‍

Lo que resuelve y lo que no

‍

Sí resuelve:

• El “yo pensaba que lo hacías tú”
• La sobrecarga del héroe habitual
• Las revisiones infinitas
• La participación innecesaria de medio equipo

‍

No resuelve por sí sola:

• conflictos políticos entre áreas
• falta de criterio técnico
• managers que evitan decidir
• procesos mal diseñados

‍

Por eso hay que usarla como herramienta de diseño operativo, no como sustituto de liderazgo.

‍

Un efecto menos obvio

‍

La matriz también protege a la gente buena. En equipos jóvenes, siempre aparece la persona fiable que acaba absorbiendo seguimiento, contexto, desbloqueos y comunicación. Parece eficiente durante un tiempo. Luego llega el desgaste.

‍

Cuando explicitas responsabilidades, dejas de depender del “héroe”. Cada rol sabe dónde entra y dónde sale. Eso baja ruido y también reduce la tentación de meter a todo el mundo en todas las decisiones “por si acaso”.

‍

Ejemplos aplicados a startups y scaleups

‍

La mejor forma de aterrizar una matriz de responsabilidad es aplicarla a procesos repetibles. No empieces por mapear toda la empresa. Empieza por flujos donde ya hubo confusión.

Hiring de un ingeniero senior

‍

Roles: Recruiter, Hiring Manager, Tech Lead, CTO.

‍

Para una startup en crecimiento, una distribución razonable sería esta:

• Definir scorecard del puesto
• Hiring Manager: A
• Tech Lead: R
• Recruiter: C
• CTO: I

‍

Aquí el error clásico es poner al CTO como Accountable en todo. Eso escala mal. El CTO debería intervenir donde aporta criterio estratégico o validación final, no en cada paso del proceso.

‍

Onboarding de un nuevo developer

‍

Roles: Manager, Buddy o Mentor, RR. HH., Teammate.

‍

Una asignación útil podría ser:

• Preparar plan de primera semana
• Manager: A
• Buddy: R
• RR. HH.: C
• Teammate: I

‍

Si no haces esto, el onboarding queda repartido entre buena voluntad, mensajes en Slack y suposiciones. El resultado suele ser el mismo: la persona nueva tarda más de lo necesario en ser productiva y nadie siente que el proceso sea suyo.

‍

Despliegue de una feature a producción

‍

Roles: Dev, QA, Tech Lead, Product Manager.

‍

Un esquema sencillo:

• Implementación
• Dev: R
• Tech Lead: A
• QA: C
• Product Manager: I

‍

Aquí hay un matiz importante. El Accountable no siempre es la persona más senior del área. Para validación funcional, puede tener más sentido que el dueño final sea Producto, no Ingeniería.

‍

En un despliegue, la pregunta útil no es “quién participa”, sino “quién puede decir sí o no sin pedir permiso a tres personas más”.

‍

Un caso más delicado con datos personales

‍

Cuando hay tratamiento de datos personales, la conversación deja de ser solo operativa. Bajo el RGPD, la corresponsabilidad obliga a documentar con precisión qué entidad decide qué, y una matriz bien diseñada actúa como mecanismo mínimo para repartir funciones de cumplimiento, mitigación de riesgo y respuesta a incidentes entre producto, legal, seguridad y operaciones, tal como recoge la guía en español de la EDPB sobre responsable y encargado del tratamiento.

‍

En una startup que construye un producto con analítica, autenticación y proveedores externos, una asignación sensata sería esta:

• Definir finalidades de tratamiento
• Producto: R
• Legal: A
• Seguridad: C
• Operaciones: I

‍

Eso no sustituye el trabajo jurídico, pero sí evita el vacío típico donde ingeniería ejecuta medidas, legal interpreta obligaciones y nadie ha documentado quién decide.

‍

Si trabajas en compañías digitales con varios equipos técnicos y de negocio, este tipo de definición suele marcar la diferencia entre coordinación real y coordinación aparente. Es un patrón muy común en empresas con tecnología que ya operan con producto, datos, seguridad y proveedores a la vez.

‍

Más allá de RACI con variantes como RASCI o DACI

‍

RACI funciona bien cuando el problema principal es ejecutar sin ambigüedad. No siempre es suficiente. En cuanto el trabajo depende de soporte activo, decisiones de producto o varios equipos con peso parecido, conviene cambiar de modelo en lugar de forzar el que ya tienes.

Cuándo RASCI tiene más sentido

‍

RASCI añade una S de Support. Parece un detalle menor, pero en equipos técnicos no lo es.

‍

Hay personas que no solo son consultadas. Ayudan a ejecutar. Un DevOps engineer que prepara el pipeline, un Data Engineer que adapta un esquema o una persona de IT que provisiona equipos no están “asesorando”. Están dando soporte operativo real.

‍

Usa RASCI cuando:

• la ejecución depende de apoyo técnico recurrente
• quieres separar claramente “aporta criterio” de “ayuda a hacer”
• el rol de soporte suele quedar invisibilizado en RACI

‍

Si no haces esa distinción, acabas metiendo a medio mundo como Responsible o degradando el valor de Consulted.

‍

Cuándo DACI encaja mejor

‍

DACI cambia el foco. Ya no organiza trabajo. Organiza decisiones.

‍

Sus roles suelen leerse así:

• Driver. Empuja el proceso y mueve la decisión.
• Approver. Tiene la decisión final.
• Contributors. Aportan criterio y contexto.
• Informed. Deben conocer el resultado.

‍

En producto funciona muy bien para decisiones como priorización, pricing, arquitectura funcional o selección de herramientas. Si el problema de tu equipo no es “quién ejecuta esta tarea”, sino “cómo decidimos sin hacer cinco reuniones”, DACI suele ser mejor.

‍

Regla simple para elegir

‍

Si tienes dudas entre modelos, usa este filtro:

• RACI cuando necesitas claridad de ejecución
• RASCI cuando hay soporte operativo explícito
• DACI cuando el cuello de botella es la toma de decisiones

‍

RACI ordena tareas. DACI ordena conversaciones. No son intercambiables.

‍

El error habitual es intentar usar RACI para decisiones estratégicas de producto donde nadie “ejecuta” una fila concreta, pero sí hay debate, inputs cruzados y una aprobación final que debe quedar clara.

‍

Errores comunes al implementar la matriz de responsabilidad

‍

La mayoría de problemas con la matriz de responsabilidad no vienen del modelo. Vienen de cómo se usa. He visto matrices impecables en Google Sheets que no servían para nada a la semana siguiente.

El documento zombi

‍

Se crea una vez, se presenta en una reunión y muere en una carpeta de Drive o Notion. Eso pasa porque se trata como entregable, no como herramienta de gobierno diario.

‍

Una matriz útil debe actualizarse cuando cambia el proceso, entra un nuevo manager, se reparte un equipo o aparece un proveedor externo. Si no cambia con la realidad, deja de describirla y pasa a confundir más que ayudar.

‍

Poner varias A para no molestar a nadie

‍

Este es el error más destructivo. Se hace por diplomacia, por miedo político o por falta de claridad en la jerarquía real.

‍

Las guías en español sobre RACI insisten en que la claridad se degrada si una actividad tiene más de una persona Accountable o si los roles se solapan. Esto se vuelve especialmente problemático en startups con equipos cruzados o squads, como resume HEFLO al analizar los límites de la matriz RACI.

‍

Cuando ves dos A en una fila, lo correcto no es aceptarlo. Lo correcto es forzar la conversación que nadie quiere tener: quién decide al final.

‍

Llenar todo de C e I

‍

Otro antipatrón común es usar la matriz como mecanismo de inclusión política. Todo el mundo queda consultado. Todo el mundo queda informado. El resultado es previsible: más reuniones, más mensajes y menos foco.

‍

Hazte estas preguntas:

• Consultado significa que su input cambia la decisión o solo que quiere opinar.
• Informado significa que necesita actuar después o solo que prefiere enterarse.
• Si quitas a esa persona de la fila, ¿el proceso se rompe o solo se siente menos incluido?

‍

Si la respuesta es la segunda, sobra.

‍

Una matriz sobredimensionada no crea alineación. Crea ruido con apariencia de orden.

‍

Usarla para buscar culpables

‍

La matriz no está para señalar al responsable después del fallo. Está para alinear antes. Si la usas como arma retrospectiva, la gente empezará a defenderse durante su creación y dejará de decir la verdad sobre cómo trabaja.

‍

La conversación correcta no es “a quién le cae esto si sale mal”. Es “qué decisión o tarea necesita un dueño claro antes de empezar”.

‍

Copiar un modelo de proyecto lineal en equipos de squads

‍

Este es el error más sutil. RACI nació y se usa muy bien para clarificar roles, pero pierde fuerza cuando el problema principal no está dentro de un equipo sino entre varios equipos.

‍

En una startup con squads de producto, plataforma, datos y seguridad, la fricción real suele estar en la interdependencia. Un squad depende de APIs de otro, de reglas de compliance de un tercero y de prioridades de negocio que cambian. Ahí una matriz por proyecto puede quedarse corta.

‍

Qué sí funciona en estructuras complejas

‍

En esos casos, funciona mejor:

• Definir ownership por capacidad. Quién es dueño de pagos, observabilidad, onboarding, IAM o CI/CD.
• Separar decisiones de ejecución. Usa una lógica tipo DACI para decisiones transversales y RACI para operaciones concretas.
• Revisar la matriz de forma periódica. No por ritual, sino cuando hay reorganización, cambios de alcance o conflicto repetido.
• Mantener pocas filas críticas. Mejor diez actividades que importan de verdad que cincuenta irrelevantes.

‍

La señal de que vas bien es simple. La matriz reduce conversaciones innecesarias y acelera las importantes. Si añade burocracia, está mal diseñada.

‍

Tu plantilla de matriz de responsabilidad para empezar hoy

‍

Si quieres que esto funcione, no empieces por toda la empresa. Empieza por un proceso que ya te haya dado problemas: un despliegue, un hiring loop, el onboarding técnico o la gestión de incidencias.

‍

La matriz de responsabilidad útil no es la más completa. Es la que el equipo entiende y usa sin abrir una sesión de terapia organizativa cada vez. Por eso conviene construirla con una estructura simple:

• Lista de tareas críticas
• Roles reales, no cargos inflados
• Asignación R/A/C/I por fila
• Revisión de incoherencias
• Fecha de última actualización

‍

Plantilla mínima

‍

Crea una hoja en Google Sheets, Airtable o Notion con estas columnas:

• Actividad
• Recruiter / Manager / Tech Lead / CTO o los roles que toquen
• Notas de decisión
• Cuándo revisar

‍

Y aplica tres filtros antes de darla por buena:

1. Cada fila tiene ejecución clara
2. Solo hay una aprobación final
3. Consultados e informados son pocos y justificables

‍

No la uses como documento de control. Úsala como disparador de conversaciones honestas. Si una fila genera debate, perfecto. Ahí estaba el problema.

‍

Empieza pequeño. Un solo proceso. Una versión simple. Si el equipo nota menos dudas, menos handoffs rotos y menos aprobaciones ambiguas, ya tendrás una base real para extenderla.

‍

Si estás montando o escalando un equipo técnico y necesitas ordenar procesos de hiring, definición de roles y evaluación de perfiles sin perder velocidad, Kulturo trabaja con startups y scaleups tecnológicas en España para ayudar a CTOs, founders y líderes de ingeniería a contratar mejor.