If your practice just hired its first CTO or CIO, you’ve made a decision that will reshape how your organization thinks about technology for years. That’s the right move. But what happens next is almost never what either side expects.
In mid-market healthcare, the first dedicated technology executive might be called a CTO, a CIO, a VP of IT, or something else entirely. The title matters less than the mandate: to create a technology strategy, govern vendor relationships, align technology with clinical and operational goals, and bring more rigor to the security and data decisions than the practice has had before.
That role is still evolving in this space. In many organizations, this is a first-generation position. There’s no established playbook. The person you just hired is going to build it as they go, and the organization they’re walking into has been operating without one.
That’s not a problem statement. It’s a reality statement. Understanding it early makes everything that follows significantly easier for both the person in the new role and the leadership team that created it.
What your new CTO is walking into
Before the CTO arrived, someone else was making your technology decisions. In many mid-market healthcare practices, that person was the practice manager.
Not because the practice manager wanted to be in charge of technology. Because there was nobody else. They came from a revenue cycle or clinical background, had no formal technology training, and were handling IT by default alongside everything else on their plate. No dedicated budget. No strategic framework. Just keeping things running, putting out fires, and making the best decisions they could with limited information.
The result is a technology landscape that nobody designed. It was assembled over time through a combination of vendor recommendations, inherited infrastructure, urgent fixes, and whatever the previous IT support provider put in place. Some of it works well. Some of it was the best option available at the time. And some of it has problems nobody has had the expertise to identify.
That’s the landscape your new CTO inherits. They didn’t build it, they don’t fully understand it yet, and the organization is expecting them to fix it. The first thing to know is that this starting point is normal. It’s not a sign that something went terribly wrong. It’s what happens when a growing healthcare practice runs technology without a dedicated technology leader for ten or fifteen years.
The two instincts
Within the first 60 days, your new CTO is going to start forming opinions about what needs to change. Those opinions commonly follow one of two patterns, depending on where they came from before this role, and knowing what to expect makes the conversation much more productive.
If they came from an IT infrastructure background, from a managed service provider or an internal IT department, the first proposal that crosses your desk will likely be about bringing IT operations in-house. You’ll hear a case for replacing the current outside provider with an internal team, or with a vendor from the CTO’s previous network.
The reasoning will sound solid: they’ve done this before, they know what good IT support looks like, and they believe they can deliver it more efficiently. You may also notice existing vendor relationships being evaluated more critically than the situation warrants, not because the vendors are failing, but because they’re not the CTO’s vendors.
If they came from a software development background, the proposals will look different. You’ll hear about building a custom data warehouse, developing internal analytics capabilities, or creating proprietary integrations. The language will shift toward ownership: “We need to own our IP. We need to control our destiny.” Budget requests may start appearing for engineering hires.
Not every new technology leader falls neatly into one of these camps. But the underlying dynamic is remarkably consistent: people apply what worked in their previous environment to the new one. That’s not a character flaw. It’s how experienced professionals operate. The challenge is that mid-market healthcare is a specific context with specific constraints, and the playbook from the previous job doesn’t always transfer.
Why healthcare is different
The new CTO has probably worked in organizations with deeper management layers, larger budgets, and more established technology governance. What they’re walking into is different in ways that matter.
The management and execution layer in a mid-market healthcare practice is thin. Very thin. Fortune 500 companies with dedicated technology departments and extensive support infrastructure struggle with the same challenges your CTO is about to take on, and they have far more resources. A 50-provider practice group does not have the bench depth of a large enterprise, and the technology strategy needs to account for that.
Regulatory requirements constrain every decision. HIPAA compliance isn’t optional and it isn’t simple. Every technology choice, every vendor relationship, every data decision has compliance implications. A CTO who came from outside healthcare may underestimate how much of their time and budget will be consumed by security and compliance requirements that didn’t exist in their previous role.
The clinical team has a different relationship with technology than what the CTO is used to. Everyone calls everything “IT.” The EHR is the center of the universe. Clinical workflows are deeply embedded and resistant to change, not because people are resistant to improvement, but because changing how a provider documents patient care has direct consequences for patients. The technology decisions that seem simple from an infrastructure perspective turn out to be deeply entangled with clinical operations.
And the vendor landscape is complicated. The practice likely has existing relationships with an IT provider, an EHR vendor, possibly a billing platform, and various point solutions that have accumulated over time. Some of those relationships are contractual.
Some of them are working well. The CTO needs to assess what they’ve inherited before they start making changes, because replacing a vendor that’s actually performing well just because it’s not the vendor they would have chosen creates disruption without creating value.
What’s driving the first big proposals
Your new CTO is operating under a specific kind of pressure that’s worth understanding, because it explains a lot of the early decision-making.
On one side, there’s confidence. They’ve read the books, they’ve been in the industry, and they genuinely believe they can do this better, faster, and cheaper than the current setup. That confidence isn’t misplaced. They probably can improve things. The question is whether the approach matches the organization’s actual capacity.
On the other side, there’s skepticism. They’ve either personally experienced or heard from trusted peers about vendors who overpromised and underdelivered. The technology services industry, in healthcare and beyond, has a reputation for exactly this. So the new CTO walks in with a healthy distrust of outside partners, which reinforces the instinct to build internally.
The combination of “I can do it better myself” and “vendors are going to let me down” creates a strong pull toward insourcing. And it’s not irrational. But it’s worth recognizing as a pattern so it can be evaluated rather than just acted on.
What the practice manager is feeling
This part doesn’t get written about, but it matters for how the transition goes.
The person who was handling technology before the CTO arrived has been doing that job without the right tools, the right training, or the right budget. They know it. They’ve been waiting for help. In some cases, they advocated for this hire.
When the new CTO arrives and starts identifying problems with the technology landscape, the practice manager can hear that as criticism of the job they’ve been doing. That’s not usually the CTO’s intention, but the dynamic is real. The CTO sees gaps and wants to fix them. The practice manager sees someone cataloging their shortcomings.
The organizations that handle this transition well are the ones where the CTO treats the practice manager as a source of institutional knowledge rather than a problem to be solved. That person knows which systems the clinical staff actually depends on, which vendor relationships are working, where the real pain points are, and what’s been tried before. The CTO has the technical expertise. The practice manager has the operational context. The combination is more valuable than either one alone.
The signals to watch for
If you’re the CEO or practice administrator who made this hire, there are a few early signals worth paying attention to. Not because they indicate failure, but because they indicate the transition is following a common pattern that benefits from early course correction.
The first is speed. If your new CTO is proposing major vendor changes or significant insourcing moves in the first 30 to 60 days, that’s fast. Not necessarily wrong, but fast. The technology landscape they inherited took years to build.
Understanding it well enough to make informed changes takes more than a few weeks. The leaders who get this right tend to spend the first month or two listening, assessing, and building relationships before they start restructuring.
The second is scope. “We need to own our IP” or “we need to bring everything in-house” are signals that the scope of change being proposed is very broad. Broad change requires deep organizational capacity to execute. At this scale, a more targeted approach, addressing the most critical gaps first and building from there, tends to produce better outcomes than a wholesale transformation.
The third is the relationship with existing vendors. If the first move is to replace every outside partner, that’s worth examining. Some of those vendors may genuinely need to be replaced. Others may be performing well and providing value that the organization will miss once it’s gone. An assessment of what’s working and what isn’t should come before any transition plan.
And the fourth is the AI conversation. Your CTO will face pressure from the leadership team to “do something about AI.” Everyone is hearing about it. Everyone wants to know what the practice’s AI strategy is. The right answer in the first 90 days is almost never to buy an AI tool.
It’s to assess the data foundation, the security posture, and the technology infrastructure that any AI strategy would need to sit on top of. AI readiness starts with the foundation, not the tools.
What leadership owes this role
The article so far has focused on what to expect from the CTO. But this transition has two sides, and the organization’s leadership has responsibilities too.
The most common version of this story that doesn’t work: a practice hires a CTO, expects transformation, and then constrains the role’s ability to actually execute. Budget is limited. Decision authority is unclear. The CTO reports to someone who doesn’t understand technology. And there’s an implicit expectation that hiring the person was the hard part, and now things should just get better.
If you hired this role, you owe it a clear mandate, a realistic budget, defined decision authority, and patience. The first year is not going to produce a fully transformed technology operation. It’s going to produce an honest assessment, a prioritized roadmap, and the early execution of the highest-impact changes. That’s what success looks like in year one. If your expectations are set higher than that, the disconnect is going to create friction that has nothing to do with the CTO’s competence.
What the ones who get it right do differently
The new CTOs who succeed in mid-market healthcare tend to share a few characteristics, and they’re not the ones you might expect.
They listen before they build. They spend their first weeks understanding the existing landscape: what works, what doesn’t, who the stakeholders are, what’s been tried before, and what the real constraints are. They resist the instinct to start making changes before they understand what they’re changing.
They respect the context. They recognize that mid-market healthcare operates differently from their previous environment. The budget is smaller. The management layer is thinner. The regulatory requirements are heavier. The clinical staff’s relationship with technology is more complex. Strategies that worked at the previous company need to be adapted, not transplanted.
They evaluate function by function. Instead of making one big decision about insourcing or outsourcing, they assess each technology function on its own merits. What does the organization have the scale and expertise to handle internally? What’s better served by a specialized partner? The answers are usually different for helpdesk support, security, data infrastructure, and software development.
They build relationships internally. The practice manager, the clinical leadership, the office staff who use the systems every day. These people have context the CTO doesn’t, and the CTO’s success depends on earning their trust. Technology strategy that’s designed in isolation from the people who live with it every day rarely survives contact with reality.
And they plan for sustainability, not just improvement. The question isn’t just “can we build this?” It’s “can we sustain this with the team, budget, and management capacity we actually have, not just in year one but in year three?”
A note for the CTO reading this
If you’re the person who just stepped into this role, here’s what the people who’ve watched this transition play out dozens of times would want you to know.
The organization hired you because they need what you bring. Your expertise is real and it’s valuable. The instincts you have about what needs to change are probably directionally correct. The adjustment is in how fast you move, how broadly you scope the changes, and how well you account for the specific constraints of mid-market healthcare.
The practice manager who was handling things before you arrived isn’t the problem. They’re an asset. They know things about the organization that you won’t learn for months, and their cooperation will make or break your first year.
The vendor landscape you inherited isn’t all bad. Some of it is. Some of it is working better than it looks from the outside. Take the time to assess before you replace.
And the leadership team that hired you has expectations that may not be fully realistic. Part of your job in the first 90 days is to help them understand what’s achievable given the organization’s actual size, budget, and readiness. That’s not underpromising. It’s setting the foundation for a technology strategy that can actually be executed.
Frequently asked questions
What should a practice expect in the first 90 days of a new CTO?
The most productive first 90 days focus on assessment rather than transformation. The CTO should be learning the existing technology landscape, understanding vendor relationships, identifying compliance gaps, building relationships with clinical and administrative staff, and developing a realistic picture of the organization’s capacity. Major changes made before this assessment is complete are more likely to create problems than solve them.
Why do new healthcare CTOs often want to insource IT?
Because they’re applying what worked in their previous role. A CTO who came from an IT operations background knows how to run an internal helpdesk and infrastructure team, so that’s what they propose. A CTO from a software development background knows how to build custom solutions, so that’s where they focus. Both instincts are rational, but they don’t always match what a mid-market healthcare organization has the scale and management capacity to sustain.
How should a practice evaluate whether their new CTO’s strategy is the right one?
Look at three things: speed, scope, and sustainability. Is the proposed timeline realistic given the complexity of the existing environment? Is the scope of change matched to the organization’s capacity to execute? And is the strategy designed to be sustainable in year three, not just achievable in year one? A good technology strategy at this scale is sequenced, realistic about constraints, and built to last.
What’s the most common mistake practices make after hiring a CTO?
Expecting transformation without providing the resources to execute it. The CTO can develop the strategy, but executing it requires budget, management capacity, organizational buy-in, and time. Practices that hire a CTO and then constrain their ability to make changes end up with a frustrated leader and an unchanged technology landscape.
What is the role of a CIO in healthcare?
In mid-market healthcare, the CIO (or CTO, or VP of IT) is the first person responsible for creating an actual technology strategy. Before this role existed, technology decisions were made by practice managers, office administrators, or whoever happened to be closest to the problem. The CIO’s mandate typically includes vendor governance, security and compliance oversight, data infrastructure decisions, and aligning technology with clinical and operational goals. In many organizations, this is a first-generation role, meaning the person in the seat is defining it at the same time they’re executing it.
What should a new healthcare CTO prioritize first?
Assessment, not action. The technology landscape they’re inheriting was built over years by people without technology backgrounds, and it takes time to understand what’s working, what’s failing, and what the real constraints are.
The most effective first move is to build relationships with stakeholders, audit the vendor and compliance landscape, understand the budget reality, and develop a sequenced roadmap that the organization can actually execute. The instinct to start making changes immediately is understandable, but changes made before the assessment is complete tend to create more problems than they solve.
If you’ve recently hired a CTO and want to talk through how the technology landscape typically evolves at this stage, that’s a conversation we have often.