The daily check-in: describing your work in a minute

Why it exists

Fifteen minutes at the start of the day so the team sees the whole picture: who's working on what, what's stuck, who needs help.

The main beginner's misunderstanding: it isn't a report to your manager. You're speaking to colleagues, so they can pick something up, offer advice, or align their work with yours.

Everything else follows from that: what to say, how, and why.

A one-minute template

What you did since yesterday. Not in detail. "Finished the expense form, sent it for review."

What you're doing today. "I'll start on the file export."

What's blocking you. The most important part, and the one most often skipped. "Waiting for access to the test database." "I don't know how the form should behave with an empty list — I need the designer."

A minute. Ninety seconds at most.

What a good answer sounds like

Yesterday I finished the list screen and sent it for review. Today I'll start the file export. One thing blocking me: I don't know what format the file should be — Ivan, could you tell me after this?

Everything is there: a result, a plan, a specific obstacle addressed to a specific person.

What a bad one sounds like

Yesterday I worked on my task, today I'll continue.

Zero information. Nobody understood anything and nobody can help.

Or the opposite:

Yesterday I started by opening the file, looked at the code, then decided I should sort out the database first, went in there, saw the table was named differently, started investigating…

That's a debugging narrative, not a check-in. Such detail belongs in a separate conversation with whoever it concerns.

What not to do

Don't report apologetically. "I tried but didn't finish" isn't needed. "Didn't finish because I got stuck on this" is.

Don't turn it into a discussion. A complex question surfaced? Agree to discuss it afterwards. Otherwise fifteen minutes becomes an hour and half the people sit idle.

Don't hide that you're stuck. The most expensive beginner's mistake. Saying "I've been stuck for three days" is awkward exactly once. Staying silent for a week is costly for everyone.

Don't read out your task list. People can see the board. Say what isn't on it.

If the check-in is written

Distributed teams often post in a shared channel. The rules are the same, plus one: write so it can be read later. No "as we discussed yesterday" — not everyone knows what you discussed.

Signs the check-in has gone wrong

• It lasts forty minutes.
• Everyone speaks while looking at one person — it has become a report.
• Nobody ever mentions being blocked — admitting it has stopped feeling safe.
• Nothing changes afterwards.

If so, that's worth raising at a review. A meeting that helps nobody consumes five team-hours a week.

Practising in advance

On a team project, hold the same check-in every few days, even in writing. Three lines: what I did, what's next, where I'm stuck.

Besides practising the phrasing, it has a side effect: a stalling project becomes visible immediately rather than a month later.