How to Keep Your Team Aligned without More Meetings
By Onyi N.
Most teams trying to spend less time in standups and retros start by changing the meeting. They shorten them, run them less often, or move updates to Slack. But if the PM still has to follow up for missing information, resolve blockers across design and engineering, relay decisions, or catch people up on what they missed, much of the work remains.
In this article, we look at why fewer standups do not always reduce the follow-up work for PMs, and why actions from retros often lose their context by the next sprint. Then we look at a better way to handle both.
Why standups still create follow-up work
Standups can help you surface blockers early and understand what is progressing, what is blocked, and what needs attention. But identifying a blocker is not the same as resolving it. In many cases, the work starts after standup: someone needs to clarify a requirement, speak to design, pull in another engineer, make a decision, or determine whether the issue affects other parts of the sprint.
You can see this in how engineers describe what happens after a blocker comes up. In one r/ExperiencedDevs discussion, an engineer said that while blockers were sometimes raised during standup, they were usually resolved later in chat or in a separate conversation. In other words, the issue was surfaced during standup, but the work needed to move it forward still happened afterwards.
For PMs, that follow-up can quickly become a significant part of the day. A blocker raised by an engineer may require input from design before engineering can proceed. A decision made in that conversation may affect another task or change what someone else is building. Then the PM has to make sure the outcome reaches everyone who needs it and, ideally, that the relevant work reflects what was decided.
None of those tasks is unusual. Some amount of coordination is part of product management. The problem is when the PM repeatedly becomes the person responsible for finding the latest information, carrying it between people, and reconciling different versions of what has been agreed.
A recent r/ProductManagement discussion shows what that can look like when taken to the extreme. The PM described working in an organization where important conversations happened informally between different people. They regularly had to chase stakeholders individually, deal with conflicting answers, and work out who needed to be involved before they could move forward. In a follow-up comment, they explained that the additional coordination was taking time away from requirements, testing, customer-success training, and other parts of their job.
That example is broader than most standups, but it illustrates the same underlying cost. When updates, decisions, and follow-ups are spread across different conversations, the PM has to spend more time piecing them together and making sure the right people know what happened.
This is why simply reducing the number of standups does not necessarily save as much time as expected. The meeting may disappear from the calendar, while the follow-up work continues elsewhere.
Retrospectives have a different challenge. The issue is not usually the follow-up required to resolve a blocker. It is making sure the team does not lose the reasoning behind the decisions and actions that come out of the retro.
Why retro actions lose their context
A team can leave a retrospective with a clear idea of what needs to change. By the next sprint, however, the specific situation that led to that decision may be hard to remember, even if the action is documented.
Most retro actions come from something that happened during the sprint. A dependency delayed a task. Design was brought in too late. A requirement changed halfway through implementation. The team discusses what happened, understands the effect it had on the work, and agrees on what it should do differently next time.
In that moment, an action like “involve design earlier” makes complete sense because everyone still remembers the work that prompted it. They know which task was affected, where the delay came from, and what might have gone differently if design had been involved sooner.
The problem starts once that action is separated from the rest of the sprint. It is copied into a retro document, Jira ticket, or Confluence page, while the discussions and events that gave rise to it remain somewhere else. A few weeks later, the team may still be able to find the action, but it has become much harder to remember exactly what happened and why the team agreed to it.
One person on r/agile described exactly this. Their team documented blockers, action items, and proposed changes after every retrospective. Yet by the next retro, they could find the document but struggled to remember why they added some items in the first place.
Writing down an action preserves what the team decided to do. It does not necessarily preserve why the team decided to do it.
Consider “involve design earlier.” Without the surrounding history, it is just a reasonable instruction. Its real value comes from knowing what happened when design entered too late: which work was affected, what had to be redone, what decision was delayed, and why the team concluded that earlier involvement would have changed the outcome.
Most teams already have different ways to stop retro actions from disappearing. They put them in Jira, assign owners, maintain a running Confluence page, or review outstanding actions at the beginning of the next retro. Those practices help because they make the action visible and give someone responsibility for following through.
But tracking the action and preserving the reasoning behind it are two different things. A Jira ticket can remind the team that it agreed to change something. It does not automatically bring back the work, conversations, and decisions that made the change necessary.
That is how a team can be disciplined about documenting retros and still find itself revisiting the same problems. The action is still there; they’ve lost the reasoning behind it.
Why moving standups async doesn’t solve the follow-up work
Moving a standup to Slack or a standup bot can solve one obvious problem: everyone no longer has to stop what they are doing and join the same meeting.
That is an improvement, especially for distributed teams. But removing the live meeting does not remove the work required to clarify blockers, make decisions, and keep everyone informed.
Someone still has to notice when an update points to a blocker, work out who needs to be involved, follow up when something is unclear, and make sure any decision that comes out of those conversations reaches the people it affects. If the update is in Slack while the task is in Jira and the decision happens somewhere else, the PM may still spend time connecting these.
Some teams that have tried async standups describe this trade-off themselves. In one r/agile discussion, practitioners said async updates worked well when teams were already good at written communication, but they could also create more follow-up when updates were vague, or someone needed clarification.
So replacing the meeting with a written update can reduce meeting time without reducing the work required to understand what is happening.
The same issue shows up with retros. Moving the retro document into Confluence or turning every action into a Jira ticket makes the outcome easier to find, but it does not keep that action connected to the work and conversations that explain why the team created it.
The important shift, then, is not simply from synchronous to asynchronous work. It is making sure the information created around the work remains connected: the update, the blocker, the discussion that follows, the decision, and the action that comes out of it.
That is what determines whether async work actually reduces coordination, or simply moves it into another tool.
How Aditi runs standups and retros in Quely
Aditi’s team used to have 30-minute standups several times a week. Today, much of that happens asynchronously in Quely, which she estimates saves the team almost two hours per sprint. But the time saving does not come simply from replacing a meeting with a written update. The bigger change is that the update stays connected to the work it is about.
The benefit becomes clearer when an issue needs more than one conversation to resolve.
Aditi gave the example of an issue that may need to be discussed with a designer first and a developer afterwards. In a more fragmented workflow, she would have to carry the outcome of the first conversation into the second and make sure both people were working from the same information. In Quely, those discussions can happen around the same unit of work, so the developer can see what has already been discussed rather than relying on Aditi to reconstruct it.
This is also why moving the standup async works differently from simply collecting status updates in Slack. The update is not separated from the task, the conversations around it, or what happens next. If a blocker leads to another discussion or a decision, that history remains attached to the same work.
Aditi uses a similar approach for retrospectives. She creates a retro document in Quely, adds the questions she wants the team to answer, and gives people time to respond before the meeting. So the team does not need to spend the beginning of the retro trying to remember the sprint together.
She can then use the AI Assistant, Orbit to work across the information already in the Space. Rather than relying only on what people remember in the moment, she can look at how the sprint progressed, where work slowed down, and what may have gone wrong. Orbit helps her pull that information together into a summary she can use during the retro.
That gives the team a better starting point for the conversation. Instead of spending most of the retro reconstructing what happened, they can spend more time discussing why it happened and what they want to change going forward.
None of this means Aditi’s team avoids meetings entirely. She was clear that some blockers still need a live conversation. When that happens, the team can schedule the meeting in Quely and keep the recording, transcript, and resulting discussion with the same piece of work.
The difference is that the meeting is no longer doing all the work of keeping everyone informed. The team can handle routine updates asynchronously, bring people into a problem without repeatedly explaining the history, and still meet when a situation genuinely needs a live discussion.
For Aditi, that is where the time-saving comes from. The time-saving is not just from fewer standup meetings. It also comes from reducing the follow-ups, handoffs, and repeated explanations that happen around them.
The Benefit Goes Beyond Fewer Meetings
Reducing meetings is useful, but it does not necessarily mean a team is working better asynchronously. A team can remove its standups and still spend just as much time gathering updates, following up on blockers, repeating decisions, and figuring out what happened.
The bigger gain is reducing how much time people spend piecing that information together. When updates, discussions, decisions, and meeting outcomes stay connected to the work they are about, people can get the context they need without relying on the PM to pass it from one person to another.
That is what changed for Aditi. Fewer standups gave her back time on the calendar. Keeping the surrounding context with the work gave her back the time she would otherwise spend coordinating everything around them.
See how Quely helps product and engineering teams keep the discussions, decisions, and meeting outcomes around their work in one place, so everyone can easily find the context they need to move the work forward.