I asked engineering leads how they stop standup action items from dying. Here’s what they said.

Every standup has the same moment. Someone says “I’ll take it — done by Thursday.” Everyone nods. The meeting moves on.

And then, quite often, nothing. No ticket. By Friday the board says “not started”, the PR is already merged, and someone is asking in Slack who owned it.

I posted a simple question in r/TechLeader: how do you stop action items from standups dying before they become tickets? The answers were short, sharp, and more useful than most blog posts on the topic. Here they are, plus what I think each one gets right.

1. “Call for an owner. If nobody owns it, let it die.”

The most upvoted answer. Don’t have anyone write anything down. Ask “who owns this?” out loud. If nobody, including you, cares enough to own it, it wasn’t important.

What it gets right: most dropped action items were never really owned. “We should look into that” isn’t a task. An owner who says yes out loud is the real commitment.

Where it breaks: ownership doesn’t create the ticket. The owner still has to remember it after three more meetings.

1. “Do it during the call.”

Make the ticket before moving to the next item. Thirty seconds, done.

What it gets right: the delay between a commitment and its ticket is what kills it. Five seconds after the meeting, everyone remembers. Five hours later, half do.

Where it breaks: someone has to screen-share Jira and type while everyone waits. On a 10-person standup that’s a lot of people watching one person type.

1. “I use a pencil.”

Honestly undefeated for one person. Writing by hand makes you commit.

Where it breaks: a notebook isn’t a board. Nobody else can see it, so the team’s board still drifts.

1. “A scheduled AI task reads my meeting notes and suggests action items. I reply ‘create 2, 4 and 6’.”

My favourite. One lead runs a daily scheduled Claude task over their Granola meeting summaries. It suggests action items, and they approve them by number.

What it gets right: the machine drafts, the human approves. Nobody has to write tickets from scratch, but nothing gets created without a person saying yes.

Where it breaks: it runs once a day. The ticket still shows up hours after the call, and the board only updates when they remember to reply.

The pattern

Put the four answers together and you get a simple playbook:

Owner said out loud. No owner, no task.
Ticket exists before the call ends. Shrink the time from “I’ll take it” to “ALI-128 exists” to near zero.
A human approves, a machine drafts. Typing tickets is the bottleneck. Deciding isn’t.
Let the code move the ticket. Branch opened → In progress. PR opened → In review. Merged → Done. Nobody should drag cards to reflect work that git already knows about. (Watch out for multiple PRs per ticket, reverts, and tickets that need QA after merge.)
Standup reads from the board, not from memory. If steps 1–4 work, tomorrow’s standup is mostly already written.
Disclosure: I’m building this

I’m a solo developer building Align, which does steps 2–5 automatically. It listens to your Google Meet or Teams call, drafts tickets with owner and due date as people commit, and files them in Jira or Linear (synced both ways) once you approve. GitHub PRs then move them, and the next standup is written from what actually happened.

It’s free to try at meet-align.com. But honestly, the playbook above works without any tool. Even “do it during the call” beats what most teams do.

What’s your team’s version? I’m especially curious whether anyone has made it work with async standups.