Capability Based Hiring

You've got work that needs doing. AI implementation, a workflow that's eating three hours a day in manual handling, a product feature that's been "next sprint" for two months.

The instinct is automatic: we need to hire someone.

So you open a job advert template. You start writing requirements. Three years' experience, familiarity with your stack, ideally available immediately.

Stop there for a second. You haven't actually answered the question that matters yet. You've skipped straight to a solution — a person, in a role, permanently — without asking what the work actually requires.

That's the difference between recruitment-based thinking and capability-based hiring. One starts with a role. The other starts with the work.

Recruitment Assumes the Answer Is a Person in a Role

Recruitment logic is familiar because it's the default, not because it's always right. It runs like this: write the advert, attract applicants, screen CVs, interview, hire, hope the role fits the work.

It's a good process for a genuine, ongoing role, someone who'll own a function, build context over years, and grow with the team. For that, recruitment is still the right tool. Nobody's arguing otherwise.

But it's a blunt instrument for specialist, time-bound, or not-yet-defined work. You end up writing a permanent job description for a six-week problem, screening 200 CVs for a skillset you only need until the workflow is automated, and committing to a salary and notice period before you're even sure the work is a full-time job at all.

Capability-Based Hiring Starts With the Work

Capability-based hiring flips the order. Instead of asking "who do we hire?", you ask: what capability does this work actually require?

That's a different, and a more honest starting point. It forces you to define the outcome before you define the role. What needs to be true when this work is done? What's blocked right now? What capability, specifically, closes that gap, AI implementation, workflow automation, product engineering, data integration?

Sometimes the answer is a hire. Often, for urgent or specialist work that doesn't clearly justify a permanent seat, the answer is deploying the right capability for a defined scope of work, then reassessing.

That's deployment, not recruitment. You're not hiring a job title. You're bringing in capability for work that needs doing now.

What This Looks Like in Practice

A scaleup needs an internal tool built to stop three people manually reconciling spreadsheets every week. That's not a "Software Engineer, full-time" problem. It's a defined build with a clear outcome, capability needed for four to six weeks, not a headcount decision.

A startup wants to pilot an AI-assisted support workflow before committing to a strategy. That's not a job advert either. It's diagnostic and build work, the kind of thing a specialist deploys, tests, and either scales or kills, without anyone signing a twelve-month contract on a guess.

A founder needs fractional product leadership to get a roadmap and team structure sorted before they hire a permanent Head of Product. That's deployment buying you time and clarity, not a substitute for the eventual hire — a precursor to making that hire correctly.

In each case, the team still might hire later. Capability-based hiring isn't anti-hiring. It's sequencing: get the work done and the picture clear first, then decide whether a permanent role is the right next step.

When Recruitment Is Still the Right Call

Worth saying plainly: if the need is a core, ongoing role, someone owning a function long-term, building institutional knowledge, accountable for a team, recruit. Capability-based hiring isn't a replacement for that, and nobody serious is claiming jobs are dead.

It's a second operating mode, for the work that doesn't fit that shape: urgent, specialist, scoped, or simply not yet proven to be a permanent need.

The Practical Shift

Capability-based hiring changes what you write first. Instead of a job advert, you write a capability brief: what outcome matters, what's currently broken, what capability is needed, what the scope looks like.

Instead of screening CVs, you review provider profiles built around what people can actually deploy, not just what their last job title was.

Instead of applicants, you get a human-reviewed shortlist of providers whose fit indicators match the work you've actually described.

It's a smaller, sharper conversation, because it starts from a clearer question.

Start With the Work

If you've got AI, product, automation or engineering work that needs doing in the next 30-60 days, and you're not sure it justifies a full-time hire yet, don't start with a job advert. Start with a capability brief.

Submit your first capability brief: https://www.deployed.works/launch/cohort-1