For many small and midsize businesses, the technology model starts relatively simply. The company works with a managed IT provider that supplies the helpdesk, engineers, cybersecurity expertise, cloud support, monitoring, projects, documentation, and strategic guidance that would be difficult to assemble internally.

Then the business grows.

There are more employees, more applications, more departments and usually more dependence on technology. Perhaps leadership wants someone onsite more frequently. Perhaps technology has become important enough that someone needs to spend considerably more time understanding operations, working with department heads, evaluating AI and automation opportunities, and thinking about where the business is going.

At that point, a question inevitably comes up:

Should we hire someone internally?

It's a reasonable question, but I think it's usually asked too broadly. "Internal IT" can mean very different things. Hiring someone to provide onsite desktop support solves a completely different problem from adding someone whose job is to understand the business and help determine technology priorities.

Before adding people to the organizational chart, leadership should first decide what capability is actually missing.

For most growing businesses, there are two very different possibilities: the company needs more hands, or it needs more technology leadership.

Those should not be confused.

Start With the Reason You Want Someone Internal

Suppose a 75-person company already has an MSP handling its technology, but employees would like more onsite support.

Maybe there is specialized equipment. Perhaps executives prefer having someone they can walk over to when they have a problem. Conference rooms generate enough issues that remote assistance is frustrating. Or perhaps the company simply wants a more personal, white-glove support experience and is willing to pay for it.

There is nothing wrong with that.

The question then becomes how to provide it.

One option is hiring a desktop support person directly. The other is having the MSP provide someone onsite for an agreed number of hours or days.

The internal employee will often look less expensive. A salary is easy to compare with an hourly or monthly service charge, and the arithmetic can make the employee appear to be the obvious choice.

But those aren't equivalent arrangements.

When you hire the employee, you're not only buying their time. You're accepting responsibility for everything surrounding that person.

They take vacations. They get sick. They need training. Eventually they may leave. They will be very good at some technologies and less experienced with others. When they encounter something outside their expertise, someone needs to decide where it goes next.

More importantly, the company has now divided responsibility for its technology between two organizations.

That creates a question that deserves much more attention than it usually receives:

Who is ultimately responsible?

Responsibility and Control Have to Stay Together

Imagine that an employee reports a recurring application problem.

Internal IT works on it and believes the network may be responsible. The MSP checks the network and finds nothing unusual. The application vendor thinks the workstation configuration is the problem. Internal IT disagrees.

Who owns getting the problem resolved?

Or imagine that the internal employee makes a configuration change that later contributes to an outage. Is the MSP responsible for preventing it? Can it be, if it didn't make or approve the change?

This is where seemingly reasonable co-managed arrangements can become difficult.

A business may tell its MSP, "You're responsible for our IT," while simultaneously giving an internal employee independent responsibility for part of the environment.

Those two ideas conflict.

An outside provider cannot completely control what an employee of another company does. It doesn't conduct that person's performance reviews. It cannot determine how that employee spends every hour. It may not know about every change they make or every conversation they have with another vendor.

Yet when something goes wrong, leadership usually doesn't want a debate over whose side of the line caused the problem.

They want someone to own it.

That is why accountability should be considered when comparing an internal support employee with an onsite resource supplied by the MSP.

The MSP-provided resource may cost more on paper, but the provider can remain responsible for the entire support process. It can determine how issues are escalated, require documentation, provide backup coverage, bring in specialists, manage the individual's performance, and replace that person when necessary.

The company is buying more than labor.

It is buying accountability.

That distinction is easy to miss when the comparison is reduced to salary versus monthly fee.

One Front Door Makes Support Much Simpler

There is another practical reason to avoid unnecessarily complicated divisions of responsibility.

Employees shouldn't have to understand the IT organizational chart before asking for help.

A user knows that an application is slow. They usually don't know whether the cause is their computer, Wi-Fi, internet connection, authentication, Microsoft 365, a server, the application vendor, or something else entirely.

And they shouldn't have to figure it out.

The easiest support model gives employees one place to report technology problems.

From there, the technology team determines what happens next. A straightforward issue may be resolved immediately by the helpdesk. Another may go to the onsite resource. A network issue can be escalated to a network engineer. A Microsoft problem may need a cloud specialist. An application problem may require coordination with the software vendor.

The employee doesn't manage any of that.

They reported a business problem. The technology organization owns getting it to the right people and following it through to resolution.

This sounds like a small operational detail, but it becomes increasingly important as companies grow. Without a clear front door, employees begin deciding for themselves whom to contact. They email the internal IT person, call the MSP, contact software vendors directly, or ask whichever technician helped them last time.

