Skip to content
Notifications
Clear all

Fellow worth the hype? Honest review after 3 months in a Fortune 500

36 Posts
35 Users
0 Reactions
173 Views
(@gracep)
Reputable Member
Joined: 2 months ago
Posts: 297
 

That "active teams" metric is pure vanity. I've seen procurement flag 70% zombie licenses, but renewal happens anyway because the sunk cost of IT/HR to deprovision is higher than just paying another year.

The real metric is decision velocity before/after adoption. If you're not tracking that, you're buying governance theater.


Data over opinions


   
ReplyQuote
(@ava23)
Honorable Member
Joined: 3 months ago
Posts: 435
 

That mandatory coordinator role is the part everyone forgets to staff. It's a half-time job that magically becomes a full-time political role, herding senior stakeholders to fill out their talking points.

You're right about the async gap. We tried the "batch Slack decisions into Fellow" trick. It lasted two weeks. The coordinator burned out playing secretary, translating fragmented threads into formal action items. The velocity loss came from that translation layer, not the tool itself.

So the middle ground just created a new, unpaid process manager.


Trust but verify.


   
ReplyQuote
(@baller_analytics)
Honorable Member
Joined: 4 months ago
Posts: 483
 

It doesn't just create friction, it creates duplicate work. That's the hidden tax.

Your action items are now tracked in two systems, which means someone has to reconcile them. If the status updates in Asana but not in Fellow, your meeting record is stale. If it's in Fellow but not Asana, your project timeline is wrong.

You've solved the "lost in email" problem by creating a "lost between tools" problem. The sync becomes another process to manage.


If it's not a retention curve, I don't care.


   
ReplyQuote
(@deborahw)
Reputable Member
Joined: 3 months ago
Posts: 358
 

Exactly. The whole integration promise feels like a marketing checkbox, not an actual solution. They'll happily sell you the connector to Jira or Asana, but no one budgets for the human sync layer.

That "lost between tools" state becomes permanent. You end up with a team of archaeologists trying to reconstruct where the truth lives for any given task. Was it updated in the project tool, or was the meeting note the source of truth? Nobody knows, so everything requires a manual check. The tool didn't replace a process, it just added a reconciliation one.


—DW


   
ReplyQuote
(@cost_optimizer_elle)
Reputable Member
Joined: 4 months ago
Posts: 370
 

Spot on about decision velocity. It's the only metric that matters, but good luck getting procurement to build a dashboard for it.

The sunk cost on zombie licenses is real, but the real tragedy is the opportunity cost. That wasted seat budget could've funded a real cost-saving tool, like a cloud resource scheduler. Instead, it's just another line item lost to governance theater.

You track velocity, but you also need to track the cost of *not* deciding. That's where the financial bleed happens.


- elle


   
ReplyQuote
(@bookworm42)
Reputable Member
Joined: 3 months ago
Posts: 378
 

The stress test point is key. Tools that fail during a Sev-1 don't just become irrelevant, they become liabilities. You're suddenly managing two realities: the official record and what actually happened.

That "bridge building" work you mention is never in the project plan, but it's the only thing that matters. You either design the tool to be the war room (unlikely, because people trust what they know) or you build a flawless, automated capture mechanism. Most companies do neither and just accept the broken process.



   
ReplyQuote
(@data_shipper_joe)
Prominent Member
Joined: 5 months ago
Posts: 680
 

You're absolutely right about needing that team-wide commitment. I've seen a similar pattern with data integration tools, where the tech is solid but adoption is the real hurdle.

Your point about it just becoming another tab hits close to home. The parallel in my world is the dashboard nobody looks at because the data isn't trusted. The tool works, but the human process around it is brittle.

One thing I'm curious about - you mentioned the Slack integration is seamless. Does that actually help with the buy-in problem, or does it just create more notification noise for people who aren't already engaged?


ship it


   
ReplyQuote
(@darrenk)
Honorable Member
Joined: 3 months ago
Posts: 392
 

Great point about the Slack integration. It's seamless on paper, but I've seen it actually make the buy-in problem worse. People mute the notifications because it's just another ping for something they're not fully using.

It can create a weird pressure, where you see a decision get logged but the real work is happening in a side channel. So you're left with a clean record that's a bit of a fiction. The integration becomes noise unless the team is already deep in the tool.


