Building compensation ranges your managers actually trust

A range only works if the people using it believe it. Here is what erodes that belief, and how to build structure that survives contact with hiring.

Every compensation team has had the conversation. A manager looks at the band for a role they are hiring, says some version of "that is not what the market is paying," and asks for an exception before the first candidate has even been screened. The band is defensible. The survey data behind it is sound. And it is not being used.

A range that managers work around is worse than no range at all, because it creates the appearance of structure while every real decision happens outside it. Getting to ranges people actually use is less a data problem than a credibility problem.

Why managers stop trusting bands

• The band was set once and never revisited, so it visibly lags what candidates are asking for.
• The band is too wide. A range spanning 40% tells a manager nothing about where a specific person should land, so they fall back on instinct.
• The band was built from a market cut that does not match how the company actually hires — wrong geography, wrong company size, wrong industry mix.
• Exceptions are granted quietly. Once a manager learns that the band is negotiable if you push, the band becomes an opening position.

The last point deserves emphasis. Exceptions are not inherently bad — a structure with zero exceptions is usually a structure that is quietly being ignored. What destroys trust is exceptions that are invisible. If one manager gets a placement above the band and their peer does not know that happened or why, the peer concludes the rule is arbitrary.

Design choices that hold up

A few structural decisions consistently make ranges more usable for the people who have to apply them.

Narrow the bands and add levels. Wide bands feel flexible but push all the judgement onto the manager. A tighter band with a clearly defined level above it converts a vague "how much?" question into a specific "which level?" question, which is a far easier conversation to have with evidence.

Define what each zone of the band means. If a placement in the lower third signals someone still developing into the scope, and the upper third signals someone consistently operating above it, then range placement becomes a statement about the person rather than a negotiation outcome. Write that definition down and use the same words every time.

Match the market cut to your hiring reality. A national average is unhelpful if you compete for the same five candidates as three specific companies. Be explicit about the peer set you benchmark against and revisit it when your hiring actually changes.

A band that cannot survive a hard hire is not a band. It is a suggestion with a decimal point.

Refresh cadence and the drift problem

Bands drift in two directions at once. The market moves, and your population moves within the band. A structure refreshed annually can still be functionally broken by month eight if hiring volume in one function pushed everyone toward the top of the range.

The practical answer for a lean team is not more frequent full refreshes — those are expensive — but continuous monitoring of a few indicators: average compa-ratio by function, the share of new hires landing above midpoint, and the rate of exception requests by band. When those move sharply, that band needs attention regardless of where you are in the annual cycle.

Publishing the reasoning, not just the numbers

When you roll out a structure, the instinct is to distribute the ranges. The higher-leverage move is to distribute the reasoning: which survey sources you used, which peer group, how levels map to scope, what each zone of the band means, and how exceptions get requested and decided.

Managers who understand how the number was constructed argue with it far less than managers who received a spreadsheet. And when they do argue, they argue on the right terms — "I think this role is actually a level higher because of scope" is a productive conversation. "That number is too low" is not.

Handling the exception well

Exceptions should be possible, documented, and consistent. Possible, because a structure with no give will be routed around. Documented, because an undocumented exception becomes an invisible precedent. Consistent, because the real test of a structure is whether two similar requests from two different managers get the same answer.

That last requirement is where most teams struggle, and it is not a discipline problem. It is a memory problem. Without a record of what was decided in comparable cases and why, consistency depends on whoever happens to be reviewing the request remembering the last one. Keep the record, and consistency stops being a matter of recall.