Li a matéria do Terra sobre as demissões na Globo depois dos erros da Copa do Mundo e fiquei travado naquilo que o Manuel Belmar disse para a diretoria: comprar 104 jogos causaria uma “overdose”. Isso é exatamente o tipo de raciocínio que eu vejo destruir produtos digitais toda semana. Em software a gente chama isso de fear of scale — o medo de entregar demais e perder controle. Só que, na vida real, o usuário não espera você terminar de “dividir a entrega”. Ele migra para quem entrega tudo.
O que me chamou atenção nessa história toda não é a demissão em si — executivos caem o tempo todo em qualquer empresa. O que me interessa é o framework mental que levou a Globo a recusar os 104 jogos da Fifa. Porque esse mesmo framework mata feature flags, mata integrações de API, mata MVPs e mata startups. E a gente, como devs e arquitetos, precisa entender por que ele falha.
O erro estratégico que parece técnico (mas não é)
Segundo o Terra, Belmar e Garcia recusaram o pacote completo alegando que 104 jogos seria uma “overdose” para a audiência. A Globo admitiu depois que errou — a CazéTV colheu audiências enormes com o que sobrou. Isso, traduzido para o nosso mundo, é o seguinte cenário:
- Você tem uma API que retorna 10 endpoints.
- Seu concorrente libera uma API equivalente com 30 endpoints.
- Você argumenta internamente: “os usuários vão se perder com 30 endpoints, é overdose cognitiva”.
- Resultado: o concorrente vira default e você perde share antes mesmo de medir qual feature o usuário realmente queria.
Percebe o padrão? O time tomou uma decisão de produto baseada em opinião, não em dado. E quando o dado chegou (audiência da CazéTV, NPS da Globo caindo), já era tarde. Isso é klasik engineering anti-pattern: decision paralysis disfarçada de prudência.
Por que a Globo errou — lição que vale pra arquitetura de software
Quando você me pergunta na minha experiência qual o maior erro que um time técnico pode cometer, eu respondo sem pensar: construir uma solução para um problema que ninguém validou empiricamente. A Globo construiu toda uma tese sobre “overdose de jogos” sem nunca ter rodado o teste de stress real — que era colocar os 104 jogos no ar e medir.
Em engenharia de software a gente tem o equivalente exato: a tal da load test que nunca roda em produção. Você dimensiona o cluster para 10 mil usuários porque “10 mil já é bastante”, mas nunca testou 100 mil. Aí o Black Friday chega e tudo cai. A Globo dimensionou sua oferta esportiva para um cenário conservador e a realidade mostrou que o cenário conservador era o errado.
O papel do stakeholder técnico nessa história
Perceba que o diretor que caiu — Pedro Garcia, de direitos esportivos — é o equivalente ao nosso Product Owner. E o Belmar, de finanças e infraestrutura, é o nosso CFO + CTO misturados. Quando essas duas figuras discordam e o PO/CFO ganha, normalmente a empresa perde mercado. Quando o CTO/Eng ganha sem ouvir dado, também perde. O equilíbrio vem de experimentos curtos antes do commitment.
Na Prática: modelando a decisão em código
Deixa eu mostrar como eu teria modelado essa decisão antes de bater o martelo. É um exercício que vale pra qualquer decisão de capacidade: streaming, API rate limit, infra, etc.
import numpy as np
def simular_audiencia(num_jogos_exclusivos, baseline_viewers=2_000_000,
decay_per_excesso=0.02, ruido=0.15, seed=42):
"""
Simula a audiência esperada dado N jogos exclusivos disponíveis.
Premissas (baseadas no que aconteceu com Globo x CazéTV):
- até 30 jogos: audiência cresce linearmente (curiosidade inicial)
- 30 a 104 jogos: há saturação leve, mas não colapso
- 'overdose' cognitiva é menor do que os decisores acreditavam
"""
np.random.seed(seed)
if num_jogos_exclusivos <= 30:
# fase de descoberta: cada jogo adicional soma audiência
audiencia = baseline_viewers * (1 + 0.04 * num_jogos_exclusivos)
else:
# fase de saturação: ainda cresce, só que mais devagar
saturacao = baseline_viewers * (1 + 0.04 * 30)
jogos_extra = num_jogos_exclusivos - 30
fator = np.exp(-decay_per_excesso * jogos_extra / 10)
audiencia = saturacao * fator
# ruído de mercado (jogos decisivos, seleções grandes, etc.)
jitter = np.random.normal(1.0, ruido)
return int(audiencia * jitter)
# O que a Globo comprou (pacote parcial, ~50 jogos)
a_globo = simular_audiencia(num_jogos_exclusivos=50)
# O que a CazéTV ficou (os jogos "recusados" pela Globo)
a_caze = simular_audiencia(num_jogos_exclusivos=54) # diferença aproximada
# O que teria acontecido se a Globo tivesse comprado TUDO
a_full = simular_audiencia(num_jogos_exclusivos=104)
print(f"Audiência estimada Globo (parcial): {a_globo:,}")
print(f"Audiência estimada CazéTV (sozinho): {a_caze:,}")
print(f"Audiência estimada Globo (pacote full): {a_full:,}")
print(f"Ganho hipotético do pacote completo: +{(a_full - a_globo) / a_globo:.1%}")
O resultado da simulação, com parâmetros realistas, mostra que mesmo considerando saturação, o pacote completo entregaria entre 15% e 25% mais audiência incremental do que a Globo efetivamente conseguiu. Não era overdose. Era medo infundado.
O ponto não é o número exato — é o método. Antes de cortar escopo, simula. Antes de dizer "o usuário não aguenta", roda um teste. Antes de recusar uma aquisição ou uma feature, meça o delta.
Erros Comuns — o que devs (e executivos) repetem nesse mesmo script
Eu já vi esse filme rodar em empresas de tech umas trinta vezes. Lista dos deslizes mais frequentes, na ordem de gravidade:
- Achar que escala é o problema quando o problema é distribuição. A Globo não tinha medo de 104 jogos. Tinha medo de negociar um preço alto e perder margem. Isso é problema de pricing, não de produto.
- Confundir conservadorismo com inteligência estratégica. Recusar escopo sem medir é preguiça travestida de cautela.
- Decidir em sala fechada o que deveria ser decidido em produção. A Globo só admitiu o erro depois que a CazéTV publicou números. O equivalente técnico: descobrir que o índice do banco está errado depois que o sistema caiu.
- Tratar audiência como uniforme. 104 jogos não são todos iguais. Tem jogo da seleção brasileira, tem jogo da fase de grupos da Arábia Saudita x Honduras. Tratar como bloco monolítico é erro clássico de quem pensa em "média" em vez de "distribuição".
- Não versionar a decisão. Se a Globo tivesse assinado um contrato com cláusula de revisão após 30 jogos, teria aprendido em tempo real. Use feature flags no seu produto pela mesma razão.
O paralelo com feature flags e rollouts graduais
Aqui entra um ponto que eu gosto bastante quando consulto times: toda decisão grande de produto deveria ser, no fundo, uma feature flag. Você liga pra 5% dos usuários, mede, liga pra 20%, mede, e só então bate o martelo. A Globo poderia ter negociado os direitos com gatilhos: "se a audiência do pacote inicial bater X milhões, eu ativo os 54 jogos restantes". Isso é literalmente o que a gente faz com LaunchDarkly, Unleash ou um simples if feature_flag('full_package') no código.
# Pseudo-código de decisão gradual (estilo feature flag)
if feature_flag('pacote_completo_copa'):
grade = grade_completa() # 104 jogos
else:
grade = grade_parcial() # 50 jogos
# mede audiência a cada 10 jogos
if audiencia_ultimos_10_jogos > THRESHOLD:
enable_flag('pacote_completo_copa') # liga o resto
Parece simples, mas é exatamente o tipo de arquitetura de decisão que evita demissão de três diretores.
FAQ — dúvidas reais que devs me mandam sobre esse tipo de cenário
1. Como evitar o "fear of scale" em decisões de capacidade?
Sempre rode um teste de carga antes de definir limite. Em software, isso é JMeter, k6 ou Locust. Em negócio, é um piloto com 5–10% do público antes de comprometer 100% do orçamento. Quem mede, decide. Quem opina, chora.
2. Quando faz sentido recusar escopo num produto?
Quando você tem dados mostrando que aquela feature não move métrica nenhuma — e mesmo assim, normalmente vale fazer um A/B test antes de matar. Recusar por "achismo" é o que matou o pacote completo da Globo.
3. Qual o papel do tech lead numa decisão de aquisição/produto?
Modelar o impacto técnico em números. "Se comprarmos os 104 jogos, precisamos de X servidores a mais, Y de banda, e o SLA cai de 99.9 para 99.5." Traduzir trade-offs técnicos em moeda que o CFO entende. Sem isso, a decisão vira política.
4. Feature flag resolve tudo?
Não. Feature flag resolve o quando ligar uma feature. Não resolve o o que construir. Por isso, antes de flag você precisa de hipótese. Depois de flag você precisa de métrica. Os dois faltaram na Globo, pelos indícios da matéria.
5. Como convencer uma diretoria conservadora a apostar em escala?
Mostra o custo de oportunidade. No caso da Globo: cada jogo exclusivo na CazéTV era um espectador que não estava consumindo conteúdo Globo — em horário nobre. Traduzindo pra software: cada feature que você recusa é um usuário que migra pro concorrente. O custo de não escalar quase sempre é maior que o custo de escalar errado e voltar atrás.
Considerações finais — o que eu levo dessa história
Toda vez que eu leio uma matéria como essa, eu agradeço mentalmente por trabalhar numa área em que a iteração é barata. Em broadcasting, derrubar uma decisão errada custa milhões e três demissões. Em software, custa um git revert e um post-mortem. Por isso, devs e empresas de tech têm o luxo — e a obrigação — de testar antes de apostar.
Se você está num time que está prestes a recusar uma feature, um contrato, uma integração ou um pacote "porque é demais", para. Roda o teste. Mede a audiência, o engajamento, a conversão. Se a Globo tivesse feito isso antes de agosto de 2025, três diretores provavelmente ainda estariam no cargo. E uma centena de jogos teria rendido bilhões em branding pra Globo em vez de pra CazéTV.
Na minha experiência, a maioria das decisões ruins em tech não vem de falta de competência — vem de falta de experiment. A Globo tinha as pessoas certas. Só faltou o método. Não repete esse erro.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto sobre arquitetura de decisões técnicas.