Declining Academic Requests Without Damage

Academic requests arrive individually and accumulate structurally. A review, a talk, a committee, a letter, a coffee with someone's student, a special issue, an external examination. Each is reasonable. Together they are unbounded, because there is no natural limit on how many people can ask.

Declining is a skill, and the version most people use — a long apologetic explanation — works worse than the short one. For a concrete operational example of how a workplace tool approaches a related coordination problem, see the website.

Decline promptly

The single most important thing.

A review request answered in two days lets the editor find someone else. Answered in three weeks, after two reminders, it has cost the author a month.

A fast no is a service. A slow yes is frequently worse than a fast no.

This applies to everything: a talk invitation, a committee, a request for comments. The person asking has a plan and needs to know.

The form that works

Short. Clear. No extended justification.

"Thank you for thinking of me — I'm not able to take this on at the moment. I hope it goes well."

That is a complete response.

Why not to over-explain: a long justification invites negotiation. If the reason is workload, the reply is "it's only a small thing." If it is timing, the reply is "we could move the deadline." A reason that can be addressed will be addressed.

No apology beyond a single polite word. Declining is not a wrong that requires atonement, and elaborate apology signals that you might be persuadable.

Do not lie about the reason. "I don't have capacity" is true and sufficient.

Suggesting someone else

Genuinely helpful and worth doing when you can.

"I can't, but X works on exactly this and might be interested" solves the requester's actual problem.

Two cautions. Ask yourself whether you are passing work to someone who is asked less because they are more junior or less visible — the same dynamic that makes some people's service load unmanageable. And do not volunteer someone without any sense of whether they would want it.

Suggesting a person early in their career is frequently doing them a favour, particularly for reviewing and for talks. Say so when you pass it on.

When you should decline

When you cannot do it properly. A review you will write in forty minutes is worse than no review. A talk you will prepare on the flight is worse than a different speaker.

When it is outside your competence, unless you say so explicitly and the requester still wants you. See reviewing outside your exact area.

When there is a conflict of interest. Close collaborator, recent co-author, student, competitor on the same question. Say why — this is one case where the reason matters, because the requester needs it.

When you are already at capacity, which is most of the time for most people.

When the request is unpaid work that should be paid, and you are able to make that point. Not everyone can, and those who can should.

When you should accept

Because declining everything is also a failure.

Reviewing, roughly in proportion to what you consume. Each of your submissions uses two or three reviews, so a rough norm is two or three reviews per submission. See how to review a paper.

Service that only you can do. Rare, and it exists.

Things that build something you care about — a conference, a seminar series, a journal you rely on.

Requests from people with less power than you, where a small amount of your time is a large amount of help. A letter for a student, twenty minutes on someone's draft, a call with a job candidate.

And keep a rough count. Not to optimise, but because most people who are overloaded have never actually looked at what they said yes to.

The asymmetry worth naming

Service load is not distributed evenly, and the pattern is well documented in several fields: women, people from underrepresented groups, and people at less prestigious institutions are asked more, particularly for committee and mentoring work that is unrewarded.

Two consequences.

If you are asked a lot, declining is not a character failing. It is a rational response to a distribution problem you did not create.

If you are doing the asking, look at who you ask. The same three people accepting everything is a sign that the load is concentrated, not that others would refuse.

Renegotiating rather than refusing

Sometimes the answer is a smaller yes.

"I can't review this by the deadline, but I could in four weeks."

"I can't join the committee, but I'll do the one session."

"I can't read the whole draft, but I'll read the introduction and the design."

These are useful and they are still commitments. A partial yes that is not delivered is the same failure as a slow no.

After declining

Do not revisit it. A decision explained twice reads as an invitation to negotiate.

Do not feel obliged to compensate elsewhere. Declining one thing does not create a debt.

And if you later have capacity and the thing still matters to you, say so. "If you're still looking, I could now" is welcome.

The short version

Decline promptly. A fast no is a service; a slow yes is often worse.

Short, clear, no extended reason — a reason that can be addressed will be.

Suggest someone else where you genuinely can, and think about whether you are passing load down.

Accept in rough proportion to what you consume, and for requests from people with less power than you.

And if you are the one asking, notice who you ask.

For an independent authoritative reference, consult the Open Science Framework for infrastructure for transparent research practice.