Functional competency frameworks by domain: sales, HR, data and more

What a sales competency framework actually is, how HR, data, and AI frameworks differ, and how to connect them to a structured hiring process.

Three illustrated cards representing Sales, HR, and Data business functions with icons on a blue and white background.

What is a functional competency framework?

Most organisations already have a competency framework - or at least the memory of one. Usually it lives in a shared drive, covers every employee from the receptionist to the chief executive, and describes virtues so universal they could apply to a monk: "communicates effectively", "works well with others", "shows initiative." This is the core competency framework, and it has its place. But it tells you very little about whether a specific candidate can actually do the job you're filling.

A functional competency framework is different. It is a structured set of observable knowledge, skills, and behaviours required for success in a specific function or role family - sales, HR, data analytics, software engineering, and so on. Where core competencies describe the universal layer that all employees share, functional competencies describe what the job actually demands. The difference between core, functional, and leadership competencies is one of scope: core is for everyone, leadership is for people managers, and functional is for people doing a particular kind of work.

In practice, an average of three to five functional competencies are assigned to a given role. More than that becomes unmanageable in an interview; fewer than three tends to leave important signals unmeasured. A competency framework for a sales role might include "qualifying opportunities against clear criteria", "navigating multi-stakeholder relationships", and "adapting messaging to buyer context." Each of these is observable, definable, and assessable in a hiring process.

The research on why this matters is clear. Functional competency development yields the greatest return when aligned to organisational priorities - because that alignment keeps the framework grounded in what the company actually needs to hire for, not what sounds impressive in a slide deck.

The pay-off is straightforward: a functional competency framework is where abstract "hiring strategy" meets a concrete list of things you can ask about in an interview, score consistently, and defend the next morning.

What functional competencies look like in practice: common examples

The quickest way to understand functional competencies is through contrast. Take three roles - a sales manager, an HR business partner, and a data analyst. Each has a hiring process. Each produces a shortlist. And in most organisations, each is assessed using broadly the same general criteria dressed up in role-specific language.

A genuine functional competency looks like this. For sales: "qualifies opportunities against clear criteria before advancing them in the pipeline" or "articulates complex value propositions without jargon to non-technical buyers." For HR: "designs structured selection processes that produce consistent, defensible hiring decisions." For data: "translates statistical outputs into recommendations a non-technical audience can act on." Each of these is observable, anchored in actual job behaviour, and assessable in an interview with a concrete question.

What they are not: personality traits or aspirational attributes. "Charisma" is not a competency. "High energy" is not a competency. "Results-oriented" is so broad it describes everyone who turns up for work. The failure mode that runs through most organisations' hiring processes is precisely this: frameworks that list outcomes ("hits quota"), methodology ("follows the sales process"), and personality proxies ("resilient") alongside actual competencies and call the whole thing a framework. Confusing outcomes with competencies, blending methodology with competency, and weak proficiency levels are the three most common structural errors - and each one undermines the framework's ability to discriminate between a strong and a weak candidate in a hiring process.

The evidence on this point is uncomfortable. McClelland (1998) showed that expert panels - people who know a role well and have strong opinions about what good looks like - agreed with competency data derived from behavioural interviews only 74 % of the time. For the critical performance thresholds that actually distinguished outstanding from typical executives, the agreement dropped to 43 %. The people who should know often have an incomplete picture of what they're actually hiring for.

That gap is what a well-built functional competency framework closes. It replaces informed intuition with observable, job-relevant criteria that a hiring process can be structured around.

Three-column table distinguishing competencies, outcomes, and traits for a sales role with example rows and icons.
Competency, outcome, and trait are not the same thing - but most frameworks treat them as if they are.

The sales competency framework: what the evidence says

Every sales leader believes their top performers have something special. The problem is describing it precisely enough to hire for it reliably. "They just have presence" is not a hiring brief. "They qualify hard and walk away from bad-fit deals without being pushed" is getting closer.

The most rigorous attempt to pin this down commercially came from Corporate Visions, whose Great 8 sales competency framework was derived from analysis of more than 150,000 B2B buying decisions. Rather than listing everything good salespeople do, the researchers correlated behaviours most associated with wins versus losses in B2B buying decisions and built the framework around what actually discriminated. The result was a smaller, sharper set of competencies than most organisations produce when they sit in a room and brainstorm what "great sales" looks like.

One structural insight from that work is worth dwelling on: acquisition and expansion sales require different competencies. The skills that win a new customer - establishing credibility quickly, differentiating from incumbents, creating urgency where none exists - are meaningfully different from those that retain and grow an existing one. A single generic sales competency framework applied to both motions produces a blurred instrument. You end up interviewing an account manager with questions designed for a hunter, or vice versa.

