Hiring the First Help

When Thursday Stops Fitting

Continue with the property-management product from the previous chapter. Vendor notifications are now visible and recoverable. The maintenance path is dependable enough that retained customers are adding buildings, and new firms are arriving through referrals.

Thursday should contain two sales calls and work on owner reporting. Instead, the founder spends the morning cleaning a new customer’s vendor spreadsheet, matching service categories, creating staff accounts, and checking notification settings. A property manager asks whether a regional supervisor can see work orders across several buildings. Another sends a spreadsheet with three names for what appears to be the same plumbing company. By late afternoon the account is ready, but the two sales calls have moved and the reporting work has not begun.

This has happened for five of the last six onboardings. The founder is no longer looking at a crowded week. There is a constraint: retained accounts need a repeatable setup sequence, and founder-only preparation is delaying activation and interrupting the work that brings in the next account.

The role title is still unknown. “Customer success” feels plausible. So do operations, engineering, and automation. Choosing among them too early would hide the useful fact: the bottleneck contains several kinds of work, and they should not all go to the same place.

First help begins with the constraint, not the vacancy.

Prove the Constraint Before Naming the Help

Founder overload is real, but overload alone does not reveal what to hire. A painful week may come from a launch, a poor process, an unreliable feature, or work that should be stopped. A durable role built around a temporary surge preserves the surge as organization design.

Write a short constraint memo before searching for people. It needs to answer five questions in ordinary language:

• What repeated evidence shows where work is waiting?
• Which customer or business outcome is delayed or put at risk?
• What does the founder do today, including repairs and exceptions?
• Which parts follow rules, and which still require judgment?
• What change would prove that the constraint has actually eased?

For the property-management product, the memo might read:

Five of the last six accounts required three to five hours of founder preparation before the first live maintenance request. Vendor-file cleanup, account setup, and checklist verification repeat. Role design, unusual vendor relationships, and customer promises still require founder judgment. Preparation now delays activation and displaces sales. A useful first engagement would let three consecutive standard accounts go live with no more than one hour of founder review each, without increasing setup errors or making promises outside the product.

This memo does more than justify spending. It separates the visible queue from the underlying system. If every account needs a different product, more hands will make the custom work arrive faster. If the founder cannot recognize a correct setup, there is no quality bar to delegate. If onboarding consumes time because the import path is brittle, a small product fix may remove more work than a person can.

The constraint is ready for help when it is expensive, repeated, teachable, and inspectable. It also has to be worth managing. A helper needs context, access, review, correction, and decisions. Estimate that load honestly. Ten hours of work handed off with eight hours of founder explanation is not leverage yet.

Split the Work Where Judgment Changes

The founder watches the next onboarding instead of treating it as one undifferentiated task. Three layers appear.

The first is mechanical. The same file checks are repeated for column names, duplicate vendor records, missing contact fields, and unsupported service categories. The rules are stable, mistakes are visible, and the product can provide a preview before import. This belongs in a narrow product improvement. Automating it removes work from every future onboarding and makes the remaining exceptions easier to see.

The second layer is operational. Someone must prepare the account, clean records that meet written rules, configure approved defaults, draft setup notes, and run the onboarding checklist. The output can be sampled. Ambiguity can be escalated. This is suitable for a part-time contractor or operations assistant.

The third layer is judgment. Should a supervisor see every building? Does a customer’s vendor relationship fit the current permissions model? Is the requested workflow part of the product or a custom promise? The founder keeps these decisions for now because they still shape positioning, scope, trust, and the product itself.

This division is more valuable than a list of tasks to “delegate.” It keeps the founder close to learning while moving preparation and execution away from founder memory. A useful default is to delegate the work around judgment before delegating the judgment: collect the inputs, prepare the draft, execute the known path, record the exception, and complete the follow-through.

Some work should remain close even when it is tiring. Early sales conversations teach who buys and why. Customer discovery exposes changes in the problem. Pricing, positioning, roadmap trade-offs, quality standards, and consequential customer promises are difficult to review if the founder has never made their standard explicit. Hiring someone to absorb that discomfort can interrupt the very learning the company still needs.

Let the Work Choose the Form

The lightest useful form of help depends on how stable the rules are, how long the need will last, and how much context good work requires.

Use automation when the founder has performed the work enough times to know the common path, exceptions, and cost of mistakes. Keep a manual override. Automating an unsettled process encodes confusion and can hide new evidence.

Use a virtual assistant or operations assistant when administrative work follows explicit rules: scheduling, research preparation, CRM hygiene, invoice follow-up, document formatting, or checklist-driven setup. Keep ambiguous customer communication, product decisions, pricing, and promises behind an escalation boundary.

Use a contractor when the assignment has a finish line and the output can be reviewed: an import preview, a billing repair tool, UI work from established patterns, a reliability improvement, a research synthesis, or the onboarding preparation in this example. A contractor is a poor substitute for open-ended ownership that depends on unspoken company context.

Use an agency when the need is bounded, specialized, and easier to buy as a coordinated capability than assemble: a security assessment, a carefully scoped migration, or a launch package after strategy is settled. The founder still has to judge the work and own what remains after the engagement. A vague retainer does not repair a vague problem.

