Co-managed IT is the model for that situation. It is also the model most easily done badly, because it introduces a boundary, and boundaries are where work falls through.
What co-managed IT actually is
In a co-managed arrangement the provider works alongside the internal team rather than instead of it. The internal team keeps the parts of the role that depend on knowing the business. The provider takes the parts that benefit from scale, tooling, out-of-hours coverage or specialist depth.
It is not a reduced version of full outsourcing, and it is not staff augmentation. The distinguishing feature is that both parties hold real operational responsibility for different, explicitly defined things — which is precisely why the definition has to be explicit.
Where internal IT usually keeps ownership
The work that depends on organisational context rarely transfers well, and generally should not:
- Relationships with the business. Knowing which department is under pressure this quarter, and who to call before a change lands badly.
- Prioritisation. Deciding what matters most this month is a business judgement, not a ticket-queue calculation.
- Line-of-business application ownership, particularly systems with local configuration, internal customisation or a supplier relationship of their own.
- Institutional knowledge — why a workaround exists, which process breaks at month-end, what was tried in 2019 and did not work.
- Strategic decisions and budget ownership. A provider should inform these and should not make them.
Where a provider adds capacity
The complementary half is the work that improves with tooling, coverage and repetition across many environments:
- Infrastructure monitoring, including out of hours, with a defined response rather than an inbox nobody reads at 02:00.
- Networking design, configuration and support across LAN, WAN and wireless.
- Cloud administration and cost governance.
- Backup operation and, critically, restore testing on a schedule.
- Cybersecurity controls, monitoring and incident support.
- Service desk for first-line volume, so internal staff are not interrupted for password resets during project work.
- Patching and lifecycle management across the estate.
- Technical escalation — a place to take the problem that has consumed two days of an internal engineer's week.
- Project delivery capacity for migrations, refreshes and rollouts that would otherwise compete with daily operations.
The split is not fixed. It should reflect where the internal team's time is most valuable, which differs by organisation and changes over time.
Define responsibility explicitly
This is the part that determines whether the model works. Verbal understanding is not sufficient, because the failure cases occur at exactly the moments when nobody has time to negotiate.
- A written responsibility matrix — RACI or equivalent — covering each service area, agreed by both parties and reviewed as the arrangement matures.
- Escalation paths with names and hours, including what happens when the first contact does not respond.
- Service levels that define severity, response and resolution separately, and state exclusions plainly.
- Change management that both parties follow, so neither is surprised by the other's work.
- Shared documentation, kept current, owned by the client. If the provider leaves, the environment's records stay.
- A named service owner on each side who is accountable for the relationship rather than any individual ticket.
Shared responsibility should not mean shared confusion
The failure patterns are consistent enough to be worth naming, because each has a specific antidote:
- Both parties assume the other owns it. The classic example is a backup alert visible on two dashboards and acted on by neither. Antidote: the matrix names one accountable party per item.
- An alert is seen but not actioned, because seeing it was somebody's responsibility and acting on it was not defined. Antidote: monitoring responsibilities specify the response, not just the visibility.
- Changes made without coordination, so a firewall rule for one project breaks another team's integration. Antidote: one change process, both parties in it.
- Escalation stalls because the path was defined for office hours only.
- Reporting that describes activity rather than outcomes, so both sides feel busy and neither can say whether the service improved.
Every one of these is a definition problem rather than a technical one, which is why they persist through changes of tooling and staff.
Measure outcomes, not activity
Ticket counts describe how much happened, not whether things got better. The measures worth reviewing together are the ones connected to the experience the business actually has:
- Availability of the services that matter, defined by the business rather than by which systems are easiest to monitor.
- Response against agreed targets, by severity, with the exceptions explained.
- Repeat incidents, and whether underlying problems are being resolved or reopened monthly.
- Security posture measured against a baseline that both parties agreed.
- Backup success and, separately, restore test results — the second is the one that matters.
- Project delivery against the dates and scope that were committed.
Review these on a regular cadence with both service owners present. A monthly or quarterly service review is where a co-managed model either matures or quietly degrades into two teams working near each other.
Getting the model right
Co-managed IT is not a compromise between doing it internally and outsourcing. Done deliberately, it lets an internal team spend its time on the work only it can do, while operational depth, coverage and specialist capability come from somewhere with scale to sustain them.
What makes it work is unglamorous: a written split, named owners, one change process, honest reporting and a regular conversation. What makes it fail is assuming those things are understood.
The strongest co-managed model is one where responsibilities are divided clearly, but accountability for the service experience never disappears.
Key takeaways
- Internal IT should keep business relationships, prioritisation, application ownership and strategic decisions.
- A provider adds most value in monitoring, out-of-hours coverage, specialist depth, restore testing and project capacity.
- Write the responsibility matrix down. The failure cases happen when nobody has time to negotiate.
- Name one accountable party per item — most co-managed failures are two parties each assuming the other owned it.
- Review outcomes, not ticket volume, with both service owners in the room.
