On a call last week, the operations lead at a fast-growing organization walked us through how she's reshaping her internal IT team, and where an outside partner fits into that. It's a good example of co-managed IT done for the right reason: not to hand off the whole function, but to add reach the internal team doesn't have yet.
Splitting one IT team into two tracks
The company grew fast, and the IT team grew with it as generalists doing a bit of everything. Now there's enough volume to specialize. The plan is to split the team into two tracks: infrastructure and security on one side, business operations and applications on the other. A few net-new roles get added, and the existing people slot into whichever side fits their strengths.
That's a healthy move, but it creates gaps. A splitting team almost always has more work than heads, and the specialists you want don't all exist internally yet. That's where co-managed IT comes in.
What co-managed actually means here
Co-managed IT means your internal team keeps ownership and an outside partner adds capacity and specific skills on top. It's not an all-or-nothing outsource. You decide what stays in-house and what flexes to the partner, and that mix can change as your team matures.
- Help desk: a partner can staff a dedicated person who handles the front line and escalates only what your team needs to see.
- Project spikes: a CRM rollout or an onboarding-automation build needs hands for a few months, not forever. A partner flexes people in and back out.
- Specialized skills: single sign-on setup, device provisioning through Intune, security hardening. Bring in the depth for the build, then hand it back.
- Escalation coverage: when the internal team hits something outside their permissions or expertise, there's a defined place to send it.
Map the environment before you take over support
One point worth stressing: before a partner can support your applications and help desk, someone has to map what's actually running. Knowing the names of the tools isn't enough. You need a catalog of what each application does, who owns it, and where a ticket goes when the first line can't solve it.
That mapping work isn't glamorous, but it's what keeps your technical people from dropping what they're doing to chase a small permissions request. When escalation points are written down, the front line resolves what it can and routes the rest cleanly.
Your team owns the environment. The partner adds breadth and depth on the projects and support tiers where you're short, and steps back as your bench fills in.
Build the org chart first
Before any of this gets staffed, it helps to draw the target org chart: the two tracks, the roles that exist, the roles you're hiring, and the spots where a co-managed partner covers the gap. Once you can see it, decisions about what to hire versus what to flex get a lot clearer, and so does the question of who escalates to whom.
If your IT team is at this crossroads
Growing past the generalist stage is a good problem, but it's still a problem to solve deliberately. If you're figuring out how to split an internal team and where an outside partner should plug in, we're glad to sketch it out with you.