Most founders of small service businesses know the feeling. It's 4pm, a client has asked how their project is going, and you don't know. So you open chat and type the same message you typed yesterday: "Where are we on this?"
Then you wait. The answer comes back an hour later, half-complete, and you realise you'll be asking again tomorrow.
The instinct is to blame the team for not reporting. Usually the team isn't the problem. Nobody has been told when to report, in what format, or where, so updates only happen when someone asks. And the person asking is you.
Why chasing doesn't scale
Do the arithmetic on a team of eight. If you ping each person twice a day for a status, that's 16 interruptions for them and 16 conversations for you. Each one costs a few minutes to ask, a few to answer and a few more to get back into the work. Call it 10 minutes all in.
8 people × 2 asks × 10 minutes = 160 minutes a day
160 minutes × 21 working days ≈ 56 hours a month
That's more than a week of someone's time every month, spent producing worse information than a two-minute written update would. And the cost isn't evenly spread: most of it lands on you, the person whose hours are worth the most.
There's a second cost. When updates only happen on request, the team learns that silence is safe. A task that's slipping stays quiet until you happen to ask about it. By then it's three days late instead of three hours.
The fix: make the update a routine, not a request
The pattern that works in small teams has four parts. None of them are clever.
1. One fixed time, the same for everyone
Pick a time when updates are due. End of day works best for most agencies, because it captures what actually happened instead of what someone intended. If your team is spread across time zones, make it "before you log off" rather than a clock time.
The point is that you stop asking. The update arrives because it's 6pm, not because you pinged.
2. Three questions, nothing more
Keep the format so short that nobody can argue it's a burden:
Done today:
Next up:
Blocked or at risk:
That's it. No hours, no percentages, no "mood". If you want more detail on a specific project, ask in that project's thread.
The third line does most of the work. "Blocked or at risk" is where you find out the client hasn't sent the copy, the API key doesn't work, or the design review keeps getting moved. Those are the things you'd otherwise discover on Friday.
3. Show what a good answer looks like
Vague answers are the most common failure. "Worked on the homepage" tells you nothing. Post two examples in the channel where updates go and pin them:
| Weak | Useful |
|---|---|
| Worked on homepage | Homepage hero and nav built, waiting on final copy from client for the pricing section |
| Bug fixes | Fixed 3 of 5 checkout bugs; the tax one needs a decision from you on rounding |
| Meetings | Discovery call with Halden Co; they want a quote by Thursday, I'll draft Wednesday |
The useful versions are barely longer. They answer the question you'd have asked next.
4. A rule for silence
Decide in advance what happens when an update doesn't arrive. The simplest rule: one missed day is fine, two in a row gets a private, friendly question, three gets a conversation in the next 1:1.
Write that rule down and tell people. Then it isn't you being suspicious, it's the process everyone agreed to.
Where the updates should live
The worst place for status updates is a busy group chat. They scroll away in an hour, and you end up scrolling back through noise to find them.
Better options, in rough order of effort:
- A dedicated channel called something like #daily-updates, where nothing else is posted. Free, and good enough for a team of five.
- The task itself. If your team works from tickets, the update goes as a comment on the ticket and the status moves on the board. This keeps the history next to the work, but you still need a way to see the whole team at once.
- A check-in tool that collects the three answers, keeps them per person and gives you one combined view.
In Suprwork, people check in each morning with what they plan to work on and check out at the end of the day with what got done, typed or spoken. You get one written summary of the whole team each day, with blockers pulled out. It doesn't chase anyone for you, so the rule for silence above still applies.
Pair the daily update with a board that tells the truth
Written updates tell you what people say. The board tells you what's actually moving. You need both, because each catches what the other misses.
The board works only if two habits hold:
- Tickets are small enough to move. A ticket called "Build website" sits in progress for three weeks and tells you nothing. Break work into pieces of a day or two, so the board changes daily.
- Estimates exist, so you can see when something runs over. A ticket estimated at 4 hours that has 11 logged against it is a conversation worth having today. If you track time against tickets in one place, you can see that without asking anyone.
When the daily update says "almost done" and the board says the ticket has been in progress for nine days, you've found the one conversation that matters this week.
What to do with the updates once you have them
Reading 8 updates should take you five minutes. Here's the routine:
- Scan only the "Blocked or at risk" lines first. Unblock what you can that evening, because that's the highest-value thing you'll do.
- Check that each person's "Next up" matches what you think the priorities are. If it doesn't, correct it now, not after they've spent a day on the wrong thing.
- Reply to at least one update with something specific. "Nice catch on the tax bug" costs you ten seconds and tells people the updates are read. Updates that vanish into a void stop arriving.
Then, once a week, look across the updates for patterns. The same blocker three days running. A person whose "done" list is consistently thin. A project that appears in nobody's updates at all. Those patterns are what a weekly operating rhythm is for.
When updates still don't come
If you've set all of this up and one person still doesn't report, it's rarely laziness. The usual causes:
- They don't know what counts as done. Their task is vague, so there's nothing clean to report. Fix the task.
- They're stuck and embarrassed. People avoid reporting when the honest answer is "I made no progress". Make "blocked" a normal, safe answer by thanking people for raising it.
- They're overloaded. Someone working across four projects has four updates to write and no time to write them. Check their workload before you check their attitude.
- They think nobody reads it. See above: reply.
Raise it in a 1:1, ask what makes the update hard, and fix that. If after a genuine fix it still doesn't happen, it's a performance conversation, and you now have a clear, fair expectation to point to.
This week
Post the three-question format in a channel tomorrow morning, with two examples of useful answers. Tell the team updates are due before they log off, and that you'll stop asking for status in DMs.
Then actually stop. The first week you'll want to ping someone. Wait for the update instead. If it doesn't come, follow the rule for silence. Within a fortnight most teams settle into it, and you get back the hour a day you were spending asking.