Building the attributes library

Who can use this: Org admins only.

Attributes are the org-wide vocabulary your team uses to describe performance. Every observation can be tagged with one or more attributes; summaries can include attribute-level commentary; ratings (when enabled) attach to attributes.

A well-curated attribute library is one of the highest-leverage admin investments. Too few attributes and feedback feels generic; too many and managers can't find the right tag. This article walks through creating and managing the library, plus opinionated guidance on what makes a library work.

This page covers the attributes feature flag and its companion managerAttributes. Both must be enabled in Settings → Features for the surfaces described here to appear.

What attributes are

An attribute is:

• Org-wide: the same library applies to every employee, every team.
• Tag-like: each observation can carry zero, one, or many attributes.
• Optional on observations by default: you can configure required attributes per observation type.
• Rated on a scale: when ratings are part of summaries, they attach to attributes.
• Grouped into categories for navigability.

Attributes are not job descriptions. Don't try to model "Software Engineer L4" or "Senior Account Executive" as attributes. Those are role definitions; attributes are the underlying competencies that may apply across multiple roles.

A good attribute is:

• Observable: you can point to specific behaviors that demonstrate it.
• Outcome-relevant: someone better at this delivers measurably better results.
• Universal enough: applies across at least 30% of your team. Highly role-specific attributes belong in role rubrics, not the org library.

Where attributes appear

Once enabled, attributes show up in:

• Observation form — the user picks one or more attributes to tag the feedback.
• Observation card — attributes display as small pills.
• Filter and search — find all observations tagged with a given attribute.
• Summary form — attributes can be commented on individually, plus rated if ratings are on.
• Employee profile — aggregate view of attributes mentioned across observations and summaries.
• 360 feedback — peer prompts can be attribute-keyed.

Creating an attribute

1. Open Admin → Settings → Attributes.
2. Click Add attribute.
3. Fill in:
   • Name (required, unique within the org). Short — two or three words.
   • Description (recommended). One or two sentences explaining what the attribute means and what behaviors evidence it.
   • Group (optional but recommended). Pick from existing groups or type a new one.
   • Required (optional). If checked, observations of certain types must include at least one attribute, and this attribute is shown more prominently. Most attributes are not required.
   • Manager-rated (optional, requires managerAttributes). If checked, this attribute can be rated by managers in summaries.
4. Save.

Attributes are immediately available in every observation and summary form across the org.

Naming conventions

Pick a convention and stick to it. Common patterns:

• Noun phrases: "Customer Empathy", "Technical Depth", "Strategic Thinking".
• Verb phrases: "Communicates Clearly", "Delivers Outcomes", "Mentors Others".

Either works. Mixing them in the same library tends to feel inconsistent, so pick one.

Description writing

A good attribute description does two things:

1. Defines what the attribute means in your context (different orgs mean different things by "leadership").
2. Lists 2–4 example behaviors that evidence it.

Example for "Customer Empathy":

Demonstrates a deep understanding of customer needs and translates that understanding into product or service decisions. Examples: shadows customer support calls; cites specific customer interactions in design discussions; drafts customer-facing communication in plain language.

Aim for under 100 words. Longer descriptions don't get read.

Grouping attributes

Groups (sometimes called "categories" or "domains") give the library navigable structure. Common group schemes:

• By type of work: Craft, Collaboration, Leadership, Self-Management.
• By career ladder dimension: Execution, Influence, Strategic Impact.
• By value: matches your company's stated values, one group per value.

Each attribute belongs to exactly one group. To create a group, just type a new group name when creating or editing an attribute — the group is created on the fly.

To rename or merge groups:

1. Open Settings → Attributes.
2. Click the Groups tab.
3. Edit, rename, or merge as needed.

Renames propagate everywhere. Merging moves all attributes from one group into another and removes the empty group.

Editing an attribute

1. Open the attribute from the list.
2. Edit any field except internal ID.
3. Save.

Edits propagate. The new name appears in historical observations and summaries that referenced it. Description changes do not change historical content; only future renderings of the description update.

What you should not do

• Don't rename attributes for cosmetic reasons mid-cycle. If a 360 cycle is in flight, prompt language changes will confuse respondents.
• Don't change scope (e.g., change "Customer Empathy" to "Customer Outcomes") without flagging it. The historical data is still tagged with the same attribute, but its meaning has changed.

When you need to change meaning, consider archiving the old attribute and creating a new one. Historical data stays under the old tag, future data goes under the new one.

Archiving an attribute

When an attribute is no longer relevant:

