How to Virtualize a Business Function Without Breaking It
Most companies are built around functions.
Sales. Finance. Engineering. Customer Success. Supply Chain. Compliance. HR.
Each function usually has a leader, a budget, a team, and a collection of responsibilities. Over time, the function becomes part of the company’s identity.
That structure made sense when most capability had to be owned through employment. If you needed a function to perform reliably, you hired the people who performed it.
That assumption is beginning to change.
Today, capability can come from employees, specialists, partners, software, AI agents, and external delivery teams. The function still matters, but the question is whether the company needs to permanently own every capability inside it.
That is where virtualization begins.
Virtualizing a business function does not mean removing the function from the company. It means separating ownership of the outcome from permanent ownership of every capability required to produce it.
That sounds simple. In practice, it changes a lot.
A function is bigger than the people inside it
Take Customer Implementation.
On the org chart, it may look like a team with a VP, a few implementation managers, integration engineers, data specialists, trainers, and support staff. That structure tells us who belongs to the function.
It does not fully explain how implementation actually happens.
One customer may need heavy integration work. Another may need almost none. One may require a difficult migration. Another may need security review, localization, or a specialist who understands a particular ERP.
The demand is uneven.
Yet the department is usually built as if all of those needs should exist permanently.
That creates a familiar problem. Some people are overloaded while others are underused, and the company still ends up borrowing people from Engineering when something unusual happens.
The function exists, but its capability shape does not match the work.
This is the same tension we explored in Work Is Episodic. Why Are Teams Permanent?. The work changes faster than the structure around it.
Virtualization starts by admitting that.
Do not virtualize the org chart
This is the first mistake I would avoid.
If a company takes its existing department, removes the employees, replaces them with contractors, and calls the result virtual, it has not improved the operating model. It has simply moved the payroll line.
The old structure remains.
The same roles remain. The same handoffs remain. The same management layers remain. The same assumptions about work remain.
Only the employment relationship changed.
That is not virtualization in any meaningful sense.
A better approach is to start from the outcome.
What is this function actually responsible for making true?
For Customer Implementation, the answer might be that customers should reach productive use quickly, safely, and with minimal disruption.
For Compliance, it may be that the business stays within regulatory requirements while still moving fast.
For Growth, it may be that demand is created, qualified, converted, and learned from efficiently.
Once the outcome is clear, you can look at what capabilities are really required.
That is where the structure starts changing.
Find the permanent core
Every function has a part that should probably stay close to the company.
This is the part that carries judgment, context, customer trust, long-term memory, and institutional responsibility. It is usually smaller than the whole department, but more important than people realize.
For Customer Implementation, the permanent core may include the implementation leader, product knowledge, customer ownership, and certain architecture decisions. For Finance, it may include financial control, capital allocation, policy, and executive judgment.
For Compliance, it may include regulatory accountability and risk interpretation. For Product Engineering, it may include product direction, architecture, and deep technical context.
This is the sovereign core of the function.
The company should be very careful about hollowing it out.
A virtualized function should not become a shell that depends entirely on outsiders to understand what the company is doing. If the external capability disappears and the company can no longer explain its own process, the model has gone too far.
That is why the internal core matters.
It holds the function together even when the execution capacity around it changes.
Separate permanent capability from variable capability
Once the core is clear, the next step is to look at everything else.
Some capability is needed every day. Some is needed every month. Some appears only when a certain type of customer, project, regulation, or technical problem shows up.
Those categories should not all be staffed the same way.
Imagine a Product Engineering function.
The company may always need product leadership, architecture, and a core set of engineers who understand the platform deeply. But it may need a performance specialist only during scale events, a security expert during major releases, or a data engineer during a particular product phase.
Hiring every possible capability permanently feels safe, but it creates a bloated structure.
This is where Roles Are Fiction. Capabilities Are Real. becomes practical. The company stops asking which roles belong permanently in the department and starts asking which capabilities must remain available.
Some should be owned.
Some can be accessed.
Some can be automated.
Some can be activated only when needed.
That is a much more flexible way to think about the function.
Let the function stay stable while the capability mix changes
This is the heart of the idea.
The function does not disappear just because its internal composition changes.
A Customer Implementation function can still have clear ownership, standards, customer accountability, and performance goals. It simply does not need the same people around every customer.
A Supply Chain Analytics function can remain responsible for decision support and operational insight. It may use internal analysts, outside data specialists, forecasting agents, and domain experts at different times.
A Compliance function can remain fully accountable to the company. It may bring in specialist legal or regulatory capability when the environment changes, while AI handles repetitive monitoring and documentation.
The function remains real.
Its capability system becomes more fluid.
This is one reason the Virtual Delivery Center Protocol matters. The VDC gives that fluid capability a persistent operating environment.
The mandate stays.
The people and tools can change.
AI makes virtualization more useful, but also more dangerous
AI changes the economics of a function because some work no longer needs to be tied to human capacity.
A finance team may automate reconciliation. A customer success function may use agents to monitor risk signals. A product team may use coding and testing agents. A compliance team may use agents to track policy changes and prepare evidence.
That sounds like a clear gain.
But there is a danger.
If companies simply add AI on top of an old department structure, they may create more noise instead of less. People get more outputs, more alerts, more drafts, and more things to review.
The point is not to make the existing department faster at producing activity.
The point is to redesign the function around what humans should own, what agents can do well, and where judgment must remain.
We looked at this in How AI Agents Fit Inside a Virtual Delivery Center. Inside a virtualized function, agents should be treated as bounded capabilities, not as magical replacements for people.
They need clear jobs.
They also need owners, access limits, and verification.
Governance becomes more important, not less
The moment capability comes from different places, governance becomes more important.
An employee may perform one piece of work. An outside specialist may perform another. An agent may handle monitoring. A partner may contribute to a specific module.
If nobody knows who owns the whole outcome, the function fragments.
That is why virtualization has to start with clear ownership.
There should still be someone inside the company who can say, "This function is ours. These are the standards. These are the decisions we keep. These are the capabilities we access."
The same logic applies to access.
An external specialist should see only what they need. An agent should have only the permissions required for its task. Temporary access should disappear when the work ends.
This is where VDC Governance: Borderless Execution Without Losing Control becomes essential.
A function can become more flexible without becoming loose.
In fact, it may become more controlled because the boundaries have to be made explicit.
What should not be virtualized
This is where I would be cautious.
Not every function should be pushed toward maximum flexibility.
Some capabilities are so central to the company that they need deep, permanent ownership. They shape competitive advantage, customer trust, culture, or institutional memory.
If a software company no longer understands its own architecture because every important technical decision sits outside, that is a problem.
If a financial institution delegates too much risk judgment, that is a problem.
If a company’s customer relationships are managed entirely through people who have no long-term connection to the business, that can become a problem too.
Virtualization should reduce unnecessary ownership of variable capability.
It should not reduce the company’s ability to understand itself.
That is the boundary.
The goal is not to make the company hollow.
The goal is to make it lighter without making it weaker.
Start with one function that already feels stretched
The easiest place to begin is usually a function where the current model is already showing strain.
Maybe the team keeps borrowing people from other departments.
Maybe demand rises and falls sharply.
Maybe the function needs too many specialist skills to hire permanently.
Maybe managers spend more time finding capacity than actually leading the work.
Those are useful signals.
Customer Implementation is often a good example because the work is persistent but the capability mix changes by customer.
Product Engineering can also be a strong candidate when the roadmap needs specialist skills that do not justify permanent headcount.
AI Modernization is another obvious one because the work naturally crosses technology, data, security, operations, and business teams.
The best starting point is not the function that is easiest to virtualize.
It is the function where the current structure is most obviously mismatched to the work.
A practical way to reshape the function
I would begin by writing down the function’s real mandate in plain English.
Then I would identify the few decisions and capabilities that must remain inside the company. That becomes the permanent core.
After that, I would look at the remaining work and group it by capability.
Some work will need regular human involvement. Some will need specialist support only occasionally. Some can be automated. Some can be handled through a delivery partner.
Then I would bring those capabilities into one VDC around the function.
The first version does not need to be perfect.
It only needs enough structure to let the company try the model on real work.
The VDC becomes the place where the function’s outcome, internal ownership, outside capability, agents, systems, governance, and verification come together.
Over time, the company learns which parts should remain stable and which parts should stay flexible.
That learning matters more than getting the design right on day one.
The biggest change is in how leaders think about headcount
Today, a functional leader is often asked a familiar question.
How many people do you need?
That question shapes budgets, planning, and even status.
A leader with a large team is often assumed to have a large mandate.
Virtualization changes the question.
Instead of asking how many people the function needs, we can ask how much capability the function needs to keep permanently and how much it should be able to activate when required.
That is a healthier question.
It also forces leaders to think about the work more carefully.
A function may become more capable while employing fewer people.
That does not mean it became weaker.
It may have simply stopped carrying capability it only needs occasionally.
This is the broader shift we explored in The Company After Headcount.
Capacity is no longer the same thing as payroll.
Managers have to change too
A virtualized function needs a different kind of manager.
The manager is no longer simply responsible for a fixed group of people.
They become responsible for the capability system around the outcome.
That means knowing what should stay internal, when to bring in a specialist, when AI can take over repetitive work, when a provider is becoming too important, and when the function is losing knowledge it should keep.
It also means caring more about the flow of work.
Where is the work waiting?
Which decision is stuck?
Which capability is missing?
Where is quality slipping?
These questions are more useful than asking whether everyone is busy.
That can feel uncomfortable at first.
But it is closer to what management should have been about all along.
The function should become easier to scale up and down
One of the clearest benefits of virtualization is that the function can respond to changing demand without constantly restructuring.
If customer implementation demand doubles for three months, the VDC can add capacity around the existing core.
If demand falls later, that temporary capacity can leave.
If a new regulation creates a specialist need, the capability can be activated without building a permanent team around it.
If an agent removes repetitive work, the function does not need to preserve the old staffing model just because it existed before.
This reduces the need for the cycle companies know too well.
Hire fast during growth.
Freeze hiring when uncertainty arrives.
Lay people off when the forecast changes.
Then hire again when demand returns.
That cycle is expensive for companies and brutal for people.
A more flexible capability model can reduce some of that instability.
The internal team may actually become more valuable
There is an interesting side effect.
When a function stops using employees for every possible kind of work, the people who remain inside can focus on the work that really needs them.
A customer implementation leader can spend more time with customers and less time hunting for specialist capacity.
An architect can focus on important technical decisions instead of being pulled into every routine implementation detail.
A compliance leader can spend more time on interpretation and risk and less time assembling repetitive evidence.
The internal team becomes smaller in scope but richer in responsibility.
That can make the work more meaningful.
It can also make the company more thoughtful about whom it hires.
Permanent employment becomes something the organization uses deliberately for permanent value.
The function should build memory, not dependence
A virtualized function will fail if every new outcome starts from zero.
The VDC needs to remember.
It should retain decisions, patterns, useful specialists, architecture knowledge, verification methods, and lessons from previous work.
If a particular integration has been solved before, the company should not rediscover it next month.
If a specialist performed well, that relationship should remain available.
If an AI workflow proved reliable, the company should reuse it.
This is what turns a loose collection of external capability into a real execution environment.
The function becomes smarter over time.
That is very different from a temporary project team that disappears when the project ends.
The function should still feel like part of the company
This is important.
Virtualization should not create a strange layer of outsiders who feel disconnected from the company’s purpose.
The people participating in the VDC should understand the outcome, the standards, and the context required to do good work.
That does not mean everyone needs the same cultural experience as a full-time employee.
It does mean the work should not feel anonymous.
Good execution still depends on care.
People do better work when they understand why it matters.
Agents do better work when the context and rules around them are clear.
A virtualized function needs enough continuity for both.
You will know the function is working when nobody cares where the capability came from
At maturity, the organization should stop obsessing over whether the work was performed by an employee, a specialist, a partner, or an agent.
People should care about whether the right capability was present and whether the outcome was delivered well.
That is the shift.
The company still needs governance.
It still needs visibility.
It still needs to know who or what acted.
But capability source stops being the first question.
The work comes first.
That is when virtualization stops feeling like a workforce experiment and starts feeling like normal operations.
The function does not disappear. It becomes more deliberate.
There is a fear behind all of this.
If we make functions more virtual, do we eventually lose the company itself?
I do not think that has to happen.
The company still has purpose.
It still has leaders.
It still has culture.
It still has customers.
It still has people who carry deep knowledge and responsibility.
What changes is the assumption that every important capability must sit permanently inside a department.
That assumption made sense when work, technology, and labor changed slowly.
It makes less sense now.
A company can own the outcome without owning every pair of hands involved in producing it.
It can retain judgment without retaining every specialist permanently.
It can preserve accountability while allowing capability to move.
That is the promise of virtualizing a business function.
Not less structure.
Not less responsibility.
Not a hollow company held together by contractors.
A clearer core, surrounded by capability that can change with the work.
The function remains.
The weight around it becomes lighter.
And if we do it carefully, the company becomes more capable without becoming more fragile.