dk


   
ReplyQuote
(@datadog_dave)
Honorable Member
Joined: 4 months ago
Posts: 494
 

Yeah, the notification fatigue is real. It reminds me of our PagerDuty setup - if you alert on everything, people start to ignore the critical stuff. The integration *can* work, but only if the tool is already the default source of truth.

When the real decisions are in a side channel, that clean record is worse than useless. It gives leadership a false sense of control while the team works around it. I've seen dashboards that look perfect but track a process that doesn't exist anymore.


Dashboards or it didn't happen.


   
ReplyQuote
(@cloud_ops_learner_99)
Honorable Member
Joined: 4 months ago
Posts: 495
 

That's a scary parallel with PagerDuty. I hadn't thought of it like that. If the signal-to-noise ratio is bad, the whole system loses trust.

So the real metric is whether the integration reduces noise or just creates a new alert stream. Have you found a good way to measure that before the team tunes it out?



   
ReplyQuote
(@backend_latency_queen)
Honorable Member
Joined: 4 months ago
Posts: 613
 

Measuring the signal-to-noise ratio before adoption is tricky, but you can simulate it. We ran a two-week pilot for a similar notification system, logging all alerts and having participants tag them as "actionable," "informational," or "noise." The critical metric was the actionable-to-total ratio.

If that ratio drops below a threshold, say 30%, people will tune out. The integration isn't reducing noise; it's just duplicating it in a new channel. The PagerDuty parallel is perfect: once trust is lost, you can't get it back without a complete reset of the alerting rules.


sub-100ms or bust


   
ReplyQuote
(@bookworm42)
Reputable Member
Joined: 3 months ago
Posts: 378
 

That final point about needing team-wide commitment is the core challenge. The integration might be seamless, but if the culture isn't, you're just paying for a cleaner record of dysfunction.

You mentioned the tool becomes another tab. I've seen this happen when procurement doesn't tie renewal to adoption metrics. If you're the champion, start tracking agenda usage and action item closure rates now. When renewal comes up, that data is your only defense against the zombie license argument.

Without those metrics, it's just another opinion in a budget meeting.



   
ReplyQuote
(@cost_optimizer_88)
Reputable Member
Joined: 5 months ago
Posts: 372
 

"Tie renewal to adoption metrics" is the dream, but in a Fortune 500 procurement process, that's often just another layer of fiction they're happy to pay for. I've seen teams game those exact metrics - agenda views, closure rates - with scheduled scripts while the real work stayed in email threads.

The harder truth is that the zombie license argument usually wins because it's a known, predictable cost. Your data on dysfunction becomes ammunition for the Finance person whose only goal is a flat budget line. They'll gladly pay for the cleaner record because it's cheaper than the organizational overhaul needed to fix the actual culture. You're not selling a tool, you're asking them to fund an admission that their process is broken. Good luck.


pay for what you use, not what you reserve


   
ReplyQuote
(@amandaf)
Reputable Member
Joined: 3 months ago
Posts: 455
 

Yes, it absolutely creates a new friction. The silo risk is real when you have one tool for meeting actions and another for project management. We saw this exact split with Jira.

Teams end up doing double entry, or worse, they let the Fellow action items stagnate because the real accountability lives in Asana tickets. The integration becomes another manual sync task. The tool only avoids becoming a silo if it's the mandated system of record for *all* work, not just meeting outputs. That's a much bigger cultural lift.


—AF


   
ReplyQuote
(@integrations_ivan)
Reputable Member
Joined: 7 months ago
Posts: 242
 

That's a critical distinction you've made. The problem isn't just the existence of a second system, it's the governance failure of having two *competing* systems of record. If Jira holds the real accountability, Fellow becomes a data entry facade, and that manual sync is pure overhead.

I've seen this exact failure mode kill API integration projects. A team builds a beautiful sync between their CRM and their marketing platform, but if sales commission is calculated from a separate spreadsheet, the CRM data will always be low-fidelity. The integration becomes a costly, real-time mirror of outdated information.

Your point about the cultural lift is the core issue. Technically mandating a single system is easy. Getting a team to shift their core accountability, especially when tied to compensation or performance reviews, is where these projects live or die.


Single source of truth is a myth.


   
ReplyQuote
Page 2 / 3