TL;DR
- The decision: whether to develop the capability inside, hire it in, or borrow it from outside while you decide.
- Do nothing: when the gap is below the line of risk, when no sponsor is asking, and when the next twelve months will resolve it.
- What must be true: the answer only holds if the choice matches where the capability should live in two years, not where it's needed next quarter.
- How they split: build for permanent, differentiating capability. Buy for speed where the work is well understood. Borrow where the requirement is uncertain or short.
- Decision rule: decide the destination first. The route follows.
- The outcome: a defensible choice, a clean handover at the end, and no surprise dependency on the supplier you chose because you were in a hurry.
The Meeting That Has Already Happened Twice
A CHRO opens the planning pack on a Tuesday morning and finds the same line in three initiatives. Workforce analytics. The leadership team has asked for it in the operations review, the talent review, and the strategic workforce plan that goes to the board next month. The HRBP leading the work has none of it. There's no model, no dashboard, no analyst, no data pipeline. The business sponsor needed it last quarter. The CHRO's instinct is to hire. But the CHRO has also read four articles on this, and every one was a definition followed by a pitch for a platform. None of them helped.
Hiring will take months. The sponsor won't wait. A contractor can start next week and will leave when the contract ends. An agency can own the outcome and hand back a working process, at the cost of a dependency that takes a year to unwind. And developing someone already on the team is free in cash and slow in time, and the work isn't yet defined well enough to know who to develop.
So the CHRO picks on speed. Borrow. That's the obvious answer. It's also the least informative answer. The question that actually decides the choice isn't how fast the work starts, because borrowing is nearly always the fastest, and that much is obvious. The question is where the capability should live in two years. Answer that first and the speed question resolves itself into a sequencing problem, not a fork.
Best tools for HR Strategy
When You Genuinely Do Not Need to Act Yet
Some capability gaps aren't gaps. They're pressure. The instinct to act is real, and the action it pushes toward is often the wrong one. Four stages sit between "your setup is fine" and "you're exposed." Honest assessment starts at the bottom of that ladder, not the top.
Your current setup is genuinely fine. A team of forty in a single location, with one HR director and two generalists, has a workforce plan that lives in a spreadsheet the FD signs off each quarter. It isn't sophisticated. It isn't strategic. It works because the headcount moves slowly, the skills base is stable, and the leadership team knows its people by name. A workforce analytics capability, in this company, would be a solution to a problem that doesn't exist. The honest answer is to leave the spreadsheet alone until the headcount triples, the locations multiply, or the skills profile starts to shift in ways the spreadsheet can't hold.
Mild friction, no real risk. Two hundred people, two sites, a turnover figure that has crept up for two quarters and a hiring manager who keeps asking why the time to hire is what it's. The friction is real. The risk isn't yet material. Here the right move is to spend a small amount of effort finding out whether the friction is a reporting gap or a process gap, because the answer changes the route. A reporting gap can be closed by the people you already have, with better tools they already pay for. A process gap needs something more.
Real risk, but the route isn't obvious. A business with seasonal volume, four hundred frontline hires a year, and a retention rate that varies by region. The capability gap is real. The risk of doing nothing is real. But the route isn't obvious because the requirement is partly cyclical and partly structural, and the wrong answer is expensive either way. This is the stage where the work below earns its place, because the choice here's a real choice and the cost of getting it wrong is visible on the next quarterly review.
The edge case. A capability gap that's also a regulatory exposure, where the absence of the capability is itself a breach, and where the only credible answer in the time available is to borrow while you build. The shape of the legal exposure is what makes the decision urgent, and local advice is what makes it defensible. The route isn't in doubt. The handover is.
Five Questions You Are Asking Yourself at 11pm
Is this really a capability gap, or is it a capacity problem I am misreading? A team that's fully staffed and still missing is missing a capability. A team that's understaffed and producing what it produces is short on capacity. The two need different routes. Treating a capacity problem as a capability gap leads to a hire that doesn't solve the original pressure. Treating a capability gap as a capacity problem leads to overtime on work that can't be done in overtime. Check what your team actually does when the work lands, not what their job descriptions say.
If I borrow, what am I borrowing, and what am I building dependency on? A contractor borrows effort. An agency borrows the outcome and lends you a process. The first leaves when the contract ends. The second leaves when you've built the process yourself and run it for a quarter without them. If you can't describe the handover, you're not borrowing. You're renting a permanent function and pretending the contract has an end.
Will the requirement still exist in two years, and will it still matter? Some gaps close themselves. A new system goes in, a business line sells, a regulator changes its mind. Other gaps widen. If the requirement is a one-off, borrowing is right and building is wrong. If the requirement is permanent, borrowing is a deferral and the bill arrives later.
Who is the capability really for, and who will own it once it lives here? A capability built for one executive sponsor can vanish when that sponsor moves. A capability built into a function survives. The answer to "who owns it" tells you whether to put the work inside that function or somewhere neutral, and that choice changes who you hire, where you put them, and how the budget line looks in a year's time.
What is the worst plausible outcome, and can I live with it? The worst plausible outcome of borrowing is that the supplier walks away at the end and you've not internalised anything. The worst plausible outcome of hiring is that you hire the wrong person and the work is still not done a year later. The worst plausible outcome of building is that the person you developed leaves. Each is recoverable. None is free. Pick the outcome you can absorb, not the one you can describe most easily.
Three Honest Categories the Approaches Split Into
Build. Build is the act of putting the capability inside the organisation in a way that survives the person who delivers it. It's hiring permanently. It's developing someone who already works here. It's acquiring a team that already has the work. Build is right when the capability is core to what the company does, when it's going to matter in five years, and when the cost of an outside supplier owning it's greater than the cost of carrying it yourself. It fails when the work isn't yet well enough understood to hire into, when the budget won't carry a permanent seat, or when the only candidate who fits is a candidate the company can't afford to lose to a competitor who is also hiring.
Buy. Buy is engaging an outside provider to own the outcome. The provider brings the people, the process and often the technology. The organisation brings the requirement and the relationship. Buy is right when the work is well understood, when speed matters more than internal capability, and when the organisation genuinely doesn't need to own the work in two years. It fails when the work turns out to be more bespoke than the supplier's standard offering can carry, when the supplier's economics push them off the account at renewal, or when the inside team has nothing to do once the supplier is in. The third failure is the most common and the least discussed. A buy that removes work from inside the team removes the team's ability to learn the work, and at the end of the contract there's no handover because there's nothing inside to hand over to.
Borrow. Borrow is engaging an individual or a small team for a defined period. The organisation keeps ownership of the outcome. The borrowed resource brings the capability the organisation doesn't have. Borrow is right when the requirement is clear, the timescale is short, and the internal team can absorb what the borrower leaves behind. It fails when the timescale creeps, when the borrower becomes load-bearing rather than enabling, or when the handover is left to the last week of the contract and turns out to be a transfer of files rather than a transfer of judgement. Borrowed capability that has not been internalised by the end of the contract is rented capability with a notice period.
Five Diagnostic Questions You Can Self-Assess Against
Where does this capability need to sit in two years? Not where the work is needed next quarter. Not where the sponsor wants it. Where it has to sit for the company to do what it says it will do in the medium term. The answer narrows the route before any of the others matter.
Is the work well understood, or is it still being defined? Well-understood work can be bought or contracted. Work that's still being defined needs someone close enough to the business to learn as the requirement clarifies. That's almost always an internal hire or a developed internal person.
Can the internal team absorb the work once the contract ends? If the answer is no, you've not closed a capability gap. You have created a permanent dependency with a cancellation clause. Diagnose this before the contract is signed, not at the end of it.
What is the cost of being wrong on speed? A two-month delay on a strategic workforce plan is uncomfortable. A two-month delay on a regulatory reporting line is a different conversation. The shape of the cost changes the route.
Who signs the next quarterly review, and what will they want to see? A board that wants a permanent capability won't be satisfied by a contractor. A CEO who wants a working dashboard next month won't be satisfied by a hire starting in three months. The audience for the decision shapes the form of the answer.
Five Routes to a Capability, Reviewed
Developing Someone You Already Employ
This is the cheapest route in cash and the slowest in time. You take a person who already understands the business, the data and the politics, and you give them the training, the exposure and the space to grow into the work. What earns this route a place is the quality of the handover that comes with it. There's no handover. The capability lives where it's needed, in a person who isn't going to leave the moment the project ends. It also carries the lowest recruitment risk. You have watched the person work. You know how they handle ambiguity. You know whether the leadership team will trust them.
The weakness is the time. Developing someone from "interested and capable" to "independently running the work" is rarely a quarter. It's often a year, and it can be longer if the work is genuinely new. The other weakness is the opportunity cost. While this person is learning, they're not doing their day job, and the day job doesn't pause. For a team of forty with no slack, the route is unavailable in practice even if it's the right answer in principle.
Hiring Permanently from Outside
A permanent hire brings the capability in a known shape, on a known timeline. The market tells you how long it takes. The weakness is that the market is also telling your competitors, and the candidate who fits is interviewing elsewhere. Hiring also assumes you know what you're hiring for. If the requirement is still being defined, a permanent hire is a bet that the definition will hold, and the cost of being wrong is a year of slow progress and a hire who may need to be moved.
Where it falls short most often is in the assumption that the hire will land and integrate. A capability hire who doesn't understand the business in their first six months adds capacity but not capability. The internal team still has to teach them the context, and the work they were hired to do slips while they learn. Permanent is right when the work is well defined and the business context is something a competent professional can pick up. It's wrong when the work is genuinely novel.
Contracting an Individual for a Defined Period
A contractor starts next week. They bring the capability you don't have. They leave when the contract ends. The route earns its place on speed and on the ability to bring in a specific skill for a specific need. It's also the cleanest form of borrowing because the end is built into the agreement.
The weakness is what happens at the end. A contractor who has done the work for eighteen months has absorbed a great deal of context that lives in their head, not in any document. If the handover is left to the last two weeks, you get a transfer of files and a goodbye lunch. If the handover is designed at the start, with regular shadowing, documented decisions and joint ownership of key relationships, the contractor leaves behind a function. The route falls short when the organisation treats the contract as the plan and doesn't design the exit.
Engaging a Managed Service or Agency to Own the Outcome
A managed service brings a team, a process and often the technology. The organisation buys an outcome, not an effort. The route is right when the work is large enough that an internal team would be a stretch, well enough understood that a provider can deliver against a specification, and time-critical enough that the only credible answer is to bring in capacity and capability at the same time.
Where it falls short is in the dependency. A managed service that runs for three years has, in that time, taken ownership of relationships, knowledge and decisions that the inside team would have built if the work had stayed inside. At the end of the contract, the inside team has to rebuild what the supplier already owns. The handover isn't a transfer of files. It's a transfer of an organisation's memory. This route is wrong when the inside team can't absorb what the supplier has built, and the only honest answer is to extend the contract, which makes the dependency permanent.
Acquiring a Team or a Company That Already Has It
Acquisition is the rarest and most decisive route. A company buys a capability by buying the people who already do the work. It's right when the capability is genuinely scarce, when the speed required is beyond what hiring can deliver, and when the team being acquired has a culture and a method that fits the acquirer.
Where it falls short is in everything that makes acquisition hard. The team being acquired has to want to be acquired. Their clients have to want to stay. The integration has to be designed before the deal closes, not after. And the cost isn't a salary. It's a transaction, with all the legal, financial and cultural exposure that brings. Acquisition is also a route that fails quietly. A team that has been acquired and not integrated is a team that walks, and the capability walks with them.
The Decision Table
| Situation | Scale | Setup | Primary Pain | Recommended Starting Point |
|---|---|---|---|---|
| Capability is core, requirement is well defined, time is short | Two hundred to five hundred people, single function | No internal specialist, business sponsor is asking | Quality of decision making over the next year | Hire permanently, with a contractor in place during the search |
| Capability is required for a regulator or audit, and the absence is exposure | Any size where the exposure applies | No internal owner, time pressure is real | The legal and reputational shape of the gap | Borrow under a managed service while you build inside |
| Requirement is unclear, work is being defined, no sponsor pressure | Team of fifty to one hundred fifty | Curiosity rather than crisis | Wrong answer is more expensive than no answer | Develop internally and design the work as the person learns it |
| Work is well understood, cyclical or short, internal team can absorb afterwards | Project based, two year horizon | No internal owner, but capable generalists | Dependency at the end of the contract | Contract an individual with a handover designed at the start |
| Capability is permanently required but the work is large and the internal team is small | Five hundred people plus, multiple sites | No internal specialist, multiple sponsors | Speed to a working outcome rather than ownership of the work | Buy a managed service with a defined exit and a clear inside owner from day one |
| Capability is genuinely scarce and speed is the binding constraint | Strategic acquisition, any size | Strategic gap, market is thin | Time and availability of the right people | Acquire a team with an integration plan written before the deal closes |
| Capability exists in pockets but is fragmented across the business | Mature organisation, multiple functions | Silos, inconsistent quality | Coherence rather than presence | Borrow a senior individual to design the function, then hire into it |
| Work is project based, well scoped, and ends within twelve months | Any size, project led | Time bounded requirement | Getting it done and moving on | Contract an individual with the project plan attached to the contract |
Sizing the Gap Before You Choose
Before any of the routes is chosen, the gap has to be described accurately. A capability gap that's misread becomes a route that misses. The table below sets out the gap types a leader is likely to meet, what each one looks like in practice, and the route it usually pulls toward.
| Gap Type | How You Would Recognise It | Which Routes Suit It | Which Route Is Usually Chosen Instead |
|---|---|---|---|
| Missing skill in an individual | The work is done, but the quality is uneven, and one person cannot cover the harder cases | Develop, hire, contract | Borrow a managed service, because the symptoms look like a volume problem |
| Missing process | The work happens by heroic effort, and the result depends on who is in the room | Borrow a process owner, then hire to run it | Hire a senior individual, who builds the process alone and leaves when they leave |
| Missing function | The work is not assigned to anyone, and it falls to the most conscientious person each time | Build a permanent function | Borrow a contractor, who ends up carrying the function alone |
| Missing technology | The work is done manually because the tools do not exist | Borrow while the tools are built | Hire a person whose first six months are configuring systems rather than doing the work |
| Missing judgement | Decisions are escalated because no one inside is trusted to make them | Hire a senior permanent, or develop internally over a longer horizon | Contract a senior individual, who makes the decisions and leaves with the context |
| Missing ownership | The work is done but no one is accountable for it, and the work drifts | Build a named owner inside, with borrowed support | Buy a managed service, which takes ownership outside and makes the drift invisible for a while |
Once the gap is sized, the next decision is the handover. The handover that decides whether borrowing worked has to be designed at the start of the engagement, not at the end. Most borrowing arrangements fail at the exit, and they fail for a reason that's visible from day one. The inside team has not been involved in the work. The borrowed resource has not been asked to document decisions. The relationships that matter are held by the borrowed resource, not by anyone inside. When the contract ends, the work doesn't transfer. It evaporates, and the inside team is left to rebuild what the borrowed resource already knew.
A clean handover is designed at the start. The borrowed resource is paired with an inside owner from the first week. Decisions are written down as they're made. Relationships are introduced with the inside owner present. The contract specifies what the inside team will be able to do without the borrowed resource by the last month. None of this is unusual. All of it's omitted.
The Handover That Decides Whether Borrowing Worked
| Element of the Handover | What It Means in Practice | Where It Usually Fails |
|---|---|---|
| Inside owner | A named person inside who is accountable for the work throughout the contract, not just at the end | The inside owner is appointed in the last month and treated as a recipient, not a participant |
| Documented decisions | A running record of the non-obvious decisions made during the engagement, with the reasoning behind each one | Decisions are made in conversation and never written down, because the borrowed resource remembers them |
| Introduced relationships | The inside owner is present in meetings with the sponsor, the regulator, the senior stakeholders, throughout the engagement | Relationships sit with the borrowed resource, and the sponsor does not know who the inside owner is |
| Specified exit | The contract states what the inside team will be able to do without the borrowed resource in the last month, with a check against that specification | The exit is a calendar date, not a specification, and the inside team is surprised by what they cannot do |
| Joint working in the final period | The last quarter of the contract is run jointly, with the borrowed resource shadowed rather than in sole charge | The borrowed resource is in sole charge until the last week, and the handover is a transfer of files |
| A written close-out | A short document describing what was delivered, what was learned, and what the inside team should watch for in the first quarter after the contract ends | The contract ends, the invoice is paid, and nothing is written down about what happened |
What to Put in Writing
| Artefact | Who Owns It | When It Is Written | What It Prevents |
|---|---|---|---|
| Capability gap statement | The sponsor of the work | Before the route is chosen | A route chosen for the wrong gap |
| Destination statement | The senior owner of the function | Before the route is chosen | A route that delivers the wrong outcome in two years |
| Inside owner appointment | The senior owner of the function | Before the contract is signed | A handover with no recipient |
| Handover specification | The inside owner, with the borrowed resource | At contract signature | A handover left to the last month |
| Decision log | The inside owner, updated monthly | Throughout the engagement | A handover that is a transfer of files, not of judgement |
| Exit criteria | The inside owner, agreed with the borrowed resource | At contract signature | A contract that ends without a working inside function |
| Renewal or extension criteria | The senior owner of the function | At contract signature | An automatic extension that hides a dependency |
| Post-engagement review | The senior owner of the function | Within a month of contract end | The next engagement repeating the same mistakes |
| Route rationale | The decision maker | Before the route is chosen | A defensible decision becoming an undefendable one |
| Budget allocation and review points | The finance partner for the function | At the point of commitment | A cost that drifts without anyone noticing |
Questions to Ask Before You Commit
On the destination. Where does this capability need to live in two years, and who owns it then? A bad answer is vague, or refers to "us" without naming a function, or changes between meetings.
On the gap. What is the work that's not being done today, and how do we know? A bad answer lists symptoms, not the work. Symptoms are feelings. Work is what gets done or doesn't.
On the route. Why is this route better than the next cheapest one? A bad answer is "it's faster" without explaining what the speed buys and what it costs.
On the handover. What will the inside team be able to do without the borrowed resource in the last month of the contract? A bad answer is silence, or a description of files and folders rather than judgements and relationships.
On the dependency. What happens if the supplier walks away at the end of the contract? A bad answer is that the contract will be renewed. A contract that will be renewed is a permanent arrangement dressed up as a temporary one.
On the inside owner. Who inside is accountable for the work, and what is their day job while they carry this? A bad answer is a name with no time, or a name who is also sponsoring the work.
On the cost of being wrong. What is the worst plausible outcome, and what does recovery look like? A bad answer is "it will be fine", because it won't be fine in some scenario, and the decision has not priced that scenario.
On the timeline. What does the next quarterly review need to see, and how does this route deliver it? A bad answer is the date of a contract signature, because a signature isn't an outcome.
The Cost of Getting This Wrong
The cost that appears on an invoice is the smallest part of the cost. The larger costs arrive later and they arrive quietly. A capability gap that was closed by borrowing and never internalised becomes a permanent dependency on a supplier whose price the company no longer controls at renewal. A capability that was closed by hiring and not integrated becomes a slow walk to the same dependency, because the hire leaves when the work is still not done and the company hires the supplier they were trying to avoid.
A capability that was closed by developing and not given the room to grow becomes a person who learned the work and left for a competitor who will pay for what the original employer wouldn't. A capability that was closed by acquisition and not integrated becomes a team that walks, and the company has paid twice, once in the deal and once in the rebuild.
The second-order costs aren't visible at the point of decision. They're visible in the third year, in the supplier negotiation that goes the wrong way, in the hire who leaves in month fourteen, in the team that walks six months after the deal closes. So the question to ask before any of the routes is chosen isn't what does it cost, but what does it cost to be wrong about this in three years, and who inside is going to be the one carrying that cost.
When You Are Ready to Go Further
HROpsLab publishes independent reviews of the platforms and providers that sit behind the routes above. We don't sell software. We don't supply payroll services. We don't give legal or financial advice. What we do is compare what is on offer, on the dimensions that matter once a route has been chosen, so that the choice inside the route is made on evidence rather than on a sales call. If you're weighing managed services for a function you've decided to buy, or workforce planning tools you've decided to use, the reviews sit alongside the reasoning here.
For teams who want a second view on the route itself, the case studies linked below show how other HR leaders have sized the gap, chosen the destination and designed the handover. They're written as decisions rather than outcomes, which is the form this article has tried to take.
[Two-CTA block: Case Studies | Talk to Expert]
[Related blogs: 6-9 handpicked related posts]
Frequently Asked Questions
What does build, buy or borrow mean in an HR context?
Build is putting the capability inside the company, either by developing someone who already works there or by hiring permanently. Buy is engaging an outside provider to own the outcome, usually through a managed service or a significant outsourcing arrangement. Borrow is engaging an individual or a small team for a defined period, with the inside team keeping ownership of the outcome. The three aren't equally fast, and they're not equally durable, which is why the choice is a real choice rather than a slogan.
How do you decide which route fits a given capability gap?
Start with the destination. Where does the capability need to live in two years, and who owns it then. The answer narrows the route before any of the other questions matter. A capability that needs to live inside is built. A capability that doesn't need to live inside can be bought or borrowed, and the choice between those two comes down to whether the inside team can absorb what the outside provider leaves behind.
When is developing internally a realistic route?
Developing internally is realistic when the work isn't yet well defined, when the inside team has someone whose trajectory fits the work, and when the organisation can afford the time it takes. It's unrealistic when the requirement is urgent, when the inside team has no one close to the work, or when the day job doesn't allow the space to learn. The route is also unrealistic when the work is genuinely scarce in the market, because the market will pay more than the inside team can match once the person is trained.
Can contractors transfer knowledge to the inside team?
They can, and they usually do, when the transfer is designed at the start of the engagement. A contractor who is paired with an inside owner, who is asked to document decisions, and who is shadowed in the final quarter leaves behind a function. A contractor who is treated as the answer rather than the bridge leaves behind a gap with a calendar attached to it. The route works when the organisation treats it as a route, not as a substitute for one.
What do you do when the business will not wait for a permanent hire?
You borrow first, and you design the borrowing so that it ends in a hire. The borrowed resource buys the time. The hire closes the gap. The inside owner is appointed at the start of the borrowing, not at the end, and the handover specification is written into the contract. The business gets the outcome it needed next quarter. The function gets the capability it needs in two years.
How do you avoid becoming dependent on a supplier?
You appoint an inside owner at the start of the engagement. You write down what the inside team will be able to do without the supplier in the last month. You keep the relationships inside, even while the supplier is doing the work. You specify the exit before you sign the contract. Dependency is what happens when none of this is done, and the contract ends without anyone inside knowing how the work was actually delivered.
Is it ever right to hire ahead of the need?
Yes, when the work is permanent and the lead time to hire is longer than the time the business can absorb the gap. Hiring ahead of the need is a strategic decision, not a planning error, and it has to be defended on the same basis. It's wrong when the work turns out to be smaller than expected, because the cost of the seat continues after the work has gone. The honest answer is to size the work before sizing the hire.
How do you tell a capability gap from a capacity problem?
A capability gap is work that the team can't do, regardless of how many hours they have. A capacity problem is work the team can do, but can't do enough of. The two need different routes. Treating a capacity problem as a capability gap leads to a hire that doesn't solve the original pressure. Treating a capability gap as a capacity problem leads to overtime on work that can't be done in overtime. The check is what the team actually produces when the work lands.
HROpsLab is an independent review publication. We compare platforms and providers on the dimensions that matter, and we publish the reasoning.
