How to Avoid Hiring the Wrong IT Person
This is the second installment in a three-part blog series on hiring an internal IT employee.

How to Avoid Hiring the Wrong IT Person
In the first post in this series, we talked about a pattern we see often. A company hires an internal IT person, that person proves their value primarily through cost cutting, and years later the business discovers the "savings" were actually a slow trade of stability for stagnation. If you read that post and recognized pieces of your own environment in it, the natural next question is: how do we avoid this the next time we hire?
The honest answer is that most of the warning signs are visible well before you sign an offer letter. You just have to know where to look, because the signs rarely show up as obvious red flags. They show up as subtle patterns in how a candidate thinks and talks about their work.
Listen to How They Define Success
Ask a candidate a simple question during the interview. "Tell me about a project you're proud of." Then listen closely to what they highlight.
Some candidates will describe a project in terms of what they built, what capability it unlocked, or how it positioned the business for growth. Others will describe it almost entirely in terms of what it cost, or more specifically, what it didn't cost. "I found a way to do this for a fraction of what the vendor quoted." "I avoided renewing that contract and nobody noticed a difference."
Neither answer is automatically disqualifying on its own. But if every single example a candidate offers is framed around avoiding spend rather than building capability, that's information. It tells you how this person will instinctively make decisions once nobody is checking their work day to day, which for most internal IT hires is most of the time.
Ask About The Things They Didn't Do
One of the most revealing interview questions you can ask an IT candidate isn't about a project they completed. It's about a project they chose not to pursue, and why.
If they describe holding off on a system upgrade because the timing genuinely didn't make sense for the business, that's a sign of judgment. If every "we didn't do that" answer traces back to cost, and none of them trace back to timing, risk, or business priorities, you're looking at someone whose default lens is spend reduction rather than business outcomes. Good technology leadership sometimes means spending money, and you want to hear evidence that the candidate understands that.
Check Whether They Can Explain Things in Your Language
Here's a test that has nothing to do with technical skill and everything to do with whether you'll actually be able to manage this person after you hire them. Ask the candidate to explain a technical concept, maybe how backups work, or what a firewall actually does, as if they were explaining it to a board member with no technical background.
Pay attention to whether they can do it. Not whether they dumb it down or talk over your head, but whether they can translate technical reality into business terms you can act on. This matters enormously, because most leadership teams don't have the technical background to evaluate an internal IT hire's decisions on their own. If the person you hire can't or won't translate their work into terms you understand, you are handing them a blank check, and you won't know it until something goes wrong.
Look At Their Curiosity, Not Just Their Resume
Technology changes constantly, and the person you hire today will need to keep learning for as long as they're in the role. During the interview, ask what they've learned recently that has nothing to do with a specific work project. Ask what they read, what communities they're part of, what they're currently curious about in the industry.
A candidate who lights up talking about something they explored just because it interested them is showing you evidence of a growth mindset. A candidate who struggles to name anything beyond what their current job required them to learn is showing you the opposite. That gap tends to widen over time, not shrink, and it's one of the clearest predictors of whether your environment will still feel current five years from now or whether it will have quietly calcified.
Try this question directly. "Walk me through how you'd decide whether to keep an aging piece of infrastructure running or replace it." Listen for whether cost is the only variable they mention, or whether they also bring up things like vendor support timelines, security exposure, redundancy, and what happens if that piece fails during business hours.
A candidate who can hold both cost and risk in their head at the same time, and who can articulate the tradeoff clearly, is far more likely to make sound decisions once they're inside your environment making calls you may not see for years.
The goal here isn't to find someone who never thinks about budget. Cost awareness is a legitimate and valuable trait. The goal is to find someone who treats cost as one input among several, alongside risk, growth, and business need, rather than treating cost reduction as the entire job description they've assigned themselves.
The best internal IT hires we've seen over the years share a common trait. They think like a business partner first and a technician second. They ask what the company is trying to become, not just what it needs to keep running today. And critically, they're comfortable telling leadership "this is going to cost more than you want it to, and here's why it matters," even when that's not the easy answer to give.
Where This Leaves You
Hiring well is the best defense against the pattern we described in the first post. But even a great hire is still one person, with one set of experiences, one perspective on technology, and a finite number of hours in the day. In the next and final post in this series, we're going to look at a question most business owners never quite ask themselves clearly enough. What happens when your entire technology strategy depends on the judgment, availability, and knowledge ceiling of a single individual, no matter how good that individual is?
WE ARE PROUD TO BE






