okr_design v1.0.0

name: okr_design description: Design, rewrite, align, and grade OKRs that survive the quarter: KR craft rules, committed vs aspirational labeling, leading vs lagging balance, company-to-team alignment checks, anti-pattern review, and 0.0 to 1.0 scoring. Triggers when someone asks to write OKRs, fix weak key results, cascade company goals to a team, run an OKR review or retro, or grade a finished quarter.

OKR Design

Purpose

Produce OKR sets that still mean something in week 10, not just in the planning meeting. The core discipline comes from Google re:Work: objectives are ambitious and qualitative, key results are measurable outcomes with findable evidence, sets stay small, and grading is honest. Full worked rewrites live in references/worked-examples.md. Source notes live in the production scratch file for this skill and are summarized in the Operating Rules.

Workflow

1. Start from the level above. Read the company or parent objectives first. Note which parent key result each proposed team objective will serve. If a draft objective serves no parent result, flag it as an orphan and ask why the work is being done this quarter.
2. Draft objectives. Write 3 to 5 per level, about 3 key results each. An objective is qualitative, short enough to remember, and written as an endpoint or a state, not a task. Ban keep, maintain, and continue as opening verbs. If the objective contains a number, move the number into a key result.
3. Label every objective. Tag each one [committed] or [aspirational] in the draft itself.

• Committed: the team agrees it will be delivered, resources will be adjusted to deliver it, expected score 1.0. A miss needs an explanation.
• Aspirational: a desired future with no guaranteed path or full resources, expected average score around 0.7. A score near 1.0 across a whole aspirational set usually means targets were set too low.

1. Write key results as outcomes. Each KR needs a metric, a baseline, a target, and a date, in the form: move <metric> from <baseline> to <target> by <date>. Apply the activity test: if the KR starts with consult, help, analyze, participate, launch, ship, hire, run, or build, it is probably an activity or an output. Ask what changes for users or the business when that work is done, and write the change. Keep the activity in the project plan.
2. Name the evidence. For each KR, write where the number comes from and where a reader can check it. Evidence should be available, credible, and easy to find: a dashboard, a published report, a query. A KR nobody can verify will be argued about at grading time.
3. Balance leading and lagging. Lagging KRs state the end result: revenue, retention, churn, incident time. Leading KRs predict the end result and can be checked and acted on during the quarter: activation steps completed, qualified meetings per week, runbook coverage. Rule of thumb: top-level sets lean lagging, team sets should add leading KRs they control directly. Every objective gets at least one leading KR or an explicit note saying why it has none. A set with only lagging KRs has no early warning.
4. Run the completeness test. Ask for each objective: could every KR score 1.0 and the objective still fail? If yes, the KR set is incomplete. Add or rework KRs until hitting all of them would, on its own, mean the objective was achieved. Also run the value test: could this objective score 1.0 and still not matter to anyone outside the team? If yes, rewrite it around the benefit.
5. Run the lint script. Save the draft in the format shown in references/worked-examples.md (Objective lines tagged with [committed] or [aspirational], KRs as list items), then run python3 scripts/okr_lint.py check <file.md>. Fix every FAIL. Treat each WARN as a review question to answer in writing, not as noise.
6. Check alignment both ways.

• Vertical: each team KR names the parent KR it serves. Translation is required at each level. Copying a company KR word for word is a failure, because the team rarely controls the whole number.
• Horizontal: list dependencies on other teams. If another team owns a stretch KR you depend on, plan on roughly 70 percent of it landing, and say so in the plan.
• Bottom-up: leave room for team-proposed objectives. A set that is 100 percent top-down usually misses what the team knows about its own work.

1. Set the cadence before the quarter starts. Weekly or biweekly confidence check-ins (on track, at risk, off track, with one line on what changed), a mid-quarter review where KRs can be dropped or reworked with a written reason, and an end-of-quarter grading session. Write the cadence into the OKR document itself.
2. Grade at the end. Score each KR from 0.0 to 1.0. For a from-to KR, use python3 scripts/okr_lint.py score --baseline B --target T --actual A; it handles both rising and falling metrics and clamps the result. Binary KRs score 0 or 1. The objective score is a rough average of its KR scores; note any weighting you applied. Bands: 0.0 to 0.3 red, 0.4 to 0.6 yellow, 0.7 to 1.0 green. Read the result by type: committed sets should be at 1.0, aspirational sets are healthy around 0.6 to 0.7. In the retro, record what was learned per low KR, what carries forward, and what the score says about how the KR was written, not just how the team performed.

Output Contract

One OKR document containing:

• Level and cycle (for example: Team, Q1) and the parent objectives it aligns to
• 3 to 5 objectives, each tagged [committed] or [aspirational], each with 2 to 5 KRs
• Every KR in from-baseline-to-target-by-date form, with its metric source named
• At least one leading KR per objective, or a written reason there is none
• An alignment table: team KR | parent KR it serves | dependency on another team, if any
• A dependency note for any stretch KR owned by another team
• The check-in and grading cadence for the cycle
• Lint output: FAIL count must be zero; each WARN answered or fixed
• At grading time: a score table (KR | baseline | target | actual | score), the objective average, and a short retro note per KR under 0.4

Operating Rules

1. OKRs are not a task list and not a performance review. Google re:Work states both plainly. If scores feed pay or ratings directly, teams will set targets they already know they can hit. State in the document that scores are a learning tool, and name any exception (for example a sales quota) out loud.
2. Public by default. OKRs should be visible to everyone at the levels around them. Visibility is what makes alignment and horizontal coordination possible without extra meetings.
3. Small sets win. More than 5 objectives or more than 5 KRs under one objective means the team has not made a choice yet. Cut before you polish wording.
4. No baseline, no KR. If the current value cannot be measured, the first KR for the cycle is to establish the baseline by a named date. Do not invent a baseline to make the draft look finished.
5. Guardrail KRs are the exception. A hold-the-line KR (keep error rate at or below the current level while a migration ships) is legitimate next to a committed change. Label it as a guardrail so reviewers do not mistake it for business as usual.
6. Business-as-usual work stays off the list. Work the team would do anyway, at the same level, with no change, does not become an OKR by being written down. It can be a KPI on a dashboard instead. OKRs name what changes this quarter; KPIs name what must stay healthy.
7. Revise in the open. Dropping or reworking a KR mid-quarter is allowed when the facts change. Record the change, the date, and the reason in the document. Silent edits destroy trust in grading.
8. Never invent numbers. Baselines and actuals come from a named source. Example numbers in drafts and templates must be marked as examples. Unverifiable claims get cut, not rounded into sounding precise.