Manager/Admin Guide
How to create, manage, assign, and publish competency frameworks for live use in WeMatter.
Who this is for
This guide is for admins, RPO users, framework editors, and WeMatter leads who need to manage frameworks directly or understand how they affect scorecards and goals downstream.
Why frameworks matter operationally
Frameworks are easy to think of as background setup. In practice, they are far more important than that. A framework tells WeMatter what kind of capability picture it is supposed to work with. It influences how performance is reviewed, how launch checks behave, and how later development work is framed.
When a framework is thoughtful, scorecards feel sharper and more credible. When it is rushed, incomplete, or published too early, the weakness tends to show up later in the review cycle.
The practical test
A good framework should not only look organised on screen. It should give a manager enough clarity to rate credibly, a participant enough clarity to see what is being asked of them, and WeMatter enough structure to support the rest of the flow.
Finding the frameworks area
To open frameworks, go to your organisation workspace and use the main navigation to select Frameworks.
The list view is designed to be more than a directory. It gives you a quick read on what exists, how much substance each framework has, how many people it applies to, who can manage it, and whether it is still a draft or already live.
That means you can usually tell quite quickly whether you are looking at a piece of in-progress design work or a framework that is ready to support active scorecards.
Creating a framework manually
The manual approach is the simplest way to start. From the Frameworks area, choose Add Framework, give it a name and description, then open it and begin building its competency structure.
For the first pass, it is usually better to aim for clarity than volume. A clean, coherent draft is more valuable than a long framework full of repetitive or generic statements. You can refine tone and detail later; what matters first is whether the structure makes sense.
New frameworks begin life as Draft. That is useful. It gives you space to shape the framework before it begins affecting live review work.
Building around Human Performance Indicators rather than around a list
One of the easiest ways to weaken a framework is to treat it like a flat set of competency statements. In WeMatter, frameworks are built around the organisation's Human Performance Indicator (HPI) structure, so the stronger approach is to think in clusters of capability rather than in isolated lines.
Those Human Performance Indicators are standardised across the organisation. The reason is simple: WeMatter needs a shared performance structure that all frameworks can plug into. That keeps role-specific frameworks flexible without losing organisational consistency, and it makes later scorecard and development work much easier to read across teams or roles.
Start by reading the HPI areas as categories of performance. Then ask what good behaviour looks like inside each one. Some HPI areas may need only a few sharp competencies. Others may need more coverage. The aim is not mathematical symmetry; it is credible coverage.
If one HPI is thin or missing, the framework may still look complete at a glance, but it may be too weak to support scorecard launch or meaningful rating.
Assigning the framework to people
Framework assignment is where the framework stops being abstract and starts to matter to a real person. In practice, the assignment usually happens from the person's profile, where you choose the framework that should apply to them.
That single choice carries a lot of weight. It affects which framework WeMatter uses when launching that person's scorecard, who may be able to view the framework when access is limited to framework users, and whether that framework context is available later in goal generation.
Because of that, assignment is worth treating as a deliberate decision rather than simple admin housekeeping.
Editors, users, and the shape of access
Inside the framework page, the Access area separates the people who manage the framework from the people it applies to. That sounds simple, but the distinction is worth holding onto.
Editors are there for governance. They shape, maintain, and review the framework. Users are there because the framework belongs to their role, population, or development context. In some cases, additional people may effectively gain editor-style access because of role or relationship, such as admins or relevant WeMatter leads.
The point is that ownership and applicability are not the same thing, and the docs should help people keep those ideas separate.
Visibility and what it really controls
Visibility decides who can open the framework, not who it applies to. That is a small distinction, but it matters.
An Editors only framework stays tightly governed. Editors & Framework Users opens access to the people the framework belongs to, whilst still keeping it contained. All Users makes it visible across the organisation.
The right setting depends on why the framework exists. Some frameworks are best treated as governed working tools. Others are more useful when widely visible, especially if transparency around role expectations is part of the intent.
Draft, published, and the moment a framework becomes live
Publishing should feel like a decision, not a finishing flourish. A framework in Draft is still being shaped. A Published framework is something you are prepared to let WeMatter use in live scorecard launch.
This is a good moment to pause before switching status. Read the framework as a manager would read it. Ask whether the competencies are distinct enough to rate, balanced enough to cover the role, and clear enough to support development conversations later. If the answer is not yet yes, the draft is doing its job.
A good publishing question
If a scorecard launched from this framework tomorrow, would you trust the competency structure to support a serious performance conversation?
What WeMatter checks before scorecard launch
Frameworks become particularly visible at launch time, because WeMatter checks whether the participant's assigned framework is suitable for live use. The framework needs to be present, published, not deleted, populated with competencies, and broad enough to cover the organisation's required HPI structure.
When those checks pass, the framework supplies the competency structure for the scorecard itself. So the framework is not simply adjacent to the scorecard; it is one of the things the scorecard is built from.
Why the framework still matters after the scorecard
Once a scorecard is complete, it can be tempting to think the framework has done its job. In reality, it continues to matter. Goal generation can use framework context alongside scorecard and Foundation evidence, which means the wording and shape of the framework still influence what development looks like next.
That is one reason to think of frameworks as living documents rather than static setup. They do not stop mattering once the review has been scored. They continue to shape how WeMatter interprets capability, frames development needs, and describes what should happen next.
Good governance habits
The best framework libraries usually feel deliberate rather than sprawling. They have names people can understand, enough variation to reflect real role differences, and not so much duplication that nobody knows which version to use.
If your organisation's HPI structure changes, frameworks deserve a review. If a framework is being published only to unblock a launch, that is usually a signal to pause rather than push through. The cleaner the framework layer is, the more stable everything downstream tends to feel.
When to use the advanced workflows guide
The advanced guide is the next stop when you are not simply writing or editing a framework by hand. Use it when you want to generate a first draft with AI, copy an existing framework, or map a framework across organisations with different HPI structures.
Last updated on