Short answer
To build a competency framework, define the Functions and role tracks you need now, choose distinct competencies for each Function, and write observable expectations for every level. Review the draft with managers using real work examples, publish a version for the next review cycle, and revise it only after you learn where the wording fails.
Which Functions should you build first?
Start with the job families included in your next review cycle. Each Function should represent one family of related work, such as Backend Engineering or Customer Success, and contain the role tracks and levels that people actually use.
Do not model a future org chart. A smaller framework that covers current decisions is more useful than a large catalog that managers cannot apply.
- List the Functions in the next review cycle.
- Record the current IC, Manager, and Executive levels for each Function.
- Choose which company-wide competencies must keep the same meaning everywhere.
How do you choose useful competencies?
Choose competencies that cover different parts of the work. Technical design, code quality, and incident response can each produce separate evidence. Communication and collaboration may overlap unless you define a clear boundary.
Check the set as a whole. It should cover the Function without rating the same shortfall twice. Company-wide competencies keep a portable definition, while the Function description explains how each one appears in that job family.
Write levels that managers can observe
For each competency, describe what changes across levels through scope, autonomy, complexity, or influence. Write in the present tense and name work a manager could verify in documents, decisions, customer outcomes, delivery records, or other normal artifacts.
Avoid personality labels and intensifiers. They do not tell an employee what to do differently or give a manager a defensible basis for a rating.
Replace a trait with evidence
Communication: 4 out of 5.
Records decisions, owners, and open questions so the team can continue without another meeting.
Test the framework before a review cycle
Give two managers the same anonymized work example and ask which level it meets. If their answers differ, find the phrase that allowed both interpretations and rewrite it. Also ask employees whether the next level describes a visible path, not a hidden judgment.
Publish a named version before the cycle starts and keep that version fixed through sign-off. Record unclear expectations during calibration, then correct them in the next version instead of changing the standard mid-cycle.