Manager/Admin Guide

Who this is for

This guide is for managers, WeMatter leads, admins, and RPO users who need to set or manage development goals for other people.

Your level of control depends on your role and your relationship to the goal owner, but the overall pattern is consistent: goals are meant to be shared enough to support development, whilst still staying owned by the person they relate to.

---

Why goals matter operationally

Goals are the part of WeMatter that keeps development active after reflection and review. They give the platform somewhere to carry forward what has been learned, what needs to change, and how progress should be made visible over time.

That makes them more than a tidy summary after a scorecard. Goals are the place where development work becomes ongoing, structured, and collaborative.

---

Where goals appear in the product

You can manage goals through the main Goals area, from a person's profile, and from the post-scorecard flow after a WeMatter workshop has been submitted.

The Goals area is useful for list management, filtering, and oversight. The profile route is where creation often begins. The post-scorecard route is where AI generation becomes especially powerful, because the platform already has the recent review context available.

---

Setting a goal manually

Manual goal creation is useful when you already know the development direction and want full control over how the goal is framed.

In the current product, manual setup starts with the goal itself: a title, a relevance statement, and an optional deadline. After that, the structure moves downwards into objectives and achievables.

The point of that structure is to prevent the goal from staying vague. Objectives turn it into measurable milestones. Achievables make those milestones practical enough to track.

---

Generating a goal with AI

AI goal generation is a core feature, not a novelty. It is designed to create a more grounded first draft by drawing on the evidence already available in WeMatter.

When available, that context can include the latest completed scorecard, submitted Foundation material, and the person's assigned competency framework. The AI uses that combination to propose a goal, explain its relevance, and build the objective and achievable structure beneath it.

That is especially useful after a completed scorecard, because the development opportunity has just been surfaced in a more evidence-based way.

---

The goal hierarchy is not optional

It is possible to write a goal headline and stop there, but that is not where the product is strongest.

WeMatter is designed around a hierarchy: the goal itself, then objectives, then achievables. This is what makes the goal trackable. It is also what makes later status, progress, and updates more meaningful.

If the hierarchy is weak, the rest of the goal becomes harder to manage well.

---

Access: owner, editors, and contributors

Every goal has an owner. It can also have editors and contributors.

The owner remains the primary stakeholder. Editors help manage and maintain the goal on the owner's behalf. Contributors support progress through updates and discussion rather than by controlling the core goal settings.

In the wider access model, certain organisational roles can also gain edit-level access where the product rules allow it. Relevant WeMatter leads, admins, and RPO users are the most important examples.

This is the right way to think about goal access: collaborative, but still structured.

---

Using updates well

Updates are one of the most important parts of the goals area, because they are what make a goal feel live.

Without updates, a goal can look well designed and still be practically stale. With updates, the goal becomes a running development record. That makes it much easier for owners, editors, contributors, and supporting managers to understand what has happened since the goal was first set.

If you are managing goals for others, updates are often the clearest signal of whether a goal is still active in practice.

At objective level, updates can also be tagged to a specific achievable. That is worth using. A tagged update makes it clear which part of the objective the note belongs to, and it allows the updates view to be filtered by achievable later. In practice, that makes progress tracking much more precise when an objective contains several parallel pieces of work.

---

Status, deadlines, and achievement

Goals can be marked On Track or At Risk whilst they are still active. They become Overdue when the deadline passes without completion. And they become Achieved when the work is genuinely complete.

The labels do different jobs:

• On Track and At Risk help describe the current health of live work
• Overdue reflects timing against the deadline
• Achieved confirms the structure has genuinely been completed

In the current product, marking a goal as achieved is not meant to be casual. A goal must have at least one objective, and all of its objectives must be completed before achievement can be confirmed.

This creates a useful discipline. It stops the status label from drifting too far away from the actual structure of the work.

---

Oversight in the goals list

The main Goals area is not only a place to open individual goals. It is also the main oversight surface.

The list supports search, filtering, sorting, and CSV export. Taken together, those tools help you read the current goal landscape across people, status, progress, objective count, achievable count, and deadlines.

The most useful list habits are usually simple:

• use filters to isolate the people or status conditions you need to review
• use sorting to surface time-sensitive or unusually complex goal structures
• use CSV export when you need a broader planning or reporting view outside the page

This becomes especially useful when you are supporting development across a team or an organisation rather than working with a single goal at a time.

---

Group goals

Group goals are useful when several people need to contribute to the same business, team, or organisational outcome, but each person still needs their own goal, objectives, achievables, and updates.

At group level, you define the shared outcome, group objectives, deadlines, and objective weightings. WeMatter connects that structure to individual goals for the participants, so each person's work can stay specific whilst still rolling up to the same group goal.

The group goal workspace gives you three useful oversight views:

• Overview for the group goal details, objectives, participants, access, and headline stats
• Progress for weighted progress, participant progress, objective progress, achievables, and last activity
• Activity for updates and key events rolled up from the connected individual goals and objectives

You can also post updates from the group goal or group objective activity thread. Those updates are copied into the relevant connected individual threads, so use them for messages that genuinely apply to everyone receiving them.

For the full workflow, read Group Goals.

---

How goals connect back to the wider flow

Goals should be understood as the ongoing layer that follows the rest of the WeMatter cycle.

Foundation gives context. Frameworks describe the capability model. Scorecards surface evidence and alignment. Goals take that combined picture and keep it alive through action, structure, and updates.

If you are managing goals for others, this wider context helps you avoid setting goals that feel detached from the review work that came before them.

---

A good operating mindset

The strongest goal practice is deliberate without becoming heavy-handed.

Use manual creation when the direction is already clear. Use AI generation when you want a faster, evidence-based first draft. Keep the hierarchy sharp enough that progress is visible. And use updates often enough that the goal still feels true to what is actually happening.

Often, that is the difference between a goal that exists on paper and one that actually helps development move forward.