Cuándo cambiar el operating model: 7 señales claras.
Los síntomas que indican que el modelo operativo actual ya no sirve para la fase del negocio — y cómo diagnosticar qué componente específico hay que revisar antes de tocar el resto.
Las 7 señales claras de que el operating model dejó de funcionar.
El operating model deja de funcionar mucho antes de que los resultados colapsen. Las señales tempranas son sutiles: decisiones que tardan más de lo razonable, coordinación que requiere más reuniones, personas clave que expresan frustración con "cómo funcionan las cosas acá". Estas señales son fáciles de racionalizar como problemas temporales — hasta que se vuelven recurrentes. Saber cuándo cambiar el operating model empieza por leer esas siete señales antes de que se conviertan en crisis abierta.
Las decisiones se traban sistemáticamente
Cada decisión operativa requiere aprobación del líder. Las decisiones tácticas escalan innecesariamente al sistema de toma de decisiones. El tiempo promedio de cierre de decisiones aumenta mes a mes sin que el tipo de decisión haya cambiado.
La coordinación consume más tiempo que la ejecución
El equipo pasa más tiempo sincronizándose que ejecutando. Reuniones para coordinar reuniones. Iniciativas simples requieren alineación de múltiples áreas que antes trabajaban autónomamente. Los procesos de trabajo agregan overhead en vez de quitarlo.
Personas clave consideran irse
Los mejores ejecutores expresan frustración con "la burocracia" o "la falta de claridad". El modelo los traba más que a otros porque intentan ejecutar rápido. Si se van, el problema empeora porque pierden expertise y los reemplazos heredan el mismo sistema.
Los mismos problemas resurgen cada trimestre
La retrospectiva identifica problemas — pero esos mismos problemas vuelven a aparecer el trimestre siguiente. No es falta de voluntad para mejorar: es que el modelo produce esos problemas estructuralmente. La iteración de equipo no convierte aprendizaje en cambio real.
La velocidad cae mientras el equipo crece
Agregar personas debería aumentar capacidad. Si la velocidad cae cuando el equipo crece, el modelo no escala — más personas producen más coordinación que más output. Fred Brooks lo formalizó en The Mythical Man-Month (1975): agregar personas a un proyecto atrasado lo retrasa más.
La cultura de revisión se erosiona en silencio
Las retros se saltean, los OKRs no se revisan, los dashboards se ignoran. El equipo deja de aprender de sus propios resultados porque nadie tiene tiempo, autoridad o foco para cerrar el loop. Es la señal más silenciosa y la más predictiva.
Los tres triggers del cambio del operating model.
Hay tres triggers principales que obligan a revisar el modelo: crecimiento del equipo, aumento de complejidad del portafolio y cambio de estrategia. Cada uno produce un tipo específico de desajuste entre el modelo actual y lo que el negocio necesita. Larry Greiner, en Evolution and Revolution as Organizations Grow (HBR 1998), describió cómo cada fase de crecimiento agota un modelo y obliga a saltar al siguiente.
Crecimiento del equipo
Un equipo de 8 personas puede coordinarse informalmente. Un equipo de 25 necesita procesos explícitos, roles definidos y un sistema de decisiones claro. El modelo que funcionó en 8 se rompe en 25.
Ejemplo: el equipo pasa de 10 a 30 personas en un año — las decisiones que antes se tomaban en Slack ahora se traban porque no está claro quién decide.
Complejidad del portafolio
Un producto con un GTM permite estructura funcional. Múltiples productos con GTMs diferenciados requieren equipos por producto. El modelo funcional se rompe cuando la complejidad supera su capacidad de coordinación.
Ejemplo: la empresa lanza una segunda línea de producto con segmento diferente — el equipo funcional no puede priorizar entre dos GTMs distintos simultáneamente.
Cambio de estrategia
Una estrategia que compite en velocidad de innovación requiere autonomía descentralizada. Una que compite en consistencia de marca requiere coordinación centralizada. Si la estrategia cambia, el modelo debe cambiar — y los objetivos North Star redefinen las prioridades operativas.
Ejemplo: la empresa cambia de self-serve a enterprise — el modelo descentralizado de growth no sirve para ciclos de venta largos con múltiples stakeholders.
Problema de modelo vs problema de ejecución: el test diagnóstico.
No todo problema operativo es un problema de modelo. Algunas fricción es ejecución — las personas no siguen los procesos, no usan las herramientas o no toman buenas decisiones. Cambiar el modelo no arregla problemas de ejecución; al revés, los amplifica. El test para distinguirlos: ¿el problema es recurrente y cross-iniciativas, o es esporádico y específico?
Si las decisiones se traban solo en un proyecto específico, probablemente sea ejecución. Si se traban en todos los proyectos durante meses, es el modelo. Si un proceso falla porque una persona no lo sigue, es ejecución. Si múltiples personas no lo siguen porque el proceso no tiene sentido, es el modelo. Este diagnóstico no es trivial — Richard Rumelt, en Good Strategy/Bad Strategy (2011), insiste en que confundir síntoma con causa raíz es el error más caro de la gestión estratégica.
El error más común es confundir síntoma con causa. Las decisiones que se traban no son el problema — son el síntoma. El problema es que el sistema de decisiones no está diseñado para el tipo de complejidad que el equipo enfrenta hoy. Podés pedir a las personas que tomen decisiones más rápido, pero si el sistema requiere aprobación de cinco stakeholders para cada decisión operativa, la lentitud es estructural. Cambiar el comportamiento sin cambiar el sistema produce frustración, no velocidad.
Lisandro IserteTipos de cambio del operating model: incremental vs transformacional.
No todos los cambios de modelo son iguales. Algunos son incrementales — ajustar un componente sin tocar el resto. Otros son transformacionales — rediseñar múltiples componentes simultáneamente. El tipo de cambio determina el costo, el riesgo y el tiempo de implementación, y la decisión correcta depende del diagnóstico previo.
Ajuste por componente
Modificar uno de los cuatro componentes sin tocar los otros. Agregar un ritual, ajustar criterios de decisión, redistribuir responsabilidades dentro del workflow existente. Menor riesgo, menor disrupción, iteración más rápida.
Rediseño sistémico
Reestructurar el equipo, cambiar el sistema de decisiones, rediseñar procesos simultáneamente. Alto impacto, alto riesgo, requiere tiempo de estabilización. Se justifica cuando el modelo completo dejó de servir — no como respuesta al primer signo de fricción.
La regla general: empezá con cambio incremental. Si ajustar un componente resuelve la fricción, no necesitás rediseñar todo. Si ajustar componentes individuales no produce mejora sostenida durante 2-3 ciclos consecutivos, probablemente necesites cambio transformacional — pero con ese diagnóstico ya sabés qué está roto. Jay Galbraith, en Designing Organizations (2014), llama a esto "diseño por compromiso": cada componente del modelo se ajusta entre sí, y rediseñar todo de golpe sin entender las dependencias produce un nuevo modelo igual de roto.
El alcance del cambio también depende del cluster afectado. Si la fricción aparece en posicionamiento de marca o propuesta de valor, suele bastar con ajuste incremental — son áreas relativamente estables. Si aparece en segmentación de ICP, adquisición paga o retención y churn, donde las tasas de conversión y el churn se mueven rápido, el cambio operativo suele ser transformacional porque toca cómo se ejecuta, no solo qué se ejecuta. La segmentación activa y el ICP validado son los puntos donde el modelo entra en contacto con el mercado real.
05 — Errores frecuentesErrores frecuentes al cambiar el operating model.
Cambiar el modelo cada 6 meses
Reestructurar constantemente porque "algo no funciona" sin dar tiempo al modelo a estabilizarse. Todo cambio tiene costo de aprendizaje — las personas necesitan tiempo para internalizar nuevos procesos. Si cambiás antes de la estabilización, nunca sabrás si el problema era el modelo o la falta de tiempo para adoptarlo. La regla práctica: ningún modelo se evalúa antes de dos trimestres completos de operación estable.
Confundir síntoma con causa raíz
Las decisiones se traban → cambiamos la estructura. Pero el problema no era la estructura — era el sistema de decisiones. El cambio produce disrupción sin resolver el problema real. El diagnóstico estratégico debe identificar qué componente específico está fallando antes de tocar nada más, idealmente apoyado en datos de los dashboards de operación, no en intuición.
Rediseño total sin validación
Anunciar un modelo nuevo sin testearlo con el equipo. El modelo parece perfecto en el diagrama pero falla en la ejecución porque el diseñador pasó por alto dependencias reales. La validación con las personas que operan el modelo — en sesiones de análisis conjunto y revisión de plan de acción — reduce el riesgo de cambios que empeoran las cosas.
Cambiar el modelo cuando el problema es de talento
El modelo está bien diseñado pero el equipo no tiene la experiencia para operarlo. Cambiar el modelo a uno "más simple" parece solución, pero el problema vuelve cuando el negocio crece. La solución real es invertir en formación, contratar el perfil correcto o redistribuir responsabilidades según los criterios de priorización y el engagement real del equipo — no degradar el sistema para que el talento actual lo aguante.
Preguntas frecuentes sobre cuándo cambiar el operating model.
¿Cómo sé si el problema es el operating model o la ejecución?
Si los mismos problemas aparecen recurrentemente en diferentes iniciativas — las decisiones se traban, los proyectos se retrasan, la coordinación falla — el problema es estructural, no de ejecución. Si los problemas son esporádicos o específicos de una iniciativa, probablemente sea ejecución. El test: ¿arreglar este problema requiere cambiar cómo opera el equipo o solo requiere que las personas hagan mejor su trabajo actual?
¿Cuánto tiempo lleva cambiar el operating model?
Depende del alcance del cambio. Un ajuste incremental (modificar procesos, agregar un ritual) puede tomar 2-4 semanas de estabilización. Un cambio transformacional (reestructurar el equipo, cambiar el sistema de decisiones) puede tomar 2-3 meses desde el diseño hasta la estabilización. El error común es subestimar el tiempo de estabilización — el modelo nuevo necesita tiempo para que las personas lo internalicen.
¿Qué es más riesgoso: cambiar o no cambiar?
Cambiar tiene costo de disrupción — pérdida de productividad temporal, riesgo de que el nuevo modelo sea peor. No cambiar tiene costo de oportunidad — fricción creciente, velocidad decreciente, personas clave que se van porque el modelo las traba. La decisión no es binaria: podés iterar por componente (cambiar procesos, después estructura, después decisiones) en lugar de rediseñar todo simultáneamente.
Galbraith, J. R. (2014). Designing Organizations: Strategy, Structure, and Process at the Business Unit and Enterprise Levels. Jossey-Bass. Caps. sobre diseño por compromiso y dependencia entre componentes.
Greiner, L. E. (1998). Evolution and Revolution as Organizations Grow. Harvard Business Review. Disponible en: hbr.org
Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley. Caps. sobre por qué agregar personas a un proyecto atrasado lo retrasa más.
Rumelt, R. (2011). Good Strategy/Bad Strategy: The Difference and Why It Matters. Crown Business. Caps. sobre diagnóstico estratégico como núcleo de la buena estrategia.
Lencioni, P. (2002). The Five Dysfunctions of a Team. Jossey-Bass. Caps. sobre la rendición de cuentas mutua y el problema de los equipos que pierden velocidad al escalar.
Grove, A. S. (1983). High Output Management. Random House. Caps. sobre cuándo y cómo modificar el output del manager y la organización.
Términos relacionados