Este es el escenario que lo hace concreto: un pool de bonos anual de $4,800,000 fondeado al 85% porque la empresa alcanzó 0.72 en sus OKRs genera $4,080,000 para distribuir. Si tu acumulación del Q1 al Q3 asumió fondeo completo, llegas al cierre de Q4 con una reversión de $720,000. Ese número aparece como partida de reconciliación en el reporte al directorio, y es una conversación que no quieres tener sin que el modelo la haya anticipado.
Por qué Google separa OKRs y compensación
La documentación oficial de Google re:Work es explícita: "los OKRs no son una herramienta para evaluar el desempeño individual ni para determinar la compensación." La mecánica detrás de esa postura es directa: si los empleados saben que su puntaje OKR determina su bono, establecen objetivos más fáciles. En una encuesta de Deloitte de 2023 sobre gestión del desempeño, el 58% de los líderes de RR.HH. reportó que el rigor en el establecimiento de metas disminuyó después de vincular el cumplimiento de objetivos al pago variable.
La escala de puntajes de Google va de 0.0 a 1.0, con 0.6-0.7 considerado "bueno" (ver nuestro análisis de la metodología de puntajes de Google re:Work). Eso funciona en Google. La mayoría de los equipos de FP&A en empresas medianas no tienen ese lujo: los OKRs y la compensación ya están vinculados, y el problema no es si desvincularlos sino cómo modelar correctamente lo que resulta de tenerlos conectados.
Cómo usan los OKRs en compensación la mayoría de las empresas
La estructura más común no es binaria. Es una arquitectura de tres capas:
- El cumplimiento OKR a nivel empresa ajusta el fondeo del pool general, típicamente entre el 70% y el 130% del objetivo
- Los puntajes OKR individuales o por equipo modulan el pago dentro de ese pool
- La discreción del manager cubre la brecha entre el resultado de la fórmula y el número final
| Cumplimiento OKR empresa | Fondeo del pool | Pool resultante (base $4,800,000) |
|---|---|---|
| 0.60 | 70% | $3,360,000 |
| 0.70 | 85% | $4,080,000 |
| 0.80 | 100% | $4,800,000 |
| 0.90 | 115% | $5,520,000 |
| 1.00 | 130% | $6,240,000 |
El delta entre el escenario base (0.80) y el escenario de cumplimiento bajo (0.70) es $720,000. Si finanzas no modeló ese rango, el número aparece como sorpresa en el cierre del año.
El problema actuarial: las variables están correlacionadas
Aquí está el error que la mayoría de los modelos comete. Los puntajes OKR no son independientes del desempeño financiero. Cuando la empresa falla la meta de ingresos en un 10%, los OKRs también tienden a bajar, no siempre, pero con la frecuencia suficiente para que tratarlos como variables independientes subestime los escenarios negativos por un margen significativo.
El resultado: en los trimestres difíciles, dos compresiones ocurren simultáneamente. El tamaño del pool base se reduce por presión de ingresos y el multiplicador OKR baja por cumplimiento insuficiente. Un modelo que trata ambas variables como independientes pierde ese efecto combinado.
La tabla de sensibilidad correcta mueve las dos variables en paralelo. Esta es la versión funcional, con impacto sobre un pool base de $4,800,000:
Pool de bonos resultante (en $000s)
| Cumpl. OKR | Fondeo OKR | Var. ing. -15% | Var. ing. -10% | Var. ing. -5% | Base (0%) | Var. ing. +5% |
|---|---|---|---|---|---|---|
| 0.90+ | 115% | $4,692 | $4,968 | $5,244 | $5,520 | $5,796 |
| 0.80 | 100% | $4,080 | $4,320 | $4,560 | $4,800 | $5,040 |
| 0.70 | 85% | $3,468 | $3,672 | $3,876 | $4,080 | $4,284 |
| 0.60 | 70% | $2,856 | $3,024 | $3,192 | $3,360 | $3,528 |
La celda crítica no es ningún escenario individual: es la diagonal inferior izquierda, donde ambas variables se mueven negativamente a la vez. Si el negocio tuvo un trimestre difícil, es probable que el cumplimiento OKR también haya sufrido. El escenario de cumplimiento 0.70 con ingresos -10% genera un pool de $3,672,000, una compresión de $1,128,000 o 23.5% respecto al escenario base. Si tu acumulación asumió el escenario base, esa diferencia aparece como reversión en el cierre.
Esta tabla debe integrarse directamente al P&L consolidado: el escenario seleccionado alimenta la línea de compensación variable en el Estado de Resultados proyectado. Sin esa conexión, la sensibilidad del pool de bonos vive en una pestaña aislada y no afecta los escenarios de EBITDA que presenta el CFO.
El error que nadie audita: promedio simple vs. promedio ponderado por masa salarial
Este es el error más frecuente en modelos de compensación vinculados a OKRs, y el que con mayor probabilidad genera una reversión en el cierre del Q4. El modificador OKR en la fórmula usa un puntaje promedio, pero el promedio que importa no es el promedio por número de personas: es el promedio ponderado por masa salarial, porque los targets de bono no son uniformes en toda la organización.
Ejemplo concreto: tu VP de Producto con salario de $220,000 obtiene un puntaje OKR de 0.95 y tu analista con salario de $85,000 obtiene 0.60. El promedio simple entre esas dos personas es 0.775. Pero el promedio ponderado por dólares, que es lo que realmente determina tu gasto en bonos, es:
= ($220,000 × 20% target × 0.95 + $85,000 × 12% target × 0.60) /
($220,000 × 20% + $85,000 × 12%)
= ($41,800 + $6,120) / ($44,000 + $10,200)
= $47,920 / $54,200
= 0.884
Ese resultado no es 0.775. Los empleados con salarios altos y puntajes OKR altos tienen un peso desproporcionado en el gasto total de compensación. Un modelo que usa el promedio simple subestimará las acumulaciones cuando tus mejores performers sean también quienes tienen los salarios más altos, que es la situación más frecuente.
La corrección es directa: calcular el modificador OKR como un promedio ponderado por dólares sobre el headcount, no un promedio por número de personas. Pero hay que construirlo así desde el inicio, porque incorporar esa ponderación a una fórmula que asumía promedios simples es un cambio estructural, no un ajuste menor.
En junio de 2026, este es el error que con mayor probabilidad genera una reversión inexplicable en el cierre del Q4.
Cómo construir el modelo en Google Sheets
Una implementación razonable usa 5 pestañas conectadas: Assumptions, OKR_Tracker, Headcount, Comp_Model y Bonus_Accrual. Esta arquitectura es un punto de partida funcional, no un modelo listo para presentar al directorio: para ese nivel necesitas integrar el pool de bonos al P&L consolidado y conectar los escenarios de la tabla de sensibilidad a tus proyecciones de EBITDA. Pero la estructura base funciona así.
La pestaña Assumptions contiene los inputs clave: pool de bonos objetivo ($4,800,000), la curva de fondeo OKR de la empresa (la tabla que mapea el cumplimiento al % del pool del apartado anterior) y el rango del modificador individual.
OKR_Tracker es donde aterrizan los puntajes trimestrales: una fila por objetivo, con columnas para responsable, departamento, peso trimestral y puntaje. El rollup por departamento:
// Comp_Model!D4 - puntaje OKR promedio ponderado, departamento Ingeniería, Q3
=SUMPRODUCT(
(OKR_Tracker!$C$2:$C$200="Ingeniería")*
(OKR_Tracker!$D$2:$D$200="Q3")*
OKR_Tracker!$E$2:$E$200*
OKR_Tracker!$F$2:$F$200
) /
SUMPRODUCT(
(OKR_Tracker!$C$2:$C$200="Ingeniería")*
(OKR_Tracker!$D$2:$D$200="Q3")*
OKR_Tracker!$E$2:$E$200
)
El cálculo de bono por empleado en Comp_Model toma el salario base de Headcount, el porcentaje de bono objetivo de Assumptions y el modificador OKR de OKR_Tracker:
// Comp_Model!G4 - acumulación de bono 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 al promedio de la empresa si falta puntaje individual
) *
VLOOKUP(Assumptions!$B$4, Assumptions!$F$3:$G$8, 2, TRUE) // modificador de fondeo del pool
El modificador de fondeo del pool usa VLOOKUP con búsqueda por rango (TRUE) para interpolar entre umbrales de cumplimiento, no buscar coincidencias exactas. Bonus_Accrual consolida esto por trimestre:
// Bonus_Accrual!C6 - gasto de bono Q3, Ingeniería
=SUMIFS(
Comp_Model!$G:$G,
Headcount!$C:$C, "Ingeniería",
Headcount!$H:$H, "<>" & "Termed"
) * Assumptions!$D$6 // fracción de acumulación Q3 (ej. 25%)
El timing de puntajes OKR al cierre del trimestre
Los puntajes OKR típicamente se finalizan entre 2 y 4 semanas después del cierre del trimestre. Tus libros del Q3 cierran en octubre, pero los puntajes OKR finales pueden no estar disponibles hasta mediados de ese mes. Eso crea una brecha donde estás registrando una acumulación basada en puntajes preliminares que pueden cambiar.
Dos enfoques posibles: (1) acumular usando el cumplimiento promedio del trimestre anterior como placeholder y ajustar en el período siguiente, o (2) construir el modelo para identificar qué puntajes son preliminares vs. finales, y calcular un rango en lugar de un estimado puntual.
Si estás extrayendo puntajes OKR desde herramientas como Asana, Lattice o un tracker propio en Google Sheets, ModelMonkey puede traer esa información directamente a tu modelo de compensación al cierre de cada trimestre, marcando automáticamente los puntajes como preliminares o finales, sin exportaciones manuales de CSV. Elige un plan de ModelMonkey.
Preguntas frecuentes
¿Es recomendable vincular OKRs a compensación variable? Depende del diseño. El riesgo principal es que los empleados calibren sus objetivos hacia abajo para proteger su bono. Si se usa, la estructura de modificadores (pool a nivel empresa más ajuste individual) reduce ese incentivo más que los esquemas binarios de cumple/no cumple.
¿Qué pasa si los puntajes OKR no están disponibles al cierre del trimestre? La práctica más común es acumular usando el cumplimiento del trimestre anterior como proxy y hacer un ajuste en el período siguiente cuando los puntajes finales estén disponibles. El modelo debe marcar explícitamente cuáles acumulaciones son preliminares para que la auditoría las distinga.
¿Por qué usar promedio ponderado por masa salarial y no por número de empleados? Porque los empleados con salarios más altos tienen targets de bono más altos en términos absolutos, de modo que su puntaje OKR tiene un peso mayor en el gasto total. Un promedio simple ignora esa diferencia y subestima el gasto cuando los empleados mejor pagados son también los de mayor desempeño.
¿Cómo integro el pool de bonos al P&L consolidado?
El escenario seleccionado en la tabla de sensibilidad bidimensional debe alimentar directamente la línea de compensación variable en el Estado de Resultados proyectado. En la práctica, esto implica una referencia desde tu pestaña Bonus_Accrual a la celda correspondiente del P&L. Sin esa conexión, los escenarios de EBITDA no reflejan el impacto real de las variaciones en cumplimiento OKR y el modelo existe en un silo que no informa las decisiones del CFO.
¿Qué herramientas sirven para rastrear OKRs en Google Sheets?
Lattice, Asana Goals y Betterworks tienen APIs que permiten exportar puntajes. También puedes mantener el tracker directamente en Google Sheets con la estructura de OKR_Tracker descrita en este artículo, lo que simplifica la integración con tu modelo de compensación y elimina dependencias externas en el cierre del trimestre.