Hiring, Paying and Keeping a Super IC

Pay at the top of your market band, benchmarked against the headcount the person replaces rather than your existing salary grid. Growing a super IC internally has a higher hit rate than hiring one externally. And keeping one depends less on compensation than on autonomy: the process that would suppress their output is the thing most likely to lose them.

This page assumes you have already decided a super IC is the right answer. If you are still choosing between that and adding headcount, start with the decision framework.

What to pay

The common mistake is benchmarking a super IC against your existing senior band. That band was priced for a role that needs management, coordination and review. A super IC needs none of those, which is where the savings actually sit.

Price against the alternative. If the outcome would otherwise require three people, the fully loaded cost of those three, including the manager time to coordinate them, is your ceiling. Paying 1.5x a senior salary against that ceiling is inexpensive. The market data points the same direction: AI-native Series A/B startups run 34% leaner median headcount and pay 36% more per person (Ravio, 2025).

Two structural notes. Equity matters more than base for this profile, because the people who fit it tend to be optimising for ownership and scope. And avoid title inflation as a substitute for pay. Giving a super IC a management title to justify a salary band is the fastest way to destroy the thing you hired.

Find one or grow one

Growing is the more reliable path, and most founders underrate it because it looks slower.

Hiring externally means competing for a small pool against companies already structured to use them well. You are asking someone to take a bet on your autonomy claims, which every company makes and few honour. The conversion rate is low and the failure mode is expensive.

Growing means finding someone on your team who already scopes ambiguous problems without being handed a spec, then removing what stops them shipping. In practice that means giving them an outcome rather than a backlog, a tooling budget, and permission to skip the approval steps that exist for people who need them. The timeline is roughly a year, and the hit rate is much higher because you are selecting on demonstrated behaviour rather than an interview signal.

Concentration risk, and what to do about it

A super IC concentrates capability in one person. That is the point, and it is also the risk. The wrong response is to hire a second person to shadow them, which reintroduces the coordination cost you were removing.

The right response is to treat their output like infrastructure. Whatever they build gets documented and gets a named second owner, even if that owner never touches it day to day. You are not duplicating the person. You are making sure that what they leave behind can be operated and extended without them.

Test it the same way you would test a backup. When they take two weeks off, does anything they built stop being extendable? If so, that system is undocumented, and you have found your gap before it found you.

Super ICs and depth hiring are not opposites

Framing this as a choice produces bad orgs. The two solve different constraints.

Build around super ICs where the work is broad and the bottleneck is coordination: internal tooling, integrations, anything that currently requires four people and three handoffs. Hire for depth where the work is narrow and the bottleneck is correctness: regulated systems, infrastructure with hard failure modes, anything where being wrong is expensive and being fast is not the point.

Most companies at Series A or B need a small number of super ICs and a stable core of deep specialists. The failure is applying one model everywhere.

Common questions

How much should I pay a super IC?

Top of your market band, and usually above the band for the title. A super IC replacing the output of three people is cheap at 1.5x a senior salary and expensive at 0.9x if the autonomy is missing. Benchmark against what the alternative headcount would cost fully loaded, not against your existing salary grid.

Can I find a super IC or do I have to grow one?

Both work, and growing is more reliable. Hiring one externally means competing on pay and autonomy against companies already set up for it. Growing one means identifying a senior engineer who already scopes ambiguity well, then removing the process that stops them shipping end to end. The second path takes about a year and has a far higher hit rate.

What happens when your super IC leaves?

More breaks than an org chart predicts, because their leverage lived in systems other people depend on. The mitigation is not redundancy of the person, which defeats the point. It is insisting the systems they build are documented and owned by someone else, so what they leave behind survives them.

Is having a super IC a liability or an asset?

An asset with a concentration risk you have to actively manage. The liability is not the person, it is treating their output as a permanent org feature while never writing down how it works. Treat a super IC like infrastructure: valuable, and requiring a documented recovery plan.

Should I build my org around super ICs or hire for depth?

Neither exclusively. Build around super ICs where the work is broad and coordination is the constraint. Hire for depth where the work is deep and correctness is the constraint, such as regulated systems or infrastructure with hard failure modes. Most companies need a small number of the former and a stable core of the latter.