Skills-based comp: promise and skepticism

We announced a new product today: Compa Skills, a new way to build custom jobs for hard-to-match roles and benchmark with greater precision.

But some of you have heard me say (many times) that skills has been five years away for 20 years — a hype-y trend rife with land mines to game the system when applied to comp.

So why are we investing in skills?

Because I believe three things have fundamentally changed what’s possible with skills:

1. New source of data
2. Job architecture rethink
3. New ontology technology

And as a result, two incredibly simple and pragmatic compensation use cases have emerged:

1. Custom job matching
2. Skills benchmarking

‍

New source of data: offers

Compa launched offers-based market data in 2023, the first-ever source of compensation market data based on job offers (instead of people) that quickly emerged as the industry leader, transforming compensation intelligence and inspiring imitation.

Offers are compelling because (a) they describe market change, and (b) they add new data sources for better matching. I’ve written about why offers matter many times — when leveled and matched in aggregate, they reflect trend data, providing insight into volatile markets and hot jobs, like the 2022 tech collapse and the 2023-2024 rise of AI engineering.

Offers also add new data sources for better matching, and this is where skills come in.

Surveys, as a form factor, cannot credibly characterize emerging job trends like AI Engineering because most companies do not update their job architectures quickly enough, or ever; the trend is hidden. Offers reveal hot jobs through job posting titles and descriptions associated with the final offer, leveled and matched.

This rich additional data about the job contains another hidden gem: skills.

Using the job description sourced from participating companies in Compa’s network (not scraped from the internet), we can associate skill information with final offer data. Critically, the skills get associated with level information from our customers’ job architectures.

The job description is an awesome source of skills data because it’s:

1. Fresh — usually updated before posting a req
2. Shopped against the market — talent is hired against the skills criteria
3. Automatic — nobody has to fill anything new out
4. Descriptive — you can tell how strong the skill has to be
5. Validated — the data is sourced from the company, not individuals

For example, take a look at this job description from AMD, a large semiconductor company:

We can see very specific skills like CPU design, trace analysis, RTL, and microarchitecture development.

Compa has built technology for compensation it calls SkillGuard, leveraging a powerful skills technology called Textkernel to normalize skills and reduce errors for the compensation use case.

‍

Job architecture rethink

Here’s the classic problem: you want your data vendor to provide more specific job matches. A group of companies finally gets them to cave, and they release a more specific job. What happens?

Nothing.

Nobody wants to use the new job because they don’t know if other companies will use it too, and they don’t want to change for fear of not getting the data they need. So the new job languishes for years.

The problem with traditional job matching is we’re forced to play a coordination game:

Each one of your jobs can only match to one survey job.

This makes precision possible only when companies get precise in the same way; but they often don’t. In fact it’s the opposite; greater specificity leads to greater diffusion of how we define work.

Skills resolves this tension because matching is one to many. Every job I have has many skills; I don’t need to change my job match to look across an overlapping set of jobs and isolate one skill.

While this seems good, why hasn’t it worked so far?

I believe consultants have thought about this the wrong way. Skills are not an extension of your job architecture; they are on an entirely different axis.

When we attempt to curate and assign a basket of skills against each job, it is (a) outdated instantly, and (b) as much a function of the curator’s bias and ignorance as it is what we imagine the real skills are.

I mean really… do you trust a comp person to understand what microarchitecture development is? I have no clue. How could they possibly know?

Instead, I envision skills as bottoms-up, market-defined. The skills assigned to any one job reflect whatever is happening in the market, not what a consultant says.

In this way, skills behave as a relief valve for job architecture.

Where job architectures reflect policy, skills reflect actuals. This allows skills to float with the market as an alternative lens through which to understand pay, not a double-click of a job family, resulting in potential for better matching that actually works.

‍

Ontology technology

Finally, skills technology has matured to a point where the compensation use case becomes possible.

Anybody who has dug into skills realizes how complex it really is. To make skills useful, you have to classify and define them, and continue doing so until you’ve more or less invented a language. That’s why people describe them as skills ontologies, not libraries.

An entire industry of companies are developing skills ontologies to address many use cases beyond compensation.

Compa is a compensation intelligence company, not a skills company. It is only possible for us to build something by standing on the shoulders of skills ontology giants.

Our expectation is that Compa can build on top of its foundational skills partner, Textkernel, by having customers bring their own ontologies. So if your HR team is using a skills ontology to manage an internal labor marketplace, you can examine the compensation market using the exact same language.

This frees compensation from the burden of building and maintaining an ontology at scale.

‍

So, what do comp people do with skills?

You might think if you embrace a skills-based compensation strategy you’ll have employees take a week-long online course and then come back demanding a $10k salary increase.

Yeah, don’t do that.

We have discovered, through collaboration with some of the most extraordinary compensation teams in the entire world, two simple use cases: custom job matching and skills benchmarking.

‍

Custom job matching

When I was in consulting I was a data analyst — I should have called myself a data scientist, I would have made a lot more money!

Do you pay more for product managers than you do project managers? Guess what your employees are doing — moving people who are definitely project managers into product manager job families to justify a pay bump.

Custom job matching solves these problems.

Using skills, you can define an exact “job” match based on a cluster of skills. The problem is, everyone defines their jobs a little bit differently. When you match to a job, you necessarily degrade specificity. Maybe your DevOps Engineer needs to know Azure, but the majority of jobs only need to know AWS.

This becomes a powerful tool to understand how your job matching compares to what you’re really trying to pay for in the market.

Similarly, you can look at your own job architecture and see how what you define as a job compares to the market. Perhaps you’ve developed a Data Scientist job family, complete with a premium, that is much closer to what the market defines as a Data Analyst, resulting in overpaying for lower-value skills.

‍

Skills benchmarking

This one is simple to understand, but very exciting.

What is an AI Engineer? That could range from someone developing self-driving technology, to building LLMs, to training LLMs, to using LLMs, to coding a chatbot. And yes, there is a big price difference in the market for these skills.

Skills benchmarking enables you to see through vague job matches to understand what’s really going on.

You can compare skills (or groups of skills) to each other, or to jobs. You can compare differences in price by pay elements like base salary and stock compensation, but also offer volumes, acceptance rates, and locations.

While some comp teams might use skills benchmarking to refactor salary ranges, others might use it to assess retention risk, guide recruiters to higher in the range, or even set location strategy.

‍

Where this goes next

Today’s launch of Compa Skills represents a powerful new toolset for enterprise compensation teams to compete in volatile markets.

And we have an exciting roadmap of feature enhancements — more skills clusters, more ontologies, and more use cases for comp.

Skills is on the frontier, and the frontier is a dangerous place. While I have long been skeptical of how skills can be used in comp, I see tangible, pragmatic use cases taking shape. Now is the time to begin experimenting.

And we’re excited to lead the way.