The role you're about to hire for — could Claude still cover it

Before you write a JD, it’s worth an honest hour asking whether the role is actually a hiring problem, or a workflow you haven’t gotten around to building yet.

A useful, blunt test: write down the actual recurring tasks the role would cover. For each one, ask — is this task judgment-heavy and relationship-dependent (a real hire’s job), or is it mostly “read this, draft that, format this consistently” (a workflow’s job)? Founders often reach for a hire when the real gap is that nobody’s built the workflow that would make one person’s existing time enough.

This isn’t an argument against ever hiring — some roles are real relationship or judgment roles from day one: a first salesperson who needs to build trust with prospects, an early engineer who needs to own real technical judgment. The test is specifically useful for the roles that feel urgent but turn out to be mostly repetitive: a lot of “part-time ops support” and “junior coordinator” asks are actually workflow gaps wearing a headcount request.

The honest version of this exercise sometimes says “no, actually hire” — and that’s a real, useful answer too. The point isn’t to avoid hiring; it’s to make sure the hire is solving the problem it’s actually needed for, not filling a gap Claude could close this week. If the answer is genuinely “hire,” the job-description playbook is the next step.