Hiring another SDR is a capacity decision, not a pipeline fix

Hire another SDR when a defined commercial workload exceeds the capacity of the current team and the new person can inherit a runnable system. Do not hire one merely because pipeline feels weak, sellers look busy, or outbound activity is inconsistent.

The failure mode is headcount before work design. The business adds a seat before it can explain which accounts the person should pursue, what evidence qualifies a conversation, where accepted work goes, or who improves the rule. The new SDR produces more activity inside the ambiguity.

That can increase nominal labor while leaving commercial capacity unchanged.

Definition

Definition: An SDR capacity decision determines whether one additional seat can absorb valid, repeatable commercial work inside a system with explicit evidence, decisions, ownership, and learning return.

Valid work matters more than raw workload. Repeated research, rebuilt handoff context, and founder approval of normal cases may signal defects in Truth, Playbook, or Architecture rather than demand for another seller. A GTM engineering firm treats hiring as one possible capacity intervention, not as the default answer to a symptom.

Write the job claim before opening the role

Start with one sentence: The next SDR will own this recurring work, using this evidence, to produce this commercial decision and return this learning.

Then make every part inspectable.

Work unit: Is the role expected to select targets, open conversations, qualify interest, or reactivate demand? A role described only as generating pipeline has no bounded unit of work.

Entry evidence: Which buyer, account, offer, and trigger facts must exist before work begins? This is Truth. It requires enough agreement that two people do not build different target lists from the same instruction.

Decision boundary: What may the SDR accept, hold, reject, or escalate? This belongs in the Playbook. A script is not enough when the real problem is deciding whether the conversation should advance.

Handoff: Which evidence travels with accepted work, who receives it, and what counts as acceptance by the next owner? This is an Architecture question, even when the tools are already installed.

Learning return: Which disposition comes back when a target, message, qualification rule, or handoff fails? This gives the Operator enough evidence to improve the system rather than blame activity volume.

If the job claim cannot survive these questions, the hiring brief is hiding a GTM diagnosis.

Separate valid load from avoidable rework

Visible overload contains at least two different things.

Valid load is recurring work that uses an agreed rule, advances a defined buyer decision, and produces evidence the next owner can use.

Avoidable rework repeats or repairs work because the system failed to define, preserve, route, or learn from the first attempt.

Examples of rework include:

  • Rebuilding account research because the ideal buyer definition changes without a recorded decision
  • Requalifying a meeting because the handoff contains a calendar event but no buyer evidence
  • Chasing an account executive for the reason a meeting was rejected
  • Asking the founder to interpret normal cases because exceptions were never separated from the standard path

Trace recent work from target selection to accepted or rejected handoff. Mark where it advances, waits, returns, disappears, or gets reconstructed.

This differs from testing whether the offer has a repeatable commercial motion. The offer may be stable while the SDR work package still leaks effort through poor evidence or handoff. Hiring needs both a usable motion and a usable role boundary.

Test management absorption, not only seller availability

A new SDR requires more than a list, inbox, and sequence. Someone must review quality, coach judgment, resolve exceptions, inspect rejected work, and change the Playbook when evidence contradicts the rule.

Call this management absorption: the system's ability to turn another person's activity into better commercial behavior rather than a larger exception queue.

Ask four questions:

  • Who reviews whether account selection still matches the Truth?
  • Who decides when an unusual conversation should advance?
  • Who owns the quality of the handoff to sales?
  • Who changes the rule when rejection reasons repeat?

If the answer to all four is the founder, the next hire may preserve the founder as the hidden restriction. This does not mean founder judgment must disappear. Strategic accounts, unusual risk, and offer changes may remain founder owned. Normal work needs a clear boundary so founder attention is invoked deliberately rather than by default.

The HBR article on the sales learning curve warns against expanding sales force capacity before the organization has learned how customers acquire and use a new product. The bounded lesson is sequencing: make normal work teachable, then add capacity. HubSpot likewise describes a sales process as a repeatable system with observable steps that teams can track and improve. Neither source proves performance, but both support giving the next person a process that exposes what happened and what must improve.

Run a seat simulation before making the capacity claim

A seat simulation does not forecast revenue. It tests whether the current system can support the proposed role.

