Roles y responsabilidades poco claros: nadie sabe exactamente “quién es dueño de qué”.
Subtítulo:
No te falta “orden”. Te falta arquitectura de ownership: D/R/I (Decide /Recomienda / Informados) para decisiones recurrentes + un “contrato” mínimo dedueños por entrega. Sin eso, todo se negocia cada vez… y cuando algo falla, sevuelve personal.
Micro-promesa (30 días): Tendrás 10–15 decisiones recurrentes con D/R/I explícito + 1 interfaz crítica con criterios de “aceptado vs rechazado”. Menos duplicidady huecos. Menos escalamiento “por cobertura”.
En 60 segundos
Te aplica si: operas con equipos funcionales y vives en modo “ ¿Y de esto quiénse supone que se encarga?” o “alguien debería de…”.
Señales de que está presente (marca lasque ves). Si marcas 3 o más, este síntoma está activo:
☐ Dos áreas hacen lo mismo (duplicidad) o ninguna lo hace (hueco).
☐ “Eso no es mío” / “yo pensé que…” es conversación normal.
☐ Todo se decide por escalamiento o por la persona más insistente.
☐ Las juntas son negociación repetida de lo básico (“entonces tú o yo…”).
☐ Cuando algo falla, se vuelve moral: culpa, defensa, reputación.
Traducción simple: no es “falta de flexibilidad”. Es falta de derechos de decisión ydueños operables.
Qué harás hoy (10–30 min)
Objetivo (hoy): dejar de “interpretar” responsabilidades y volverlas operables: D/R/Ipara decisiones recurrentes + un handoff (entrega) con “aceptado vs rechazado”.
Tiempo realista: 10–30 min para instalar + 10 min/semana para sostener(ajustes solo en día 30).
Protocolo Express
1) Lista 10–15 decisiones recurrentes(no roles abstractos)
No empieces con organigrama. Empieza condecisiones que se repiten y causan fricción, por ejemplo:
- ¿Quién prioriza solicitudes?
- ¿Quién aprueba cambios?
- ¿Quién decide paro / contención?
- ¿Quién define “listo” para entregar?
- ¿Quién acepta/rechaza el entregable?
2) Asigna D/R/I para cada decisión (unalínea por decisión)
- D (Decide): una persona/rol. Uno.
- R (Recomienda): quien trae A/B con trade-offs y evidencia mínima.
- I (Informados): quién debe saberlo, no opinarlo.
Regla: si hay dos “D”, no hay D. Hay política.
3) Define la “frontera”: qué NO decideese foro/rol
Escribe 2–3 “no decide” para evitarinvasión:
- “Este foro no decide excepciones fuera del criterio.”
- “Este rol no aprueba retrabajos sin evidencia.”
La claridad también vive en el “no”.
4) Convierte una decisión crítica en unhandoff operable (IC1)
Donde más se “pierde” el trabajo casisiempre es una interfaz A→B.
Instala IC1 — Contrato de Interfaz (1 página) con 3 cosas:
- Qué se entrega y cuándo (ventana)
- Qué cuenta como aceptado (3–5 criterios verificables)
- Qué indicador manda (1 indicador compartido + fuente única)
Regla fría:si no cumple criterio, se rechaza y se registra. No se renegocia por canalesalternos (como WhatsApp, Webex, Teams, etc).
5) Abre una bitácora mínima (registrovivo)
Campos: decisión | D | fecha | evidencia| estado.
Y para el traspaso: aceptado sí/no + motivo.
Sin bitácora, el sistema vuelve a depender de memoria y “lo que entendió cadaquien”.
6) Ritual semanal 10 minutos (por 4semanas)
- ¿Qué decisiones se atoraron por falta de D/R/I?
- ¿Qué traspasos rebotaron por criterios ambiguos?
Ajustas en el día 30 con evidencia, no con emociones del martes.
Artefacto mínimo (1 página)
OA1 — Arquitectura de Ownership (1página)
Incluye solo:
- lista de 10–15 decisiones recurrentes con D/R/I
- 1 IC1 del traspaso crítico
- 1 indicador compartido (ej. “Aceptado a la primera %”) + fuente
- link a bitácora viva
(Si quieres la plantilla editable y ejemplos por tipo de decisión/flujo, estas las comparto en mi Newsletter “EnMarcha” (Regístrate aquí).)
Por qué funciona (sin teoría)
- La ambigüedad deja de ser “flexibilidad” y se vuelve regla.
- Baja duplicidad/huecos: el sistema sabe quién decide y quién recomienda.
- “Terminado” deja de ser opinión: se vuelve criterio observable (aceptado vs rechazado).
- La bitácora crea memoria: menos renegociación infinita.
No es magia: dónde se rompe
Esto falla si:
- Se tolera que el “I” opine como si fuera “D”
- El decisor real está ausente o no respalda su decisión cuando hay fricción
- El IC1 existe pero nadie sostiene el derecho a rechazar
- El indicador no tiene fuente única (se vuelve pleito de Excel vs. Excel)
No es suficiente si:
- Hay vetos cruzados (nadie tiene autoridad final) y no existe escalamiento real
- Incentivos están en guerra (bonos 100% locales; el global “no cuenta”)
- Capacidad crónicamente insuficiente: todo es urgente siempre
Indicadores rápidos de éxito (2–4semanas)
- Escalamientos “por cobertura” ↓
- Decisiones reabiertas ↓
- “Aceptado a la primera” ↑
- Retrabajo por handoff ↓
- Tiempo de ciclo para decisiones recurrentes ↓
Qué cambia si lo sostienes (4–6 semanas)
- Menos juntas para negociar lo básico; más ejecución por regla.
- Los problemas dejan de volverse personales: ya existe “el sistema” (criterio + dueño + registro).
- El líder deja de ser árbitro perpetuo: el flujo empieza a gobernarse.
Si no se mueve…
Si en 4–6 semanas esto no cambia,probablemente estás frente a algo más profundo y más sistémico que un tema puntual de roles.
Siguiente paso recomendado: aplica el Flash Scorecard para obtener el mapa del sistema detu equipo y ubicar el punto de palanca real — antes de meter más presión o másjuntas.