Cuándo cambiar el operating model
Los síntomas que indican que el modelo operativo actual ya no sirve para la fase del negocio — y cómo diagnosticar qué componente hay que revisar.
Señales de que el modelo 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.
Los tres triggers del cambio.
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.
Crecimiento del equipo
Un equipo de 8 personas puede coordinarse informalmente. Un equipo de 25 necesita procesos explícitos, roles definidos y sistema de decisiones claro. El modelo que funcionó en 8 se rompe en 25.
Ejemplo: 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: empresa lanza 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.
Ejemplo: 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.
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. 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.
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: 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.
Ajuste por componente
Modificar uno de los cuatro componentes sin tocar los otros. Agregar un ritual, ajustar criterios de decisión, redistribuir responsabilidades. 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.
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, probablemente necesites cambio transformacional — pero con ese diagnóstico ya sabés qué está roto.
05 — Errores frecuentesErrores frecuentes al cambiar.
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.
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 debe identificar qué componente específico está fallando.
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 reduce el riesgo de cambios que empeoran las cosas.
Preguntas frecuentes.
¿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.
Referencias y bibliografía.
Galbraith, J. R. (2014). Designing Organizations: Strategy, Structure, and Process at the Business Unit and Enterprise Levels. Jossey-Bass.
Greiner, L. E. (1998). Evolution and Revolution as Organizations Grow. Harvard Business Review.
Lencioni, P. (2002). The Five Dysfunctions of a Team. Jossey-Bass.
Rumelt, R. (2011). Good Strategy/Bad Strategy: The Difference and Why It Matters. Crown Business.
Términos del glosario