Choose recent work that reflects normal cases and known exceptions. Remove private explanations the new person would not possess. Give the sample to someone who did not create the current process.

Ask that person to:

  • Select which accounts deserve action and state the evidence
  • Choose the next action from the current Playbook
  • Record the evidence required for qualification
  • Route accepted work to the correct owner
  • Place incomplete or unusual cases into an exception path
  • Process the reason when work is rejected or returned

Observe where the person must guess, ask privately, invent a field meaning, or wait for invisible approval. Label each point before calling it a headcount shortage.

Worked example: inconsistent outbound meetings

A founder wants another SDR because outbound meetings are inconsistent. The current SDRs are active, but each one builds a different account list. The target definition changes in conversation, not in the CRM or Playbook. Meetings reach sales with different qualification notes. Rejected meetings return as vague comments or not at all.

Another SDR would add more account research and more meeting attempts. It would also create another interpretation of the target, another handoff style, and another stream of missing rejection evidence.

The diagnosis changes the sequence. First, the founder defines the target condition and offer boundary in Truth. The Playbook states the evidence required to advance, hold, reject, or escalate a conversation. Architecture carries that evidence into the handoff and requires a usable disposition from the receiver. Operator review looks for recurring mismatch and changes the rule.

The team then reruns the seat simulation. If normal work now moves without private reconstruction and valid recurring load still exceeds current capacity, hiring is rational. If capacity returns because rework falls, the business has repaired the restriction without pretending the repair guarantees more revenue.

Decision rule

Use three outcomes:

  • Hire: Valid recurring work exceeds current usable capacity. The buyer and offer boundary are stable enough for the role. Normal decisions are teachable. Handoffs carry evidence. Coaching and exception ownership exist.
  • Repair: The role is necessary, but avoidable rework, missing evidence, disputed ownership, or a broken handoff consumes the apparent capacity. Fix the first failed condition, then repeat the simulation.
  • Redesign: The business cannot name the work unit or decision boundary the next SDR would own. Run a GTM diagnosis before committing headcount.

Do not use activity volume alone as the decision. Do not require perfect data or a process that removes judgment. Require a bounded job that can operate, reveal failure, and return learning.

Checklist

Before approving another SDR seat:

  • Write the job claim in one sentence.
  • Name the recurring work unit and intended commercial decision.
  • Define the minimum buyer and account evidence.
  • Separate normal decisions from exceptions.
  • Trace recent work from target selection through handoff disposition.
  • Mark valid load, waiting, reconstruction, return, and disappearance.
  • Confirm that accepted work reaches a named owner with usable context.
  • Confirm that rejection reasons return to the Playbook owner.
  • Name who coaches quality and resolves exceptions.
  • Run the seat simulation without private founder instructions.
  • Choose hire, repair, or redesign.
  • Repeat the test after any repair before opening the role.

What this is not

This is not an argument against SDRs. Hiring is correct when usable systems have more valid work than people can absorb.

It is not a promise that process creates revenue. Demand, offer fit, buyer timing, seller skill, pricing, and delivery capacity still matter.

It is not a universal quota, ramp plan, team ratio, compensation model, or plan to automate an undefined job. AI can support bounded actions after evidence and decision rules are explicit. Automation should face the same seat simulation.

FAQ

Does this mean a founder should delay every SDR hire?

No. It means the founder should know which capacity the hire adds. When valid recurring work exceeds current capacity and the role inherits a runnable system, delay can be the wrong choice.

What if the current SDR team is visibly overloaded?

Treat overload as a signal, then inspect its composition. If most waiting comes from valid work, add capacity. If work repeats because targeting, qualification, handoff, or ownership is unclear, repair that restriction first.

Can AI replace the next SDR instead?

Not when the commercial decision is undefined. AI can multiply the same ambiguity faster. Give automation explicit evidence, permissions, actions, and exception routes, then decide whether the remaining work needs software, people, or both.

If the hiring request still cannot be translated into a bounded job claim, a Lorde GTM diagnosis can locate the restriction and define whether the next investment belongs in Truth, Playbook, Architecture, Operator ownership, or headcount.

Lorde

Message on WhatsApp