Crítica de Livro: «Good Strategy / Bad Strategy» de Richard Rumelt
Li «Good Strategy / Bad Strategy» de Richard Rumelt pela primeira vez em 2019. Reli-o duas vezes desde então. É o tipo de livro que se torna mais nítido a cada leitura porque continuas a reconhecer os seus padrões nas tuas próprias decisões — especialmente nas más.
O argumento central de Rumelt é enganosamente simples: a maior parte do que passa por estratégia não é estratégia de todo. São objetivos disfarçados de linguagem aspiracional. São declarações de visão num slide. São listas de prioridades tão longas que nada está realmente priorizado. E no mundo das startups, onde a "estratégia" é mencionada em cada reunião do conselho e em cada all-hands, este problema é endémico.
Se lideras uma equipa de engenharia, geres um produto ou diriges uma startup, este livro mudará a forma como pensas sobre as decisões. Eis porquê.
O Núcleo da Boa Estratégia
Rumelt define a boa estratégia como tendo três partes — o que chama o núcleo (kernel):
1. Diagnóstico: Qual é o verdadeiro desafio?
O diagnóstico é uma avaliação honesta da situação. Não o que desejavas que fosse verdade. O problema real.
Estive em reuniões de estratégia onde o diagnóstico era "precisamos de crescer mais depressa". Isso não é um diagnóstico — é um desejo. Um diagnóstico real: "A nossa conversão de trial para pago é de 4%, metade do benchmark do setor, porque o onboarding perde 60% dos utilizadores antes de verem o valor central."
Em termos de engenharia, um bom diagnóstico: "O nosso ciclo de deployment demora 3 semanas porque não temos testes automatizados, um processo de QA manual e uma estratégia de ramo único." Específico. Acionável. Nomeia a verdadeira restrição.
Um mau diagnóstico: "Precisamos de lançar mais depressa." Toda a gente acena. Ninguém sabe o que fazer.
2. Política Orientadora: A abordagem
A política orientadora é a abordagem geral ao desafio diagnosticado. Não uma ação específica — a direção que constrange as tuas ações.
A analogia de Rumelt: uma política orientadora é como uma barreira de proteção numa estrada de montanha. Não te diz para onde virar, mas impede-te de cair do precipício.
Para o exemplo do deployment: "Investiremos em automação para tornar os deployments self-service e eliminar a coordenação manual." Isso não especifica qual ferramenta CI/CD usar nem como lidar com migrações. Define a direção.
A característica-chave de uma boa política orientadora é que faz escolhas. Diz "faremos isto, não aquilo". Se a tua "estratégia" não descarta nada, não é uma estratégia.
3. Ações Coerentes: Passos coordenados
O terceiro elemento é um conjunto de ações coordenadas que implementam a política orientadora. Não uma lista de desejos. Não 47 iniciativas. Um conjunto focado de movimentos que se reforçam mutuamente.
Para o nosso problema de deployment: (1) introduzir feature flags para desacoplar o deployment do lançamento, (2) configurar CI com suites de testes automatizados para os dois serviços de maior tráfego, (3) mudar para desenvolvimento trunk-based. Estes três movimentos são coerentes — cada um apoia os outros, e juntos abordam o problema diagnosticado.
A coerência é o que separa a estratégia de uma lista de tarefas. Uma lista de projetos de melhoria não relacionados não é uma estratégia. Um conjunto de ações mutuamente reforçantes dirigidas a um desafio específico é.
A Má Estratégia Está Por Todo o Lado
A taxonomia da má estratégia de Rumelt atingiu-me como um comboio de mercadorias porque reconheci cada padrão em empresas com que trabalhei:
A retórica vazia. Linguagem inflada que não diz nada. "Vamos alavancar as nossas capacidades de plataforma sinérgicas para desbloquear valor em todo o ecossistema." Tira o jargão e não fica nada por baixo.
Confundir objetivos com estratégia. "A nossa estratégia é ser o líder de mercado em ferramentas para programadores." Isso é um objetivo, não uma estratégia. Onde está o diagnóstico? Onde está a política orientadora?
Não fazer escolhas. O padrão mais prejudicial. Uma empresa que lista 12 "prioridades estratégicas" tem zero prioridades estratégicas. Estratégia significa decidir o que NÃO farás. Se a tua equipa de engenharia está simultaneamente a reescrever o backend, a construir três funcionalidades, a migrar para uma nova cloud e a reduzir a dívida técnica em 40%, tens uma fantasia, não uma estratégia.
Ignorar o desafio. Saltar diretamente para objetivos e ações sem identificar o que é realmente difícil. O resultado são playbooks genéricos que não abordam as restrições específicas.
Por que a Maioria dos OKRs Não São Estratégia
É aqui que o framework de Rumelt realmente dói no mundo tech. Os OKRs — Objetivos e Resultados-Chave — são excelentes ferramentas de execução. Mas não são estratégia, e tratá-los como tal é um dos erros mais comuns que vejo.
Um OKR como "Aumentar a fiabilidade da plataforma para 99,95% de uptime" é um objetivo com um resultado mensurável. Diz-te como é o sucesso. Não te diz:
- Porque é que a fiabilidade é o desafio mais importante agora (diagnóstico)
- Que abordagem adotarás para a melhorar (política orientadora)
- Que ações específicas e coordenadas executarás (ações coerentes)
Os OKRs estão a jusante da estratégia. Operacionalizam-na. Mas se defines OKRs sem estratégia, acabas com uma coleção de objetivos mensuráveis que não se conectam entre si e não abordam o teu desafio central. Cada equipa atinge os seus OKRs e a empresa ainda não avança, porque ninguém fez a pergunta difícil: "Qual é o problema mais importante que precisamos de resolver, e o que vamos fazer a esse respeito?"
Aplicar Rumelt às Decisões de Engenharia
É aqui que o livro se torna intensamente prático para qualquer pessoa que lidere engenharia:
Decisões de arquitetura. Devo reescrever ou refatorizar? O framework de Rumelt obriga-te a começar pelo diagnóstico. Qual é o problema real? Se é "o monólito é lento a fazer deploy", a política orientadora pode ser extrair os módulos de maior rotação em serviços — não uma reescrita completa. As ações coerentes seguem: identificar os 3 módulos principais por frequência de mudança, definir fronteiras de serviço, implementar uma extração como prova de conceito.
Build vs. buy. "Construímos tudo internamente" não é uma estratégia — é um padrão por defeito. Um bom diagnóstico: "Gastamos 30% do tempo de engenharia a manter infraestrutura de base." Política orientadora: "Comprar serviços geridos para os não diferenciadores; construir apenas onde temos vantagem única." Agora cada decisão futura tem um filtro.
Scaling da equipa. "Contratar 20 engenheiros" é um objetivo. A versão estratégica: "A velocidade de entrega reduziu-se a metade porque duas equipas se sobrepõem numa codebase partilhada." Política orientadora: "Estabelecer propriedade de domínio antes de aumentar o headcount." Ações coerentes: definir contextos delimitados, dividir a codebase, criar APIs de equipa, depois contratar para a nova estrutura.
A Parte Difícil: Fazer Escolhas
A verdade mais desconfortável neste livro é que a boa estratégia exige dizer não. Não "agora não". Não.
Se és uma startup com 8 engenheiros e estás a tentar construir simultaneamente uma app móvel, uma app web, uma plataforma API e uma funcionalidade de IA, não tens uma estratégia. Tens FOMO. Rumelt dir-te-ia para diagnosticares a tua vantagem competitiva real, escolheres a única coisa que mais importa e executá-la com coerência.
Isso significa dizer a alguém — um co-fundador, um membro do conselho, um cliente — que não vais fazer o que quer. É por isso que a má estratégia é muito mais comum que a boa. A má estratégia permite-te evitar o conflito. A boa estratégia exige-o.
Na Conectia, vemos este padrão constantemente com as startups com que trabalhamos. Os fundadores vêm ter connosco a precisar de engenheiros, mas a conversa real muitas vezes começa com "o que devíamos construir primeiro?" Quando integramos engenheiros sénior numa equipa, não escrevem apenas código — fazem as perguntas de diagnóstico que afiam a estratégia. Qual é o verdadeiro gargalo? O que devíamos parar de fazer? Onde adicionar capacidade resolve o problema em vez de apenas tornar o caos mais rápido?
É isso que os engenheiros experientes trazem: não apenas execução, mas julgamento sobre o que executar.
A construir a tua equipa de engenharia e queres pessoas que pensem estrategicamente, não apenas que escrevam código? Fala com um CTO — integramos engenheiros sénior LATAM que fazem as perguntas certas antes de escrever a primeira linha.
