Complexity-weighted output
Objective. Define complexity-weighted output as work counted by difficulty rather than by raw volume, and use it to make fair comparisons.
Complexity-weighted output is the fix for the oldest unfairness in work measurement - counting every item as equal. It lets you compare people, teams and periods doing different mixes of hard and easy work, provided the weights are trusted.
See it in the demo
Definition
Complexity-weighted output is completed work counted with each unit weighted by its difficulty, rather than a flat count of items. A team that handles harder work is credited for that difficulty, so the figure reflects the real weight of what was done, not just how many items passed through.
How it is calculated
At app-logic level: each completed unit is multiplied by a complexity weight for its type or band, and the weighted units are summed. Included: completed units with an assigned complexity. The weighting scheme - how many bands, how weights are set, how items are classified into them - is configurable and is the whole basis of the figure, so confirm with product how complexity is defined and assigned for a given customer. Never present a weighted figure without knowing its weighting scheme.
How to read it and the common misread
Read complexity-weighted output when comparing teams or periods with different work mixes - it is the fairer basis than raw count. The common misread is comparing raw counts as if items were equal, which penalises teams doing harder work and flatters teams doing easy volume. The opposite misread is trusting the weights blindly: if the complexity classification is wrong or gamed, the weighted figure is wrong, so the classification needs the same scrutiny as any standard.
Where it appears
Complexity-weighted views appear in Work Output across transactions, people and teams, benchmarks and quadrants. The complexity scheme and weights are SME-validation-pending; confirm with product.
Interpretation check
Complexity-weighted output credits difficulty, not just volume; it is fairer than a raw count but only as trustworthy as the complexity classification behind it.
Practical task
In transactions, compare one team's raw count with its complexity-weighted output, and write one line on how the comparison with another team changes when you move from raw count to weighted, plus what you would confirm about the weights.
Self-check
Team A completed 100 items, Team B completed 70. Why might B have the higher complexity-weighted output?
If B's work is harder, its units carry higher complexity weights, so fewer items can outweigh more easy items. Raw count would wrongly favour A; complexity weighting corrects for the difficulty of the mix.
What is the risk of trusting complexity-weighted output without checking the weights?
If the complexity classification is wrong or manipulated, the weighted figure is wrong. The weighting scheme needs the same scrutiny as a standard; otherwise it just moves the bias rather than removing it.
When should you prefer complexity-weighted output over a raw count?
Whenever you are comparing people, teams or periods that handle different mixes of hard and easy work - a raw count there is misleading because it treats unequal work as equal.
Verified vs demo. Complexity-weighted output is shown in the Work Output demo; the complexity scheme, bands and weights are configurable and SME-validation-pending - confirm with product.