
If you searched “co-managed IT,” you probably found a dozen articles telling you it’s the tidy middle ground between running IT yourself and outsourcing it entirely. You have a team, a provider supplements them, everyone shares the load.
That definition is accurate. It just doesn’t describe what most companies actually end up buying.
Co-managed IT describes a relationship we rarely encounter in practice. Companies may call it co-managed. But at the end of the day, one party owns accountability, and it’s almost always the client.
That gap between the search term and the reality is worth closing, because picking the wrong model is expensive.
There are three distinct arrangements hiding under the co-managed umbrella, and the difference between them comes down to one question: who owns the SLA?
Staff augmentation. External people, internal management. You place skilled resources inside the client’s org chart, and they follow the client’s direction day to day. The provider owns none of the service-level accountability. As Derive Technologies EVP Mitch Martinez puts it, staff augmentation is “the furthest away from outsourced managed services as you can get.”
Managed services. The provider owns a defined scope and is accountable to measurable SLAs: uptime, resolution time, resiliency. Critically, that scope can be narrow. A managed service doesn’t have to mean all of IT.
Co-managed IT. A shared-accountability model where the internal team and the provider each own defined pieces of the same environment, with overlapping escalation.
| Model | Who manages day to day | Who owns the SLA |
|---|---|---|
| Staff augmentation | The client | No one on the provider side |
| Managed services | The provider, within a defined scope | The provider |
| Co-managed IT | Both, for defined pieces | Shared, with overlapping escalation |
Most organizations think they want the third one. Most of them are actually shopping for the first or the second.
There’s no fixed rule, but there’s a very reliable pattern.
Enterprise (10,000+). Large banks, global tech firms, major financial institutions. These companies almost never outsource management of critical systems. Their leadership doesn’t want a third party accountable for uptime and data integrity, because the board holds them accountable. They’ll rent cloud capacity and colocation space all day long, but they buy people, not accountability. That’s a staffing model.
Middle market (roughly 1,000 to 10,000). This is where specialized managed services thrive. These organizations rarely outsource all of IT, but they’ll hand over a well-defined domain (data center operations, tactical work like installs, moves and changes) and hold the provider to deliverables.
Smaller teams with spiky demand. This is where true co-managed makes the most sense, and it’s usually driven by two conditions at once: a staff too small to cover every skill, and demand that isn’t flat across the year.
That second condition matters more than people expect. Consider a public-sector organization whose IT load spikes hard around primary and general elections and stays quiet the rest of the year. They can’t fully outsource, because the sensitivity of the work demands internal oversight. But they also can’t justify staffing for their peak, leaving people idle ten months a year and still short-handed during the other two. Co-managed is the best-fit model in this instance.

One of our healthcare clients is a large public hospital system. We support the medical carts used across their acute-care facilities, under a defined SLA. We own that accountability completely.
Is that “co-managed”? Not really. It’s a managed service with a deliberately narrow cross-section, chosen because the client has no workshop, no specialized tooling, and no realistic path to doing that work in-house. Almost no organization can.
Another client, a senior care provider, has strong end-user, cloud, and data center capability but almost no networking skill in-house. They never hired for it, because we own that cross-section for them. They keep their applications internally and go straight to the software manufacturers for support.
Neither one is buying “co-managed IT.” Both are buying a precisely scoped managed service that closes a specific capability gap.
When executives evaluate this decision, they’re rarely thinking about team burnout. Burnout is real, and it’s a consequence, but it doesn’t drive the conversation.
What drives it is coverage and capability. The question sounds like this: I need 24×7 coverage. I have six people who work from nine to five. How do I get there?
Or: We need a skill set we’ve never hired for, and hiring for it now means one person with no backup.
Here’s the arithmetic that closes these deals.
Two internal hires at $50,000 each. Add benefits, FICA, and overhead and the real cost is closer to $70,000 apiece. Call it $140,000, plus desk space, so roughly $150,000 all in.
A provider comes in and says: we’ll deliver that same function for $100,000.
The cost comparison is the easy part. The part clients underestimate is what else comes with it. Those provider resources are 100% focused on their specialty, sharpened across multiple environments. And you get a bench. When your one internal specialist is out sick, there’s no backup unless you already built one. When a provider’s engineer is out, someone equally qualified picks it up.
Almost never for technical reasons. Three failure modes account for most of it:
What is co-managed IT?
A shared-accountability model where an internal IT team and a provider each own defined pieces of the same environment, with overlapping escalation. In practice it is rarer than the search volume suggests.
What is the difference between co-managed IT services and managed services?
Under managed services, the provider owns a defined scope and is accountable to measurable SLAs. Under co-managed IT, accountability is shared between the internal team and the provider for defined pieces of the same environment.
Is staff augmentation the same as co-managed IT?
No. With staff augmentation, external people work under the client’s management and the provider owns none of the SLA accountability. It is the furthest model from outsourced managed services.
Why do co-managed IT engagements fail?
Almost never for technical reasons. The common causes are no transition plan, an undefined escalation path, and a provider without the right skills or the bench depth to meet its SLAs.
There is no universally right answer here. Size, industry, IT intensity, and existing skill gaps all move the line, and the line isn’t fixed.
What is fixed is the discipline: define the terminology, define who owns what, define the SLAs you’ll be measured against, and build the transition plan before anyone touches a ticket. Get those right and the label on the contract barely matters.
Not sure whether you need co-managed IT, a scoped managed service, or additional staff? Let’s map your environment against your actual capability gaps. Talk to Derive.