Technical Skills vs Behavioral Competencies: Where Each Belongs in Your Framework

Why One "Technical Skill" Rating Can Mean Two Different Things

Two engineers on the same team both get rated 5 out of 5 on "technical skill" during a calibration cycle. One manager means it because the engineer can configure a Kubernetes cluster from memory and nobody else on the team can. The other manager means it because the engineer rewrote a fragile billing service, the code review came back clean on the first pass, and nothing broke in production for the following quarter. Both managers are describing something real. Neither is describing the same thing.

When the calibration committee tries to compare the two ratings, the conversation stalls. Is "technical skill" about tool mastery, or about judgment demonstrated through the quality of the work? If it's both, how does a 3 differ from a 4, and what evidence would move someone from one to the other? The rubric doesn't answer this, because the rubric was never actually one thing — it was a tool-specific proficiency and a generalizable behavior, bundled into a single label and scored on a scale built for neither.

This is the most common design flaw in homegrown career frameworks, and it's fixable with one distinction applied consistently: technical requirements and behavioral competencies are not two flavors of the same category. They need different formats, different evidence standards, and in most cases different places in the framework entirely. By the end of this article you'll be able to look at any skill on a ladder draft and know, in under a minute, which bucket it belongs in and how to write it there.

Technical vs Behavioral Competencies: The Three-Part Test

Before writing a single level statement, run every candidate skill through three questions.

Is it generalizable, or tied to one tool? A behavioral competency holds its meaning across contexts — "gives timely, specific feedback" means the same thing whether the team uses Jira or Linear. A technical requirement is usually anchored to a specific tool, language, method, or credential — "proficient in Python," "certified in GAAP," "can configure a CI/CD pipeline in GitHub Actions." If the statement stops making sense the moment you swap out the tool name, it's technical.

Can it be demonstrated through a meaningful 1–5 spread, or is it closer to pass/fail? Behavioral competencies have genuine range: a 2 and a 4 on "resolves conflict between peers" look like visibly different behaviors, not just "more" or "less" of a binary. Most technical requirements don't have that kind of range — you either know the tool well enough to do the job, or you don't, and a handful of proficiency tiers (novice, working, expert) covers it without needing five behaviorally distinct evidence-backed levels.

Is it a gate for entering the role, or a lever for growing within it? Technical requirements most often function as a threshold — the minimum bar to be doing the job credibly at all. Behavioral competencies are what the promotion conversation is actually about once that bar is cleared. Confusing the two means a framework either under-specifies the real entry requirements or turns a one-time qualification check into an ongoing scored evaluation that never changes.

A competency is a behavior you can observe and score across situations; a technical skill is a tool-specific capability you either have at the required level or you don't.

If a skill fails all three tests as "generalizable, scaled, growth-oriented," it almost certainly belongs as a technical requirement, not a competency.

Where Technical Requirements Actually Belong

Technical requirements work best as a checklist, not a scale. List what's required to perform the role credibly — specific languages, certifications, tools, methodologies — and treat it as a gate: present or absent, with at most a short proficiency tier (novice / working / expert) rather than a full 1–5 evidence-backed rubric. This keeps the technical bar explicit without forcing a manager to manufacture five behaviorally distinct levels for something that's really a yes/no qualification.

There's a useful structural precedent for this split. The ONET database — sponsored by the U.S. Department of Labor's Employment and Training Administration and licensed under Creative Commons Attribution 4.0, with attribution required rather than public-domain use — separates its content model into distinct categories: Knowledge and Worker Requirements sit apart from cross-functional Skills like Active Listening, Critical Thinking, and Coordination. ONET covers more than 900 occupations with roughly 500 standardized descriptors each, and it doesn't try to score "knows SQL" on the same kind of scale as "communicates effectively with non-technical audiences." That's the same distinction a career framework needs to preserve: tool- and credential-based knowledge in one place, generalizable behavior in another. The O*NET taxonomy itself is a reference library of descriptors, not a ready-made evaluation scale — useful as a starting vocabulary for naming skills, not as a template for scoring them. If you're borrowing from it to seed a framework, our walkthrough of the O*NET competency framework covers how to translate those descriptors into usable level language.

What a Behavioral Competency Looks Like When It's Written Correctly