Information becomes fragmented, documentation suffers, and accountability becomes increasingly difficult.

A well-designed technology organization should make support simpler for employees, not expose them to the complexity behind it.

The More Important Internal Role May Not Be Technical Support

There is another reason I would be cautious about automatically making desktop support the first internal IT hire.

For many growing businesses, the bigger gap isn't technical execution.

It's the connection between technology and the business.

An MSP can provide engineers, security specialists, cloud expertise, helpdesk support, monitoring, project resources, and many of the other technical capabilities the company needs. What an outside provider needs from the client is someone who understands where the business is going and is willing to work closely enough with the technology team to translate those goals into priorities.

In a smaller company, that person doesn't need to have a technology title at all.

It may be the owner, COO, CFO, operations leader, or another executive. What matters is that someone understands the company's operations, knows what leadership is trying to accomplish, and participates in regular technology planning.

That partnership can accomplish quite a lot.

Regular Technology Business Reviews become particularly important because they create a structured opportunity to discuss what is changing in the business rather than simply what is changing in IT. Perhaps a new location is planned. A department is hiring rapidly. A client has introduced new security requirements. The company wants better reporting. Employees are experimenting with AI. A manual process is becoming a bottleneck.

Those are business conversations first and technology conversations second.

The MSP brings technical knowledge and experience from working across many environments. The person inside the company brings knowledge of the business.

For many smaller organizations, that combination may be all that is necessary.

As the Business Grows, Technology Leadership Can Become a Job

Eventually, however, technology may become important enough that managing the relationship can no longer be one of ten responsibilities assigned to the COO or another executive.

That doesn't necessarily mean the company needs another engineer.

It may mean the company needs a technology leader.

The title isn't particularly important. Some organizations may call the person a CTO, Director of Technology, IT Director, or something else. What matters is the function.

This person should understand the business before worrying about the technology.

They should understand operations, how the company makes money, which processes cause friction, what clients are asking for, where the organization is growing, and what leadership is trying to accomplish. They should be able to work with department heads and identify where technology can improve efficiency, reporting, security, customer experience, or competitive advantage.

They don't need to personally troubleshoot every network problem.

In fact, if the company already has access to a strong technical team through its MSP, spending this person's time troubleshooting laptops may be a poor use of an expensive resource.

Their value comes from connecting the business to the technology team.

For some organizations, this need can initially be filled by a fractional technology leader. As the business becomes larger or more complex, it may eventually justify a full-time position.

The progression is not based on hitting a particular employee count. A 40-person company with complicated manufacturing operations, demanding compliance requirements, and aggressive automation plans may need more technology leadership than a 100-person company operating primarily in standardized cloud applications.

Complexity matters more than headcount.

A Technology Leader Doesn't Necessarily Need a Technology Empire

There is another organizational tendency business owners should understand.

Internal departments naturally tend to grow.

This isn't an accusation against IT, and it isn't unique to technology. It happens throughout organizations.

A department encounters a problem, so adding a person seems reasonable. Another responsibility appears, so the department adds a tool. A new specialty becomes important, and bringing that capability in-house feels like the logical next step.

Each decision may make complete sense on its own.

Five years later, however, the organization may have built a substantial internal department without ever stopping to ask whether every capability actually needed to be internal.

This is where leadership needs to separate the size of the department from the value of the department.

A technology leader should not need a large internal team to demonstrate importance.

In fact, one sign of an effective leader may be the ability to maintain a relatively lean internal organization while drawing on outside specialists when the business needs them.

If cybersecurity expertise is needed but not for 160 hours every month, there may be little reason to employ a full-time security specialist. The same may be true of network architecture, cloud engineering, business continuity, Microsoft expertise, or other disciplines.

The question should always come back to the business:

Is bringing this capability inside the company the most effective way to obtain it?

Sometimes the answer will absolutely be yes.

But it should be a deliberate decision rather than the natural result of an internal department gradually expanding its boundaries.

Onsite Support Can Still Be the Right Choice

None of this means onsite support is unnecessary.

There are environments where physical presence creates real value.

Manufacturing is an obvious example. Technology may touch production equipment, warehouse devices, scanners, specialized workstations, engineering systems, conference rooms, and other equipment that is difficult to support entirely from a distance.

There are also organizations where service expectations justify it. Executives may want highly personal assistance. Employees may work better knowing that someone is physically available. The company may simply decide that the experience is worth paying for.

That's a business choice.

The important distinction is that onsite support and internal IT are not the same decision.

