We Set Response Time Norms (1hr/24hr/48hr) But Half the Team Ignores Them—How Do You Make Async Norms Stick?

[maya_builds]

Okay, I need some real talk here.

Six months ago, my team sat down and agreed on response time norms for async communication. We documented them in Notion, posted them in Slack, and everyone nodded in agreement:

• Urgent issues (production incidents, customer blockers): 1 hour
• Code reviews: 24 hours
• General questions: 48-72 hours

It felt like a breakthrough. Finally, we had shared expectations! No more anxiety about whether your message would be seen. No more guilt about not responding immediately.

Fast forward to today: Half the team completely ignores these norms.

What’s Actually Happening

I see this pattern constantly:

• Engineers posting code reviews at 4pm and pinging “hey can you review this today?” (treating it as 1hr when it should be 24hr)
• Product managers tagging multiple people with “quick question” and expecting immediate responses (treating general as urgent)
• Everyone using the fire emoji to escalate their requests to urgent status

The norms we agreed on have become… suggestions? Wishes? I’m not even sure anymore.

What I Tried (That Didn’t Work)

Attempt 1: Reminded the team in our retrospective
Result: People nodded, said “good point,” nothing changed.

Attempt 2: Posted the norms in our Slack guidelines channel
Result: Nobody reads that channel.

Attempt 3: Added response time expectations to onboarding docs
Result: New hires learn the written norms, then observe the actual behavior and match that instead.

What’s Working Now (Kinda)

The only thing that’s actually helped:

Response time badges in Slack. I created custom emoji badges that show response time commitments:

• = 1 hour response
• = 24 hour response
• = 48-72 hour response

People tag their messages with these to signal how urgent they actually are. It’s helped about 30% because now there’s visible accountability—if you mark something when it’s not actually urgent, people notice.

I also set up a Slack bot that gently reminds people when they post after 6pm or on weekends: “This message was posted outside working hours. Recipients may not respond until their next working day.”

But honestly, these feel like band-aids. Is this a tooling problem or a culture problem?

My Theory

I think the issue is that everyone genuinely believes their request IS urgent. From their perspective:

• The PM needs the answer to unblock their customer call tomorrow
• The engineer needs the code review to hit the sprint deadline
• The designer needs feedback to present in the meeting this afternoon

They’re not being malicious or ignoring norms. They’re just operating from their own context where their task feels time-sensitive.

The problem is when everyone treats their work as urgent, nothing is urgent. We’re back to the constant-interruption model that async was supposed to solve.

Questions for You All

How do you make async norms actually stick?

• Is it about better tooling (automation, bots, workflow enforcement)?
• Is it about culture change (rewarding good behavior, consequences for violations)?
• Is it about hiring different people (some folks just aren’t wired for async)?

And the deeper question: If people keep reverting to sync behavior despite agreeing to async norms, does that mean async doesn’t actually work for most teams? Or are we just doing it wrong?

I’m genuinely curious because I believe in async-first, but I’m also tired of being the person constantly defending boundaries that the team collectively agreed to but individually ignores.

Help me out here—what’s worked for you?

[cto_michelle]

Maya, your theory about everyone believing their request is urgent is spot-on. But I’d argue the root cause is deeper: Response time is an outcome, not the root problem.

The Real Issue: Trust

People revert to sync interruptions because they don’t trust that async will actually work. They’ve been burned before:

• Posted a question, got no response, missed their deadline
• Shared feedback async, felt ignored, learned that sync gets attention
• Waited 48 hours for an answer only to find out the person was on PTO

When async feels unreliable, people hedge. They ping Slack. They schedule “quick calls.” They escalate everything to urgent as insurance.

My Approach: Leadership Modeling

Here’s what I did to build trust in async: I stopped responding fast, even when I was available.

This sounds counterintuitive, but hear me out. When I used to respond to Slack messages within 10 minutes, I was training my team that fast responses were normal. Then when I didn’t respond fast, they got anxious.

Now I batch my responses. If someone messages me at 10am, I respond at 2pm even if I saw it right away. My team learned: Michelle will respond, but not immediately. Plan accordingly.

This creates predictable async behavior instead of unpredictable sync availability.

Show the Data

I also started sharing focus time data with the team every month:

"When we follow our response time norms:

• Engineers average 4.8 hours of uninterrupted work per day
• Code quality improves (fewer bugs in reviewed code)
• We ship features 15% faster

When we don’t follow norms:

• Focus time drops to 2.8 hours per day
• Context switching increases, bugs increase
• We ship slower despite feeling busier"

People don’t change behavior because it’s “the right thing to do.” They change when they see concrete benefits.

The Controversial Part

Here’s what I haven’t shared publicly before: I think some people genuinely can’t thrive in async-first environments.

After 18 months of async-first, I had to let go of two otherwise talented people who could not stop treating everything as urgent. They were smart, hardworking, and also fundamentally wired for synchronous work.

I tried coaching, metrics, everything. But they were miserable. Async felt like being ignored to them, even when the team was following norms perfectly.

Not everyone is suited for every work style. That’s okay. But if you’re building an async-first culture, you need people who can thrive in it.

To Your Question

Is it tooling or culture? It’s systems and incentives.

Your Slack badges help make expectations visible (good). But if people still get rewarded for fast responses—if the PM who pings immediately gets their answer faster than the one who waits—you’re incentivizing the wrong behavior.

Align your incentives. Celebrate deep work and good async communication. Stop rewarding firefighting and constant availability.

Then watch the behavior shift.

[product_david]

Maya, I’m dealing with a variation of this that’s even messier: Engineering can set response norms, but sales and customer support can’t.

The Cross-Functional Nightmare

Your team is pure engineering, so you have more control. But at our B2B SaaS company, I sit between:

