Our engineering retros had become a predictable, low-value ritual. We were cycling through the same three vague action items while our post-incident review cadence slowed to a crawl. The standard "What went well? What didn't? What can we improve?" template in Fellow was failing us; it produced qualitative fluff that was impossible to trend or act upon.
I built a custom template to enforce a data-driven, SRE-aligned retrospective process. The goal is to shift discussions from subjective feelings to measurable system behavior and concrete toil reduction. The template forces quantification and ties discussions directly to our service level objectives.
**Core Sections of the Template:**
* **Incident Context (Pre-Filled):** This pulls in the incident ID, timeline, and impacted services from our PagerDuty integration. No more starting from scratch.
* **Impact Quantification:** A table requiring numeric inputs for:
* Duration of user-impacting degradation (in minutes)
* Scope of impact (percentage of user base or request volume)
* SLO/SLI burn (e.g., "Error Budget consumed: 2.1 hours")
* **Root Cause Analysis (Structured):** A multiple-choice dropdown for primary cause category (Code Defect, Configuration Change, Platform Failure, Dependency Failure, Unknown) followed by a free-text field for the precise trigger. This allows us to generate Pareto charts of failure modes over time.
* **Action Items with Accountability:** Each action item must be tagged with:
* Type: `Mitigation` (fix the immediate issue), `Prevention` (prevent this exact failure), or `Optimization` (reduce toil in the response).
* Owner: Assigned directly in Fellow.
* ETA: A concrete date, not "next sprint."
* **Follow-Up Tracking:** A dedicated field for the link to the post-mortem document in our wiki and the ticket number for the primary prevention work.
Here is the JSON structure of the template as exported from Fellow's API, which you can adapt. The key is in the `items` array, where each object defines a section or field with specific `attributes` to constrain input.
```json
{
"template": {
"name": "SRE Incident Retrospective",
"items": [
{
"type": "text",
"attributes": {
"label": "Incident ID & Link",
"description": "From PagerDuty or incident management system.",
"required": true
}
},
{
"type": "table",
"attributes": {
"label": "Impact Quantification",
"columns": [
{"heading": "Metric", "required": true},
{"heading": "Value", "required": true},
{"heading": "Method of Calculation", "required": false}
],
"description": "Quantifiable impact only. Use SLI/SLO data."
}
},
{
"type": "dropdown",
"attributes": {
"label": "Primary Cause Category",
"options": ["Code Defect", "Configuration Change", "Platform Failure", "Dependency Failure", "Unknown"],
"required": true,
"multiple": false
}
}
]
}
}
```
The results after three months are telling. We've reduced the average time to publish a finalized retro from 5 days to 1.5 days. More importantly, 80% of our action items are now of the `Prevention` type, compared to roughly 30% before. The structured data allows us to feed metrics into our FinOps dashboard, drawing a direct line between incident causes and cloud cost drivers (e.g., a specific platform failure mode correlated with auto-scaling overprovisioning).
The template isn't a silver bullet—it requires discipline to fill in correctly—but it has transformed our retros from conversational post-mortems into actionable engineering audits. I'm interested to see if others have taken a similar structured approach or if you've found different key metrics to be indispensable for continuous improvement.
-- alex