Ask HN: How do small teams make sure recurring tasks don't slip?

[batels]

In small teams(~10), a lot of important work is recurring and operational: checks, reports, maintenance, follow-ups.

These tasks are rarely complex, but they’re easy to forget or assume "someone did it".

How do you assign and track recurring work in a small team?

Do you: - use task managers? - calendars? - informal routines? - just trust it gets done?

What actually works long-term?

[atmosx]

We use Doppler reminders (secrets manager SaaS - no affiliation, it’s just a tool) and Slack reminders for team notifications.

Additionally, we use long and detailed commits that act as “howTos” when manual actions is required - we just link to the commit SHA1 even though we have notion. Git docs are evolving more naturally alongside the code. Now ofc with AI fairly high quality docs can be generated and updated automatically.

[batels]

Makes sense.

Keeping docs close to the code has worked well in my experience too.

[brownfinch]

Our team uses two methods to help with manual but not yet automated tasks.

1) Slack Workflow - used to remind us for recurring but not "have to do right away" tasks. Each of us adds a reaction when they complete the task 2) Recurring calendar invite - for important "must do" tasks where we invite the whole team. The 'owner' will accept the meeting

Being a small team means we each look out of each other, so we kindly remind each other when things could slip through the cracks.

[batels]

I’ve seen similar setups work well in small teams, especially when people actively look out for each other.

[cpach]

For recurring and future tasks that are not automated and is not tracked by any other process I have a page in Confluence Cloud. It contains a table where one column has the due date and the other column a short description of the task. Then I have a weekly reminder that reminds me to look at this page.

If it’s time to do the task but it’s so big that I cannot do it directly I will create a Jira ticket for it.

When the task is done I either remove it from the list, or bump the due date if it’s a recurring task.

[batels]

This works well as a personal system.

The cases I’ve been thinking about are team-level recurring tasks, where execution and ownership need to be visible beyond a single person.

[scrapheap]

Where possible automate them!

From my point of view the power of automation for recurring tasks is less to do with time saved, and more to do with making sure that it will get done and be done the same way every time.

Bonus tip: log the outputs of automated tasks when they run, but only send out notifications of errors - that way you don't train staff to ignore the notifications from the task just because they see it every time the job runs, and instead seeing a notification from it is rare, so they know they need to investigate.

[batels]

Strongly agree. Automation is the ideal outcome whenever possible.

What I keep running into is the gray area between "can’t be automated yet" and "shouldn’t be automated". Things like reviews, checks, approvals, or manual verifications.

The notification fatigue point is especially real. If everything notifies, nothing gets attention.

Do you usually treat non-automatable tasks as exceptions, or do you still rely on routines / trust for those?

[scrapheap]

As a team we use Kanban, so everything being worked on gets a ticket and we walk the Kanban board every morning. So if a task is waiting for someone to review it, then it gets highlighted to the whole team each morning. If a task is blocked until something else happens then it gets highlighted to the whole team.

Walking the board feels a bit awkward and slow at first, but after a few weeks you find that it takes very little time. It certainly works well for us.

[batels]

That makes sense.

I’ve mostly been thinking about lower visibility recurring tasks that don’t always make it onto a board.

[codingdave]

If your team is small, it must be people who are organized and trustworthy enough that you don't need to micro-manage them and track their work. If you find things are slipping through the cracks, you don't have the correct small team. The key hiring focus when you are that small is: "Is this person good enough that I can simply tell them to get it done and it will happen, so I can go work on other things?"

[batels]

I agree this works well for one-off or high-signal tasks.

Where I’ve personally seen friction is with recurring, low-visibility work.

Things people fully intend to do, but that don’t produce immediate feedback.

[mindcrash]

We used to track and plan this ahead in a shared weekly schedule, together with feature work and assignments.

Any good (agile) collaboration system supports this. We did this succesfully in Azure DevOps and GitLab, for example.

[batels]

That makes sense.

Did it still feel lightweight enough for very small, administrative routine tasks?

[mindcrash]

Yes, something like "Update soon to be expired SSL certificates" as a task with a deadline in the weekly planning.

The ops team then could assign the task to themselves whenever they were ready to execute. And as a manager it made tracking and follow up a lot easier.

[grugdev42]

This might sound crazy, but cronjobs which send emails!

A simple email reminder will suffice for most things. Assuming you have good employees, they just need gently prodding. :)

[batels]

Agreed, cron + email is very effective.

The only thing I’ve seen missing sometimes is an explicit acknowledgement, so later you don’t have to rely on memory.