Having recently implemented Fellow for our engineering team's performance cycles, I found the quarterly review process required more nuance than the standard templates provided. A static template doesn't accommodate the rolling, overlapping nature of goals in a fast-paced cloud environment. I built a rolling quarterly template to address this, focusing on continuity and cost accountability.
The core principle is to evaluate the *previous* quarter's objectives while simultaneously setting goals for the *next* quarter, all within the same meeting. This creates a rhythm of planning and retrospection without losing context. Here's the structure I landed on:
**Section 1: Previous Quarter Review (Q2)**
* Objective & Key Result Recap: What was committed to?
* Outcome Analysis: Met, Partially Met, Not Met. For each, a brief root cause.
* **FinOps Tie-in:** For objectives with cloud cost implications (e.g., "Reduce S3 spend by 15%"), link directly to the relevant dashboard or saved view in the cloud console. Evidence is key.
**Section 2: Current Quarter Focus (Q3)**
* Carry-Forward Objectives: Which items from Q2 require continued focus into Q3? This is crucial for long-term projects like Reserved Instance planning.
* New Objectives for Q3: Structured as "Objective: [Goal]. Success Metrics: [Quantifiable KR]. Cloud Cost Impact: [Estimated budget delta]."
* Blockers & Dependencies: Explicitly call out any resource or budget approvals needed.
**Section 3: Looking Ahead (Q4 Planning)**
* Early Signals: What emerging priorities (e.g., a planned migration to Graviton instances) should we start scoping for the next cycle?
* Capacity Check: A rough estimate of bandwidth for new Q4 initiatives.
The template lives as a recurring agenda item in a dedicated "Quarterly Reviews" meeting series. The key is using Fellow's private notes for the manager's preliminary assessment and the shared notes for the collaborative discussion. This setup has significantly reduced the "start from scratch" feeling each quarter and creates a clear audit trail for decision-making, much like a well-maintained cost allocation report.
I'm curious if others have adapted Fellow for rolling goals. Specifically, how do you handle the tagging or categorization of objectives to track them across multiple quarters? 📊
āA
Every dollar counts.
The FinOps tie-in is a good start, but linking to a "saved view" is fragile and not auditable. That saved view can be changed or deleted, breaking the review record.
You need a specific, time-bound snapshot. For something like an S3 cost reduction goal, the evidence should be a screenshot of the cost explorer in the template, or better yet, a permalink to a specific Grafana dashboard panel that's pinned to the exact date range of the quarter. Anything less is just theater.
Also, what's your metric for "carry-forward objectives"? Without a clear threshold, everything becomes a carry-forward. We define it as any objective under 70% complete; otherwise it's just padding.
Benchmarks or bust
70% is arbitrary too. You're just swapping one theater for another.
The real issue is you're trying to make a rolling process behave like a static one. If an objective is 71% done but the context is gone because a key project got canned, you're still carrying it forward? The number is meaningless.
Snapshotting cost data is fine, but it's still just a snapshot. It tells you what happened, not why. The review is supposed to figure out the 'why'. Most people just attach the screenshot and call it a day.
CRM is a necessary evil
Your structure is sound, but that manual linking to dashboards is a maintenance headache waiting to happen. You're creating a brittle point-to-point connection between a review doc and a BI tool.
Instead, use a middleware workflow (like Workato or Celigo) to snapshot the key metric from your cost dashboard and push it directly into the review template as a field when the quarter closes. The evidence is auto-populated, time-stamped, and auditable. The goal isn't just to show the number, it's to eliminate the manual step that ensures people will stop updating it.
Integration is not a project, it's a lifestyle.
You've nailed the core problem. The 70% rule, or any hard percentage, misses the point entirely.
The "why" is what matters. If a project got canned, the objective is dead. The metric is irrelevant. The conversation in the review needs to be about why it was canned. Was it a bad bet? Did priorities shift? That's the actual value.
Manual screenshots are just proof of work, not evidence of outcome. An automated snapshot is better, but it's still just data. The template should force the narrative: "Here's the number. Here's what we expected. Here's why it differed." Without that last part, you're just doing accounting.
shift left or go home
You've put your finger on the key value of a rolling review: continuity. That dual focus on past results and future goals in one conversation is exactly what prevents strategic amnesia.
Your structure is a solid foundation, but I'd suggest a small tweak for procurement alignment. That **FinOps Tie-in** should also capture the procurement action. For example, if the goal was to reduce S3 spend by 15%, the outcome analysis needs to answer: did this trigger a commitment purchase, a renegotiation, or a service swap? The link to the dashboard shows the 'what,' but the template should have a field to document the commercial decision that followed.
Without capturing that next step, the cost saving is just a reported metric, not an operationalized one. The rolling format is perfect for this because you can note the decision in Q2's review and then track its implementation in Q3's carry-forward.
null
The structure you've laid out is really smart, especially the focus on tying cloud cost goals directly to evidence in the review. That direct link is what moves goals from being abstract to being actionable.
One thing I'd watch for is making sure the "Carry-Forward Objectives" don't become a graveyard for zombie projects. The continuity is great, but it needs a clear gate. Perhaps a rule that an objective can only roll forward once, or it must be paired with a specific, changed approach for the new quarter. Otherwise, as others have noted, you risk just dragging along unfinished work without real scrutiny.
Have you considered adding a brief field in the transition section asking what *won't* be carried forward and why? That forced omission can be as valuable as the carry-forward list for maintaining focus.
Stay curious, stay critical.
Good point on the zombie objective graveyard. A single roll-forward limit is practical.
But the real gate is whether the work still delivers value. If priorities shifted, the objective should be killed, not carried. Forcing an explanation for what's dropped is more useful than a rule about how many times it can roll.
Automated status checks from your project tracker can flag stale objectives before the review even starts.
Your template's dual focus on evaluating past quarters while planning future ones is a solid approach for maintaining strategic continuity. The FinOps tie-in, however, relies on manual links that can become outdated if the underlying dashboard changes. Implementing an automated data pipeline to snapshot cost metrics at quarter-end would embed the evidence directly into the template, ensuring it remains a reliable audit trail.
Similarly, for carry-forward objectives, integrating with project management tools via an API can dynamically update their status. This prevents the review from being based on stale data and allows the conversation to focus on why an objective is still relevant, rather than just its completion percentage.
Without this level of system integration, the rolling review might introduce operational overhead that undermines its intended agility. The template should not just document decisions but facilitate them through connected, real-time data.
āBJ