We've been rolling out OKRs across engineering and ops using Atlassian Goals, and we keep hitting the same structural wall.
The setup we're trying to model:
- Company Key Result (e.g., 'Reduce p95 latency to <200ms')
- Team Objective that maps directly to that KR
- Team Key Results owned by individual squads
This is pretty standard cascade logic. A company's KR becomes the team's Objective. But in Atlassian Goals, the hierarchy doesn't seem to support this cleanly. You can nest goals, but the parent-child relationship treats everything as the same node type. There's no way to say 'this KR is also an Objective one level down' without duplicating the goal or losing the rollup integrity.
What we've tried so far:
- Creating the team objective as a child of the company KR works visually but breaks progress rollup logic
- Duplicating the KR as a standalone team objective and linking them manually creates drift, two sources of truth
- Flattening the whole thing to two levels loses the team ownership layer entirely
None of these feels right at scale. When you have 6+ teams, each with their own objectives rolling into 4-5 company KRs, the manual overhead compounds fast.
Curious whether others have found a workable pattern here:
- Are you modeling this differently in Atlassian Goals?
- Have you accepted the two-source-of-truth tradeoff and built a process around it?
- Or have you given up on native Goals for this use case and moved tracking elsewhere?
Would especially love to hear from folks running OKRs across more than 3 teams. What does your hierarchy actually look like in practice?
