Don't Hire a Person and Then Discover the Job

When a founder is buried in work, the usual plan is to find someone good and figure out later what they'll take on. That order is the problem. If the job isn't defined before the person arrives, their first months go to helping you define it, and you pay a salary for the discovery. Don't hire a person and then discover the job. Prove the job exists first.

What it means for a job to exist

Before you look at a single candidate, you should be able to write down three things.

The work that leaves your hands. Name tasks, not areas. "Sales" is an area. "Follow up with every inbound lead within a day and book the demo" is work.

The result it should produce without you. What a normal week looks like when it's done well, in terms someone else could aim for.

How you'll judge it. How you'll know from outside the work whether it's going well, without doing it again yourself.

If you can write all three, you have the outline of a role. If you can only write the first, you have a list of things you're tired of doing, and a hire won't turn that list into a job. If you're still deciding which work to let go of at all, start with You Only See the Needles You Find Yourself.

Test it the cheapest way you can

A written description is a claim. The evidence is watching the work get done by someone who isn't you. Use the cheapest, most reversible setup you have: a contractor, a freelancer, a part-timer, a bounded project, or someone already on the team who can take it on for a while.

Then watch two things. Does the work keep showing up, week after week, in roughly the shape you wrote down? And can you tell whether the result is good without redoing it?

If both answers are yes, you have evidence of a role. A full-time hire would be taking over something you've already shown can exist outside your hands.

If the work changes shape every week, or the person keeps coming back for you to redefine what to do, a full-time hire won't fix that. It turns the ambiguity into payroll. If the work keeps its shape but every judgment call on it still comes back to you, that's a different problem: Delegation Fails When You Transfer Tasks Instead of Judgment.

The trial also gives you the economic case. Look at what the work produced next to what not doing it was costing you: leads that went cold, invoices that went out late, hours pulled away from the product. That gives you something concrete to compare with the cost of a full-time hire, before you sign one.

When you can't test it cheaply

Some first hires can't be trialed with a contractor. The role needs deep context, talks to your customers, handles sensitive information, or makes calls you wouldn't hand to someone passing through. The job can still be real. The written version has to carry more of the weight.

Write the result and how you'll judge it anyway, specifically enough that a candidate could read it and tell you whether they'd hit it. If you can't write that, you aren't ready to hire for it, with or without a trial.

A proven job still slows you down first

Proving the job doesn't make the hire free. The new person needs onboarding, context, and your time for questions and reviews, and for a while you'll get less of your own work done than before they arrived. Before you hire, ask whether you can absorb that dip now. In the middle of a launch or a fundraise, that can mean planning for it, or hiring right after.

So, hire fast or wait?

Hire fast when the job is proven: the work shows up consistently, you can judge the result, and you can afford the slow start. Wait when you still can't say what the person would produce, or when the trial keeps changing shape. In that case, waiting is how you define the job.

How QuickInsight analyzes decisions

FAQ

When should I hire my first employee?

When the job is proven: the work shows up consistently, you can judge the result without redoing it, and you can afford the slow start. Wait when you still can't say what the person would produce, or when a trial keeps changing shape.

How do I know the job exists before I hire?

Write down three things: the work that leaves your hands, the result it should produce without you, and how you'll judge it. Then test it the cheapest, most reversible way you have, such as a contractor, a part-timer, a bounded project, or someone already on the team. Watch whether the work keeps showing up in roughly the shape you wrote down, and whether you can tell the result is good without redoing it.

What if the role can't be tested with a contractor?

Some roles need deep context, talk to your customers, or handle sensitive information. The job can still be real, and the written version has to carry more of the weight. Write the result and how you'll judge it specifically enough that a candidate could tell you whether they'd hit it. If you can't write that, you aren't ready to hire for it.

Will my first hire save me time right away?

Not at first. The new person needs onboarding, context, and your time for questions and reviews, so for a while you'll get less of your own work done. Check whether you can absorb that dip now. In the middle of a launch or a fundraise, that can mean planning for it or hiring right after.

QuickInsight is informational only. It is not medical, legal, financial, or other regulated advice.