Are You Paying Your Team to Be Responsive Instead of Effective?

Turn this article into takeaways for your work.

Each assistant summarizes the article only for you and suggests best practices for your work.

Most leaders would say they pay for results. Look at what actually gets noticed, though. The person who answers a message in two minutes gets called reliable. The person who goes quiet for three hours to finish something hard gets asked whether everything is okay.

Our view is plain: in most companies, reply speed has quietly become a stand-in for performance. It's visible, it's easy to measure by feel, and it makes managers comfortable. But it trades the deep work that produces results for the appearance of availability. The fix isn't to ban fast replies. It's to decide, channel by channel, how fast a reply is actually needed, and then to judge people on what they deliver.

Key Facts

What you're really rewarding

Responsiveness is a behavior, not an outcome. A fast reply tells you someone saw a message. It tells you nothing about whether the customer problem got fixed, the proposal got better, or the forecast got more accurate.

Yet it's what many teams learn to optimize. Think about how it plays out in a normal week. A director posts a question in a channel at 4:10 pm. Two people answer within minutes. A third, who was deep in a pricing model, answers the next morning and the answer is the right one. Which of the three gets the "always on top of things" reputation? Usually the first two. And the third learns, quietly, that going deep carries a social cost.

That's the part leaders underestimate. You don't have to write a policy to create this culture. You only have to reward visible speed a few times, and people will do the math on their own.

The pattern has deep roots. The Harvard Business Review research above describes a 24/7 on-call culture in professional services, where people believed an "always on" ethic was essential to succeed. The authors then tested that belief inside BCG teams and found the assumption was something the teams could collectively change without hurting service. The belief was the constraint, not the client.

The cost shows up in focus, not in the inbox

Ask where the cost of an instant-reply culture lands and you'll rarely find it on a dashboard. It lands in fragmented attention.

Microsoft's figure of an interruption every two minutes is a telemetry average across a lot of people, so treat it as a sign of direction rather than a rule for your team. The point is the shape of the day: constant pings, short stretches in between, and very little room for the kind of thinking that moves a quarter. We covered the organizational side of this in Deep Work Isn't a Productivity Hack. It's a Business Strategy, and the measurement trap behind it in busyness as the most expensive habit.

There's a second cost, which is people's well-being. In the UBC experiment, participants who limited email checking to three times a day reported lower stress, and lower stress predicted better well-being across several outcomes. It's worth being honest about the limits here. The study ran for two weeks, the participants were adults recruited for the experiment, and the stress measure was self-reported. It doesn't prove that every team should check email three times a day. It does show that constant checking isn't free.

A third cost is quieter still. The 2021 study of IT professionals found that hours went up by about 30% during the shift to remote work while average output didn't significantly change, and that time on coordination and meetings grew as uninterrupted hours shrank. When effort goes up and output stays flat, you're paying for more activity, not more result. Responsiveness is one of the cheapest ways for activity to expand to fill the day.

Why leaders keep paying for it anyway

Three reasons, and none of them are stupid.

Results are slow and noisy; replies are instant. A manager can see a response in seconds. A result might take a quarter to show up, and it will be tangled up with luck, timing and other teams. When the real signal is slow, a fast proxy is tempting.

Fear of a dropped ball. Everyone has lived through the one time a slow answer cost a deal or upset a client. That memory justifies a thousand unnecessary quick replies afterward. The honest question is how often a two-hour delay actually hurts, and for which kinds of requests.

No shared norm, so everyone assumes the strictest one. If nobody says how fast a Slack message needs an answer, people guess. And they guess high, because the downside of being slow feels worse than the downside of being interrupted. The result is a company-wide standard of "now" that no one ever chose.

Set norms by channel, not by person

The workable fix is to make the response expectation explicit and attach it to the channel. People already treat a phone call differently from an email. You're just writing down what they half-know, and removing the guesswork that drives everyone to the fastest assumption.

Here's a starting point. Adjust the numbers to your business, then publish them.

