Reseña de Libro: «Good Strategy / Bad Strategy» de Richard Rumelt
Leí «Good Strategy / Bad Strategy» de Richard Rumelt por primera vez en 2019. Lo he vuelto a leer dos veces desde entonces. Es el tipo de libro que se vuelve más nítido cada vez porque sigues reconociendo sus patrones en tus propias decisiones — especialmente en las malas.
El argumento central de Rumelt es engañosamente simple: la mayor parte de lo que pasa por estrategia no es estrategia en absoluto. Son objetivos disfrazados de lenguaje aspiracional. Son declaraciones de visión en una presentación. Son listas de prioridades tan largas que nada está realmente priorizado. Y en el mundo de las startups, donde "estrategia" se menciona en cada reunión de junta y en cada all-hands, este problema es endémico.
Si lideras un equipo de ingeniería, gestionas un producto o diriges una startup, este libro cambiará cómo piensas sobre las decisiones. He aquí por qué.
El Núcleo de la Buena Estrategia
Rumelt define la buena estrategia como compuesta por tres partes — 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 desearías 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 el 60% de los usuarios antes de que vean el valor central."
En términos de ingeniería, un buen diagnóstico: "Nuestro ciclo de despliegue tarda 3 semanas porque no tenemos pruebas automatizadas, un proceso de QA manual y una estrategia de una sola rama de lanzamiento." 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 una acción específica — la dirección que condiciona tus acciones.
La analogía de Rumelt: una política orientadora es como una barrera de protección en 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 eliminaremos la coordinación manual." Eso no especifica qué herramienta de CI/CD usar ni cómo gestionar las migraciones. Fija la dirección.
La característica clave de una buena política orientadora es que toma decisiones. Dice "haremos esto, 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 implementan la política orientadora. No una lista de deseos. No 47 iniciativas. Un conjunto enfocado de movimientos que se refuerzan mutuamente.
Para nuestro problema de despliegue: (1) introducir feature flags para desacoplar el despliegue del lanzamiento, (2) configurar CI con suites de pruebas automatizadas para los dos servicios de mayor tráfico, (3) pasar al desarrollo trunk-based. Estos tres movimientos son coherentes — cada uno apoya a los demás y juntos abordan el problema diagnosticado.
La coherencia es lo que separa la estrategia de una lista de tareas. Una lista de proyectos de mejora no relacionados no es una estrategia. Un conjunto de acciones mutuamente reforzantes dirigidas a un reto específico sí lo es.
La Mala Estrategia Está Por Todos Lados
La taxonomía de la mala estrategia de Rumelt me golpeó como un tren de carga porque reconocí cada patrón en empresas con las que había trabajado:
Palabrería. Lenguaje inflado que no dice nada. "Aprovecharemos nuestras capacidades de plataforma sinérgicas para desbloquear valor en todo el ecosistema." Elimina la jerga y no queda nada debajo.
Confundir objetivos con estrategia. "Nuestra estrategia es ser el líder del mercado en herramientas para desarrolladores." Eso es un objetivo, no una estrategia. ¿Dónde está el diagnóstico? ¿Dónde está la política orientadora?
No tomar decisiones. El patrón más dañino. Una empresa que lista 12 "prioridades estratégicas" tiene cero prioridades estratégicas. La estrategia significa decidir qué NO harás. Si tu equipo de ingeniería está simultáneamente reescribiendo el backend, construyendo tres funcionalidades, migrando a una nueva nube y reduciendo la deuda técnica en un 40%, tienes una fantasía, no una estrategia.
Ignorar el reto. Saltar directamente a objetivos y acciones sin identificar qué es realmente difícil. El resultado son manuales genéricos que no abordan las restricciones específicas.
Por Qué la Mayoría de los OKRs No Son Estrategia
Aquí es donde el framework de Rumelt realmente duele en el mundo tecnológico. Los OKRs — 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 cómo luce el éxito. No te dice:
- Por qué la fiabilidad es el reto más importante ahora (diagnóstico)
- Qué enfoque tomarás para mejorarla (política orientadora)
- Qué acciones específicas y coordinadas ejecutarás (acción coherente)
Los OKRs están corriente abajo de la estrategia. La operacionalizan. Pero si estableces OKRs sin estrategia, acabas con una colección de objetivos medibles que no se conectan entre sí y no abordan tu reto central. Cada equipo cumple sus OKRs y la empresa aún no avanza, porque nadie hizo la pregunta difícil: "¿Cuál es el problema más importante que necesitamos resolver, y qué vamos a hacer al respecto?"
Aplicando Rumelt a las Decisiones de Ingeniería
Aquí es donde el libro se vuelve intensamente práctico para cualquiera que lidere ingeniería:
Decisiones de arquitectura. ¿Debería reescribir o refactorizar? El framework de Rumelt te obliga a empezar con el diagnóstico. ¿Cuál es el problema real? Si es "el monolito tarda demasiado en desplegarse", la política orientadora podría ser extraer los módulos de mayor rotación en servicios — no una reescritura completa. Las acciones coherentes siguen: identificar los 3 módulos principales por frecuencia de cambio, definir límites de servicio, implementar una extracción como prueba de concepto.
Build vs. buy. "Construimos todo internamente" no es una estrategia — es un default. Un buen diagnóstico: "Gastamos el 30% del tiempo de ingeniería manteniendo infraestructura básica." Política orientadora: "Comprar servicios gestionados para los no diferenciadores; construir solo donde tenemos ventaja única." Ahora 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 redujo a la mitad porque dos equipos se interfieren en una base de código compartida." Política orientadora: "Establecer propiedad de dominio antes de aumentar el headcount." Acciones coherentes: definir contextos delimitados, dividir la base de código, crear APIs de equipo, luego contratar para la nueva estructura.
La Parte Difícil: Tomar Decisiones
La verdad más incómoda de este libro es que la buena estrategia requiere decir no. No "no ahora mismo". No.
Si eres una startup de 8 ingenieros y estás intentando construir una aplicación móvil, una aplicación web, una plataforma API y una función de IA simultáneamente, no tienes una estrategia. Tienes FOMO. Rumelt te diría que diagnostiques tu ventaja competitiva real, elijas la única cosa que más importa y la ejecutes con coherencia.
Eso significa decirle a alguien — un cofundador, un miembro de la junta, un cliente — que no vas a hacer lo que quieren. Por eso la mala estrategia es mucho más común que la buena. La mala estrategia te permite evitar el conflicto. La buena estrategia lo exige.
En Conectia, vemos este patrón constantemente con las startups con las que trabajamos. Los fundadores acuden a nosotros necesitando ingenieros, pero la conversación real a menudo empieza con "¿qué deberíamos construir primero?" Cuando integramos ingenieros senior en un equipo, no solo escriben código — hacen las preguntas de diagnóstico que afinan la estrategia. ¿Cuál es el verdadero cuello de botella? ¿Qué deberíamos dejar de hacer? ¿Dónde añadir capacidad realmente resuelve el problema frente a simplemente hacer el caos más rápido?
Eso es lo que aportan los ingenieros con experiencia: no solo ejecución, sino juicio sobre qué ejecutar.
¿Construyendo tu equipo de ingeniería y quieres personas que piensen estratégicamente, no solo que escriban código? Habla con un CTO — integramos ingenieros senior de LATAM que hacen las preguntas correctas antes de escribir la primera línea.
