Variance

The first thing reached for when several numbers have to be reported as one is the mean — add everything up, divide by the count. It's easy to compute and easy to explain. But carry only a mean into a room and two completely different situations get reported as the same number.

A team whose five tasks finished in 35, 40, 40, 40 and 45 minutes and a team whose five finished in 10, 15, 40, 70 and 65 minutes both average 40 minutes. You can promise "about 40 minutes" for the first team and you cannot write that sentence for the second. The report says 40 either way, so whoever reads it has no way to tell the two apart.

Response times behave the same. Five requests at 0.3, 0.4, 0.3, 6.2 and 0.3 seconds average 1.5 seconds, yet not one request experienced 1.5 seconds and one person waited six. Answer "the average is 1.5 seconds" and you get "it's slow for me every time" back, with neither side saying anything false.

Variance fills that gap. Where the mean says where the middle is, variance says how far the values sit from that middle.

Take the mean, square the distance from the mean for every value, add those up, and divide by the count.

1. Start with the mean. For 35, 40 and 45 the total is 120 across three values, so the mean is 40.
2. Subtract the mean from each value. That difference is the deviation; here it gives -5, 0 and 5.
3. Square the deviations, giving 25, 0 and 25. Squaring is necessary because adding them raw lets values above and below the mean cancel each other. Add -5 and 5 directly and you get zero, which reports no spread in data that is clearly spread out.
4. Add the squares and divide by the count. The total is 50 over three values, so the variance is about 16.7. If the numbers are a sample rather than the whole population, divide by the count minus one instead — looking at part of something tends to understate the spread, and this corrects for that.
5. Check the unit. It comes out squared: minutes squared, seconds squared. That is why the number is hard to read out loud, and why the square root of it, expressed in the original unit, travels alongside it.

Run the two teams through the same steps and the difference becomes concrete. The team at 35, 40, 40, 40, 45 has a variance of 10; the team at 10, 15, 40, 70, 65 has 610. Same mean of 40, spread more than sixty times apart.

There is no benchmark for the absolute value. The squared unit makes the magnitude hard to feel, and the number grows with the scale of whatever is being measured — response times measured in seconds and the same data measured in milliseconds differ by a factor of a million. So it never gets used alone; it gets used in comparisons.

Three comparisons work. Two groups measured on the same metric, side by side. One group tracked over time. And the standard deviation divided by the mean, which normalizes for scale and lets different metrics be compared: deploy time with a standard deviation of 6 minutes against a mean of 22 gives 0.27, and if the same calculation on response time gives 0.9, the second is far less consistent.

Whether smaller is better depends on the purpose. For promising a schedule or describing service quality, smaller wins. For designing an experiment, a large spread is itself an input to the decision. High variance means more people are needed to detect a difference of the same size, and that calculation belongs to statistical power — the probability of catching a real difference. Without knowing the variance you can't fix how many people the test needs, which is why a rough measurement of spread usually precedes the test itself.

One more property worth watching is how easily a single value moves it. Because deviations get squared, one distant value can account for more than everything else combined. Drop the 6.2-second request from those five and the variance falls to nearly zero. So when variance jumps, the first question is whether the whole set loosened or a single outlier arrived.

"Same mean, sixty times the variance. We can't promise a date for this team."

Identical middles can carry completely different predictability.

"Variance is high, so we need twice the sample. The test has to run longer."

Spread feeds directly into experiment design.

"Drop that one value and the variance halves. Check whether it's an error first."

Separating a set that loosened from a single bad record.

Theo once pulled the duration of the last twenty deploys. The mean was 22 minutes, which looked fine, but the fastest was 8 minutes and the slowest 70. The spread was Mia's reason for saying she couldn't commit to deploy dates.

Looking into it, a particular test failed intermittently and got retried twice, which had happened in three of the twenty runs. Removing those three cut the variance to a fifth. Theo fixed the test, and the next twenty runs averaged 19 minutes with a maximum of 24. The mean dropping three minutes mattered less than the maximum falling from 70 to 24 — that is what made a commitment possible.

The most common mistake is reading the variance in the original unit. A figure of 16.7 sounds like 16.7 minutes. But it went through a squaring step, so the unit is squared too. Leave that mistake in place and you report "the spread is about 16.7 minutes" when the actual spread is closer to four, and a schedule built on that number carries four times the buffer it needs. For anything said out loud, use the square root and keep variance as an intermediate number that stays inside the calculation.

Assuming smaller is always better is nearly as common, since spread usually shows up in reports as a problem. But when a metric of user behavior has almost no variance, that can be a sign the measurement is only seeing one part of the population. And starting to remove distant values in order to shrink the variance throws away the most important signal. A payment 300 times the usual size might be a typo or might be a newly signed enterprise contract, so the reason for it has to be established before it comes out.