The research on interview validity reinforces why job-relevant competencies matter so much. McDaniel, Whetzel, Schmidt and Maurer (1994), in a meta-analysis of 245 validity coefficients across 86,311 individuals, found that situational and job-relevant structured interview questions outperformed psychologically-based ones. The implication for sales hiring is direct: a structured interview anchored in real deal situations - "tell me about a time you lost a deal you should have won and what you did next" - is more predictive of job performance than one that asks about general communication style or resilience.

McClelland (1998) made the point in starker terms. When a large multinational used Behavioural Event Interview-derived competency selection for executive hiring, turnover fell from 49 % to 6.3 %. The competency framework was not the magic; the structured interview anchored to job-relevant behavioural evidence was. The framework was the specification; the interview was the measurement.

The governance dimension is easy to overlook. Competency frameworks degrade quickly without governance structures - clear ownership, update cycles, and accountability for whether the framework is actually used in hiring decisions. A sales competency framework that was accurate three years ago and hasn't been reviewed since a market shift is not a neutral document; it is quietly pointing hiring managers at the wrong things.

Circular diagram showing a sales competency framework split into acquisition competencies on the left and expansion competencies on the right.
Acquisition and expansion require different competencies - a single generic sales framework misses this split.

Competency frameworks beyond sales: HR, data, and AI

The architecture of a functional competency framework is broadly consistent across domains: observable behaviours, proficiency levels, separation from the generic core. What differs is the content - and, in fast-moving fields, the shelf life.

Take HR. AIHR's T-shaped competency model for HR professionals identifies six core competencies that all HR practitioners share: Business Acumen, Data Literacy, Digital Agility, AI Fluency, People Advocacy, and Execution Excellence. On top of that sits deeper specialist expertise in functional domains - compensation, talent acquisition, organisational design, and so on. The six core HR competencies today's professionals need across data literacy, digital agility, and AI fluency are not optional extras; they are the baseline for a generalist. The T-shape deliberately separates what everyone must have from what specialists develop further. That layering is useful: a competency framework for HR built this way avoids the trap of listing everything HR touches and calling the whole thing a framework.

For data roles, the challenge is proficiency levels. DataCamp's framework organises skills across four domains organising data and AI skills from communicating to working with data: Communicating with Data, Reading with Data, Reasoning with Data, and Working with Data and AI. The insight worth borrowing is that competency at "communicating with data" looks entirely different at awareness level - someone who can read a chart without being misled by it - versus influence level, where someone shapes organisational decisions from a data position. Hiring against "data literacy" without specifying the proficiency level expected is the same problem as hiring against "sales skills" without specifying acquisition versus expansion.

AI is the most contested domain at the moment. The Alan Turing Institute's AI Skills for Business Competency Framework, now at Version 3 (December 2025), structures competencies by persona - AI Professional, AI Leader, and the broader workforce - and then by duty, competency, and specific Knowledge, Skills, and Behaviours. That multi-layer approach is increasingly common in domains where the roles themselves are still being defined. The competency framework for an AI product manager in 2026 will look materially different from the one that seemed adequate in 2023.

Innovation and entrepreneurship sit at the harder end. Competency frameworks exist - Babson College and various EU research programmes have published versions - but they are less standardised than sales or HR, partly because the behaviours that matter depend heavily on organisational context and risk tolerance. A startup founder's competency profile is not the same as a corporate innovation lead's, even if both are nominally "driving innovation."

The common thread across all these domains: a functional competency framework is only as good as the behavioural specificity it achieves. Generic descriptions, however confidently presented, produce generic hiring decisions.

Side-by-side diagram comparing HR T-shaped, Data four-domain, and AI layered competency framework structures with icons and labels.
Same architecture, different content - how HR, data, and AI competency frameworks are structured.

How to build a functional competency framework for a specific role

The starting point is not a spreadsheet or a workshop. It is a question: what do your best performers in this role actually do that your typical performers do not? That comparison - outstanding versus typical, not outstanding versus bad - is where the useful signal lives.

McClelland (1998) showed that expert judgement about what distinguishes top performers agreed with behavioural interview data only 74 % of the time, and correctly identified the critical performance thresholds for just 43 % of the competencies that actually predicted success. The people who should know have a partial picture. That argues for grounding the framework in observed behaviour rather than received opinion about what the role requires.

In practice, a four-step process works well for most organisations that cannot run a full Behavioural Event Interview programme.

First, gather role information from the people doing the job, not just from job descriptions. Gathering role information from job analysis, observation, and interviews with strong performers consistently produces sharper competency definitions than drafting by committee. Ask your top performers what they actually do in the most demanding parts of the job; ask your hiring managers what they see in candidates who fail in the first six months.

Second, define three to five job-relevant competencies, each with observable behavioural anchors at two or three proficiency levels. "Strong negotiation skills" is not a competency. "Adjusts pricing and terms in response to buyer objections while maintaining deal economics" is. Campion, Palmer and Campion (1997) identified question design and standardised scoring as the structural components with the strongest effect on interview validity - and both depend entirely on competencies being specific enough to generate concrete, answerable questions.