1. Open it.
2. Click Archive.
3. Confirm.

Archived attributes:

• Stop appearing in selectors for new observations and summaries.
• Remain visible on historical observations and summaries that already reference them.
• Can be unarchived if needed.

You cannot delete an attribute that has been used. Archive is the lifecycle endpoint.

Required attributes

You can mark attributes as required for specific observation types. The most common pattern: at least one attribute is required when filing an observation, but no specific attribute is required.

To configure:

1. Open Settings → Attributes.
2. Click the Required configuration tab.
3. For each observation type (Strength, Opportunity), choose:
   • No requirement.
   • At least one attribute required.
   • At least one attribute from a specific group required.

Use sparingly. Required attributes increase friction and can lead to lazy tagging ("just pick one to get past the form").

Rating scales

When managerAttributes is enabled, managers can rate employees on attributes during summaries.

The rating scale is org-wide. The default is a 5-point scale:

Value	Label
1	Below expectations
2	Approaching expectations
3	Meets expectations
4	Exceeds expectations
5	Exceptional

You can customize the labels in Settings → Attributes → Rating Scale. The number of points is fixed at 5 (changing it would break historical data).

We recommend keeping the default labels unless you have strong organizational reasons to change. The labels are familiar to anyone who has worked in a corporate review system; novel labels confuse new hires.

Behaviorally anchored ratings

For each attribute, you can optionally provide a one-sentence anchor for each rating level. Anchors guide raters toward consistent interpretation.

Example for "Communicates Clearly":

Level	Anchor
1	Communication frequently leaves teammates confused or blocked.
2	Communication is generally clear within team but breaks down across functions.
3	Communication is clear and effective across most situations.
4	Drives clarity in group settings; teammates rely on them to summarize and align.
5	Sets the bar for clarity org-wide; their writing or speaking is shared as a model.

Anchors are optional. They take time to write but pay off in rating consistency.

Manager-rated versus universally-rated

The managerAttributes flag distinguishes which attributes can be rated:

• All on: every attribute can be rated in summaries.
• Selective: only attributes you've individually marked as Manager-rated can be rated. Others appear as tags but no rating field.

Selective is the more common pattern. Many orgs want a small handful of "ratable competencies" (Craft, Outcomes, Leadership) plus a long tail of "tagable competencies" that show qualitative breadth without per-attribute scoring.

Attribute drift and refresh

Attribute libraries drift. New initiatives bring new vocabulary; old attributes lose relevance. Plan for periodic refresh:

• Quarterly: review the Usage column in the Attributes settings page. Attributes with under 1% usage in the last 90 days are candidates for archive.
• Annually: hold a working session with managers to review the full library. Archive what's stale, add what's missing, refine descriptions.

Treat the library like a product, not a one-time setup.

Migrations

When you significantly restructure the library — for example, moving from 40 attributes to a more focused 12 — Performance Blocks supports a guided migration:

1. Open Settings → Attributes → Migrate.
2. Map old attributes to new attributes (one-to-one, many-to-one, or "archive without replacement").
3. Choose whether to retag historical observations and summaries.
4. Run the migration.

Retagging is irreversible — the underlying records are updated. Export your data first if you want a snapshot of the pre-migration state.

Best practices

• Keep the library small. Most orgs land between 12 and 25 attributes. More than 30 is usually over-engineered.
• Group by 4–7 categories. Fewer feels grab-bag; more is hard to scan.
• Refresh annually. Block 90 minutes once a year to prune and add.
• Write good descriptions. They get read more than you think, especially by new managers.
• Don't model job titles. Attributes describe how someone works, not what role they hold.
• Use rating scales sparingly. A library with 5 ratable attributes plus 15 tagable ones is more usable than 20 ratable.

Frequently asked

Can each department have its own attribute library? No — the library is org-wide. Use grouping to organize, and rely on cultural conventions to decide which attributes apply where.

Can attributes be required for some employees and not others? No. Required is a per-observation-type setting, not per-employee.

What happens to ratings if I archive a manager-rated attribute mid-cycle? Existing draft summaries keep the rating field for that attribute; you cannot add it to new summaries. We recommend archiving outside of an active cycle.

Can I import attributes from a CSV? Yes — Settings → Attributes → Import accepts a CSV with name, description, group, required, manager_rated columns. Useful when you've already designed your library in a doc.

Next steps

• Custom fields — extend employee records with non-attribute metadata.
• Running review cycles — use attributes within summaries.
• Observations — how attributes show up for employees and managers day-to-day.