How do you write a project goal a team can rate confidence against?

Why this is a precondition, not a nicety

An engineering leader in our research identified this before we did. Asked what would need to be true for a confidence signal to mean anything, he said:

"There is almost a pre-round associated with this: is the goal clear or not?"

He's right, and the failure is subtle. If four people on a team hold four different ideas of what "done" means, they can all answer a confidence question in good faith and produce a number. The number will be an average across four different questions. It'll look exactly like a real measurement, move around plausibly, and mean nothing.

Another leader identified the same thing as his fundamental problem, independent of any tooling:

"In my experience the biggest problem is when people are not clear on what the goal is." — principal developer

The test

One question, and it's harder to pass than it sounds.

If you asked each person on the team separately what success looks like and when we'll know, would the answers match?

Not roughly. Would a QA engineer and a backend developer name the same condition? If you're not sure, that's the answer — and it's worth actually asking rather than assuming, because goal ambiguity is invisible from the inside. Everyone believes they understand it.

The four ways goals fail

1. Open-ended improvement

"Improve performance." "Reduce technical debt." "Make onboarding better." A developer we interviewed described exactly this:

"Some goals are well defined. You end up working on some open-ended things — 'improve performance'."

These have no finish line, so confidence is unratable. Confident of what? There's no moment at which the team either did or didn't achieve it.

Fix: attach a threshold and a date. "P95 latency on the search endpoint under 200ms by 31 March" is ratable. Everyone knows what's being asked.

2. Activity rather than outcome

"Migrate the service to the new platform." "Ship the redesign." These sound concrete and are still ambiguous, because they describe work rather than result. Migrated with three known regressions and a rollback plan? Shipped to 5% of users?

Fix: name the end state. "All traffic served from the new platform, old cluster decommissioned, by 15 May."

3. No date, or a date nobody believes

Confidence is confidence that we'll achieve this by then. Remove the "by then" and there's nothing to be confident about — everything ships eventually.

A date the team has never agreed to is a subtler version of the same problem. People end up rating confidence against a target they consider fictional, which produces low scores that don't mean what they appear to.

4. Too far away

An interviewee named this precisely:

"If the goals are too far away, it might be green until it turns red."

Confidence about something eighteen months out is weakly informative, because nobody has met the evidence yet. It stays high until it collapses.

Fix: track something closer. A quarterly milestone with a real success condition produces a usable signal; the annual objective sits above it as context. Genchi supports parent-child initiatives partly for this reason — the long-horizon goal is the parent, and the ratable things are underneath it.

What a good goal looks like: use SMART

You don't need a new framework for this. SMART — specific, measurable, achievable, relevant, time-bound — has been the standard for goal-setting for decades, and a goal that genuinely passes it is a goal a team can rate confidence against. The four failure modes above are each a SMART criterion being skipped.

• Specific. One outcome, described precisely enough that two people would picture the same thing. "Improve onboarding" isn't specific. Two goals joined by "and" isn't specific either — that's two initiatives, and confidence in each will differ.
• Measurable. A condition someone outside the team could verify without asking the team. This is what makes confidence ratable: people are estimating against a defined finish line rather than against their own idea of "done".
• Achievable. The team has to believe the goal is possible — not certain, but possible. A target nobody believes in produces low scores that reflect the target rather than the work, and the signal stops being about delivery. This is the criterion most often quietly skipped when a date is imposed from outside.
• Relevant. The team should understand why this goal matters and how it connects to something larger. One leader we interviewed wanted exactly this: "It'd be good to understand whether or not the individual goals map to the company's strategic initiatives." A team that doesn't see the connection rates confidence in a task rather than in an outcome.
• Time-bound. Confidence is confidence that we'll achieve this by then. Remove the date and there's nothing to be confident about — everything ships eventually. And keep the horizon to a few months, for the reason above.

The addition worth making to SMART for this purpose: outcome, not activity. "Migrate the service" can be specific, measurable and time-bound while still describing work rather than a result. Ask what will be true when you're done, not what will have been done.

The impartial-observer test

One practical way to check a goal: would someone with no context score it the same way you would?

"Make our product better" fails immediately — whether things are better afterwards is arguable, and two reasonable people will disagree. "Increase response time by 100ms" passes, and it passes in a way that matters: if the team lands 90ms, even an outsider can see they missed the goal and got 90% of the way there.

That partial credit is doing real work. A goal that can only be met or failed makes confidence a binary bet, and people hedge. A goal with visible degrees lets a team say "we're at three, we'll get most of the way" — which is both more honest and more useful than a green light that turns red on the last day.

Some worked examples:

Weak: Improve the checkout experience.
Better: New checkout flow live for all users, cart abandonment no worse than today, by 30 June.

Weak: Platform migration.
Better: All services running on the new cluster with the old one shut down, by 15 May.

Weak: Make the API more reliable.
Better: API error rate below 0.1% sustained for four weeks, by end of Q3.

The useful side effect

Writing a ratable goal frequently surfaces a disagreement that was already there. Teams discover mid-conversation that the lead and two engineers had materially different pictures of what they were building.

That discovery is worth more than the measurement it enables. A group project manager named team alignment around a specific goal as his single biggest problem — before any discussion of measuring anything. The exercise of making a goal ratable is an alignment exercise wearing a different hat.

How Genchi handles this

Every Genchi initiative has an owner, a goal and a deadline, and the check-in asks a single question about that specific goal: how confident are you that we'll achieve our goal? The wording is deliberate — it's not "how's it going", it's about a defined outcome by a defined date.

Initiatives can be linked into parent-child trees, so a long-horizon programme can sit above the shorter, ratable pieces that actually produce a useful signal.