Right-Sizing IT to Your Growth Stage: Fully Managed, Co-Managed, or Staff Augmentation
I met the founder of a Bay Area SaaS company a few months after she'd made a decision she was still second-guessing. Her company had run on a fully managed IT contract since the day she signed her first lease, and it had worked fine for years. There was no drama and no incidents worth mentioning. Then she hit around 120 employees, hired a VP of Operations, and within six months that VP had convinced her the company had "outgrown" outsourced IT. They hired three internal engineers, gave notice to their MSP, and set out to run IT themselves. Their initial setup had been right-sized for a 20-person startup, and nobody had stopped to ask whether it still fit a company six times that size.
Eight months later, I sat across from her while she walked me through what had happened. One of the three engineers, the one who'd set up most of the infrastructure, held nearly all the institutional knowledge in his head. Nobody else on the team had deep security experience, so patching and monitoring happened in bursts whenever someone remembered, rather than on a schedule. When that engineer took two weeks of vacation, nothing broke outright, but nothing moved either. Tickets piled up, laptop provisioning requests sat untouched for days, and the VP who'd pushed for this quietly started asking whether they needed a fourth hire just to cover the gaps. That fourth hire, fully loaded with salary, benefits, and recruiting cost in this market, would run more than the entire MSP contract they'd walked away from.
Nothing about this company's decision was foolish. Hiring your own IT team feels like the mature move, the one that says you've arrived. What went wrong is quieter and more common than that: they treated the choice as binary, either the MSP does everything, or we do everything ourselves, and skipped the stage in between where a lot of the value sits. That stage has a name. It's called co-managed IT, and knowing when you've reached it matters more than knowing the service model.
The Question We Keep Getting Asked Wrong
Founders and operators tend to frame this as "should we outsource our IT or bring it in-house," as if there are only two doors and you have to pick one for good. I understand why. Vendor conversations are usually pitched that way, and so are internal hiring conversations too. Nobody walks into a board meeting and proposes "let's do a bit of both, split by function." It sounds indecisive next to "we're building our own team."
But growth doesn't happen in two stages; it happens in three, and each one calls for a distinctly different relationship between what you own internally and what you hand to a partner. A company with 30 employees has no internal IT function to protect, so fully managed is the correct way forward, not a placeholder. A company with 150 employees usually has, or should have, someone internal who understands IT as well as the business well enough to make judgment calls, but doesn't have the depth or the coverage to run the entire IT function alone. A company past 500 has a real IT department with its own management layer, and the question shifts again, from "do we have enough people" to "do we have the right specialized skills for this specific project."
Skipping the middle stage is what got our SaaS founder into trouble, and it's what I want to walk through here, stage by stage, so you can tell which one you're in.
Defining Managed, Co-Managed, and Staff Augmentation Models
To see where your company fits, we need to be precise about the marketing blurred lines between these three models.
Fully managed IT means an outside provider owns the entire function end to end: helpdesk, infrastructure, security monitoring, vendor relationships, all of it, typically under a service level agreement that spells out response times and scope. You're not expected to have anyone internal directing the work.
Co-managed IT splits the work by strength. Your internal team, even if it's one person, keeps the institutional knowledge, the architecture decisions, and the roadmap. The MSP absorbs the functions that don't require that context: after-hours coverage, specialized security operations, help desk overflow, patching at scale, etc. Nobody is "junior" in this relationship. It's simply a division of labor between two parties, each possessing unique expertise the other doesn't.
Staff augmentation is different from both. You keep full ownership and management of IT, and you bring in outside people to fill specific seats, usually for a defined project or a skill you don't have time to hire for permanently. The augmented staff report into your management structure. They're extra hands, not strategy.
The billing structure behind each model tells you almost as much as the definition does. Fully managed usually runs on a flat monthly retainer scaled to headcount, device count, or hours, because the provider is pricing in everything from helpdesk tickets to security response. Co-managed splits the invoice by scope: you're paying your own team's salaries directly, and paying the MSP separately for whichever slice of the work they've taken on, which means the contract should spell out exactly where their responsibility starts and stops. Staff augmentation is usually billed by time and materials or a fixed term per seat, closer to a staffing agency relationship than either of the other two. If a vendor can't explain clearly which of these three billing structures you'd be under, that's worth pausing on before you sign anything.
The mistake isn't picking the wrong one of these. It's assuming you only ever get to pick one, forever.
10 to 100 Employees: Why Fully Managed IT Is the Right Default
If you’re under 100 employees and don’t have a dedicated IT lead, stay the course. Fully managed IT is the gold standard for this stage, and you shouldn’t feel pressured to "graduate" just because your headcount crossed a specific threshold. At this size, your focus must remain on product-market fit and revenue, not infrastructure architecture. Every hour you spend trying to manage IT yourself, or hiring a junior person to act as a glorified helpdesk, is an hour stripped from your core business.
The real risk isn't staying "managed" for too long; it's rushing to build an internal function before you have the genuine need for it, or the leadership to guide it.
You’ll know you’ve outgrown this stage not when you hit a specific number on the spreadsheet, but when you make your first strategic IT hire. Just ensure that when you do, you update the relationship with your MSP. If you hire a lead and they’re still spending their day fielding the same tickets your MSP already handles, you haven’t upgraded your IT model; you’ve simply increased your overhead.
100 to 500 Employees: This Is Where Companies Skip a Step
This is the stage my SaaS founder was in when she made the switch, and it's the stage where the binary framing does the most damage. By this point, you almost certainly have, or need, someone internal who understands your business, your compliance posture, and your vendor relationships well enough to make calls the way an outside party never could. What you don't yet have is the depth of a bench an MSP builds by working across dozens of clients, or the coverage to handle a 2 a.m. security alert without burning out the one person who knows how to respond to it.
There’s a real cost to taking your IT fully internal too soon. When companies skip co-managed and build a full internal team at this stage, the costs show up in ways that don't appear on the org chart. Recruiting for specialized security or infrastructure roles in the Bay Area takes real time and money, and every month a seat remains vacant is another month of unmitigated risk. Once you've hired, there's a training and ramp period where that person is learning your environment rather than protecting it, and during that window you're paying full salary for partial coverage.
Then there's the single point of failure problem, the one that bit my SaaS founder. When institutional knowledge lives in one or two heads, a vacation, an illness, or a resignation doesn't just create an inconvenience; it creates a gap nobody else can see into. And even a strong internal hire has a narrower range of specialized experience than a provider who's dealt with ransomware recovery, SOC 2 audits, and network redesigns across a much wider set of environments.
None of this means the internal hire was a bad idea. It just means that the internal hire needed a partner, not a replacement.
What co-managed solves here. Done well, co-managed IT at this stage means your internal person owns strategy, prioritization, and the decisions that require knowing your business, while the MSP owns the functions that don't need that context: monitoring, patching, after-hours response, help desk overflow, and specialized security work your internal team doesn't have bandwidth to build in-house. When my SaaS founder's team eventually reversed course and brought in a co-managed partner, the same internal engineer who'd been drowning in tickets went back to setting technical direction, because the routine load had somewhere else to go. The MSP relationship gave the team something a fourth hire wouldn't have: coverage that doesn't disappear when one person takes time off.
The reason companies skip this stage isn't that co-managed doesn't make sense. It's that switching from fully managed to co-managed feels like an unfinished decision next to "we built our own team," and renewing the existing MSP contract without asking whether the relationship still fits is the path of least resistance. Nobody schedules a meeting to ask "should we still be structured this way," so the structure just persists past the point where it fits.
500+ Employees: Staff Augmentation and the Hybrid Reality
Past 500 employees, most companies have a real IT department with its own management layer, its own budget, and its own hiring pipeline. The gap isn't strategy or coverage anymore, both of which the internal team already has, but the capacity for specific projects or specialized skills that don't justify a permanent hire: a cloud migration, a hiring surge, a compliance push ahead of an audit, a platform build that needs someone with narrow expertise for four months.
Staff augmentation fills exactly that gap. You bring in people under your own management, for a defined scope, without adding permanent headcount for work that has an end date. What surprises a lot of leaders at this stage is that staff augmentation and co-managed IT aren't mutually exclusive, and plenty of 500-plus organizations run both at once. Security operations is the function I see stay co-managed most often even after a company has built out a full internal IT org, simply because round-the-clock specialized monitoring is expensive to staff internally and easy to get from a partner who's already built for it.
The mistake at this stage isn't usually about picking the wrong model. It's assuming that because you've built a full internal org, every remaining gap needs a permanent hire to fill it.
Why Right-Sizing IT Matters More If You're Regulated
Everything covered above holds regardless of industry, but the stakes change if you're a SaaS company chasing a SOC 2 report, a fintech startup under SOX-adjacent controls, or a healthcare company handling PHI under HIPAA. Auditors care about segregation of duties, about who can access what and why, and about whether the same person who requests a change is also the one approving it. A single internal engineer holding all the institutional knowledge isn't just an operational risk in a regulated environment; it's a control weakness an auditor will flag directly.
Co-managed arrangements tend to hold up better here than a rushed internal buildout, because the split of responsibility that makes co-managed work day to day is often the same split an auditor wants to see documented anyway. Your internal team owns the decisions and can speak to why access is structured the way it is, while the MSP provides the specialized monitoring, patch cadence, and incident response documentation that shows up directly in an audit trail. We've seen companies scramble to retrofit this structure in the three months before an audit, when it would have taken a fraction of the effort to build it using a co-managed IT service model.
How to Tell Which Stage You're In
Headcount is a rough proxy, not the real answer. A few honest checks get you closer to the truth than a number on an org chart ever will.
Start with institutional knowledge. If one person holds most of what there is to know about your systems, to the point that their vacation would create real risk rather than minor inconvenience, that's a structural gap, not a staffing preference. Look at PTO next, not the policy but the practice: whether anyone on your IT team has taken real time off recently, or whether it's quietly become theoretical because there's no coverage plan behind it. Check where your internal hire's calendar goes, because a calendar full of reactive firefighting is a calendar with no room left for the strategic work you hired them to do in the first place. And take stock of when anyone last revisited whether your current structure still fits, as opposed to just renewing what's already in place out of habit.
If those checks land uncomfortably close to home, that discomfort is the signal. The fix usually isn't a bigger internal team. It's redrawing the line between what you own and what you hand off.
Right-Sizing the Line Between What You Own and What You Hand Off
I keep coming back to how avoidable my SaaS founder's situation was. Nothing about her company's growth was unusual, and nothing about the decision to bring IT in-house was wrong in spirit. The miss was smaller and more common than that: nobody stopped to ask whether the relationship between internal ownership and outside support needed to change shape as the company did, and by the time the gaps showed up, they looked like a hiring problem instead of a structural one.
Avoiding the "binary" trap of believing that you must choose between fully managed services and an entirely internal team is the first step toward building a resilient IT strategy. Whether your company is best served by fully managed IT services, a co-managed IT model, or targeted staff augmentation, the right answer depends entirely on your current growth stage, compliance requirements, and risk tolerance.
The founders who avoid the "hiring trap" are the ones who make a habit of asking, every six months, whether the IT structure that made sense at their last stage still holds up. Your IT infrastructure should evolve alongside your team. Instead of waiting for burnout, a resignation, or an audit finding to expose gaps, take a proactive look at whether your support model is truly built for your long-term scalability.
If you aren't sure which model fits your current size, or if your existing setup no longer feels like a perfect match, that’s a conversation worth having before the gaps become emergencies. We’ve helped organizations navigate every transition: from moving into co-managed arrangements to balancing overbuilt internal teams. If you’d like a second opinion on where your IT line should be drawn, let’s talk.
About The Author
Evan JonesFounder and CEO of Jones IT
With over two decades of IT experience in San Francisco, Evan guides Jones IT's long-term strategy, finances, and culture, with a vision of building the city's highest-rated IT services firm. Outside of work, you'll find him on the golf course or running Bay Area Warriors, his non-profit connecting Bay Area kids to college through basketball.
Is your IT model right-sized? Discover when to switch between fully managed, co-managed, or staff augmentation based on your company's growth and actual risks.