Median

Work constantly asks people to collapse a pile of numbers into one. How fast is the service, how big is a typical contract — nobody reads out the whole list, so one number stands in for all of them. For a long time that job belonged to the mean. Add everything up, divide by the count, done. Every value gets represented in the result, which sounds like exactly what a summary should do.

The trouble is that a single distant value drags the mean along with it. This happened at Pagedeck. Theo measured five server responses and reported an average of 1.5 seconds. The raw numbers were 0.3, 0.4, 0.3, 6.2 and 0.3 seconds. Four requests finished inside four tenths of a second and one took 6.2. Not one request actually experienced 1.5 seconds, and yet 1.5 seconds is what the report said.

A number like that can't guide a decision. Set a goal of cutting 1.5 seconds down to 0.8 and the team tunes the four requests that were already fine, while nobody asks what made the slow one slow. The median cuts that problem off at the level of arithmetic. Instead of adding values together, it lines them up and picks the one in the middle, so whether the far end reads 6.2 seconds or 60 seconds, the middle seat is occupied by the same number.

Sort the values from smallest to largest and take the one that lands in the middle position.

The procedure has two steps, and the second one splits depending on whether the count is odd or even.

1. Sort the values by size. The original order, including the order they arrived in, gets thrown away. Sorting the five measurements above gives 0.3, 0.3, 0.3, 0.4, 6.2.
2. With an odd count, take the value in the exact middle. With five values that's the third one, so the median here is 0.3 seconds.
3. With an even count, take the two middle values and average them. For six readings of 0.3, 0.3, 0.4, 0.5, 1.1 and 6.2, the third and fourth are 0.4 and 0.5, and the median is 0.45 seconds.

To find which position counts as the middle, add one to the count and halve it. With 999 values, the 500th one is the median.

What deserves attention here is how few numbers actually enter the calculation — one, or two. Change the 6.2 to 60 and the median stays 0.3. Change the smallest reading to 0.01 and it stays 0.3 as well. As long as the ranking holds, how large or small the values are never reaches the result. That is where the resistance to an outlier, a value sitting far away from the rest, comes from.

The same property is also the weakness. A median says nothing about what happens outside the middle. Whether one request in twenty takes 6.2 seconds or nine of them do, the median comes out about the same.

There is no universal threshold for a median. Lower is better for response time, higher is better for documents created per user, so what counts as good is decided by what got measured. What does generalize is how to tell whether the number is being used well, and three checks cover most of it.

The first is to print it next to the mean. When the two land close together, the values are clustered around the middle and either one works as a summary. When they pull apart, the distribution has a long tail on one side. A mean of 1.5 seconds against a median of 0.3 says a small group of slow requests is lifting the average, and the thing worth investigating is that small group, not the summary statistic.

The second is to report spread alongside the middle. On its own, a median can't distinguish a set clustered tightly around it from one split toward both ends. Pairing it with a number that describes spread — a standard deviation, or a couple of percentiles — restores that distinction. For anything users wait on, the 95th percentile matters more than the middle.

The third is how many values went in. Because the median is computed from rank, a small set lets one new entry shove the middle position somewhere else entirely. A median drawn from five readings does not belong in a quarterly target. A sample in the hundreds, drawn so it represents the whole, is what makes the number land in roughly the same place next month.

"Pull that with the median instead of the mean. Two huge contracts are carrying the whole number."

A request to switch to a statistic that a handful of large values can't distort.

"Mean is 1.5 seconds, median is 0.3. So the slowness lives somewhere specific."

Using the gap between the two numbers as a pointer to where the problem sits.

"The median went up, but that isn't automatically good. We may have lost the low end."

A reminder that the middle can move because users left, not because anything improved.

At Pagedeck this number surfaces most often in the performance review Mia and Theo sit in together. Theo posts response time as two lines, mean and median, and Mia looks at the gap before anything else. A wide gap changes the month's work from making everything faster to finding the conditions that produce the slow requests.

The same number shows up in pricing discussions. When Sofia reports contract sizes as an average, one or two large deals push the figure upward, and Grace can't tell from it what a normal incoming contract actually looks like. Adding the median makes the level most deals sit at visible.

The most common mistake is treating the median as the more accurate statistic. After watching a mean get distorted a few times, that conclusion is easy to reach. But the two answer different questions. Where totals matter, the mean is the correct choice. If server costs are billed against aggregate usage, multiplying average usage per user by headcount produces next month's bill; multiplying the median by headcount produces nothing meaningful at all. This is not a choice between a right statistic and a wrong one, it's a choice between the one that fits the question and the one that doesn't.

The second mistake is believing the median deals with outliers. Since extreme values can't move it, the problem looks solved. In reality those values are still there and have merely been hidden from the report. The request that took 6.2 seconds still happens every day, and the person who sent it still waits 6.2 seconds. Report a healthy median and move on, and the cause surfaces months later when churn climbs. Extreme values are something to look at separately, not something to cover.