Shubham closed his laptop at 8 PM, exhausted.

He'd spent the day:

• Updating Jira tickets (because someone would ask if he didn't)
• Writing detailed Slack updates (so the team stayed "aligned")
• Documenting decisions in Notion (for the async record)
• And then attending four meetings to discuss all of it anyway

His company proudly calls itself "async-first."

The leadership team talks about trust, flexibility, and deep work time.

But here's what Shubham actually experiences:

Slack messages that expect responses within minutes.

Project management tools that need constant nudging to stay current.

"Async discussions" that always end with "let's hop on a quick call to sort this out."

Documentation that nobody reads before meetings.

He's doing all the overhead of async work - the writing, the updating, the tool maintenance.

And still doing all the synchronous work - the meetings, the calls, the immediate responses.

Today's Permission Slip:

You have permission to admit your async setup isn't working - and either commit to real async or stop pretending.

Why this feels impossible to say out loud:

Because your company invested in all the async tools.

Because leadership keeps talking about "trust" and "flexibility."

Because admitting it's not working feels like admitting you can't handle modern work culture.

But here's what nobody's saying: Half-assing async is worse than not doing it at all.

The Old Way: Traditional Office Culture

At least the expectations were clear:

• Be in office 9-5
• Meetings happen in conference rooms
• Questions get asked at desks
• Work happens in real-time

You knew what "responsive" meant. You knew what "available" looked like.

It wasn't perfect, but it was honest about what it was.

The Shift: Async Theater

Then organisations discovered async tools and made a fatal assumption:

Adopting async tools = having an async culture

So they:

• Replaced email with Slack (but kept the expectation of instant response)
• Adopted project management tools (but still needed meetings to make decisions)
• Created documentation systems (but nobody had time to actually read them)
• Announced "flexibility" (but penalised people who actually used it)

The result? People get the worst of both worlds:

All the discipline of async (writing everything down, keeping tools updated, documenting decisions).

None of the benefits (actual flexibility, protected deep work time, reduced meetings).

What Real Async Actually Requires:

Here's what most organisations miss:

Async isn't about tools. It's about discipline, trust, and systems.

Real async means:

Questions don't need immediate answers - and that's okay.

Updates happen on schedule, not on demand.

Decisions get made in writing, with clear deadlines for input.

Meetings are rare, optional, and recorded.

"I'll respond tomorrow" is a complete sentence.

Real async requires:

Leaders who don't check message timestamps.

Teams trained to give complete context in writing.

Decisions that can wait for thoughtful input.

Documentation that people actually read and trust.

Consequences for people who bypass the system with "quick calls."

Most importantly, real async requires letting go of control over when work happens.

If you're checking whether someone responded within an hour, you're not doing async.

If you're nudging people to update tools, you're not doing async.

If "let's just hop on a call" is your solution to every complex discussion, you're not doing async.

The Practice:

Pick one area where you're doing async theater:

Is it Slack? Set actual response time expectations (like: 24 hours is normal).

Is it project management? Define exactly when updates are due, and stop asking between those times.

Is it meetings? Cancel one recurring meeting and handle it truly async - in writing, with clear deadlines.

Then watch what happens.

Either your team will discover they can actually work async (and love it).

Or you'll discover you can't (and can stop pretending).

Both outcomes are better than the exhausting middle ground you're in now.

This Week's Question:

What async overhead are you creating that nobody's actually using?

Here's to leading differently,

Raghav

P.S. I've watched this pattern at multiple organisations - including ones that proudly marketed their "async culture" to recruits. The people who burned out fastest? The ones who actually tried to do the async work while everyone else just kept scheduling calls. What's your experience been? Hit reply - I read every response.

P.P.S. Know a leader drowning in "async" work while still attending eight meetings a day? Forward this to them. They can subscribe here.