How distributed teams replace the accountability and momentum physical proximity used to provide for free
By Jae S. Jung
Let's be honest: nobody looks forward to meetings.
I once noticed all my client meetings clustered on Tuesdays. When I asked an executive about it, he said, "Nobody wants meetings on Monday. We schedule Tuesday to get it out of the way."
That's the problem right there. We schedule meetings to get them out of the way, not because they serve a purpose.
So when I posted on New Year's Eve about why remote teams need daily stand-ups, I expected pushback. Instead, within 24 hours it reached 8,000 senior engineers who clearly cared enough to engage with the topic on a holiday.
The responses revealed something important: the teams struggling most aren't having too many meetings or too few. They're the ones running purposeless status theater instead of designing intentional accountability structures.
Here's what I've learned from managing distributed teams across 28 years and multiple continents: written daily status updates tied to specific work items change behavior in ways that weekly meetings and async tools alone don't.
Not because meetings are good. Because the right structure creates accountability that remote work removes.
Why? Because they're all wrestling with the same paradox I've experienced: async tools should work, but work still clusters around meeting deadlines and complex issues still wait for synchronous discussion.
For years, stand-ups have been criticized for breaking developer flow. The argument usually points back to Paul Graham's essay "Maker's Schedule, Manager's Schedule" (later included in Hackers & Painters), which explains why makers need long, uninterrupted blocks of time to do meaningful work.
That argument is sound. But it was written in a different operating reality.
Fifteen years ago, most development teams were co-located.
If someone was blocked, they didn't wait for a meeting. They stood up, walked over to a teammate or product owner, had a two-minute conversation, and went right back to work. Alignment, visibility, and momentum happened organically throughout the day.
As one commenter on my LinkedIn post recalled: “I remember walking with a fellow engineer for coffee to talk about some problems and solutions… Face to face in situations was the way to change thinking in entrenched work. No meetings, just sidekick with good advice.”
In that environment, daily stand-ups often felt redundant. The team already knew what was going on.
Post-COVID, many teams became fully remote—often across regions and countries.
What often replaces that is silence until the next scheduled update.
In fully remote teams, I've consistently seen two failure modes emerge, and the conversation on LinkedIn validated both.
Excessive meetings fragment focus and validate every concern raised about protecting maker time. This problem is real and hasn't gone away.
One developer pushed back directly: “Over 15 years ago I was shipping more, managing more data than ever in my career, had 0 meetings and things were awesome… Do I really need a meeting about the meeting about the thing already in Jira, Slack, and email?”
That frustration is legitimate. Meeting inflation is a genuine productivity killer.
When teams lean too hard into async-only communication, some (not all) drift into an out-of-sight, out-of-mind pattern. Questions surface late. Work clusters right before updates. Momentum becomes uneven.
The issue isn't meetings versus no meetings. It's how alignment happens when it's no longer implicit.
The LinkedIn discussion surfaced an important pattern: teams that succeed in remote environments aren't blindly following "best practices." They're designing intentional structures that fit their specific context.
One senior product manager shared: “I've been part of teams where 50%+ of stand-ups weren't in person, but over Slack or Teams via quick text-based updates… For some teams, it caused blind spots. For others, velocity almost doubled and blockers resolved within a day or two at most.”
Structure matters more than the specific ceremony.
Another team coach described an observational approach: “I prefer to observe what's happening. They will know what every team member is working on, and communicate as needed. If they do not communicate as needed, it will show at our weekly planning sessions.”
Different teams. Different structures. Same principle: alignment has to be deliberate in remote environments.
Rather than debating whether stand-ups should exist, we focused on how to make them lightweight and purposeful.
Each team member references a unique work identifier to answer three simple questions.
What was completed since the last check-in?
What is actively being worked on?
What is planned before the next check-in?
For us, that identifier is often a Jira ticket ID, but the tool itself doesn't matter. The same approach works with ClickUp, Asana, Basecamp, or any system that provides clear, traceable work items.
This creates visibility without forcing people into meetings just to report status. If someone can't attend due to urgent work, the update still exists and the team isn't blocked.
Here's what I've observed consistently across teams:
Simple questions work great asynchronously. A quick Slack or Teams message about a configuration setting or API endpoint gets answered promptly. No meeting needed.
We started with weekly meetings. Product owners and project managers continued that pattern. The results were problematic: work wasn't getting completed in a timely manner. On a team of four developers, we'd regularly see two of them bring up complex issues they'd been sitting on for the entire week. Worse, some would only do minimal work the day before the meeting.
Not everyone exhibited this pattern. But it happened frequently enough to become a productivity problem.
I encouraged the team to document complex questions in ticket comments and use AI to help articulate the details clearly and professionally. That helped with clarity. But it didn't solve the core behavior: developers still waited until the meeting to engage with complex issues, and work still clustered right before the weekly check-in.
The shift that worked: Daily stand-ups (or 3x weekly when daily felt excessive) with asynchronous written status updates.
Suddenly, developers were getting things done daily instead of in a pre-meeting sprint. The same team members who would sit on architectural questions for a week were now surfacing them within 24-48 hours.
The pattern I've come to accept: This is human psychology in a remote environment. Out of sight, out of mind is real. When co-located in an office, that developer sitting on a complex issue for a week would see their teammates making progress, feel the ambient pressure of proximity, and bring it up sooner. Remotely, that social pressure disappears.
Here's what I've observed: there's something fundamentally different about writing down your status with a specific ticket number versus saying it out loud in a meeting.
When we answer the three questions orally, it's easier to be vague or embellish. "Working on the integration" sounds like progress. But when you have to document it in writing with a ticket identifier, the accountability shifts. You can't hide behind verbal hand-waving. Either you completed ticket #2847 or you didn't. Either you're blocked on a specific issue or you're not.
I'm not a psychologist, but I've seen this pattern play out consistently: written status updates tied to concrete work items create a level of accountability that oral reporting simply doesn't. The act of documenting creates psychological ownership in a way that verbal updates don't.
The daily cadence matters, but the written documentation matters more. It's the combination that changed behavior in ways that better async tools alone didn't.
It's:
"How do we create the accountability and momentum that physical proximity used to provide for free?"
For some teams, the answer is purely async with strong self-directed individuals. For others, it requires deliberate synchronous checkpoints that replace the psychological effect of working in the same room. The goal is the same: keep work moving steadily instead of clustering around meeting deadlines.
Stand-ups shouldn't be status theater. They should be alignment checkpoints.
Developers spend more time building and less time explaining.
Paul Graham was right about protecting deep work.
What changed isn't the value of focus. It's the mechanics of alignment in distributed teams.
The real question isn't:
"Are stand-ups good or bad?"
It's:
"How do we keep a remote team aligned, accountable, and moving in the same direction without fragmenting focus"
At a certain stage, operational maturity stops being about tools or rituals and becomes about intentional system design.
Over 28 years building distributed teams for government contractors and enterprise clients, I've learned that mature teams don't argue dogmatically for or against meetings. They design structures that compensate for what their environment no longer provides. In an office, alignment is ambient. Remotely, it has to be deliberate.
How to diagnose if your team needs this: Look at your completed tickets over the last sprint. If complex architectural decisions are clustered in the final 48 hours before your weekly meeting, you have a pacing problem. If ticket comments show simple status updates but complex discussions happen elsewhere (or not at all), you have an alignment gap.
The most effective teams aren't meeting more or less. They're meeting on purpose.
When alignment, progress, and ownership are visible without constant interruption, developer time is protected and leadership stays informed. That's not a process win. It's an operational one.
And in fully remote teams, that difference often determines whether execution feels steady or constantly uphill.
Every remote team is navigating this balance differently. Some have found async-only workflows that genuinely work. Others need structured touchpoints to maintain momentum.
The LinkedIn discussion showed this challenge transcends company size and geography. From startups to Microsoft, from Seattle to London, senior engineering leaders are wrestling with the same fundamental question: how do we maintain execution velocity in distributed environments?
There's no universal answer, but there are definitely patterns worth sharing.
If your organization is navigating distributed team dynamics while modernizing legacy systems, WAM DevTech can help. We work with enterprise-scale organizations and government contractors on both technical architecture and operational process design, because sustainable execution requires both.
With 28 years of experience building and leading distributed development teams across multiple continents and time zones, I've seen what works when remote teams scale beyond the startup phase into enterprise complexity.
The conversation continues on LinkedIn or reach out directly at info@wamdevtech.com.
Jae S. Jung is the founder and CTO of WAM DevTech, a consulting and development firm specializing in cloud architecture and legacy system modernization for enterprise-scale organizations and government contractors. With over 25 years of experience building and leading distributed development teams across North America, Europe, South America, and Asia, he helps organizations navigate the intersection of technical infrastructure and operational effectiveness at scale.