• Engineering: wants 48-hour response times, async-first, deep work
• Sales/Support: needs answers in 2 hours when a $200K deal is on the line or a customer is escalating

These aren’t compatible. And when I set product response norms at 48 hours, Sales loses their minds: “The customer is waiting on a call, I need an answer NOW.”

Different SLAs for Different Request Types

Here’s what I’ve implemented (it’s messy but it works):

Internal product questions: 48-hour response
Customer-facing escalations (Sales, Support): 2-hour response during business hours
Critical customer issues (revenue risk, churn risk): 1-hour response

We have a Slack channel called #customer-urgent where Sales/Support can post requests that need fast turnaround. Product team monitors it during working hours.

Everything else goes through our normal async RFC/feedback process.

The Tension Is Real

The problem is this creates a two-tier system:

• Customer-facing teams get fast async responses (because we know they’re time-sensitive)
• Internal teams get slow async responses (because we want to preserve focus time)

And honestly? It breeds resentment.

Engineering sees Sales as constantly escalating non-urgent things. Sales sees Engineering as hiding behind “async norms” to avoid hard questions.

I’ve had engineers say “Why does Sales always get priority?” And I’ve had sales reps say “If engineers can’t respond in 2 hours, we’ll lose deals to faster competitors.”

Both are partially right.

My Compromise (Which Nobody Loves)

Clear escalation criteria:

• Revenue at risk > $50K → 2-hour response
• Customer threatening churn → 2-hour response
• Prospect asking pre-sales question → 24-hour response
• Internal feature debate → 48-hour response

We document these in our team handbook. When someone requests fast turnaround, we ask: “Does this meet escalation criteria?”

Sometimes the answer is yes (customer about to churn). Sometimes it’s no (sales rep wants competitive intel for a deal that’s 6 months out).

The Meta Question

This makes me wonder: Can async-first work company-wide, or is it inherently an engineering luxury?

Engineering work benefits from long, uninterrupted focus time. Sales and support work is inherently reactive and time-sensitive.

Maybe the honest answer is: Async-first works for knowledge work with flexible timelines. It struggles for work with external time pressure (customers, markets, compliance deadlines).

I don’t have this figured out. We’re making it work through explicit SLAs and escalation paths, but it’s fragile. One sales leader who doesn’t respect the norms can break the whole system.

Anyone else dealing with cross-functional async norms? How do you balance engineering’s need for focus with the business’s need for speed?

[vp_eng_keisha]

This thread is giving me life because I’ve been wrestling with exactly this for the past year. Maya, to your question about whether it’s hiring—I think that’s a bigger piece than we want to admit.

We Were Hiring People Who Thrive on Sync, Then Asking Them to Be Async

Here’s what I realized: Our interview process was optimized for the wrong skills.

We tested:

• Can you solve algorithms on a whiteboard?
• Can you explain your technical decisions in real-time?
• Can you think on your feet under pressure?

We didn’t test:

• Can you write clear, thorough documentation?
• Can you work independently without constant feedback?
• Can you handle ambiguity and delay without anxiety?

We were literally selecting for people who excel at synchronous collaboration, then putting them in an async-first environment and wondering why they struggled.

Screening for Async Skills

Now we’ve changed our hiring process:

1. Take-home assignment with async communication
We give candidates a small project and communicate only via async comments (simulating code review). We watch:

• Do they ask clarifying questions upfront, or ping constantly for guidance?
• Can they handle a 24-hour feedback loop, or do they get stuck waiting?
• Is their written communication clear enough that we don’t need a call?

2. Written communication assessment
We ask: “Explain a complex technical decision you made recently as if you’re documenting it for future team members.”

• Great candidates write clearly structured docs with context, decision, and reasoning
• Weak candidates write stream-of-consciousness that would require a meeting to decode

3. Comfort with ambiguity
We explicitly ask: “Describe a time when you had to make progress on a project without having all the information you wanted.”

• Strong async folks talk about making incremental progress, documenting assumptions, moving forward
• Sync-dependent folks talk about scheduling meetings to “get alignment” before starting

Culture Fit Is Whether You Can Thrive in Async

This sounds harsh, but: Some people are fundamentally energized by real-time interaction and feel isolated by async.

I’ve had candidates in final rounds admit: “I work best when I can just walk over to someone’s desk and hash out a problem. The async thing sounds lonely.”

That’s valuable self-awareness! And it tells me they won’t thrive on our team.

We’re not smarter or better for being async-first. But it IS our culture, and hiring people who match that culture is critical.

The Result

Since we started screening for async skills (about 8 months ago), our response time norm violations have dropped 60%. Not because we enforce better—because we hired people who naturally work this way.

Our new hires:

• Default to documentation over meetings
• Ask questions in public channels with full context
• Respect response time boundaries without needing reminders

It’s not perfect, but it’s way better than trying to train sync-native people to be async-native.

To Michelle’s Point About Letting People Go

Michelle mentioned letting go of two people who couldn’t adapt to async. I’ve had similar experiences, and it’s gut-wrenching.

These were smart, talented people. But they were like fish out of water in an async environment. They weren’t failing—they were suffering.

Sometimes the kindest thing is acknowledging: this environment isn’t the right fit, and that’s okay.

The Bigger Lesson

Maya, to your question about whether async works for most teams: I think async works for teams that hire for it, design for it, and commit to it fully.

If you bolt async norms onto a team built for sync, you’ll get exactly what you’re experiencing—constant erosion and frustration.

But if you build async into your DNA—hiring, onboarding, performance evaluation, everything—it becomes self-reinforcing.

The people who can’t thrive in it select out (during interviews or early tenure). The people who remain actually like working this way.

That’s when async norms stick: when they’re not fighting against people’s natural work styles, but aligned with them.