Standups and Status Updates: A Practical Guide for Engineering Teams
A working guide to standups and status updates: what they're for, how they fail, and the tooling worth knowing, for engineering leads who want actual signal.
By Ellis Keane · 2026-04-17
Picture a Tuesday morning, fifteen minutes past nine. Seven engineers, a PM, and a tech lead are standing (some of them actually standing, most of them on Zoom with one earbud in) for the daily ritual – the one that was meant to consolidate standups and status updates into a single fifteen-minute touchpoint and has instead become a chronological recitation of yesterday's tickets. The tech lead goes first, because he always goes first. He says he's continuing on the migration. He said that yesterday too. He'll say it tomorrow. The engineer next to him reports that she pushed a PR, the one she mentioned on Friday, which is still waiting on review. Nobody in the meeting reviews PRs during the meeting, but everyone nods sympathetically. By the time the fifth person speaks, two people have quietly opened Slack. By the seventh, the tech lead is mentally drafting his reply to the VP who wants a status slide by lunch.
This is the standup most engineering teams are actually running, and if you've been in one this week, you know the particular texture of it – the slight embarrassment of being asked a question whose answer you rehearsed in the shower, the faint guilt of not listening to anyone else, the sense that nothing quite wrong is happening and yet nothing quite right is either. The ritual costs fifteen minutes, produces an hour of downstream translation work for someone (usually the lead), and leaves the team roughly as informed as they were when they walked in. And yet nobody cancels it, because cancelling the standup feels like cancelling the team.
The composite above honestly understates the variety of ways this can go wrong. The worst shape I have personally sat through is the weekly two-hour all-hands where the CEO waxes about nothing in particular – boring status items that do not move the needle and have quietly detached from reality somewhere around the twenty-minute mark. A close second is the daily standup that feels forced: everyone is obligated to give an update, the schedule is first-thing-in-the-morning for some engineers and end-of-day for others on the other side of the world, nobody really cares what anybody else is saying, and there is almost always a superior who is either in overdrive (draconian about every last aspect) or phoned-in (doing it because it is "what we do"). Both shapes are, at heart, the same failure. A ritual that has survived its usefulness.
The failure mode above isn't a people problem, it's a format problem – most teams are running one ritual to do the job of two. This piece separates them. Standups and status updates look similar on the surface (both report state, both happen on a cadence) but they're different tools solving different problems, and collapsing them is how the rot starts. I'll cover both halves, name the distinct failure modes of each, and try to be honest about where we're still figuring things out (which is a lot of places, frankly) and where the evidence is clearer.
The difference between standups and status updates
This is the most important distinction in the whole piece, and most teams have never drawn it explicitly. A standup is a synchronous meeting. A status update is an asynchronous artefact. They are not interchangeable, and the cost of treating them as if they are is the majority of the pain that shows up in retros.
A standup exists to unblock the team for the next twenty-four hours. That's it. That's the whole job. You gather the people who are coupled on a piece of work, you find out what might go wrong today, you make sure nobody is silently stuck, and you get out. It is a working meeting with a narrow, time-boxed purpose. The output is a shared understanding of what needs human attention in the next day, not a record of what happened in the last one.
A status update, by contrast, exists to leave a readable trace. It's written for people who weren't in the room – the manager skipping this sprint, the PM on holiday, the stakeholder two teams over who needs to know whether the integration is on track. A status update is a persistent, scannable artefact that says "here is what happened and here is what's happening next." You read it on your own time, at your own pace, and you don't need anyone else to be available when you do.
These two things answer different questions, for different audiences, on different clocks. A standup answers "what do we need to talk about right now?" A status update answers "what should I know if I wasn't there?" The moment you try to collapse them – usually by asking everyone to give a verbal status update in the standup, which is exactly the failure mode I described at the top – you get a meeting that's too long to run daily and too shallow to substitute for a written record. You get the worst of both formats.
Standups and status updates answer different questions on different clocks. A standup is a meeting that unblocks the next day's work. A status update is an artefact that leaves a record for people who weren't there. Collapsing the two into one ritual is the root cause of most of the status pain that ends up in retros.
The failure mode has a particular signature. Standups that drift into status-update territory develop a characteristic cadence: each person speaks in a chronological narrative (yesterday, today, blockers), the lead takes quiet notes to translate into a doc afterwards, and the meeting runs long because narrating a day takes longer than identifying what's risky about it. Status updates that drift into standup territory develop a different pathology: they become reactive, timed to meetings instead of readers, full of real-time reactions and unfinished thoughts, and they lose the property of being useful later. If your standup runs over twenty minutes, it's probably a status meeting pretending to be a standup. If nobody reads your written updates, they're probably standup notes pretending to be documentation.
Synchronous standups: what they are for
A good standup is boring. That's the first thing to say, and it's the thing most people resist hearing. A well-run standup should feel like a crew check – brief, structured, slightly repetitive, and over quickly. The goal is not for the meeting to be interesting. The goal is for the next twenty-four hours of work to be unblocked.
Synchronous standups work best when three conditions hold. The team is small enough (somewhere between three and ten people, with eight as a soft ceiling). The work is coupled enough that there are real dependencies to surface. And the people attending actually have the authority or context to act on what they hear, same day. If you've got fifteen people in a standup, or you've got a standup where nobody present can unblock anyone else, you don't have a standup, you have a ceremony, and the ceremony will keep expanding until someone has the nerve to cancel it.
The questions you ask determine everything else. The classic three questions – what did you do yesterday, what are you doing today, any blockers – are the reason most standups feel like status theatre, because they optimise for memory rather than forward-looking risk. I've written a lot more about this in a dedicated piece on standup questions for engineering teams, and I'd rather not rehash the whole argument here, but the short version is that questions like "what's the riskiest thing on your plate?" and "where are you waiting on someone else?" produce far more useful answers in far less time. If you try any single change to your standup this quarter, change the questions before you change the tool.
Timeboxing matters more than people admit. A fifteen-minute hard ceiling for a team of eight is tight but achievable. Two minutes per person is a reasonable target. If you've got the discipline to actually cut people off, do – warmly, but firmly. The tangents that kill standups ("oh that's interesting, have you tried...") are almost always things that should be a follow-up conversation between two people, not a real-time debate in front of five spectators. If something genuinely needs group discussion, agree on it in the standup, take it offline, and reconvene the right people afterwards. There's a separate rabbit hole around parking-lot conventions and why most teams hold their standup at the wrong time of day (a surprisingly underrated variable) in this piece on making standups more effective – worth a read if your timeboxing problem is actually a scheduling problem in disguise.
Standups fall apart under four conditions, and it's worth knowing them so you can recognise when to change the format rather than abandon it. They fall apart when the team is distributed across enough time zones that synchronous meeting time is actively painful for someone. They fall apart when the work is loosely coupled (each engineer on their own isolated stream, with no real dependencies between them), because there's nothing to unblock. They fall apart when they become management reporting theatre, where the lead uses the meeting as a source of weekly-report fodder and the engineers know it. And they fall apart when the team has grown too large, because a standup of twelve is not a standup, it's a roundtable. In any of those cases, the right move is usually not "fix the standup" – it's "drop the standup and lean harder on the asynchronous layer."
Async status updates: what they are for
If the standup is the working meeting, the status update is the record, and records are valuable precisely because they don't require everyone to be in the same place at the same time. A good status update is the thing a manager reads on a Monday morning with a coffee, or a teammate catches up on after two days off, or a stakeholder skims before a budget meeting – persistent, scannable, and undemanding in the sense that it doesn't need you to say anything back for it to do its job.
The format matters a great deal more than people think. The best written status updates I've seen share a few properties – they lead with the state (on track, at risk, slipped), they name one or two things that changed since the last update, and they name the next decision that's due. That's often it. Three or four lines, maybe a link to a board. The worst status updates are, unsurprisingly, the ones that try to narrate everything: "Monday I did this, Tuesday I did that, Wednesday we had a meeting..." Nobody reads these. The writer knows nobody reads them. The reader knows the writer knows. And yet the ritual continues, because cancelling it feels like cancelling the accountability it was meant to provide. The fix isn't to cancel the update, it's to restructure it. The manager-facing version has a different shape than the team-facing one, and that asymmetry – the fact that the same "status" word describes two genuinely different artefacts – is where most of the trouble starts, which is why there's a separate piece on the daily-status-to-manager pattern specifically.
Cadence deserves more thought than it usually gets. Most teams default to daily written updates because that's what the template they found on Notion suggested, but daily is almost always wrong. Daily updates either repeat yesterday's information (because nothing changed in twenty-four hours) or compete with the standup itself (because both are trying to answer the same question on the same clock). The exceptions are real but narrow – active incidents, launch week, the first fortnight of a new team forming, or any period where the situation genuinely is changing every twenty-four hours. Outside of those, a weekly written update for leadership, paired with either a daily standup or a very light daily thread for active coordination, is a more honest match to how engineering information actually changes. Monthly is fine for directors. Quarterly is for the board.
Standup (synchronous)
- Purpose – unblock the next twenty-four hours of work
- Audience – the coupled team, same room (or call)
- Format – brief verbal exchange, risks and dependencies first
- Cadence – daily or every other day, under fifteen minutes
- Failure mode – drifts into chronological status narration
Status update (asynchronous)
- Purpose – leave a readable trace for people who weren't there
- Audience – managers, stakeholders, future-you
- Format – written, state-led, scannable in under thirty seconds
- Cadence – weekly is honest for most teams, daily is usually theatre
- Failure mode – drifts into real-time reactions and alibis
A status update that will get read has three properties. It's short enough that skimming it takes under thirty seconds. It foregrounds what changed, not what happened. And it's written for the reader's question, not the writer's anxiety – which is to say, it answers "is there anything I need to do?" and "is there anything I need to know?" rather than "have I demonstrated enough visible effort this week to justify my salary?" The last one is the quiet engine behind most bad status updates, and it's worth naming because it can't be fixed with formatting alone. If your team's updates read like alibis, the problem is culture before it is template.
Status update fatigue
At some point the ritual becomes theatre, and the team knows it's theatre before anyone is willing to say so. Status update fatigue is what happens when the reporting layer has grown large enough that describing the work starts to eat the work. It's not about any one meeting or one document being too long. It's about the cumulative weight of translating the same information across formats, tools, and audiences, over and over, every week.
The signs are consistent across teams. Compliance starts to slip – first a missed day here, then a terse update there, then the "same as yesterday" entries begin appearing. People start copy-pasting ticket titles into the update field, because ticket titles are right there, and writing a genuine sentence about a ticket feels like redundant work. The leadership-facing summary stops reflecting the real state, because the gap between the board view and the written update widens until someone (usually the lead) becomes the human reconciliation layer. And eventually the rituals themselves become a target for retro complaints – "can we kill standups?" – but the underlying cause isn't identified, so the next team just reinvents the same cycle with a different tool.
I've watched each of those four shapes play out at different times – the drift from specific to vague, the copy-paste tell, the disappearing blocker, and the update that quietly becomes the work it was meant to describe – and usually more than one of them in the same team before anyone is willing to name the pattern.
I traced the forensic timeline of a single week of this in a dedicated piece on status update fatigue, and the maths of it was worse than I expected when I actually did the arithmetic. For a team of five doing what they thought was a lean process, the total came out to roughly eleven person-hours a week – fifteen minutes of daily standup times five people times five days (six hours), plus the lead's hour of writing up the weekly report, plus four engineers spending twenty minutes each drafting their section of it, plus the hour of prep and follow-up the lead did around the monthly report. That's a working day of collective engineering capacity, every week, spent describing the work rather than doing it.
If your team's updates read like alibis, the problem is culture before it is template. attribution: Ellis Keane
The fix is not "be more disciplined." Discipline is not a strategy. The fix is some combination of three things: kill the translation chain (one canonical source of truth, not a doc translated from a board translated to a deck), reduce the ceremony count (one weekly written update beats three daily ones), and automate the mechanical parts. The last one is where tooling genuinely helps. If your tools already know what PRs merged, what issues moved, what threads resolved, the transcription step doesn't need a human. I covered the practical mechanics in a piece on automating status updates, and while I'd point out that automation alone doesn't fix a culture problem, it does at least stop you paying engineers to be a slower, less accurate version of a database query.
Tooling landscape
The market of "async standup" and "team check-in" products is crowded but it's mostly variations on the same theme: prompt people to write updates, aggregate them, display them back to the team. The useful axes of comparison are friction to respond, whether the updates live in Slack or a separate app, and whether there's any attempt to correlate the updates with what the tools actually show happened.
Range is the most polished, with structured daily rituals and a social team feed – good for teams that value the writing ritual, same failure mode as the category (compliance slips). Geekbot is the Slack-native default, virtuous in its simplicity but limited by Slack itself being a conversation tool, not a documentation one. Dailybot has leaned hardest on AI summarisation, which helps when input is large and variable and is mostly decorative when five engineers write three lines each. Spinach and Fellow sit closer to the meeting-notes side of the ledger, better for "nobody remembers what was decided" than for "nobody reads the written updates." I've written longer per-tool breakdowns on Range, Geekbot, Dailybot, and Fellow for anyone specifically evaluating them.
Then there's the custom-script pattern, which is what I see a lot of engineering-heavy teams quietly adopting when the off-the-shelf tools don't fit. Someone writes a script that pulls PRs merged, issues moved, and a couple of Slack channels, and emails it out as a draft status update each week. The engineer or lead then edits it, adds judgment, and sends it. It's not elegant, but the teams I know that do this tend to report the lowest status-update fatigue, because the mechanical layer is handled and the human-judgment layer is what stays.
The weekly and monthly reporting layer
The layer above the daily grind – weekly reports, monthly updates, quarterly business reviews – is where most of the real organisational damage from status fatigue actually gets done, because each translation introduces loss, compression artefacts, and a quiet pressure to round up. By the time information reaches the director level, the "on track" in the slide deck has almost no shared definition with the "on track" the engineer said in Tuesday's standup – they're both English words, they just no longer mean the same thing.
A sensible pattern is to make the weekly update the primary human artefact and let everything upstream of it be derivative. That is – the weekly written update is where judgment gets added, risks get named, and the state of the work gets committed to text, while the daily standup produces no document at all, the monthly update is an aggregation of the weeklies, and the quarterly is an aggregation of the monthlies. One human-authored layer, three derivative layers, no additional writing required. The practical template for what the weekly itself should actually say (mostly: state, what changed, what decision is due, who's unblocked and who isn't) is walked through in this piece on what my team actually did this week, which doubles as a template for the Friday skip-level note most new engineering managers find themselves having to write and immediately dreading.
When teams start getting serious about reducing the reporting burden, the usual next move is partial automation of the derivative layers – aggregating weeklies into a monthly and monthlies into a quarterly in a largely automated way (there's a concrete version of this for anyone who wants the mechanics). The lesson that keeps repeating across every variation I've seen: automation works well on the transcription and aggregation, and works badly on the judgment. Which is exactly the division of labour you want.
Make the weekly written update the one human-authored layer, then derive everything else from it. One piece of honest prose a week beats five compressed translations of the same information into different audiences' formats.
Where this is all heading
What I've watched hold up so far, in the handful of teams who've genuinely cut their status-reporting burden rather than just reshuffling the ceremony, is a quiet move towards tools that do the mechanical research before a human sits down to write – not tools that generate the update, but tools that assemble the raw material for it. Which PRs merged into which branches, which Linear issues closed against which milestones, which Slack threads resolved a decision, which Figma comments flagged something that's now blocking – all of it is already in your tools; the problem is that it's in six different tools, and the human currently does the stitching across them by hand (badly, late, and with a cup of cold coffee).
(Full disclosure, since I'd rather say this plainly than bury it: this is also roughly the design we're building into Sugarbug.) It connects to GitHub, Linear, Slack, Figma, Gmail, and calendar, and builds a knowledge graph so that when a PR closes a Linear issue that was discussed in a Slack thread that referenced a Figma comment, the graph knows that's one story, not four. A concrete example from my own week: a Figma comment flagged a spacing regression, a Linear issue was filed referencing it, the fix landed in a PR that merged on Thursday, and the follow-up QA got confirmed in a Slack thread on Friday. In my old flow that was four separate entries across four tools that I had to reconcile at week's end; in the stitched-graph view, it was one line in the weekly update. We haven't figured out all the edge cases yet (genuinely, there are a lot of them, and every new team throws up a new one), but the research layer is where I'm confident the value is. For what it is worth, the two of us building Sugarbug also run our own short sync cadence – daily or every few days, with a fixed structure – which is exactly the small-coupled-team shape this guide describes earlier. It works at two people for the reasons above; whether the same pattern scales is of course a different question.
You could build a version of this yourself with a weekend of scripting, and some teams do. That's honestly a reasonable choice. The thing we're trying to solve that the weekend script doesn't is the cross-tool stitching – the part where a Slack thread and a Figma comment and a Linear issue are actually the same story, and the graph knows it. If that stitching isn't valuable for your team, a cron job and a couple of API calls will probably get you most of the way.
Closing
The pattern matters because, by my rough count across the teams I've worked with and watched closely, most engineering teams spend somewhere in the range of eight to twelve per cent of their collective working time on some form of status reporting, and that's before you count the meetings about meetings. Your number might be lower, and if it is, good for you – but the ones I've measured honestly have always been higher than the leadership layer assumed. Getting this right is not a productivity hack. It's a budgetary choice about how much of your engineering capacity you want to spend describing work versus doing it.
You'll know you've got it wrong when the ritual starts absorbing the content it was meant to describe – when the standup becomes a mini status meeting, the status update becomes a performance, and the team quietly stops believing any of it reflects reality. You'll know you've got it right when the standup is boring, the written update is short enough that people actually read it, and the question "what's the team working on this week?" can be answered in thirty seconds by anyone who bothered to check.
If you've got this far, the one thing I'd leave you with is that most teams' problems with standups and status updates aren't tool problems or template problems, they're question problems. Change the questions and the ritual will reshape itself around them. Keep the questions the same and no platform migration will save you. Start there.
Get signal intelligence delivered to your inbox.
Frequently Asked Questions
Q: What is the difference between a standup and a status update? A: A standup is a short synchronous meeting whose job is to unblock the team for the next twenty-four hours – risks, dependencies, and decisions that need a human in the room. A status update is an asynchronous written artefact whose job is to leave a record that someone who wasn't in the room can read later. They answer different questions, for different audiences, on different clocks. Collapse them into one ritual and you get a meeting that's both too long to run every day and too shallow to replace the written record.
Q: How often should engineering teams do standups and status updates? A: Daily standups work for teams under about ten people who are genuinely coupled on the same piece of work. Once a week is usually plenty for teams that are loosely coupled or operating across time zones. Written status updates are better on a weekly cadence for leadership, with a separate lighter-weight daily note if async coordination needs it. Doing both ceremonies daily, synchronously and in writing, is how status fatigue starts.
Q: Should we replace our standup with an async tool like Geekbot or Range? A: Only if the standup itself is the bottleneck. If your team stands up reliably in fifteen minutes and walks out with clearer plans, keep the meeting. If the meeting has become a recitation of yesterday's tickets with no decisions taken, the problem isn't the medium, it's the questions. Switching to an async tool with the same three questions just moves the theatre into Slack. The async tools earn their keep when teams are genuinely distributed or when the format is redesigned to surface risks rather than activity logs.
Q: Does Sugarbug replace our standup tool or sit alongside it? A: Sugarbug sits alongside it. It connects to GitHub, Linear, Slack, Figma, Gmail, and your calendar, then builds a knowledge graph across those sources so the mechanical half of status reporting – what shipped, what merged, which tickets moved, which threads resolved – is already stitched together by the time a human goes to write the update. You keep whatever standup format is working; Sugarbug handles the research layer underneath it.
Q: Can Sugarbug generate an automated weekly status update for engineering teams? A: Sugarbug surfaces the underlying activity – PRs merged, issues closed, decisions taken in Slack threads, Figma comments that flagged risk – organised by project and person, for any time window you choose. Most teams use it as a draft they edit for five minutes before sending, rather than a fully hands-off report. The mechanical layer is automated; the judgment layer stays with whoever is writing the update.
Q: Can AI tools or automation fully replace manual status updates? A: Not fully, and the teams that try end up with polished summaries nobody trusts. The mechanical part of status reporting – what shipped, what merged, which tickets moved – can and should be automated, because that information already exists in your tools. The part that genuinely needs a human is the judgment layer: what's risky, what's stuck, what the numbers aren't showing. A good automation pattern handles the transcription and lets people spend their time on the context that only they have.