A company can have an onsite person supplied by its MSP while keeping responsibility for technology with one provider. The onsite resource becomes part of a larger team rather than an independent IT department.

If that person is on vacation, someone else covers. If the problem requires deeper expertise, it gets escalated. If the individual leaves, replacing them is the provider's responsibility. The documentation, tools, procedures, and support system remain in place.

That may cost more than the salary of an employee when viewed narrowly.

But the comparison should include what happens when the employee isn't available, doesn't know the answer, leaves the company, or becomes involved in a problem that crosses the boundary between internal and external responsibility.

Price matters. So does continuity—and so does knowing who is responsible when something goes wrong.

Co-Managed IT Requires More Than Dividing a List

For larger organizations that already have internal technology employees, co-managed IT can work extremely well.

But it has to be designed.

Simply saying "internal IT handles users and the MSP handles infrastructure" sounds clean until a user problem turns out to be an infrastructure problem.

"Internal IT manages Microsoft 365 and the MSP handles security" sounds reasonable until a Microsoft configuration becomes a security issue.

Technology doesn't respect organizational boundaries particularly well.

That is why a co-managed arrangement needs more than a list of responsibilities. It needs agreed processes for escalation, change management, documentation, communication, and ultimately accountability.

Someone has to own the whole picture.

That may be the internal technology leader. It may be the MSP under a clearly defined arrangement. In some organizations, accountability may deliberately be divided—but if it is, leadership should understand exactly where those boundaries are.

The dangerous model is the accidental one, where everyone assumes somebody else is responsible until something important gets missed.

Don't Confuse a Lower Hourly Cost With a Lower IT Cost

The financial comparison deserves the same level of scrutiny.

An internal employee will often appear less expensive if the calculation is simply salary divided by hours worked.

But businesses don't actually buy IT by the hour.

They buy outcomes.

An employee has payroll taxes, benefits, recruiting costs, training, management time, vacation, sick leave, and turnover. Those costs are real, but even they don't capture the biggest difference.

The employee represents one person's experience and one person's capacity. That is one reason growing businesses compare Managed IT Services vs. internal IT before deciding how to structure their technology team.

A team provides different kinds of expertise and the ability to shift resources depending on what happens.

Think back to the kind of week a modern technology organization can encounter: a Wi-Fi redesign, a Microsoft tenant access problem, a business application deployment, an AI implementation discussion, a datacenter connectivity issue, newly discovered security vulnerabilities, and an e-commerce website failing on Sunday.

No individual needs to be bad at their job for that model to struggle.

It is simply an enormous range of work for one person.

The relevant financial question therefore isn't:

"What does this person cost per hour?"

It is:

What structure gives the business the capabilities, responsiveness, continuity, and accountability it needs at a reasonable total cost?

Those are very different calculations.

The Best Structure Changes as the Business Changes

For a smaller organization, the model can be quite simple.

A business leader works closely with the MSP. Employees have one place to request support. The provider supplies the technical team and accepts responsibility for the environment. Regular business reviews connect technology decisions to company priorities.

As the organization becomes more complex, it may benefit from fractional technology leadership—someone spending more time understanding operations, coordinating initiatives, and translating business needs into technology priorities.

Eventually, the organization may justify a dedicated technology leader. That person can become the bridge between leadership, operations, clients, departments, and the outside technical team.

If the company needs substantial onsite support, it can add that too.

And if the organization becomes large enough that certain technical capabilities genuinely make more sense internally, it can selectively build those capabilities.

The important thing is that growth should be intentional.

The goal isn't to eventually replace the MSP with an internal department, nor is it to outsource everything forever. The goal is to preserve the advantages of a broad technical team while adding internal capabilities only where being inside the organization creates enough additional value to justify them.

The Real Question Is Who Owns the Outcome

Technology organizations can become complicated very quickly.

There can be internal employees, an MSP, cybersecurity vendors, software companies, internet providers, cloud platforms, application consultants, and equipment manufacturers involved in keeping a modern business operating.

Leadership shouldn't have to coordinate all of them.

Employees certainly shouldn't.

A good technology structure hides that complexity from the business.

Employees have one place to ask for help. Leadership has someone who understands business priorities. Technical problems reach the appropriate specialists. Vendors are coordinated. Documentation is maintained. Strategic decisions are reviewed regularly.

And when something goes wrong, there is no meeting to determine who should have been responsible.

Someone already is.

A growing business needs access to expertise and coverage, people who understand its operations and direction, and a structure that makes clear who owns the outcome when something goes wrong.

Because having five people who can potentially solve a problem is not the same as having one organization responsible for making sure it gets solved.