The most responsive leader on your team is probably the worst thinker

Here is a paradox that nobody in product leadership wants to confront. The person on your team who replies fastest, who is always available, who never keeps anyone waiting for a decision or a Slack response, is almost certainly doing their worst strategic thinking. Not because they are incapable. Because they have structured their days in a way that makes deep thinking nearly impossible.

And the entire organisation reads their behaviour as exemplary.

For years, responsiveness has been the implicit standard for leadership credibility in product organisations. The leader who answers within minutes is perceived as engaged. The one who replies in four-hour windows is perceived as checked out, or worse, as someone who does not care. This is not written in any performance review rubric. But it operates like doctrine. And most senior product people have internalised it so deeply that they do not even recognise it as a choice. It feels like the job.

But every time you switch from one cognitive task to another, you lose approximately 23 minutes of refocus time. Not because you are slow. Because the brain needs to reload context, re-establish working memory, and suppress the residue of the previous task. That number comes from research at the University of California, Irvine, and it has been replicated enough times that arguing with it is like arguing with gravity. You can disagree. You will still fall.

Responsiveness is a performance of engagement. Batching is the practice of it.

The Responsiveness Trap

I fell into this trap myself. For years. At Freshworks, I was the PM who replied to every Slack message within ten minutes. I wore it like a badge. My calendar was a patchwork of thirty-minute blocks separated by five-minute gaps that I used to clear notifications. I attended every standup. I was available for every "quick sync." I felt productive. I felt like I was on top of things.

But my strategic output during that period was mediocre. I can say that now because I have the distance to compare it with what came later. The roadmap decisions I made were safe. The product direction memos I wrote were competent but unremarkable. I was so busy responding to the work that I never created the conditions for the kind of thinking that produces genuinely good strategic calls.

I was present for everything. I was deep on nothing.

The irony is that the organisation rewarded this. My responsiveness was visible. My shallow thinking was invisible. Nobody sees the strategy memo that could have been sharper if you had spent three uninterrupted hours on it instead of forty-five fragmented minutes. They only see the Slack reply that arrived in under two minutes.

I have started calling this the responsiveness trap: the pattern where visible availability crowds out invisible quality, and the organisation cannot tell the difference because it only measures the visible part.

Cognitive Batching

The alternative that has been gaining serious traction among senior product people in early 2025 is cognitive batching. The idea is not new. Cal Newport wrote about deep work years ago. But the specific application to product leadership is different, because product work involves a wider range of cognitive modes than most knowledge work. Strategy writing, design reviews, one-on-ones, and customer escalations all draw on different mental resources. But the practice spreading now groups those modes together rather than interleaving them.

All external communication happens between 2pm and 4pm. All strategy work happens on Tuesdays and Thursdays before noon. All one-on-ones are compressed into a single afternoon. The principle is that switching between similar tasks costs almost nothing, but switching between different types of cognition costs almost everything.

At Grab, I worked with a product director named Wei Lin who was the most ruthless batcher I have ever seen. She checked email twice a day. She rejected roughly half of all meeting invitations. Her Slack status said "Replies between 2pm and 4pm SGT" and she meant it. Half the team thought she was disengaged.

But her output was extraordinary.

Her roadmap documents were the sharpest I had encountered at the company. Her quarterly planning sessions were the most efficient because she arrived having done real thinking in uninterrupted blocks, not thoughts cobbled together between meetings. The team that initially found her unavailability frustrating started to notice that when she did engage, the quality was different from everyone else's.

She was not doing more work. She was protecting the conditions under which good work becomes possible.

Why the Resistance Is So Strong

If cognitive batching works this well, you might ask why it has taken this long to gain traction. The answer is cultural, not logical. Responsiveness is legible. Batching is not.

When you reply to a message in two minutes, your manager sees it. Your peers see it. The person who asked the question sees it. But when you spend three hours in deep strategic thinking and produce a document that is 20 percent sharper than it would have been otherwise, nobody can see the counterfactual. Nobody knows the document could have been worse. They only see the document as it is and assume that is what you would have produced regardless.

This is the measurement problem at the heart of the responsiveness trap. Organisations measure what is visible. Responsiveness is visible. Thinking quality is not. But nobody questions the incentive structure, and so it quietly rewards the behaviour that produces worse strategic output.

I noticed this most acutely when I moved from Bangalore to Wayanad. The physical distance from an office meant that nobody expected me to be available for hallway conversations or impromptu syncs. For the first time in my career, the default was batched. Not because I had chosen it philosophically. Because geography had imposed it. But the change in my output quality was stark enough to be embarrassing. My writing got sharper. My product thinking got deeper. My strategic calls improved. The only variable was the structure of my days. I had not become smarter. But I had stopped fragmenting the intelligence I already had.

I had been capable of this thinking all along. I had just never given myself the conditions to do it.

The Permission Problem

The hardest part of adopting cognitive batching is not the practice. It is the permission. Most product leaders feel they cannot batch because the organisation expects constant availability. But that expectation is usually assumed, not stated. When I have seen senior PMs explicitly tell their teams "I reply to messages between these hours, and I am unreachable outside them," the initial discomfort lasts about two weeks. After that, the team adapts. They learn to batch their questions too. They learn to solve more problems independently. They learn that an answer at 3pm is usually just as useful as an answer at 9:15am.

But the PM has to go first. And going first feels like risk.

The product leaders I respect most right now are the ones who have stopped performing engagement and started practising it. They are less responsive. They are less available. But the thinking they produce carries a weight that their always-on peers simply cannot match.

The 23 minutes of refocus time is not a number you can negotiate with. It is the tax on every context switch. Most product leaders believe they are immune to it. They are paying it fifteen or twenty times a day without knowing it.

Protecting the conditions for thinking is not a productivity technique. It is a professional obligation for anyone whose job is to think well on behalf of a product and the people who use it.