.png)
This is Post 2 in The Live Layer series. (Read Post 1 here)
The route changed, and so did the road.
What is your Business Process Analyst II actually doing this year? Almost certainly more than the title tells you. In the last post, we looked at how a benchmark can be accurate and yet simultaneously out of date.
Job architecture is the structure that links job titles, grades, and pay bands to the work people actually do. AI is changing that work faster than titles change, so skills are now repricing roles before titles or survey matches catch up.
Most comp teams will track that kind of aging. The other kind of aging, though, is much harder to detect. It doesn't appear in the job title, so most teams never even look for it.
It’s the job itself that’s changing.
The title remained unchanged. The work didn’t.
Take a Business Process Analyst II.
The title's unchanged, the grade's the same, and the survey still maps it to the same job family. On paper, nothing is different. In reality, however, the analyst who used to spend most of their week building process maps and running reports now configures automation, reviews AI output, and handles the exceptions it creates. The market has started to pay for those skills.
The skills came first, the pay came next, the title (which your job architecture is predicated on) came last.
Skills reprice the role before the title does
Compensation has oscillated between titles and skills over the decades. In the 1940s, one early job evaluation system was based on the job's skills and responsibilities. For decades after that, pay ran on titles. Job codes, grades, and survey matches gave comp teams a stable map, and a title was a fair shorthand for the work because the work changed slowly. That's the architecture most of us still run on. AI is now pulling pay back toward skills, and it's doing so faster than ever.
Skill shifts used to take years to be reflected in the data. Today, they appear on job boards within months and in the pay data shortly thereafter. World Economic Forum (WEF) data shows the half-life of skills in technical roles is about 2.5 years, and that's even shorter in AI and advanced analytics.
Facilities Engineers and Technicians look pretty stable on the surface with very clear pay bands. But as you start seeing data center skills in those job descriptions, the work is changing. An Engineer or Technician with those skills is clearly more valuable in the market, and the role as it was a year ago won’t capture that.
Why this is hard to track
The old playbook was that a job title would reflect the work — this was reliable. But now, the same title can mean entirely different things at different companies, while the gap between the title and the actual skills keeps growing.
When was the last time you checked that a title in your catalog still actually describes the work?
Sara Hillenmeyer, PhD, VP of AI and Data Science at Payscale, puts it this way:
“Roles are being redefined faster than survey job descriptions can be updated. Your own job description may be current, but the survey match describes the typical version of the job. The employers asking for the most, and paying the most for it, are setting a price for the role plus the skill that the survey baseline doesn’t show.”
That’s why skill-level signals matter. Titles describe the middle of the market. Skills show you the edge, where roles are being redefined, and premiums show up first.
What the signals show
A skill premium is the additional pay the market attaches to a specific skill, separate from the role’s base pay. Skill premiums are one of the clearest indicators: If a skill appears more often in job descriptions and those jobs pay more for it, then the market is effectively pricing that skill in isolation from the title.
However, not all premiums are created equal; a skill that fundamentally changes the job requires different pricing mechanisms than one that is simply scarce at the moment.
Premiums like that are easy to miss when you look only at the role as a whole. It’s much easier to spot when you look at the skill directly.
This pattern is most noticeable in a specific role. For instance, take Structural Engineers at level 3, where a Data Centers skill appears in just 2.7% of postings. A role-level benchmark would still look steady, because the title and the core job description remain familiar. The skill data, however, shows a +6.8% pay impact tied to that one capability. Because so few postings ask for it, the premium is easy to overlook in a survey and far easier to spot when you examine the skill on its own.
Some of this is the market moving faster than the calendar, and some of it is the work changing faster than job architectures can keep up. In any case, the signal is in the data — the question is whether your process is designed to see it.
What to do about it
The bit about seeing the shift is the easy bit; it’s getting on with it that's the tougher bit.
As yourself: does the skill change the job, or only its market price? The answer decides which tool fits.
If the skill actually changes what the job is, build it into the job architecture: create a separate job code and pay band for the skill-enhanced role, and benchmark it against the others. If the skill commands a premium only because it's currently in short supply, don't put it in base pay. Manage it as a variable differential, a certification bonus, or a hiring bonus. This kind of supply-driven premium is often called pay for skills, and it keeps your base structure stable while still rewarding scarce capability.
Before you pay any premium, confirm the scarcity in your own labor market rather than acting on one recruiter's request. For signals that aren't yet proven, wait a quarter.
So the real question is whether you make the decision on purpose, with the data in front of you, or by default because the role still looks the way it did last year.
Next up
In the next post, I’ll look at rare but meaningful skill signals, and why small populations can still change the picture.
.png)