A first employee is warranted when the function is durable, central to the company’s next stage, and large enough to support continuing ownership. Employment brings onboarding, management cadence, decision rights, career context, and a longer obligation than relief from this month’s queue. The first engineer should extend a product direction the founder can explain. The first designer should improve a workflow whose user and outcome are known. The first marketer or salesperson should scale language and a motion the founder has learned firsthand. The first customer-success hire needs repeatable onboarding or support patterns, account context, and escalation paths; otherwise the role becomes a human router back to the founder.

Role labels become useful after this reasoning. They describe the durable center of the work rather than substituting for it.

Make the First Assignment Small Enough to Teach You

The founder chooses a part-time operations contractor for onboarding preparation and ships the import preview before the engagement begins. The first assignment is not “own customer success.” It is narrow enough to reveal whether the process can travel from one person to another:

Outcome
  Prepare three standard property-management accounts so each can reach its
  first live maintenance request with no more than one hour of founder review.

In scope
  Validate the vendor file with the import preview, clean records under the
  written rules, configure approved defaults, create the draft staff setup,
  and prepare customer notes from approved examples.

Founder decisions
  Permission exceptions, unusual vendor relationships, pricing, product-scope
  questions, and every customer promise.

Quality bar
  The onboarding checklist is complete; source records remain recoverable;
  ambiguous rows are flagged rather than guessed; setup notes agree with the
  account configuration.

Review
  Founder reviews every account in week one, then samples completed steps and
  reviews all escalations. Each correction updates the playbook or narrows the
  scope.

Stop condition
  Pause if ordinary preparation still requires more than one hour of founder
  explanation per account, if setup defects increase, or if most cases fall
  outside the written rules.

The brief is an operating test. If the outcome cannot be named, the founder has not identified the relief being purchased. If the quality bar cannot be inspected, review will become taste expressed after the fact. If almost every line is a founder decision, the work is not ready to move—or the product has allowed too many variants.

The stop condition matters as much as the success condition. A short engagement can reveal that the playbook is weak, the product needs another admin tool, the chosen segment is less uniform than it appeared, or the constraint was temporary. That is useful evidence, provided the company has not already organized itself around the wrong answer.

Give Access in Proportion to the Work

Delegation changes the product’s trust boundary. The contractor needs enough access to prepare an account, but not unrestricted production access simply because the founder has always operated that way.

Use named accounts, least-privilege permissions, and test or preview paths where possible. Keep secrets out of recordings and shared documents. Make destructive actions reversible or approval-gated. Record changes that affect customer data, roles, billing, or communication. Define where customer files may be stored, how they are transferred, and when local copies are deleted. Remove access when the engagement ends.

Decision rights need the same precision. “Use good judgment” is not a boundary. The contractor may correct a malformed phone number when the source is unambiguous; they may not decide that two similar vendor records represent the same legal business. They may draft setup notes from an approved example; they may not promise a permissions feature. A useful escalation rule identifies the condition, the person who decides, and what work should pause meanwhile.

The engagement also has a legal and administrative shape. Contractor classification, employment obligations, tax, payroll, intellectual-property terms, confidentiality, and data-protection duties vary by jurisdiction and relationship. Use appropriate local professional advice rather than choosing a label for convenience. Operationally light should not mean legally careless.

Count the Management Load

During the first three onboardings, the founder tracks more than hours saved. They watch where the contractor stops, which corrections repeat, whether customers receive consistent notes, and whether founder review becomes shorter without becoming superficial.

A repeated correction has three possible homes. Improve the instruction when the rule is sound but unclear. Improve the product when software can prevent or expose the mistake. Return the decision to the founder when the case still carries product judgment. Blaming the helper for a system that teaches badly preserves the bottleneck.

After three accounts, one of four decisions should be possible:

• expand the contractor’s scope because the work and review path hold;
• keep the scope stable while gathering more evidence;
• redesign the process or product because exceptions still dominate;
• stop because the management load exceeds the constraint removed.

Only later might this become a customer-success or operations role. If onboarding volume remains durable, the playbook survives more varied accounts, and ownership beyond preparation becomes necessary, an employee may be the right form. If the import preview and product changes remove most of the work, the contractor engagement may end successfully. The purpose was never to acquire a team member. It was to restore capacity without losing the founder’s contact with the product.

Write the Assignment Before the Job Description

Choose the most expensive repeated constraint in the current value path and write its evidence in one sentence:

Because [observed pattern], [repeated work] now delays or risks [customer or business outcome].

Separate the work into rules, exceptions, and founder judgment. Decide what should be simplified or automated before it is handed to a person. Then write one assignment with an outcome, scope, non-scope, quality bar, decision rights, review cadence, access boundary, and stop condition.

If that assignment cannot yet be written, do not disguise the missing understanding with a role title. If it can be written, the founder has something more useful than a hiring plan: a controlled way to discover whether another person can remove the constraint.

The next bottleneck will often be private knowledge. A bounded assignment can expose it without pretending it is already documentation. Before engineering work can travel safely, the founder must turn the codebase’s private knowledge into a system another person can enter.