Hiring Manager Response Time

What is the practical cost of slow response?

It is paid by candidates, and it compounds. A person waiting on a decision continues interviewing elsewhere, and the strongest candidates are precisely those with the most alternatives, so delay filters the pipeline in the least desirable direction. The cost is invisible in the metric itself because the candidates who leave stop appearing in the process, and their departure is usually attributed to a competitive market rather than to elapsed time. Joining response time data to withdrawal data for the same requisitions is what makes the connection visible: if the requisitions with the longest manager latency are also the ones with the most withdrawals after screening, that is a specific, evidenced argument rather than a general complaint about speed.

How should this be reported without damaging the recruiter relationship?

Report it to the manager first, privately, alongside the outcome it affected, rather than circulating a comparative table. The framing that works is the requisition rather than the person: this search took a given number of days, this portion was sourcing, this portion was waiting on review, and these candidates withdrew during the wait. That invites a problem-solving conversation. A ranked list distributed to leadership invites defensiveness and gaming, usually in the form of rapid low-quality decisions or requests routed outside the system so they are never measured. The metric is most durable when it is owned as a shared process measure rather than deployed as evidence against one party.

How does the system capture this data?

An applicant tracking system records the timestamp when candidates enter a review stage and when the manager records a decision, which yields the interval without anyone tracking it manually. The same applies to scorecard submission and offer approval where those run through defined workflows. The accuracy depends on one behaviour: requests must be raised in the system rather than by message or conversation, since an unlogged request has no start time and produces a measurement of the wrong interval. Automated reminders tied to the same timestamps also address a meaningful share of delays before they need measuring at all, because a proportion of slow responses are not decisions being deferred but requests that were simply never seen.

Why measure this separately from time in stage?

Time in stage tells you a step is slow. It does not tell you who is holding it, and that distinction determines the fix. A screening stage running long because sourcing has not produced enough people needs more candidates. The same stage running long because completed profiles are sitting unreviewed needs a different conversation entirely, and no amount of additional sourcing improves it. Without separating the two, a recruiting team is frequently asked to solve a problem that is not theirs.

Isolating manager latency also changes the tone of the discussion from an impression to a fact. Recruiters routinely believe managers are slow and managers routinely believe recruiters send unsuitable candidates, and both positions are argued from memory of the worst recent case. A measured interval per request, per manager, over a period, replaces that with something reviewable, which is the precondition for changing anything.

How is it calculated?

Each measurement is a single interval: the timestamp when a request requiring the manager's action is raised, and the timestamp when they complete it. The three intervals worth tracking separately are shortlist review, interview feedback submission, and offer approval, because they have different causes and different remedies. Aggregate them per manager over a period, and use the median rather than the mean.

The median matters more than it sounds. Response intervals are heavily skewed: most requests are handled in a normal window and a few sit for weeks because the manager was on leave or the request was buried. A mean is dominated by those few and describes nobody's typical experience. The median describes the usual case, and reporting the median alongside the count of requests exceeding an agreed threshold captures both the norm and the tail without letting either hide the other.

What distorts the number?

Calendar effects come first. Raw elapsed time counts weekends, public holidays, and annual leave, so a request raised on a Friday before a manager's vacation records a long response that reflects nothing about their responsiveness. Measuring in working days against a calendar, and excluding known absence, removes most of this. It will not be perfect, and the residual is a reason to read the metric as an indicator rather than a verdict.

Batching is the second distortion, and it cuts both ways. A manager who reviews all candidates every Tuesday produces a response time that varies with the day the request arrived rather than with their attentiveness. That may be a perfectly sound working practice; it simply means the number reflects a cadence rather than a delay. The third distortion is requests made outside the system. If a recruiter asks in a corridor or a chat message and only logs it later, the recorded start time is wrong and the manager is credited with a response they were never asked for on time.

What counts as a response?

This definition decides whether the metric is honest. If any interaction stops the clock, a manager can reply asking a clarifying question and record a fast response while the actual decision waits another week. The measurable event should be the completion of the requested action: a decision recorded for each candidate on the shortlist, a submitted scorecard, an approval registered.

Partial completion needs an explicit rule too. A manager who decides on three of five candidates has not completed the request, and treating it as done understates the delay for the other two. The straightforward convention is that the clock stops when the last item in the request is resolved, with the request measured as a whole. Whatever rule is chosen, it must be written down and applied consistently, since the metric is only comparable across managers if they are all measured the same way.

Why is there no benchmark for this?

No credible universal figure exists for how quickly a hiring manager should respond, and any number circulated as a standard should be treated as one organization's internal target rather than as evidence. The realistic interval depends on how many open requisitions the manager carries, how large their team is, whether recruiting is part of their formal responsibilities or an addition to a full operational load, and how many candidates each request contains. A manager running one search and a manager running six are not comparable.

What is comparable is the same manager over consecutive periods, and the same population of managers before and after a change. That makes the metric a diagnostic and a trend rather than a scorecard. Importing an external target and holding managers to it produces the predictable response of fast, low-quality decisions, which converts a visible delay into an invisible quality problem that surfaces months later as a poor hire.

How should the number be used?

Start by agreeing an expectation at intake, before any candidate exists, as part of the same conversation that establishes the requirements. A commitment made in the abstract is far easier to obtain than one requested while a specific candidate waits, and it converts later follow-up from chasing a favour into referencing an agreement.

Then use the data to find causes rather than to rank people. A manager who is consistently slow across every request usually has a capacity problem that no reminder will fix, and the appropriate response is fewer concurrent requisitions or a delegated first review. A manager who is fast on feedback and slow on shortlist review may be receiving profiles without enough evidence to decide on. Both are actionable; a list of managers ordered by response time is not.