First Hire Decision Matrix

Begin With the Queue, Not the Job Title

A founder can feel overwhelmed long before the company has a role for another person. A launch creates a temporary surge. A brittle import creates work that software should remove. An unclear product creates exceptions that nobody else can resolve. Hiring against any of these may add a second workload—onboarding, review, correction, and coordination—without removing the first.

Use this artifact when the same work has interrupted a valuable customer or business outcome several times and the founder is considering outside help. Its first question is not who should I hire? It is what constraint has been proven, and what is the lightest responsible way to relieve it?

Open one decision file. Give it a review date rather than letting “we should hire” become a permanent background belief.

FIRST-HELP DECISION

Constraint under review:
Customer or business outcome delayed or put at risk:
Observed instances and evidence window:
Work the founder performs today:
What has changed to make the decision timely:
Decision date:
Review date if the answer is "not yet":

Write observations, not identity claims. “I am bad at sales” is not useful evidence. “Qualified prospects wait nine days for a reply while delivery work is active” reveals a queue, an outcome, and something that can be investigated.

Decide Whether the Work Should Survive

Before transferring work, challenge its existence. For each repeated task, ask whether the company should:

• stop it because it serves no chosen customer or necessary obligation;
• simplify it by narrowing variants, promises, or supported paths;
• automate it because the normal path and failure cases are stable enough;
• delegate it because a person can execute or own it with a visible quality bar;
• keep it with the founder because it still produces essential product, market, pricing, or trust judgment.

This pass often changes the hiring question. Thirty hours of “support burden” may contain ten hours of obsolete manual reporting, eight hours caused by one product defect, six hours of answerable questions, and six hours of customer conversations that still shape the product. Hiring one person to absorb the entire bundle would conceal three different decisions.

Describe the work that remains after stopping, simplifying, and automating:

WORK PARCEL

Repeated work:
Trigger and natural frequency:
Inputs available at the start:
Rules that are already stable:
Exceptions that still occur:
Founder judgment that must remain with the founder:
Correct and incorrect outputs:
Customer data, money, systems, or promises the work can affect:
Expected duration: temporary / uncertain / durable

If the founder cannot show a correct output or explain which cases must be escalated, the parcel is not ready to hand off. The next action is to observe, document, or narrow the work—not to hide the ambiguity inside a job description.

Test Every Candidate Against the Same Gates

Create one candidate card for every plausible form of relief, including “no new help.” Compare an employee with a contractor, agency, assistant, automation, product change, or deliberate reduction in service. Do not compare people by enthusiasm while comparing software by cost; each option must answer the same operating questions.

CANDIDATE CARD

Form of help:
Work parcel it would own:
Why this form fits the work's duration and uncertainty:
Evidence that demand will persist:
Outcome it should improve:
First bounded assignment:
Quality bar and review method:
Decisions retained by the founder:
Access required and damage possible:
Founder hours needed each week to brief, review, and manage:
Cash commitment, including tools and overhead:
30-day evidence of leverage:
Stop, narrow, or change-form condition:

Pass each card through four gates.

1. The constraint is proven

There is a repeated pattern, not one exhausting week. The cost appears in an outcome that matters: activation, retention, revenue, product quality, reliability, trust, learning speed, or founder capacity for the current bottleneck. The decision file names what should improve if help works.

2. The work can travel

The first assignment has a boundary. Inputs, outputs, quality, escalation, and decision rights can be explained. Exceptions do not consume most cases. The founder can review the result without doing the assignment again in disguise.

3. The founder can support the relationship

Management capacity is an input, not an optimistic afterthought. Reserve time for context, access, feedback, correction, and decisions. If no such time exists, reduce the scope until the relationship can be managed or defer it. An unattended first hire does not create autonomy; it creates hidden drift.

4. The commitment matches the evidence

A short, uncertain, inspectable package favors a contractor. A bounded need for coordinated specialists may favor an agency. Stable rules and a clear escalation path may suit an operations or virtual assistant. A durable, central function with continuing ownership may justify an employee. The more expensive the mistake is to reverse, the stronger the evidence should be.

Any failed gate changes the action. It may call for a product fix, a smaller paid engagement, more documentation, a new review date, or no additional help.

Let the Constraint Suggest the Role

Role titles are hypotheses about the center of the remaining work. Test them against what the company can already explain.

• Consider engineering help when product direction is stable enough that another engineer can extend, harden, or operate it without being asked to discover what should exist. Repeated production risk, a reviewable delivery queue, or specialized work may support the case. Unsettled scope does not.
• Consider design help when the user, job, and desired behavior are known but interaction quality or design throughput constrains the outcome. Do not ask design to manufacture product evidence the founder has avoided seeking.
• Consider sales or marketing help when the founder has learned who buys, why they buy, what language reaches them, and how a real motion works. Early conversations that still change positioning should remain close to the founder.
• Consider support or customer-success help when questions, onboarding paths, account signals, and escalation rules repeat. If most contacts reveal product ambiguity, promises, or segment mismatch, the founder still owns the learning even when someone else prepares the response.
• Consider operations or assistant help when rules are stable, completion is visible, and ambiguous cases can stop at a clear boundary. Administrative repetition is a better fit than delegated product judgment.
• Consider a contractor or agency when the outcome has a finish line and the founder can judge delivery. Do not use a temporary label to disguise an open-ended role that depends on private context.

One constraint may produce more than one answer. A product improvement can remove the common path while a contractor handles a temporary backlog and the founder keeps the exceptions. That is often safer than turning the whole queue into a permanent position.

Write the First Assignment Before the Role

The first assignment should be small enough to expose whether the work and the relationship are ready to expand. It is not a miniature job description; it is a real outcome with boundaries.

FIRST ASSIGNMENT

Outcome:
In scope:
Explicitly out of scope:
Founder-only decisions:
Access and permissions:
Quality bar:
Review and feedback cadence:
Escalation rule:
Documentation or handoff produced:
Success condition:
Stop condition:

For an employee, this can define the first month without pretending long-term ownership has already been earned. For a contractor or agency, attach it to a paid, bounded engagement. For an assistant, begin with rules-based work and review every exception. In every form, use named accounts and the least access that permits the assignment. Make consequential changes reviewable and remove access when the relationship or need ends.

Review should improve the system, not merely grade the person. A repeated correction belongs in one of three places: clearer instructions when the rule is sound, a product or tool change when software can prevent the error, or the founder boundary when the case still requires judgment.

Record the Decision and Its Reversal Path

DECISION

We will:
Because the evidence shows:
This should improve:
The founder will continue to own:
The first assignment is:
The management budget is:
The maximum initial commitment is:
We will expand when:
We will stop, narrow, or change form when:
Next review date:

“Hire a customer-success person” is not a completed decision. “Use a part-time contractor for the next four standard onboardings, with founder review of all permissions and promises, then continue only if review falls below one hour per account without more setup defects” can be tested and reversed.

The same standard applies to a decision not to hire. Name the product change, process reduction, documentation work, or evidence window that comes next. Deferral without a next observation simply preserves the anxiety.

Decision Rule

Proceed when the constraint is proven, the surviving work is bounded, the quality bar is inspectable, founder-only judgment is protected, management time is available, and the commitment fits the evidence. Choose the lightest form of help that can test the relief honestly.

If any of those conditions is missing, do not fill the gap with a role title. Run the smallest investigation or assignment that can resolve it, set a review date, and keep the company from organizing itself around an unproven answer.