Create a competency framework
A good competency framework does two things at the same time: it gives people clear growth expectations, and it gives managers a consistent way to coach. When both are true, performance conversations become less subjective and much more useful.
Competency framework how-toβ
Watch this first to see how to structure a framework, choose the right starting option, and publish something managers can actually use.
Start in the right placeβ
In the product sidebar, open Growth > Competency Framework.
Everyone in the workspace can view the published framework. Workspace owners also have access to the management experience, where frameworks are created, edited, and published.
Understand the page before you createβ
Owners will usually work across two views:
- Published: what the wider workspace sees.
- Manage: where drafts are created and maintained.
The typical workflow is simple: create or update a draft in Manage, then publish when it is ready.
Choose your starting optionβ
Click Create New to open the creation dialog.

You have three options, and each serves a different use case.
1) Use Predefinedβ
This is the best option when you want momentum quickly. You pick a template, name your framework, and start with a practical structure that you can adapt.
Choose this if your team wants a strong first version without spending time on blank-page design.
Templates currently available:
- Enterprise Technology: strong fit for larger teams with specialist functions and clearer role boundaries.
- Tech Scale ups: useful for fast-growing orgs that need structure and flexibility together.
- Tech Startup: useful for early-stage teams with broad ownership and lightweight process.
- FAANG-style: useful when progression is anchored to scope, impact, and influence.
- GitLab-style: useful for remote-first, async-heavy collaboration environments.
- Dropbox-style: useful where craftsmanship, quality, and customer outcomes are key themes.
A practical way to choose: pick the template that is easiest for your managers to use and adapt, not the one that sounds most ambitious.
2) Smartly Craftedβ
This is ideal when your org setup has nuance and you want AI to turn that context into a structured first draft. You provide your framework name and describe your org in plain language, for example team shape, role families, track model, and leveling depth.
ClarityLoop uses that context to draft departments, roles, optional tracks, and levels. After that, you refine the content in the editor.
To get better draft quality, include:
- team size and stage,
- department list,
- key role families,
- whether IC and manager tracks are separate,
- level depth and naming style.
Example:
We are a 70-person B2B SaaS company.
Departments: Engineering, Product, Design, Sales, Customer Success.
Engineering has separate IC and Manager tracks.
Use six levels from Junior to Staff/Principal-style progression.
Keep language practical and easy to use in coaching conversations.
3) Build from Scratchβ
This is best when you already have a clear internal model and want full control from the first step. You start with an empty draft and build each layer exactly as you need it.
Build your framework in a natural orderβ

ClarityLoopβs structure is:
- Department
- Role
- Track (optional)
- Level
A practical way to build is top-down: define departments first, then roles, then tracks only where they are needed, and finally levels.
What each field means in practiceβ
Departmentβ
Use department entries for broad functions like Engineering, Product, or Sales.
- Name: the functional area.
- Overview: context that explains how that function works in your org.
- Hide when published: keeps the department out of member view until ready.
Roleβ
Roles are job families within a department.
- Name: the role family, such as Software Engineer or Account Executive.
- Responsibilities: expected outcomes for this role family.
- Competencies: capability areas needed to deliver those outcomes.
- Hide when published: useful when a role is still in progress.
Track (optional)β
Tracks are separate progression paths inside a role, such as IC and Manager.
- Name: path label.
- Responsibilities and competencies: what is unique to that path.
- Hide when published: helps you stage rollouts gradually.
If a role does not need different progression paths, skip tracks and keep it simple.
Levelβ
Levels define progression steps within a role or track.
- Level: sequence number that controls progression order.
- Name: the level title people see.
- Responsibilities and competencies: what success looks like at that step.
- Hide when published: useful while drafting future levels.
Responsibility, competency, skill, behavior: how they fit togetherβ
These terms are easiest to understand as one chain:
- A responsibility describes the outcome expected.
- A competency describes the capability area behind that outcome.
- A skill is a practical ability inside the competency.
- A behavior is observable evidence that the skill is being applied well.
Example chain:
- Responsibility: deliver reliable services under production load.
- Competency: systems thinking.
- Skill: performance diagnosis.
- Behavior: identifies bottlenecks early and proposes measurable fixes.
This structure helps people understand not only what is expected, but how to show progress.
How inheritance worksβ
Framework content accumulates as you move down the structure. That means lower layers can inherit higher-level expectations and then add the specifics for that role, track, or level.
This keeps the framework consistent and avoids rewriting the same expectations repeatedly.
Tools that help while editingβ
Inside the builder, owners can add, edit, clone, delete, and reorder framework elements. You can also preview levels, compare levels, and align levels across tracks when a role has multiple tracks.
These tools are especially useful when you are reviewing progression clarity across adjacent levels.
Using AI after the draft existsβ
AI is most useful when you already have structure and want to improve wording quality.
Use it to:
- make responsibilities more outcome-focused,
- remove overlap between levels,
- tighten competency language,
- add missing skill or behavior detail.
A quick quality check before publishingβ
Before you publish, ask:
- Can a person read their level and understand what strong performance looks like?
- Can a manager use this in a coaching conversation without translating the language?
- Is the difference between adjacent levels clear and defensible?
If the answer is yes, your framework is ready for rollout.
Next stepsβ
- Publish the framework: Publish a competency framework
- Assign levels to people: Assign people to framework levels
- Connect growth to goals: Linking competency framework to goals