Alright, let's pull back the curtain on this one. We've been running Fellow for about 18 months now, and I was the skeptic who got tapped to lead the "all-hands integration" project. The mandate was clear: one source of truth for meeting agendas, notes, and action items, especially for our massive, 250-person, bi-weekly engineering all-hands.
The promise was seductive—seamless integration with Google Calendar, shared agendas where everyone can add topics, and action items that magically sync to Jira. Our VP of Eng was sold. My SRE brain, however, immediately started looking for the failure modes and the observability gaps. How do you *measure* the effectiveness of a meeting tool?
Here’s the real talk, with metrics we tracked:
* **Adoption Rate:** We enforced usage for the all-hands. 100% calendar integration. But *voluntary* usage for topic submissions? That started at a dismal ~15% of invites. We had to run a parallel "topic collection" Google Form for six months. The turning point was when we started displaying the Fellow agenda link **in the Zoom chat** as the first message. That boosted live submissions to ~65%.
* **The Action Item Black Hole:** This was the biggest pain. The Jira integration *works*, but it's noisy. Every action item creates a Jira ticket. For an all-hands with 20+ action items (think "team X to investigate latency spike"), it flooded our boards. We had to create a dedicated "All-Hands Actions" project with a custom workflow. Our critical metric here was **time-to-acknowledge**. We aimed for '{fellow-all-hands}'
AND status = 'Created'
AND ticket.created < NOW() - INTERVAL '24 hours';
```
* **The Performance Quirk:** Fellow's web app is fine, but the mobile experience during a live all-hands (when everyone is frantically taking notes) introduced latency. We saw anecdotal reports of "notes not saving." We couldn't instrument this directly, but we correlated Zoom drop-offs (people leaving early) with a spike in "unsaved changes" warning Google Analytics events from Fellow's client-side logging. Not ideal, but a workaround.
**The Verdict after 18 months:**
We still use it. The centralized record is invaluable for post-incident reviews of announcements and decisions. Searchability beats scattered Google Docs.
But is it the *single* source of truth? No. It's a **source**. We treat its data like a telemetry stream—useful, but requiring correlation with other sources (Jira, Slack archives, Zoom recordings). The value isn't in the tool itself; it's in the **process rigor** it forces upon us. The metrics we built around it (adoption, acknowledgment time) are what made it successful, not the features.
For any team considering this: don't just roll out Fellow. Roll out a *measurement plan* for your meeting hygiene. The tool will follow.
-- sre_tales
-- sre_tales
Ah, the action item black hole. We observed a similar decay pattern, though ours was less about sync failures and more about social ones. The Jira sync created tickets, but without defined owners or due dates, they just became backlog noise. Our p95 time-to-first-comment on those auto-generated tickets was something like 14 days.
We ended up instrumenting the process itself - a simple gauge in Grafana counting open action items by age bracket, sourced by querying Fellow's API. The VP's weekly report included that graph. Nothing focuses the mind like a public chart showing 50+ items rotting in the 30-60 day bucket.
The real metric that mattered, though, was the ratio of agenda items that resulted in a *discussion* versus those that were just pre-read updates dumped into the doc. That number told us if the tool was creating a better meeting or just a more documented one.
P99 or bust.
The API integration is clever. But you're just monitoring the symptom.
You need to enforce the policy at creation. Action items without a defined owner and a due date shouldn't be createable. That's a process control failure, not a monitoring gap.
Your Grafana chart is a lagging indicator. It shows the process already failed.
Least privilege is not a suggestion.