A well-written competency names an observable behavior, not a trait or a tool, and differentiates levels by what evidence would actually look like at each one. Take "Technical Judgment" as a competency for an engineering track:

• Level 1: Implements assigned tasks correctly with guidance; does not yet weigh tradeoffs independently.
• Level 2: Chooses an appropriate approach for well-scoped problems; explains the choice when asked.
• Level 3: Proactively identifies tradeoffs (performance, maintainability, time-to-ship) and recommends a path without being prompted.
• Level 4: Anticipates second-order consequences of design choices across a system; mentors others through the tradeoff reasoning.
• Level 5: Sets technical direction that other engineers and teams calibrate against; tradeoffs are documented and reused as precedent.

Notice this says nothing about which language or framework the engineer used. It's demonstrable with a Python codebase or a Go one. That's what makes it a competency rather than a disguised technical requirement, and it's why the evidence note attached to a score matters as much as the number — the note is what turns "I gave her a 3" into something a calibration committee can actually evaluate against the next person's 3. Our guide to writing competency statements walks through the sentence-level mechanics of getting this differentiation right.

This distinction isn't academic. In the foundational idiosyncratic rater-effect research, 62% of the variance in performance ratings was attributable to the individual rater's own perceptual tendencies, with actual performance accounting for only 21% (Mount, Scullen & Goff, Journal of Applied Psychology, 2000). Vague, tool-blended competency language gives raters more room to project their own assumptions onto a score — which is part of why only 29% of employees strongly agree their reviews are fair, and only 26% strongly agree they're accurate (Gallup, 2024). Clean separation between gate and scale doesn't eliminate rater variance, but it removes one avoidable source of it.

Building the Split Into a Real Job Family

The split needs to be applied per job family, because the technical gate changes by family while the behavioral core often doesn't. A product manager and a software engineer at the same level might share identical "Stakeholder Communication" and "Ownership" competency language, while their technical requirements look nothing alike — SQL and experimentation literacy for one, a systems-design vocabulary for the other. If you haven't mapped which roles share a ladder and which need their own, our breakdown of job families is the right starting point, and the distinction between a competency model and a full career framework explains how the two layers — shared behaviors and family-specific gates — fit together into one document rather than two disconnected ones. If your organization is also untangling career leveling from formal compensation and reporting-line architecture, the comparison of career framework vs. job architecture is worth reading alongside this one.

A Worked Example: Splitting a Software Engineering Ladder

Here's how the split plays out for an IC2-to-IC3 transition on an engineering ladder.

Technical gate for IC3 (checklist, not scored):

• Proficient in at least one primary language used by the team, verified through code review history.
• Comfortable writing and maintaining automated tests without prompting.
• Can read and reason about the team's deployment pipeline well enough to debug a failed release.

Behavioral competency scored for IC3 (1–5 scale with evidence notes): Using the Technical Judgment ladder above, IC3 is pegged at a target of Level 3. Suppose an engineer's most recent evaluation, backed by two cited examples from the quarter, lands at Level 2. The gap is −1 against the IC3 target. That single number and the evidence behind it become the input to the next development conversation and the corresponding action item — not a renegotiation of whether the engineer "knows the tech stack," which was already settled by the gate, but a specific, bounded conversation about tradeoff reasoning.

This is also where mixing the two categories would have caused the most damage: if "Technical Judgment" had quietly folded in "knows our deployment tooling," the −1 gap would be ambiguous — is it a reasoning gap or a tooling gap? — and the resulting action item would target the wrong thing.

Keeping the Split Consistent as Your Framework Grows

The hardest part of this distinction isn't making it once — it's holding the line as new roles, new managers, and new urgency get added to the framework over time. A manager under pressure to justify a promotion will often reach for whatever language is fastest to write, and "good at the tech stack" is faster than a properly differentiated behavioral statement. Treating the technical/behavioral split as a published rule in your framework documentation, rather than an unwritten convention, is what keeps it from eroding one ladder revision at a time.

If you'd rather start from a set of pre-separated technical gates and behavioral competencies than build the taxonomy from a blank page, the Competency Library Starter Kit provides both categories drafted and ready to adapt across common job families. And if you want the mechanics of competency design — level differentiation, evidence standards, calibration method — delivered as they're published rather than searched for individually, our newsletter covers exactly this kind of framework-building detail on a regular cadence.