Hire, Automate, or Super IC: A Decision Framework

Start from the constraint, not the option. Write down the business outcome that is blocked, then identify what is actually blocking it. Volume of work points to automation or a hire. Delay caused by coordination across handoffs points to a super IC. A genuinely missing capability points to a hire.

Most teams run this backwards. They start with the option, usually a headcount request that has been sitting in a plan since the last funding round, and then look for the justification. That produces roles nobody can define six months later.

Step 1: State the constraint in one sentence

Not "we need a data engineer". Something closer to "we cannot tell customers their usage in real time, and three deals stalled on it last quarter". If you cannot write that sentence, no hiring decision will fix the problem, because you have not found it yet.

The sentence has to name an outcome and a cost of waiting. Roles justified without a cost of waiting are the ones that turn out to be unnecessary once someone leaves.

Step 2: Classify the work behind the constraint

Once the constraint is written down, look at what work would actually relieve it. Three properties decide the answer.

Real processes rarely sit in one row. The useful move is to split the process and route each segment separately, rather than choosing one answer for the whole thing. A billing workflow might be 70% automatable with the remaining 30% needing judgment that justifies a person.

Step 3: Check the durability of demand

This is the question that separates a contractor from an employee, and it gets skipped most often.

Ask whether the work will still exist in twelve months at similar volume. If yes, a hire amortises. If no, you are buying a permanent cost for a temporary problem, and the honest options are a contractor or automation.

The market has moved in this direction already: 45% of significant AI adopters describe themselves as very reliant on contractors, against 12% of non-AI companies, close to a fourfold difference (Mercury, 2025). Companies using AI heavily are buying flexible capacity rather than permanent headcount for work whose shape is still changing.

Step 4: Re-run the decision on roles you already have

The framework is not only for new roles. Existing roles drift, and the drift is usually toward automation.

Watch the ratio of judgment to throughput inside a role. When most of someone's week goes to moving data between systems, reformatting outputs, or running the same decision tree, that role has shifted whether or not the title changed. A practical trigger: if the last three people who held a role described it as repetitive, re-run this framework on it before backfilling again.

Apply this to your own company

The free Revenue per Employee Planner walks this framework against your actual inputs: your stage, team shape, and the constraint in front of you. It asks the diagnostic questions from steps one to three and returns ranked options across hiring, automation, and redesign, with the reasoning attached. The decision stays with you.

Common questions

What's the framework for deciding hire vs automate vs super IC?

Name the business constraint, then classify the work behind it. Repetitive and rule-based work goes to automation. Broad work blocked by handoffs goes to a super IC. Deep, judgment-heavy work with a durable volume of demand goes to a hire. If you cannot state the constraint in one sentence, none of the three is the right next step.

Should I hire a contractor, an employee, or a super IC?

Contractor when the work is bounded, urgent, and unlikely to recur. Employee when demand is durable and the work needs institutional context. Super IC when the outcome spans several functions and the delay is coming from coordination rather than capacity. The distinguishing question is not cost, it is whether the work will still exist in a year.

When should I automate vs. hire?

Automate when the work is high frequency, rule-based, and the cost of a rare error is low. Hire when the work is low frequency, judgment-heavy, or the cost of being wrong is high. Most real processes are a mix, so the useful move is splitting the process and automating only the repetitive segment.

How do I know when a role has shifted from hire to automate?

Watch the ratio of judgment to throughput inside the role. When most of a person’s week is spent moving data between systems, formatting outputs, or running the same decision tree, the role has drifted toward automation whether or not the job title changed. Re-examine any role where the last three hires all described the job as repetitive.

How do I decide between hiring, automating, or finding a super IC?

Start from the constraint, not the option. Write down the business outcome that is blocked, then ask what is actually blocking it: volume of work, coordination across handoffs, or a missing capability. Volume points to automation or a hire, coordination points to a super IC, and a missing capability points to a hire.