Deployment, Not Recruitment

Here is a scenario most founders and operators will recognise.

You have work that needs doing. It is specific, it is urgent, and it is not going away. Your internal team does not have the capacity or the expertise. Someone senior says: "We should probably hire for this."

And so begins a process designed for a different problem.

How recruitment logic works

Recruitment starts with a set of assumptions: that the answer is a person, that the person belongs in a permanent role, and that the way to find them is to describe that role as an advert.

The process follows from there:

• Write the job description.
• Post it.
• Wait for applicants.
• Screen CVs.
• Interview.
• Select.
• Hire.
• Onboard.
• Hope the work fits the role as it was written.

For the right kind of work, this is exactly the right process. A core engineering hire, a head of product, a long-term commercial role with strategic importance — recruitment makes sense. You are buying a relationship, not just a result.

But recruitment was not designed for specialist work that is urgent, scoped and not clearly a long-term role. When you use it for that kind of work, you tend to get slow starts, too many irrelevant applicants, and a process that consumes more time and attention than the work itself.

How deployment logic works

Deployment starts with the work.

Not "what role do we need?" but "what needs to happen, and what capability should be brought to bear?"

The logic runs differently:

• Define the work clearly.
• Describe the outcome.
• Identify the capability needed to produce it.
• Find providers who have deployed that capability before.
• Start with fit, proof and scope.
• Begin the work.

The unit is not a role. It is a piece of work with a clear outcome, a defined scope and a relevant capability. The process is faster because it does not need to solve for the long term before it can solve for the immediate need.

The brief versus the advert

The practical difference shows up in what you write.

A job advert describes a role: responsibilities, requirements, qualifications, years of experience, desirable traits. It is designed to attract a broad pool and filter it down. It optimises for fit with a position.

A capability brief describes work: the outcome you need, the problem currently blocking you, the type of capability required, the scope, the timeline and what a good first conversation should resolve. It is designed to surface providers who can deploy exactly what you need. It optimises for relevance.

An advert says: here is a role we have created, apply if you think you fit.

A brief says: here is the work that needs doing, respond if you can deploy the capability to do it.

For AI implementation, workflow automation, product engineering or internal tools work, the brief is almost always more useful. The work is specific. The skill set is specialist. The need is now, not in three months after a hiring process.

Where recruitment is still the right answer

This is not an argument against hiring.

Some work genuinely needs a permanent role. If you are building a core product team and need someone who will own the roadmap for the next three years, recruit. If you need a head of engineering who will hire, develop and retain a team, recruit. If the work is repeated, strategic and culturally significant, the relationship that comes with a hire is worth the process.

Recruitment solves a real problem. It just does not solve every problem.

Where deployment is the better operating mode

Deployment is the right lens when:

• The work is urgent and the hiring process is too slow.
• The need is specialist and unlikely to justify a full-time role once the project is done.
• You are running an AI or automation experiment and need someone who has done it before.
• You need fractional product or engineering leadership while the full-time hire is being planned.
• You have an internal tool or workflow project that has a clear scope and end state.
• You need to validate a need before committing to a permanent headcount.

In all of these cases, the first question should not be "who do we hire?" It should be "what capability do we need to deploy, and where does it live?"

What this looks like in practice

A 40-person B2B SaaS company needs to automate a manual reporting workflow. The operations team is losing two days a week to it. The CTO knows it can be fixed but does not have the internal bandwidth. It is probably a six to eight week project.

The recruitment reflex says: post a job, look for an automation engineer.

The deployment reflex says: write a capability brief. Describe the workflow, the pain, the desired outcome, the stack and the timeline. Find a specialist who has solved exactly this kind of problem before. Get a human-reviewed shortlist of relevant providers. Start a conversation.

Six months later, the workflow runs without the manual overhead. There is no permanent hire on payroll for work that no longer needs doing. The company has clarity on whether this kind of capability should be internal or deployable.

That is what deployment looks like in practice.

A different operating mode, not a replacement

Deployed Works is not saying recruitment is broken. It is saying that modern teams need another operating mode for work that is urgent, specialist and not clearly a full-time role.

A capability brief is not a job advert.

A capability profile is not a CV.

Relevant providers are not applicants.

A human-reviewed shortlist is not a ranked pile of CVs.

The market for work is not going to look like one thing. Some of it will be permanent hiring. Some of it will be deployed capability. The teams that learn to use both — and know which to reach for — will move faster and spend better.

If you have AI, product, automation or engineering work that needs doing in the next 30–60 days and does not justify a full-time hire yet, submit your first capability brief: https://www.deployed.works/launch/cohort-1