That audit trail benefit sounds really useful. I hadn't thought about how the sync data could help other teams like finance.
For the webhook approach, did you run into any issues with authentication between Fellow and Linear? Setting up secure, serverless webhooks is new to me and I'm worried about getting the permissions right.
Great point about the audit trail extending beyond just process hygiene. We've had our data team build a small dbt model that ingests the closure logs from that webhook function, which lets finance attribute initiative costs to specific meeting outcomes. It turned a side-effect into a useful dataset.
On the authentication question with Fellow and Linear, yes, it's a common friction point. Both services use API keys, but the trick is managing them securely in a serverless environment. I use AWS Secrets Manager to store the keys and have the Lambda fetch them at cold start. For the webhook endpoint itself in Fellow, you'll need to whitelist the IP range of your cloud function, which is the part that usually trips people up. Linear's webhook setup is more straightforward, as they just need a valid, publicly accessible URL to POST to.
If you're new to serverless webhooks, start by setting up the outbound part (from your function to the APIs) first, get that working, then tackle the inbound security. That breaks the problem into manageable chunks.
Extract, transform, trust
That's such a good point about the coordination burden being a real signal. The gaming of time estimates feels so familiar - we tried that and everything just became "a couple of hours" to keep it simple.
But I'm curious, how do you actually spot the cross-functional trigger in a meeting? Is it just when someone says "I'll need to check with marketing and engineering," or do you have a more formal flag for it?
Yeah, the gaming of estimates is real. We tried the hours threshold and got the same "two-hour specials" on everything.
What worked for us was linking the promotion trigger to a pull request. If an action item spawns work that needs its own repo and a PR template (especially one that requires multiple approvers from different teams), that's the signal. It's concrete and hard to game because the process enforces it.
The cross-functional check is baked into the review workflow, not just a meeting tag.
git push and pray
I really like your tagging approach, it feels like a clear first step to capture the intent. That `--tag project-candidate` filter is smart for isolating the items you're even considering for promotion.
I'm curious about your sub-task threshold, though. You mentioned the item growing beyond 3-4 sub-tasks as one trigger. In my experience, some tasks are just inherently procedural and generate a list of steps, but they're still a single-owner piece of work. Have you ever had a case where that rule flagged something incorrectly, where moving it to a project board felt like overkill? I'm wondering if adding a second check, like 'has multiple assignees' or 'spans team boundaries,' would help reduce false positives before the export script runs.
Yeah, the authentication part was tricky for me too. I stored the keys in AWS Secrets Manager like user185 said, but I got stuck on the whitelisting. Fellow's IP whitelist kept rejecting my Lambda because it was using a NAT gateway with a dynamic IP.
I ended up having to put an API Gateway in front of the Lambda just to get a static IP for Fellow. It felt like overkill, but it worked. Did you find a simpler way?
The "I'll need to check with..." phrase is usually just a deflection tactic. If that's your trigger, you'll end up promoting everything.
The real signal is when they start naming specific individuals from other teams and those names make it into the actual task description. Even then, that's just coordination. It only becomes a project when you need a separate budget or formal sign-off from those other department heads.
Trust but verify
The sub-task count is a decent trigger, but you're right, it can misfire. We also added a "requires new repo" check after flagging a few procedural tickets. If the work doesn't need its own repository or a dedicated CI pipeline, we keep it as a task.
A multiple assignee check helps, but we've found that using team labels is more reliable for spotting cross-boundary work. A `frontend` task with 5 sub-tasks stays put. A `frontend` task that also gets a `platform` or `data` label gets promoted.
YAML all the things.
Automating the export is smart, but relying on sub-task count is a flawed metric. I've benchmarked this. Items balloon sub-tasks when someone's just detail-oriented, not because they're complex.
Your `--tag project-candidate` during the meeting is the real value. It's a forced, human judgment call when the context is fresh. The automation just executes the decision later.
The link-back you mentioned is non-negotiable for traceability, but I'd argue the status should be "completed - promoted," not "blocked." Blocked implies a dependency to resolve within the same system, which is misleading. You've transferred ownership. The audit trail is the link; the status should reflect the final state change.
Benchmarks or bust