Competency Frameworks That Actually Work: Building One That Your Managers Will Use

Most organisations that commission a competency framework get exactly what they asked for: a well-formatted document with competency names, proficiency levels, and behavioural indicators neatly arranged by role family. It sits in a shared drive. Managers receive a communication about it. And six months later, the only people who remember it exists are the L&D team who built it and the consultant who billed for it.

This is not a design problem. It is an adoption problem. And solving it requires understanding why competency frameworks fail before committing to how to build one.

Why Most Competency Frameworks Do Not Survive Contact with the Organisation

The failure pattern is consistent enough to be predictable. A framework is designed, validated with a sample of senior leaders, and then deployed organisation-wide through a combination of awareness sessions and job aid documents. Managers are expected to use it in performance conversations, calibration meetings, and development planning. Most do not, at least not in any meaningful way.

The reasons cluster around three root causes.

The language is borrowed rather than lived. Many frameworks are built using competency dictionaries from consulting firms or global benchmarking databases. The competency names sound right. The descriptors are technically accurate. But they do not reflect how managers in that organisation actually talk about performance. When a manager in a mid-sized Indian manufacturing company reads “drives results through strategic orientation and stakeholder influence,” they recognise the words but do not feel the behaviour. They cannot hold it in their hand and compare it to someone they manage.

The framework is too complex to use in a conversation. A framework with twelve competencies, five proficiency levels, and four to six behavioural indicators per level per competency is a useful research document. It is not a useful conversation tool. Managers will not memorise it, carry it into appraisals, or refer to it when writing development plans. Complexity does not signal rigour. It signals that the designers were not thinking about the end user.

There is no consequence or reinforcement for using it. If the performance management system, the talent review process, and the promotion criteria do not reference the framework, managers absorb the correct signal: this is optional. The framework exists in parallel to the real work of people management rather than being embedded within it.

The Characteristics of a Framework That Gets Used

Before designing anything, the question to answer is: what does the framework need to do? Not what should it cover. What does it need to do? If the answer is “inform development conversations between managers and their teams,” the design choices follow from that. If the answer is “support promotion calibration for senior individual contributors,” a different set of choices apply. A framework designed to do everything ends up doing nothing well.

Frameworks that get used in Indian organisations tend to share these characteristics:

They use language that insiders recognise. Behavioural indicators are written in plain, direct language that sounds like something a manager in that organisation would actually say. Not “demonstrates intellectual curiosity through cross-functional inquiry” but “asks questions beyond their own domain to understand how their work connects to the bigger picture.” The second version is longer in words but shorter in mental processing time.

They separate what is core from what is differentiated. Every competency framework should distinguish between the two or three competencies that are non-negotiable for every person at every level from the competencies that are role-specific or level-specific. Conflating them creates an unwieldy list that nobody owns. Separating them gives managers a clear signal: these are the things we hold everyone to, and here is what changes as you grow.

They are anchored to real examples from inside the organisation. The most effective frameworks include brief illustrations of what a competency looks like in practice, drawn from the organisation’s own work. Not fictional scenarios from a case study bank. Real enough that a manager reads it and thinks, “that sounds like what happened when Priya managed the Q3 supplier issue.” This is what makes the framework feel like it belongs to the organisation rather than having been installed from outside.

They have a short version. A one-page summary that a manager can take into a coaching conversation. Not the full framework document with all its definitions and levels, a reference card that surfaces the four to six most important observable behaviours at a given level. This is the version that actually travels.

A Practical Building Process for HR Teams

The following sequence reflects how competency frameworks get built when adoption is the design goal from the start, not an afterthought.

Step 1: Diagnose Before Designing

Before writing a single competency name, invest time in understanding what the framework needs to resolve. Is the organisation struggling to have quality development conversations? Is calibration inconsistent across business units? Are promotion decisions contested? Is there a mismatch between the leaders being developed and the leaders the business actually needs?

The answers shape everything: the scope, the language, the depth, and the process by which the framework is validated. Skipping this step and going directly to framework design is the most common reason organisations end up with a document nobody uses.

Able Ventures’ Organisation Development Consulting work typically begins here, with a diagnostic phase that separates the presenting problem from the underlying need before any framework design begins.

Step 2: Define the Anchoring Principle

Decide what the framework is primarily for. Organisations that try to build a single framework to serve recruitment, performance management, talent review, learning design, succession planning, and promotion decisions simultaneously usually produce something that partially serves all of them and fully serves none.

Pick a primary purpose. Let that purpose drive the design decisions. Build in explicit flexibility for secondary uses rather than trying to optimise for all of them at once.

Step 3: Generate Behavioural Data from the Organisation

The most manager-ready frameworks are built from data gathered inside the organisation, not from competency libraries. This means running structured conversations with high performers, middle managers, and senior leaders to surface what effective performance actually looks like at different levels.

The questions are simple: What does excellent look like at this level in our organisation? What behaviours distinguish someone who is performing at the level they are at from someone who is ready to move to the next? What do we consistently see in people who fail to grow here?

This process takes time. It is worth it. The output is a set of raw behavioural data points that are specific to the organisation, in the language of the organisation, and immediately recognisable to managers because they describe real work.

The insight that a competency around “execution” looks different in an FMCG company with fast-moving, distributed teams than it does in a professional services firm with project-based delivery structures is obvious in principle and consistently ignored in practice. Generic frameworks cannot capture this. Organisation-specific data can.

Step 4: Cluster and Name with Managers, Not for Managers

Once raw behavioural data has been gathered, the clustering and naming process should involve a representative group of managers, not just the HR team and a consultant. This serves two purposes. It produces better output because managers will catch abstraction and jargon that HR professionals have stopped noticing. And it creates early ownership because the managers involved can say, truthfully, that they helped build this.

Naming conventions matter more than most people realise. A competency called “business judgment” will be interpreted differently by different managers. A competency called “seeing the whole before acting” is more specific and more memorable, even if it is less conventional. Name for recognition, not for correctness.

Step 5: Write Behavioural Indicators at Three Levels, Not Five

Most frameworks use five proficiency levels. Most managers use two: “doing it” and “not doing it.” This is not because managers lack sophistication. It is because five levels are genuinely difficult to distinguish in a live performance conversation without extensive calibration training.

Three levels work better in practice: developing (not yet consistent), proficient (consistently demonstrated), and advanced (coaches others or applies at greater complexity). The distinctions are meaningful, the language is manageable, and managers can use them without referring to a guidebook.

Able Ventures’ Competency Mapping Certification programme covers this design decision in depth, including how to calibrate proficiency levels across assessors so that the framework produces consistent judgments rather than subjective ones.