Third, validate the framework against your hiring process before you deploy it. Can each competency generate a realistic interview question? Can interviewers score responses consistently without extensive calibration? If the answer to either is no, the competency definition needs tightening.

Fourth - and this is where most frameworks quietly fail - connect it to actual hiring decisions. A functional competency framework that is not reflected in how you write interview questions, score responses, and reach panel decisions is documentation. The test is not whether the framework exists; it is whether the panel is still using it on the third interview of the afternoon when everyone is tired and running late.

Three well-defined, job-relevant competencies with clear behavioural indicators will outperform a twenty-competency framework that nobody can remember by the time the panel convenes. Brevity is a feature, not a shortcut.

Connecting your competency framework to a structured hiring process

A functional competency framework sitting in a document is not a hiring system. The gap between the two is where most organisations lose the value they spent time creating. The framework defines what you are looking for; a structured interview is how you actually measure it; standardised scoring is how you make the measurement consistent across interviewers and across time. All three need to work together, or the framework is decorative.

Campion, Palmer and Campion (1997) reviewed 80 years of interview research and found corrected validities for structured interviews ranging from .35 to .62, compared with .14 to .33 for unstructured ones. The mechanism driving that difference is precisely what a functional competency framework provides - job-relevance and standardisation. The interview is structured around real role demands, and everyone on the panel is scoring against the same criteria. Remove either ingredient and validity drops.

McDaniel, Whetzel, Schmidt and Maurer (1994) confirmed the same finding from a different angle: the content of the interview, specifically whether it maps to actual job demands, was a stronger predictor of validity than format alone. A well-designed functional competency framework is, in effect, the specification for that content.

The practical challenge for most small businesses and scale-ups is not understanding this - most hiring leaders understand it in principle. The challenge is installing it as a repeatable system that survives leadership changes, team growth, and the general entropy of a fast-moving organisation.

That is the problem the Structured Hiring Method from HireSchool is built to solve. It is a self-guided digital programme - video content plus a learning management system - that helps businesses build exactly this kind of end-to-end structured hiring infrastructure, without hiring consultants to run the transformation for them.

The programme includes Leadership Values: a structured process for defining the core and functional competencies the organisation hires against, rather than borrowing generic lists from the internet and hoping for the best. It includes behavioural interviewing training, so the people running interviews know how to turn a competency definition into a probe, follow up on vague answers, and score responses consistently. It includes codified scoring and Decision Management, so the panel reaches a decision based on evidence rather than whoever spoke last in the debrief.

For a company building a sales competency framework, this matters in a specific way. The framework you spent time defining - acquisition versus expansion competencies, three to five job-relevant behaviours per role - needs to generate structured interview questions, a scoring rubric, and a panel decision process that uses both. The Structured Hiring Method provides the infrastructure to do that without rebuilding the wheel for every role. For HR, data, or AI roles, the same infrastructure applies to whatever domain-specific competencies the company defines.

HireSchool is not a recruiter, not an applicant tracking system, and not a consulting engagement. It is a programme your team implements themselves, with access to the method and materials that make the implementation stick.

If you have a functional competency framework that is not yet connected to a structured hiring process - or if you are building one from scratch - explore the Structured Hiring Method programme to see how the components fit together.

Keeping a functional competency framework current

The least glamorous part of building a functional competency framework is also the part that determines whether it actually works two years from now. Frameworks go stale. Roles evolve. The AI skills relevant to a data analyst in 2025 are not the same as they were in 2022. A sales competency framework built for a market that no longer exists is not a neutral document - it is quietly directing hiring panels toward the wrong evidence.

Competency frameworks degrade quickly without ownership and governance structures. Three maintenance principles apply across domains.

First, assign clear ownership. One person or team is responsible for the framework - not "everyone in HR" or "the hiring managers collectively." Shared ownership tends to mean no ownership. The owner sets the review cadence, tracks whether the framework is being used in actual hiring decisions, and decides when a competency definition has drifted far enough from the job to need updating.

Second, set a review cadence and stick to it. Annual is the minimum for stable roles. For fast-moving functions - AI, data, product - a six-month review cycle is more realistic. The trigger for an out-of-cycle review is a material change: a new product motion, a shift in the competitive market, a change in the seniority level being hired. Any of these can invalidate a competency definition that was accurate at the last review.

Third, track usage. A functional competency framework that is updated and then ignored is not better than no framework - it is worse, because it creates the appearance of rigour without the substance. The question to ask at each review is not "is the documentation current?" but "is the panel still using this on the fifth interview of the week?" If the honest answer is no, the framework is either too complex, too abstract, or not connected to the hiring process in a way that makes it easy to apply under pressure.

The governance question is not how to build a great framework. It is how to make sure you still use it - and still trust it - eighteen months after the launch workshop.

Circular maintenance cycle diagram showing Build, Use, Review, and Update stages with a note asking whether the panel still uses the framework.
The governance question is not how to build a great framework - it is how to ensure you still use it eighteen months later.