Mgr Smart Goals

---
name: mgr-smart-goals
description: Rewrites vague expectations for one person as SMART goals (specific, measurable, assignable, realistic, time-related), linked to team OKRs, with agreed check dates. Use for "run mgr-smart-goals", "write SMART goals", "make these goals SMART", "set clear expectations for my report", "my report does not know what I expect", "goals for a new team member", "turn this key result into individual goals", part of the AI for Managers Pack by Polar Bear.
---

# SMART Goals

## When To Use
Expectations for one person are vague: you know what you want, they are guessing, and the gap only shows up when something is late. Use it with a new starter, at the start of a cycle, or when a role changes. It answers: what exactly is this person expected to deliver, by when, and how will both of you know?

## When Not To Use
If the team has no shared outcomes yet, run Team OKRs first so individual goals have something to point at. If expectations were already clear and a documented gap has persisted after informal conversations, this is no longer goal setting; the Performance Improvement Plan (PIP) is the fair path.

## Inputs
- The vague expectations as you would say them today, in your own words
- The team OKRs or charter, and the person's role description
- What the person has told you about their workload, time and what they want to work on
If you have none of this, I start from the role and one sentence on what you expect this cycle, and mark the output as a first draft for the two of you to rewrite together.

## Approach
SMART as set out by Doran, G. T. (1981), "There's a S.M.A.R.T. way to write management's goals and objectives", Management Review 70(11), 35 to 36: specific, measurable, assignable, realistic and time-related. A common variant reads achievable, relevant and time-bound, and appears in Acas guidance; the checks below use Doran's version and cover the variant. The failure it prevents is "improve stakeholder communication": nobody can tell in three months whether it happened, so the review becomes an opinion.

## Workflow
1. Ask at most three questions: which team key result or charter line each expectation serves, what time and resources the person actually has this cycle, and when you will next sit down together to agree the goals.
2. Specific: split each vague expectation into one area and one change. "Own onboarding" becomes separate goals if it hides three jobs.
3. Measurable: name the evidence that shows it happened (a document shipped, a count, a response time, a sign-off). If the only evidence is your impression, rewrite the goal. Measurable does not mean meaningful: for exploratory work, measure the milestone, not an invented number.
4. Assignable: name who does it. If it depends on someone else, write the dependency and who clears it; do not load another team's work onto this person.
5. Realistic: check each goal against the time and resources the person said they have. If the goals add up to more than the week holds, cut or defer, and say which.
6. Time-related: a date for each goal, plus check dates the two of you agree, set inside the user's cycle.
7. Link each goal to a team OKR or charter line, then hand the draft to the person to edit. Goals are agreed in conversation, not handed down; mark anything they have not yet seen as [draft].

## Output Format
```markdown
# SMART Goals
[Role] | Cycle [start date] to [end date] | Status [draft or agreed on date]
## Goals
| Goal | Evidence it happened | Who does it (and dependencies) | Realistic given | Due | Links to team OKR |
|---|---|---|---|---|---|
| [one area, one change] | [evidence] | [role; dependency and who clears it] | [time and resources available] | [date] | [KR or charter line] |
## Deferred
| Expectation | Why deferred | Revisit on |
|---|---|---|
| [item] | [reason] | [date] |
## Check dates
| Date | What we look at together | Changes agreed |
|---|---|---|
| [date] | [goals] | [blank until the check] |
## Decision
[name] and [name] agree the goals, or change them, in their 1:1 by [date].
```

## Done When
- Every goal passes all five of Doran's checks, or says which one it fails and why.
- Every goal links to a team OKR or a charter line.
- The goals fit the time the person actually has; overflow sits in Deferred.
- Check dates are set and the person has seen and edited the draft.

## Quality Bar
- One area, one change per goal; no goal with "and" in the middle.
- Evidence is something both of you can see, never your impression.
- No rating scales, scores or performance levels attached to any goal.
- No invented targets or numbers; blanks stay as [placeholders] for the two of you.
- Goals describe the work expected, not a judgement of the person.

## Next
Run mgr-one-on-one-agenda (One-on-One Meeting Agenda) to review the goals in 1:1s.

## About the makers

This pack is made by Polar Bear, a consultancy built by ex-McKinsey founders with a dream to make AI work for People, not instead of them. We help our clients build people systems and AI-first ways of working, and we run our own company on Claude. If your team has outgrown the self-serve version, message Pauline (linkedin.com/in/paulinebertry).