Reseña: «Good Strategy / Bad Strategy», de Richard Rumelt
Leí «Good Strategy / Bad Strategy», de Richard Rumelt, por primera vez en 2019. Desde entonces lo he releído dos veces. Es de esos libros que ganan filo con cada relectura, porque no dejas de reconocer sus patrones en tus propias decisiones — sobre todo en las malas.
El argumento central de Rumelt es engañosamente simple: la mayor parte de lo que pasa por estrategia no es estrategia. Son objetivos vestidos con lenguaje aspiracional. Son declaraciones de visión en una presentación. Son listas de prioridades tan largas que, en realidad, nada tiene prioridad. Y en el mundo startup, donde la palabra «estrategia» aparece en cada consejo y en cada all-hands, el problema es endémico.
Si lideras un equipo de ingeniería, gestionas un producto o diriges una startup, este libro cambiará tu forma de pensar las decisiones. Te explico por qué.
La buena estrategia tiene exactamente tres partes
Rumelt define la buena estrategia por tres componentes — lo que él llama el núcleo (kernel):
1. Diagnóstico: ¿cuál es el reto real?
El diagnóstico es una evaluación honesta de la situación. No lo que te gustaría que fuera verdad. El problema real.
He estado en reuniones de estrategia donde el diagnóstico era «necesitamos crecer más rápido». Eso no es un diagnóstico: es un deseo. Un diagnóstico real: «Nuestra conversión de prueba a pago es del 4%, la mitad del benchmark del sector, porque el onboarding pierde al 60% de los usuarios antes de que lleguen a ver el valor del producto».
En términos de ingeniería, un buen diagnóstico: «Nuestro ciclo de despliegue tarda 3 semanas porque no tenemos pruebas automatizadas, el QA es manual y lanzamos todo desde una única rama». Específico. Accionable. Nombra la restricción real.
Un mal diagnóstico: «Necesitamos lanzar más rápido». Todo el mundo asiente. Nadie sabe qué hacer.
2. Política orientadora: el enfoque
La política orientadora es el enfoque general ante el reto diagnosticado. No es una acción concreta — es la dirección que acota tus acciones.
La analogía de Rumelt: una política orientadora es como el guardarraíl de una carretera de montaña. No te dice hacia dónde girar, pero te impide caer por el precipicio.
Para el ejemplo del despliegue: «Invertiremos en automatización para que los despliegues sean autoservicio y eliminar la coordinación manual». No especifica qué herramienta de CI/CD usar ni cómo gestionar las migraciones. Marca la dirección.
La característica clave de una buena política orientadora es que elige. Dice «haremos esto, y no aquello». Si tu «estrategia» no descarta nada, no es una estrategia.
3. Acción coherente: pasos coordinados
El tercer elemento es un conjunto de acciones coordinadas que ejecutan la política orientadora. No una lista de deseos. No 47 iniciativas. Un conjunto acotado de movimientos que se refuerzan entre sí.
Para nuestro problema de despliegue: (1) introducir feature flags para desacoplar despliegue y lanzamiento, (2) montar CI con suites de pruebas automatizadas para los dos servicios de mayor tráfico, (3) pasar a desarrollo trunk-based. Los tres movimientos son coherentes: cada uno apoya a los demás, y juntos atacan el problema diagnosticado.
La coherencia es lo que separa una estrategia de una lista de tareas. Una colección de proyectos de mejora inconexos no es una estrategia. Un conjunto de acciones que se refuerzan mutuamente, dirigidas a un reto concreto, sí lo es.
La mala estrategia está en todas partes
La taxonomía de la mala estrategia de Rumelt me cayó como un mazazo, porque reconocí cada patrón en empresas con las que había trabajado:
Palabrería. Lenguaje inflado que no dice nada. «Aprovecharemos las capacidades sinérgicas de nuestra plataforma para desbloquear valor en todo el ecosistema.» Quita la jerga y debajo no queda nada.
Confundir objetivos con estrategia. «Nuestra estrategia es liderar el mercado de herramientas para desarrolladores.» Eso es un objetivo, no una estrategia. ¿Dónde está el diagnóstico? ¿Dónde está la política orientadora?
No elegir. El patrón más dañino. Una empresa con 12 «prioridades estratégicas» tiene cero prioridades estratégicas. Estrategia significa decidir qué NO vas a hacer. Si tu equipo de ingeniería está a la vez reescribiendo el backend, construyendo tres funcionalidades, migrando a otra nube y reduciendo la deuda técnica un 40%, no tienes una estrategia: tienes una fantasía.
Ignorar el reto. Saltar directamente a los objetivos y las acciones sin identificar qué es lo verdaderamente difícil. El resultado son recetas genéricas que no abordan ninguna restricción concreta.
Por qué la mayoría de los OKR no son estrategia
Aquí es donde el marco de Rumelt más escuece en el mundo tecnológico. Los OKR — objetivos y resultados clave — son excelentes herramientas de ejecución. Pero no son estrategia, y tratarlos como si lo fueran es uno de los errores más comunes que veo.
Un OKR como «aumentar la fiabilidad de la plataforma al 99,95% de uptime» es un objetivo con un resultado medible. Te dice qué aspecto tiene el éxito. Lo que no te dice:
- Por qué la fiabilidad es el reto más importante ahora mismo (diagnóstico)
- Con qué enfoque vas a mejorarla (política orientadora)
- Qué acciones concretas y coordinadas vas a ejecutar (acción coherente)
Los OKR vienen después de la estrategia: la operativizan. Pero si fijas OKR sin estrategia, acabas con una colección de objetivos medibles que no conectan entre sí ni abordan tu reto central. Cada equipo cumple sus OKR y la empresa sigue sin avanzar, porque nadie se ha hecho la pregunta difícil: «¿cuál es el problema más importante que tenemos que resolver, y qué vamos a hacer al respecto?»
Las decisiones de ingeniería son decisiones de estrategia
Aquí es donde el libro se vuelve intensamente práctico para cualquiera que lidere ingeniería:
Decisiones de arquitectura. ¿Reescribir o refactorizar? El marco de Rumelt te obliga a empezar por el diagnóstico. ¿Cuál es el problema real? Si es «el monolito tarda demasiado en desplegarse», la política orientadora puede ser extraer a servicios los módulos que más cambian — no una reescritura completa. Las acciones coherentes vienen solas: identificar los 3 módulos con más frecuencia de cambio, definir las fronteras de los servicios, implementar una extracción como prueba de concepto.
Build vs. buy. «Lo construimos todo en casa» no es una estrategia: es una inercia. Un buen diagnóstico: «Dedicamos el 30% del tiempo de ingeniería a mantener infraestructura que es pura commodity». Política orientadora: «Comprar servicios gestionados para lo que no nos diferencia; construir solo donde tenemos una ventaja única». A partir de ahí, cada decisión futura tiene un filtro.
Escalado del equipo. «Contratar 20 ingenieros» es un objetivo. La versión estratégica: «La velocidad de entrega se ha reducido a la mitad porque dos equipos se pisan en una base de código compartida». Política orientadora: «Establecer propiedad por dominios antes de ampliar la plantilla». Acciones coherentes: definir contextos delimitados, dividir la base de código, crear APIs entre equipos y, después, contratar para la nueva estructura.
La parte difícil: elegir
La verdad más incómoda del libro es que la buena estrategia exige decir que no. No «ahora no». No.
Si eres una startup de 8 ingenieros y estás intentando construir a la vez una app móvil, una app web, una plataforma de APIs y una funcionalidad de IA, no tienes una estrategia. Tienes FOMO. Rumelt te diría que diagnostiques tu ventaja competitiva real, elijas lo único que de verdad importa y lo ejecutes con coherencia.
Eso significa decirle a alguien — un cofundador, un miembro del consejo, un cliente — que no vas a hacer lo que te pide. Por eso la mala estrategia abunda mucho más que la buena: la mala estrategia te permite evitar el conflicto; la buena lo exige.
En Conectia vemos este patrón constantemente en las startups con las que trabajamos. Los fundadores llegan necesitando ingenieros, pero la conversación real suele empezar por «¿qué construimos primero?». Cuando integramos ingenieros senior en un equipo, no se limitan a escribir código: hacen las preguntas de diagnóstico que afilan la estrategia. ¿Cuál es el cuello de botella real? ¿Qué deberíamos dejar de hacer? ¿Dónde añadir capacidad resuelve de verdad el problema, y dónde solo acelera el caos?
Eso es lo que aporta un ingeniero con experiencia: no solo ejecución, sino criterio sobre qué ejecutar.
¿Estás construyendo tu equipo de ingeniería y quieres gente que piense estratégicamente, no que solo escriba código? Habla con un CTO — integramos ingenieros senior de LATAM que hacen las preguntas correctas antes de escribir la primera línea.
