Goals and competencies

Sparkus links two related ideas for every program: a competency framework (the set of skills or behaviors a program cares about) and development goals (the personal growth objectives a participant sets for themselves). This page explains what each is and how they connect.

What a competency framework is

A competency framework in Sparkus is a competency set — a named collection of competencies (for example, a leadership framework or a technical skills list). Competencies can be organized into groups, with section headers used purely for display and simple leaf competencies that are the actual assessable items. A company can maintain more than one competency set, and a set can be shared across companies, so the same framework can be reused by multiple programs.

Mapping competencies to a purpose

A competency set on its own doesn’t do anything until a program admin maps it to a purpose. Mapping tells the program which set of competencies to use for a given feature. The purposes available today are:

Default — used when no specific mapping is defined for a purpose
Self-Assessment — competencies users can rate themselves against
Development Goals — competencies available when a participant sets a growth goal
360 Feedback — competencies rated by multiple people about a participant
Work-Life Balance — dimensions used in work-life balance exercises
Values Exploration — core values used in values-based exercises
Team Analyzer — competencies used for team-level analysis
Matching — competencies used to match coaches/mentors to participants
Custom — an open-ended purpose an admin can define for a program-specific need

A program can use a different competency set per purpose — for example, a broad leadership framework for self-assessment, but a narrower behavioral set for 360 feedback. If a purpose has no specific mapping, the program’s Default mapping is used instead; if there’s no Default either, the feature simply has no competencies to work with.

This mapping is the single source of truth that other Goals/Competencies screens read from — when a participant sees competency options while setting a goal, or when a report renders self-assessment results in a particular order, they are reading the same underlying mapping an admin configured on the program’s Competencies settings page.

Some programs also support giving an individual program item (rather than the whole program) its own competency mapping, so that one specific instance of a feature can use a different set than the program default while everything else keeps using the program-wide mapping. Where this exists, it is intended as an optional override on top of the program default — the program-level mapping remains the fallback for anything that doesn’t have its own override.

Development goals

A development goal is a participant’s own growth objective within a program — a title, an optional description, a target date, and success criteria. Goals move through a simple lifecycle (not started, in progress, completed) and can carry a numeric progress level on a configurable progress scale. Each goal can have a set of actions — smaller steps the participant is working through — and completing all of a goal’s actions can automatically mark the goal as complete.

Participants typically keep a small number of active goals at a time (the rest are kept but not in active focus), and goals can be linked to one or more competencies from the program’s Development Goals competency mapping. Linking a goal to a competency is what lets a program later report on which competencies participants are actively developing.

Goals can also be marked confidential, in which case only the goal owner sees the detail; the participant can choose to share a confidential goal so program staff can see it too.

Goal-setting as a journey step

Development Goals and Competencies each exist as their own step type in a participant’s program journey, alongside other step types like sessions, forms, and 360 feedback. When a program includes a Development Goals step, participants set and track their goals as part of their guided journey rather than in a disconnected tool.

One common building block for this journey step is a simple ordered list where a participant lists out their goals directly. Behind the scenes, entries in that list are synced into the participant’s actual goal records, so what looks like a simple list to the participant becomes structured, trackable goal data — with the same linking to competencies, progress tracking, and reporting as goals created any other way. This sync is additive: editing the list updates or adds goals, but goals are never silently deleted by a sync, which protects a participant’s existing progress notes and actions.

How competencies feed reporting

When a report shows a participant’s self-assessment answers, the competencies are displayed in a specific order — grouped under section headers, with the underlying leaf competencies listed beneath each group. That ordering comes from the same competency mapping an admin configures for the Self-Assessment purpose, so what a participant assessed against and what a report displays stay consistent. This resolution is shared by every report surface that renders self-assessment answers, so a participant’s own report and any admin-facing views of the same data present competencies in the same order.

More broadly, because goals, self-assessment, and 360 feedback all draw from mapped competency sets, program reporting can roll up development activity — which competencies participants are working on, self-rating, or being rated on by others — using one consistent competency vocabulary rather than several disconnected lists.