"That's not what we committed to for Q3"
Engineering finishes a feature, tests pass, it deploys. Then sales says it isn't what was promised for the quarter. The sprint is over, the work is real, and it still doesn't count — because two teams built against two different plans that were never actually the same document.
This happens when goals live on a slide somewhere and tasks live on the board, with nothing connecting the two. Both are internally consistent. Neither one is checked against the other until a customer or a board meeting forces the comparison.
Symptoms and the real cost
| Symptom | Cost |
|---|---|
| Tasks marked Done, but the goal they were meant to serve is still red | The sprint's effort doesn't show up as progress on anything that matters |
| The roadmap slide and the actual board tell two different stories | Whichever one a stakeholder saw last is the one they believe |
| Sales makes a commitment engineering never heard about | The surprise lands mid-quarter, not during planning |
| Key results exist but nothing is actually linked to them | They're decoration, not a tool anyone uses to prioritize |
| Steering meetings argue priorities without checking goals at all | The debate is about opinions instead of a shared reference point |
A framework for linking the board to goals
1. Put goals in the same system as the work. A quarterly OKR slide that nobody opens between reviews isn't a goal — it's a memory of one. list_goals keeps them where the board already lives, not in a deck that goes stale in week two.
2. Make the epic-to-key-result link required, not optional. If a top-level epic doesn't specify which key result it moves, the team can't tell whether the work is a priority or just familiar.
3. Roll up weekly: what percentage of work in flight is actually linked to a goal? A low number isn't necessarily wrong, but it should be a deliberate choice — not a fact nobody has looked at.
4. Give sales and engineering the same brief before they talk. executive_brief pulled fresh for both sides means the negotiation about what's realistic for the quarter starts from the same facts instead of each side's private version.
5. When something gets added, name what gets dropped. Scope only grows in most teams because nobody explicitly weighs a new ask against the goals it would displace. Tie the trade-off to key-result impact, not to whoever asked loudest.
6. Tie demos to the key result they serve, not to "what we happened to finish." A demo that can't say which goal it moves is a status update, not evidence of progress.
7. When misalignment surfaces in retro, fix the missing link — not just the symptom. "We should communicate better" doesn't survive to next sprint. "This epic type now requires a KR field before it can start" does.
Anti-patterns
- OKRs reviewed only once a quarter. By the time misalignment shows up in that review, it's been costing sprints for weeks.
- Roadmap kept in a separate tool from the board. Two systems of record always drift, and the drift is invisible until someone compares them.
- Sales commitments made through a side channel. If a promise to a customer never touches the board, engineering finds out the same way the customer does — too late.
- Goals with no metric attached. "Improve reliability" isn't a key result; it's a mood.
- Punishing engineering for a sales promise engineering never saw. The fix is a linking process, not blame aimed at whoever happened to be in the room.
How WKFGo supports this
- Goals (
list_goals) — key results tracked in the same system as the tasks meant to move them. executive_brief(MCP) — a shared, evidence-based summary either side of the sales/engineering conversation can pull before they talk, instead of arguing from memory.- Task-to-goal linking — epics carry a KR field, so "is this actually a priority" has an answer that isn't a guess.
- Reports — goal progress alongside task counts, so a steering meeting can check the roadmap and the board in one place.
Where this shows up
B2B teams feel it when a custom commitment made in a sales call never gets checked against what's actually planned. Platform teams feel it in the tension between tech-debt work that protects future key results and feature work that shows up on a demo — both real, but rarely weighed against the same goals. Startups feel it hardest mid-quarter, when priorities pivot and nobody updates which key results the current sprint is even serving anymore.
Start this week
Pick the reddest signal from the symptom table and run one experiment against it, with a named owner and a two-week review date. If the epic-to-KR link is the gap, make it a required field for new epics this sprint — not a policy for "eventually." Measure the same signal again in two weeks; if it hasn't moved, the fix belongs in the process, not in reminding people to try harder.
Role-specific starting points
Product managers: report the weekly percentage of in-flight work linked to a goal — it's a more honest health signal than velocity alone.
Engineering: ask, for any epic without a KR link, whether it should be next in the queue at all.
PMO / leadership: pull executive_brief before steering meetings so priority debates start from the same numbers, not from whoever presents most persuasively.
Summary
Engineering-business misalignment isn't solved by a better slide deck — it's solved by making the link between an epic and the key result it serves a required part of planning, not an afterthought discovered in a postmortem.