Channel Use it for Expected response Not for
Phone call or page True emergencies: outage, safety, a customer at risk right now Within minutes Anything that can wait until tomorrow
Direct message Quick, specific questions with a short answer Same working day Decisions, long threads, anything needing thought
Team channel Questions that others may also answer or learn from By end of next working day Urgent escalations
Email Requests from outside the team, anything that needs a record Within 1 to 2 working days Real-time coordination
Project or ticket comment Work-specific updates, decisions, blockers Within 1 working day, or by the stated due date General chat
Shared document Proposals, plans, decisions that need considered input By the date named in the request Quick yes/no questions

Two things make this table work. First, the slow channels need a faster path for real emergencies, or people won't trust them. A single, clearly named escalation route (a phone call, an on-call rotation) is enough. Second, the norm has to apply to leaders too. If the CEO expects a reply to a direct message in ten minutes, the table is decoration.

If you're moving toward written-first habits, the same logic sits underneath async-first operating models, and the practical writing habits are covered in async communication best practices.

Judge people on results, with a few honest checks

Norms only hold if the way you evaluate people changes with them. Otherwise the norm says "take your time" while the review says "why were you quiet?"

A simple way to put results first is to define what each role is accountable for in terms of outcomes, check progress on a fixed rhythm, and leave the minute-to-minute availability alone. This is the old logic of management by objectives, and it works because it pushes the conversation toward what was delivered.

Use this table as a manager's checklist when you review someone's performance.

What you notice What it might mean Ask instead
Fastest replier on the team Good communicator, or someone avoiding hard work What did they finish this quarter that mattered?
Slow on chat, strong deliverables Protecting focus Are the people who depend on them getting what they need on time?
Slow on chat, weak deliverables A genuine performance issue What is blocking them, and is it the work or the workload?
Fast on chat, weak deliverables Busyness standing in for output Where is their time actually going?

Notice what the table does. It stops treating speed as evidence in either direction. Slow plus strong is fine. Fast plus weak is a problem. And you can only tell them apart if you're measuring deliverables.

Where fast response truly earns its keep

None of this means slow is good. Some work is genuinely time-sensitive, and some roles are paid for being reachable.

  • Customer-facing and on-call roles. Support queues, incident response and live sales conversations have real response-time targets. Set them by role and measure them explicitly, rather than letting them leak into everyone else's job.
  • Decisions that block other people. When a stalled approval holds up three teammates, speed matters. The better answer is usually clearer ownership, which is what our piece on decision-making velocity is about, rather than faster chat replies.
  • Early days on a new team. New hires benefit from quick answers while they learn. Treat it as a deliberate onboarding support, with an end date.

The rule of thumb: pay for responsiveness where responsiveness is the product. Everywhere else, pay for what gets finished.

What to do next

You can start this month without a reorganization.

  1. Write the channel table. Take the one above, edit it with your team leads, and publish it where people will see it. Make sure it includes one emergency route.
  2. Go first. Leaders should model the norms for two weeks: scheduled sends, no "ping?" follow-ups inside the stated window, and visible protected focus blocks.
  3. Add a line to role descriptions. For each role, name two or three outcomes it is accountable for. If you can't, that's the real finding.
  4. Change one review question. In your next round of one-to-ones, replace "are you keeping up?" with "what did you finish, and what's in your way?"
  5. Remove one reply-speed signal. That might be a status dot you comment on, a read receipt joke, or a habit of praising instant answers in public. Small signals teach more than policies do.
  6. Audit your meeting load at the same time. Faster replies often substitute for meetings that should have been a document, and the reverse is true too. Our look at coordination costs is a good companion.
  7. Check back in 60 days. Look at deliverables on time, not response time. If output held or improved while replies slowed, you've moved the incentive.

Learn More

About the author

Victor Hoang

Victor Hoang

Co-Founder, Rework.com

Victor Hoang is Co-Founder and CMO of Rework. He spent 12+ years scaling B2B SaaS growth, building a lead engine that generated over 1 million leads and $10M+ in annual recurring revenue. Today he builds AI agents and MCP servers into Rework's products to empower customers across growth and operations. He writes about what actually works.