An Inquiry into the Skills-Based Organization; or, Why Abilities, Skills, Competencies, and Capabilities Are Not the Same Thing, and Why Job Architecture Is Still Your Foundation

At the risk of aging myself, hearing the phrase "Skills-Based Organization" (SBO) has triggered a distinct sense of deja vu. It sounds a lot like the "Competency-Based Matrix" movement that was the new, cool kid on the block twenty years ago.

Don’t be alarmed if you never heard of this movement - it didn’t last, and it wasn’t overly popular. My take is that it was ultimately an interesting academic exercise that simply collapsed under the weight of reality. This methodology rode alongside "broadbanding" (collapsing dozens of pay grades into a few wide bands), which promised ultimate flexibility but ultimately failed because it couldn't connect to actual market pricing and pay consistency.

However, I am cautiously optimistic that this time is different. Jobs are changing faster than ever, making static architectures brittle. More importantly, we finally have the data storage and processing power required to break work down into observable, granular skills at scale and map them accordingly. But before we get carried away, let’s ground ourselves in definitions. "Skills," "competencies," and "capabilities" are frequently tossed around as synonyms, but they aren't the same thing. To see how they interact, we have to look at the anatomy of a job from ability to architecture:

Layer	Definition	Example	Est #	Considerations
Abilities	Enduring, largely innate capacity underlying performance	Numerical reasoning	\~40-60	Hire for these traits; hard to train
Knowledge	A body of facts or principles in a subject area	Accounting rules	\~30-40	Learnable; grounded in continuing education
Skill	A learned ability to perform a task to standard	Build a financial model	\~15k–40k	The explosion in data; very short life
Competency	The measured application of skills + knowledge + behaviors in a role, on a proficiency scale	Financial analysis (Advanced)	\~50–500	Only as good as its observable anchors — the subjectivity trap
Capability	What the organization needs to accomplish through its workforce	Reliable financial forecasting	\~10–40	Strategic workforce planning is a competitive advantage
Job Level	A rung of scope, autonomy & impact	Sr. Analyst (P3)	\~10–15	The leveling scale - how to progress your career
Job Family	A grouping of related roles sharing skills & purpose	Finance	\~20–40	The horizontal axis; defines skill-adjacency & mobility
Job	Intersection of job family and level	Sr Financial Analyst	\~500-5k	What we benchmark
Job Architecture	All families × levels + governance	Full finance matrix	1	The foundation

Why did the last time fail?

With the anatomy in mind, my take on why the competency movement of the 2000s collapsed wasn’t because the theory was wrong. It failed because we were constrained by the tech limits of the era.

Think about the sheer data volume: a modern organization might utilize tens of thousands of granular skills. In the era of static databases and manual Excel spreadsheets, tracking and mapping those for every single employee was an administrative impossibility.

Faced with those technological limitations, organizations had to find a shortcut. Out of sheer necessity, thousands of granular skills were collapsed into a dozen broad, manageable competency buckets - like "Analytical Thinking" or "Strategic Agility" - simply so we could track them on paper.

Because we lacked the processing power to anchor those competencies to real-time skill data, the framework broke in three distinct ways:

• First, it suffered from a complete lack of foundational anchors. Models jumped straight to massive constructs like "Strategic Agility" with absolutely nothing defined in the Ability, Knowledge, or Skill layers beneath them. Because the rating scales weren't tied to observable evidence, "Advanced Strategic Agility" became a vibe rather than a measurement. Every performance review was a subjective judgment call.

• Second, we blurred behavior into technical skill. Personality traits like "integrity" and "drive" were folded into actual capabilities like "communication." This made it impossible to tell whether you were measuring a demonstrable proficiency or just a manager's fondness for an employee's disposition.

• Finally, it tried to replace the job, not just inform it. Using a competency to place an employee within a salary range is fine—we still do it today. The overreach occurred when we tried to price the competencies themselves in place of the job, which lost our market anchor. Broadbanding stretched the pay ranges so wide that internal equity drifted entirely, leading inevitably to salary creep and compression.

The technology changed. But it still can't answer the one question that lands on our desk: what do we pay for a skill? Survey vendors price jobs, not skills - and that hasn't changed at all. That's why the job is still the anchor.

What does today look like?

While we previously lacked the data and the tools to make this work, today we are practically drowning in both. We have real infrastructure and sophisticated software, but we also have a crowded, un-standardized market where every vendor swears their AI will fix your problems.

But before evaluating software, it helps to be precise about what is actually required to become a true skills-based organization. A standalone list of skills isn't enough; you need a multi-layered infrastructure to bridge the gap between data and execution:

Skill Taxonomy: This is your structured, shared vocabulary. It creates a common language so that a skill is named the same way in a job posting, a learning path, and a job description. Without it, you get "database querying" in recruiting and "SQL" in L\&D. Technically these are correct, but they are not connected.

Skill Ontology: If the taxonomy is the dictionary, the ontology is the grammar. It maps the relationships between skills, defining how they cluster together, how proficiency changes by level, and how individual skills scale up into organizational capabilities.

Job Architecture: This is your operating system. A common misconception is that architecture slows things down, but a clear framework of families and levels is exactly what enables an internal talent marketplace. It allows you to dynamically map skills to jobs, and jobs to people. When a new project or an urgent organizational need arises, this structure is what lets leadership instantly see where the right skills live and quickly deploy talent. This also enables L\&D to curate training programs where we have skill gaps.

The taxonomy makes skills comparable, the ontology makes them relational, but the job architecture sets the foundation to make a skills-based organization possible.

Once you know what components you are building, you generally face two distinct paths to acquire the data and engine behind them:

Approach	Examples	Consideration
Proprietary Vendors	Lightcast, Workday Skills Cloud, TechWolf, Visual Workforce	Can be expensive. Integrates w/ HRIS. Black-box. Vendor lock-in
Open-Source	O*NET, ESCO, Open Skills Network (WGU-led)	Completely free Valid, peer reviewed data Cross-industry standardization US maps to SOC code, no full cross-walk w/ ESCO No native platform or HRIS Integration

Who Owns What in a Skills-Based Org?

As an organization transitions toward a relentless focus on skills, establishing clear cross-functional boundaries isn't just nice to have—it's a survival requirement. Because every business function looks at skills through a different lens, we risk pulling the organization apart if we don't coordinate:

• Talent Acquisition sources and hires based on candidate skills to fill immediate gaps.
• Talent Management maintains the competency and capability frameworks — succession, performance, and career pathways.
• Learning & Development owns skill growth—curating the curricula, pathways, and proficiency scales.
• HRIS owns the technology layer, maintaining the system of record and data integrations.
• People Managers deploy those skills day-to-day, driving internal mobility and project assignments.
• Leadership sets the overarching capability strategy and funds the transformation.

Left alone, these functions naturally drift. TA will use one set of terms to hire, L\&D will use another to train, and managers will deploy people based on intuition.

This is exactly where the job architecture comes in. Our role is to own the connective tissue - we map the skills to the jobs, and the jobs to the market benchmark data. We build the infrastructure that ensures a skill is valued, recognized, and compensated consistently across the entire enterprise.

Each function is pulling on the skills data loop from a different end, but the one thing that keeps everyone operating from the exact same sheet of music is the job architecture. TA hires into it. L\&D builds toward it. Managers move people within it. Total Rewards prices from it. It is the single source of truth that keeps organizational agility from turning into organizational chaos.

That is the strategic seat we have been handed. Skills are the currency, but job architecture is the bank. Strategy shapes culture, but job architecture executes it. If our organizations want a skills-based future, we are responsible for building the foundation.