Essa é uma escolha de política, não necessariamente errada. Mas ela cria um problema específico de FP&A que quase nenhum guia de implementação de OKRs aborda: quando o atingimento de OKRs vira um multiplicador de remuneração, o modelo do seu pool de bônus passa a ter um problema de distribuição correlacionada, e as provisões trimestrais viram chute no escuro se o modelo não for construído da forma certa.
Por que o Google mantém OKRs e remuneração separados
A mecânica é simples. Se os funcionários sabem que a pontuação de OKR afeta o bônus, eles definem objetivos mais fáceis. Isso está documentado, é previsível e acontece em praticamente toda empresa que vincula os dois. Em uma pesquisa de 2023 da Deloitte sobre gestão de desempenho, 58% dos líderes de RH relataram que o rigor na definição de metas caiu depois que a organização passou a vincular o atingimento de metas diretamente à remuneração variável.
A escala de pontuação do Google vai de 0,0 a 1,0, com 0,6 a 0,7 considerado "bom" (veja nosso detalhamento da metodologia de pontuação do Google re:Work). A lógica dessa calibração é que, se 1,0 é rotineiramente alcançável, os objetivos não eram ambiciosos o suficiente. Vincular à remuneração inverte essa lógica: os funcionários se ancoram em 0,8 porque 0,6 parece arriscado quando afeta o contracheque.
Por isso o Google mantém os dois separados. Isso funciona no Google. A maioria dos times de FP&A não está modelando a estrutura de remuneração do Google.
Como as empresas usam OKRs e remuneração na prática
Na prática, a arquitetura mais comum não é binária (bateu os OKRs = recebe bônus). É uma estrutura de multiplicadores:
- Atingimento de OKRs da empresa ajusta o financiamento global do pool de bônus, tipicamente entre 70% e 130% da meta
- Pontuações de OKRs individuais ou de equipe modulam o pagamento individual dentro desse pool
- Discricionariedade do gestor cobre o gap entre o resultado da fórmula e o número final
A curva de financiamento do pool de bônus em função do atingimento de OKRs costuma seguir uma tabela como esta:
| Atingimento de OKR (empresa) | Financiamento do pool |
|---|---|
| Abaixo de 0,5 | 0% |
| 0,6 | 70% |
| 0,7 | 85% |
| 0,8 | 100% (meta) |
| 0,9 | 115% |
| 1,0 | 130% |
Um pool anual de bônus de R$ 24 milhões financiado a 85% porque a empresa atingiu 0,72 nos seus OKRs resulta em R$ 20,4 milhões para distribuir. Essa diferença vai direto para o P&L, e se a sua provisão trimestral assumiu financiamento pleno, você vai reverter R$ 3,6 milhões no fechamento do quarto trimestre. É um número relevante. Ele aparece no board pack como item de conciliação, e se o time de finanças não modelou o intervalo, parece surpresa.
O desafio de modelagem: distribuições correlacionadas
Aqui está o problema atuarial que a maioria dos modelos ignora. As pontuações de OKR não são independentes do desempenho do negócio. Quando a empresa perde a meta de receita em 12%, os OKRs tendem a vir baixos também - nem sempre, mas com frequência. Isso significa:
- Seu pool de bônus está subfinanciado (variância negativa de receita)
- Seu multiplicador de OKR está abaixo de 1,0 (atingimento ruim)
- Ambos comprimem a provisão ao mesmo tempo
Se o seu modelo trata o financiamento do pool de bônus e os multiplicadores de OKR como entradas independentes, você está subestimando os cenários de queda por uma margem significativa. Uma perda de 10% de receita combinada com atingimento médio de OKR de 0,65 (contra 0,80 assumido) pode comprimir um pool de R$ 24 milhões para R$ 16 milhões - uma variação de 33%.
A arquitetura certa é uma tabela de sensibilidade que move as duas variáveis juntas, não de forma independente.
Construindo o modelo de remuneração no Sheets
Uma implementação razoável usa 5 abas: Assumptions, OKR_Tracker, Headcount, Comp_Model e Bonus_Accrual. Veja como elas se conectam.
A aba Assumptions contém as entradas principais: pool de bônus alvo (R$ 24 milhões), a curva de financiamento de OKR da empresa (a tabela acima, mapeando atingimento para % do pool) e o intervalo do multiplicador individual.
OKR_Tracker é onde chegam as pontuações trimestrais, uma linha por objetivo, com colunas para responsável, departamento, peso trimestral e pontuação. O consolidado por departamento:
// Comp_Model!D4 - média ponderada de OKR do departamento de Engenharia no T3
=SUMPRODUCT(
(OKR_Tracker!$C$2:$C$200="Engenharia")*
(OKR_Tracker!$D$2:$D$200="T3")*
OKR_Tracker!$E$2:$E$200*
OKR_Tracker!$F$2:$F$200
) /
SUMPRODUCT(
(OKR_Tracker!$C$2:$C$200="Engenharia")*
(OKR_Tracker!$D$2:$D$200="T3")*
OKR_Tracker!$E$2:$E$200
)
O cálculo de bônus por funcionário em Comp_Model puxa o salário base do Headcount, o percentual de bônus alvo das Assumptions e o multiplicador de OKR do OKR_Tracker:
// Comp_Model!G4 - provisão de bônus individual, anual
=Headcount!$E4 *
VLOOKUP(Headcount!$D4, Assumptions!$B$14:$C$18, 2, FALSE) *
IFERROR(
VLOOKUP(Headcount!$A4, OKR_Tracker!$A:$G, 7, FALSE),
Assumptions!$C$22 // fallback para média da empresa se pontuação individual estiver ausente
) *
VLOOKUP(Assumptions!$B$4, Assumptions!$F$3:$G$8, 2, TRUE) // multiplicador de financiamento do pool corporativo
O multiplicador de financiamento do pool corporativo usa VLOOKUP com busca por intervalo definida como TRUE porque você quer interpolação entre os limites de atingimento, não correspondências exatas.
Bonus_Accrual consolida tudo por trimestre com os ajustes de tempo adequados:
// Bonus_Accrual!C6 - despesa de bônus do T3, Engenharia
=SUMIFS(
Comp_Model!$G:$G,
Headcount!$C:$C, "Engenharia",
Headcount!$H:$H, "<>" & "Desligado"
) * Assumptions!$D$6 // fração de acréscimo do T3 (ex.: 25%)
O problema da distribuição de pontuações
Aqui está o que a maioria dos modelos ignora, mesmo quando acerta tudo acima: o multiplicador de OKR na fórmula usa uma pontuação média. Mas a distribuição das pontuações importa para o total pago, porque as metas de bônus não são uniformes em toda a empresa.
Se o seu VP de Produto com salário de R$ 1.100.000 tira 0,95 e o seu analista com salário de R$ 420.000 tira 0,60, a pontuação média de OKR entre essas duas pessoas é 0,775. Mas a média ponderada pelo salário, que é o que realmente conduz a despesa com bônus, é:
= (R$ 1.100.000 × 20% × 0,95 + R$ 420.000 × 12% × 0,60) /
(R$ 1.100.000 × 20% + R$ 420.000 × 12%)
= (R$ 209.000 + R$ 30.240) / (R$ 220.000 + R$ 50.400)
= R$ 239.240 / R$ 270.400
= 0,885
Isso não é 0,775. Profissionais de salário alto com pontuações elevadas de OKR têm peso desproporcional na despesa total com remuneração, e um modelo que usa atingimento de média simples vai subestimar as provisões quando seus melhores talentos também são seus melhores em OKRs.
A correção é direta: calcule o multiplicador de OKR como uma média ponderada pelo salário em todo o headcount, não uma média ponderada por número de pessoas. Mas você precisa construir assim desde o início, porque adaptar ponderação salarial em uma fórmula que assumia contagem de cabeças é uma mudança estrutural significativa.
Em junho de 2026, esse é o erro mais comum que vejo em modelos de remuneração vinculados a OKRs. É também o que tem maior probabilidade de gerar uma reversão no fechamento do quarto trimestre.
Atualizando dados de OKR no fechamento do trimestre
O outro problema prático: as pontuações de OKR costumam ser finalizadas 2 a 4 semanas após o fim do trimestre. Os livros do terceiro trimestre fecham em outubro, mas as pontuações finais de OKR podem não chegar até meados de outubro. Isso cria uma defasagem de tempo em que você está lançando uma provisão com base em pontuações preliminares que podem mudar.
Duas abordagens: (1) provisionar com o atingimento médio do trimestre anterior como placeholder e fazer o ajuste no período seguinte, ou (2) construir o modelo para sinalizar quais pontuações de OKR são preliminares ou finais, e calcular um intervalo em vez de um valor pontual.
Se você está puxando pontuações de OKR de uma ferramenta como Asana, Lattice ou um tracker próprio no Sheets, o ModelMonkey consegue buscar esses dados direto no seu modelo de remuneração no fechamento do trimestre, sem exportações manuais de CSV. Escolha um plano do ModelMonkey.
Perguntas frequentes
OKRs devem ser vinculados a bônus?
Depende da maturidade da organização e da cultura de definição de metas. O Google recomenda explicitamente manter os dois separados para preservar a ambição nos objetivos. Na prática, muitas empresas vinculam OKRs à remuneração variável usando estruturas de multiplicadores. O risco central é o conservadorismo nas metas: quando a pontuação afeta o contracheque, equipes tendem a definir objetivos mais fáceis de bater. Se a empresa decidir vincular os dois, o modelo de FP&A precisa tratar o atingimento de OKR e o desempenho de receita como variáveis correlacionadas, não independentes.
Como calcular o multiplicador de OKR no pool de bônus?
O multiplicador é definido por uma curva de financiamento que mapeia o atingimento médio de OKR da empresa para um percentual do pool-alvo. Por exemplo: atingimento de 0,8 libera 100% do pool, 0,6 libera 70% e 1,0 libera 130%. No modelo, isso é implementado com VLOOKUP com busca por intervalo (TRUE) para interpolação entre os pontos da curva. O atingimento deve ser calculado como média ponderada pelo peso de cada objetivo, não como contagem simples de OKRs concluídos.
O que é a média ponderada pelo salário em modelos de OKR e remuneração?
É o cálculo do multiplicador de OKR levando em conta quanto cada pessoa ganha, não apenas quantas pessoas existem. Como executivos sênior têm salário-base e percentual de bônus maiores, uma pontuação alta de OKR deles tem impacto desproporcional na despesa total com bônus. Um modelo que usa média simples de pontuações subestima as provisões quando os colaboradores de maior remuneração também têm os melhores resultados de OKR. A correção é ponderar cada pontuação individual pelo produto de salário-base e percentual de bônus-alvo antes de calcular a média do grupo.
O que fazer quando as pontuações de OKR não estão disponíveis no fechamento do trimestre?
As pontuações finais costumam ser confirmadas 2 a 4 semanas após o encerramento do período. Existem duas abordagens práticas: usar o atingimento médio do trimestre anterior como placeholder na provisão e ajustar no período seguinte, ou construir o modelo com uma flag de status (preliminar ou final) que aciona o cálculo de um intervalo de provisão em vez de um valor pontual. Em ambos os casos, documente o critério adotado para que a revisão do auditor ou do board entenda a diferença entre a provisão lançada e o número final liquidado.