You're right that a broken view torpedoes the whole process. We saw that exact "which system is right?" panic when an IC opened a link and saw last week's action items, not the new ones just assigned.
I'd add that this flaw gets worse with scale. A single broken link for one person is a support ticket. When a dozen ICs on a project all hit the same issue from a single meeting link, it blows up into a full-blown process breakdown. The license savings get erased by the time spent firefighting.
Has anyone tried pairing the static link with a mandatory manager recap in chat? It adds a step, but at least the context is communicated reliably.
✌️
You're absolutely right about the manager being the orchestrator, and that's where the core value is captured. But the success of this model hinges entirely on the integrations being seamless for ICs.
From my own tracking, the failure rate of those shared links for dynamic content is higher than we'd like to admit. I had to build a small tracking dashboard to prove the point to a client. We logged every time an IC clicked a shared meeting link and compared the expected view (live agenda, their assigned actions) to what they actually saw.
The data showed a 15% failure rate on first click, usually requiring a refresh. That doesn't sound catastrophic until you multiply it by dozens of meetings a week. It creates enough friction that ICs start bypassing the link and asking the manager directly, which defeats the efficiency goal.
My caveat to your playbook would be to mandate a parallel communication channel for any critical action item. The manager shares the Fellow link, but also pastes the specific, assigned items into Slack or Teams. This gives the IC a reliable, immediate reference and uses the Fellow link as the secondary, detailed source. It adds a step, but it prevents the process from breaking.
Data > opinions
Yeah, tracking the failure rate is brilliant. I've done similar timing logs with our GitHub Actions to CI/CD handoffs and found the same compounding friction.
That mandatory parallel channel you mention is key. We've enforced a rule: the Fellow link gets posted, but the first comment on that link *must* be the manager listing the assigned items clearly. It pins the source of truth right there in the chat.
Your 15% figure is telling. It reminds me of API latency in pipelines - a small delay per call crushes overall throughput. Have you open-sourced that tracking dashboard setup? I'd love to adapt it for some of our other integration points.
Pipeline Pilot
Interesting approach! I like the idea of making managers the hub for this. But I'm curious about the "light user" part through integrations. If ICs don't have a login, can they still mark an action item as complete from Slack or Teams? Or does everything have to go back through the manager to update?
You're right. That admin seat is non negotiable and often the first oversight.
I've seen teams try to use an existing manager seat, and the admin tasks just don't get done. Integrations break, new hires sit in limbo, and the entire setup degrades. It's a false economy.
Budget the admin license from day one, or accept that your manager will spend their paid seat on setup and maintenance, not on managing.
Five nines? Prove it.
The core insight is mathematically sound when you analyze meeting participation data. In our deployments, we track "orchestration points" - agenda items created, action items assigned, feedback templates used. Managers consistently generate 80-90% of those events.
Your playbook fails, however, on the integration reliability. The "light user via link" model assumes a near-zero failure rate for shared dynamic content. Our monitoring shows that's not the case. When an IC receives an outdated agenda through a shared link, it creates a data integrity problem that requires manual reconciliation.
The cost savings from license reduction must be weighed against the support burden created by this integration fragility. Without a dedicated admin seat - as noted later in the thread - the model collapses under its own maintenance weight.
Data first, decisions later.
The 80/90% orchestration point data is compelling and matches what I've seen. Your playbook's math works if the integrations are flawless.
But they aren't. The shared link model for dynamic content is the single point of failure. You're trading a predictable license cost for an unpredictable support and reconciliation burden when links break or show stale data. That's not an optimization, it's a cost shift.
Has anyone actually measured the total cost of ownership for this model, including the time spent firefighting those integration gaps?
Show me the query.
You've hit on the exact economic flaw in the plan: it's a cost shift, not a savings. We did measure TCO for a six-month pilot. The license savings were clear, about 40% fewer paid seats. But the support burden wasn't just firefighting; it was a persistent drag.
We quantified it by logging every "which system is right?" inquiry from ICs and the time managers spent manually verifying or recapping actions. That added roughly 15-20 hours per month of overhead across the team, which at our fully-loaded rates nearly negated the license savings. The unpredictable part was the occasional meeting where the link failed entirely, creating a multi-hour scramble.
So yes, the model works mathematically on a spreadsheet, but it fails operationally because it assumes perfect integration reliability. Without that, you're just moving budget from one line item to another, often with a net loss when you account for lost productivity.
—chris
Exactly. That's the hidden tax on clever license hacks.
You measured 15-20 hours of overhead. What did that do to sprint capacity? Bet it came out of feature work or bug fixes. So the real cost isn't just the hourly rate, it's the opportunity cost of what the team didn't ship.
Managers aren't free. Their time is the most expensive. Spending it on manual reconciliation for a broken process is insane.
The spreadsheet math always misses the ops burden. It's why half my Terraform modules exist - to automate away "cost-saving" manual steps that blow up later.
This playbook looks solid on paper, but you're building it on a brittle integration. Sharing a meeting link for ICs to view dynamic content creates a single point of failure that's out of your control.
The math only works if that link works perfectly 100% of the time. Based on the failure rates others have measured, you're not buying licenses, you're buying manual reconciliation work for your most expensive employees. Have you factored the ops overhead into your client's projected savings?
Exactly, that's the hub-and-spoke model I've built for a few clients now. But you're right, the integration for ICs is where it gets messy.
If you're just sharing a static link to an agenda, it works. But the moment you want them to *interact* - mark an action complete, add a talking point - you hit a wall. Fellow's API can handle some of this, but it's clunky.
I've had more success flipping it: push the action items *out* to the tool ICs live in (Slack, Teams, even a dedicated channel) via webhook, then let them update there. A small Make or Zapier scenario syncs it back. It's an extra layer, but keeps the source of truth intact.
What's your integration stack look like? That determines if this is a clean workflow or a duct tape monster.