The Questions That Stopped an IT Hiring Decision in Its Tracks

We were an hour into what should have been a straightforward conversation about hiring an IT Manager when the room went quiet.

We had not asked about salary expectations. We had not asked about certifications, years of experience, or whether the ideal candidate needed to know a particular ticketing system. We had asked one simple question: “Where is your infrastructure documented?”

No one answered right away. A few people glanced at each other. Someone finally said, “That would mostly be with our MSP.”

That single answer changed the entire direction of the search.

Picking Up Where Part 1 Left Off

In Part 1, a growing Winnipeg organization had reached its breaking point with its MSP and decided the answer was to hire an IT Manager. When we looked closer, we found years of undocumented infrastructure, scattered vendor ownership, and no clear picture of what the role would actually be responsible for. We left off with three questions every executive should answer before recruiting: support or strategy, is your infrastructure documented, and what does success look like in twelve months. That is where this conversation picks up.

The Discovery Meeting

Most hiring conversations start with a job description. This one started with a whiteboard and a list of questions that had almost nothing to do with qualifications:

What are the systems you need to operate your business?
What is the location of infrastructure documentation, and who is responsible for it?
Who is responsible for your backups and has anyone ever restored them for a complete test recently?
Who is currently in control of admin access to your systems?
Are there written policies for cybersecurity and where are they stored?
Who is responsible for the continual upkeep of your line of business applications?
Where are your source code repositories or configuration files stored, if you have anything developed in-house?
If your MSP ended the relationship tomorrow, what would you lose access to?
Which of these responsibilities do you expect a new IT Manager to take over on day one?

These are not trick questions. They are the questions any competent IT Manager would ask in their first week on the job. We simply asked them two months earlier than they otherwise would have been asked, before an offer letter was signed rather than after.

The answers, or the lack of them, told us everything we needed to know.

Nobody in the room could fully describe how the cloud environment’s ownership was structured. A password vault existed, but only one person, on the call from the MSP’s office rather than the client’s, had complete access to it. Backup schedules existed on paper, but no one could recall the last time a full restore had actually been tested. Cybersecurity policy was, in practice, whatever the MSP had configured several years earlier and never revisited since.

This was not a reflection of a poorly run company. It was a company that had done exactly what a growing business is supposed to do: outsource a specialized function to people who understood it better than they did and put internal energy toward running the business. The problem was that, somewhere along the way, outsourcing had quietly become an information gap.

What Executives Assumed vs. What Was Actually True

Going into the meeting, the executive team’s mental model was simple: hire an experienced IT Manager, hand them the keys, and watch the technology problems start resolving themselves within a few months.

The operational reality was considerably more complicated:

Infrastructure existed, but was not documented anywhere the client actually controlled.
Vendor responsibilities had never been clearly divided between the MSP and any future internal hire.
Processes for provisioning, offboarding, and access control were inconsistent from one department to the next.
Nobody internally could produce a full inventory of the software the business depended on.
Some responsibilities, patching, monitoring, and backup verification among them, appeared to belong to no one at all.

Here is the uncomfortable truth we had to share with the executive team: no candidate, regardless of how many years of experience they brought or how strong their references were, could walk into that environment and succeed quickly. Not because the role was too senior or too junior, but because the organization had not yet defined what the role actually needed to control.

The Real Cost of Getting This Wrong

When a company hires into an undefined environment, the consequences rarely show up immediately. They show up three, six, or nine months later, and by then they are far more expensive to fix.

We see the same handful of outcomes repeat themselves:

Mismatched expectations. The new hire mistakenly assumed that they were running a well-defined environment. The company took the position that they believe that the new employee will "figure it out. They both feel let down and disillusioned in the first quarter.
Wasted recruitment investment. A search that should have taken eight to ten weeks stretches into a second attempt when the first hire leaves, frustrated, inside a year.
Frustrated employees. Talented technical professionals do not enjoy spending their first months rebuilding documentation that should have existed before they arrived. Many start looking elsewhere.
Infrastructure risk. A lack of backup verification, access control and security policy doesn't fix itself when a new title is added to the org chart.
Continued dependence on external providers. Ironically, the company that hired internally to reduce vendor dependence often ends up leaning on that same vendor even more heavily, because only the vendor still holds the missing knowledge.

None of these outcomes stem from a bad hiring decision in the traditional sense. They stem from a hiring decision made before the organization understood what it was actually hiring for.

Why This Happens More Often Than You Would Think

This scenario is not unusual. In our experience working with growing organizations, it is closer to the norm than the exception.

Here is the pattern we see repeatedly. A company brings on an MSP early, often when it has five, ten, or twenty employees and no internal technical staff at all. The relationship works well. The MSP handles helpdesk tickets, manages a few servers, and keeps the lights on without much friction.

The company is expanding and so is its technology footprint. New software solutions are being rolled out departmentally, and this is typically done without a central management approach. Cloud services multiply. Working remotely creates additional endpoints and additional security concerns. But, throughout all of this, the MSP is the only constant source of technical knowledge as no one inside has the bandwidth or the mandate to build it in parallel.

Eventually, the business reaches a size where full internal IT leadership makes sense. But by then, years of institutional technical knowledge live almost entirely outside the organization, sitting with a vendor rather than an employee.

Why Recruitment Has to Start With Discovery, Not Job Descriptions

A job posting can describe what a company wants. It cannot tell you whether the company is actually ready to support the person who takes that job.

Before we help a client fill a technical leadership role, we ask a different set of questions than most recruiters do:

What problem are we actually trying to solve by making this hire?
Is the role clearly enough defined that a strong candidate could describe their first ninety days back to us in the interview?
Does the organization have the information this person will need to succeed, or will they spend their first six months rebuilding basic documentation from scratch?
Are our expectations for year one realistic given the current state of the environment?

These questions should be asked before writing a Job Description to keep everyone protected. It safeguards the employer from taking on a mandate that he or she cannot handle. It shields the candidate from being placed in a job that was designed to let him or her down from the get-go. It helps preserve the bond between the two since you aren’t assuming, but rather basing your expectations on the facts.

Questions Every Business Should Ask Before Hiring Its First IT Leader

If you are considering your first dedicated IT hire, or planning a move away from a managed service provider, work through these questions before the role ever gets posted:

Do we know every system our business depends on? If the honest answer requires a phone call to your MSP, that is worth noting.
Is our infrastructure documented somewhere we control? Documentation held only by a vendor is not documentation your company owns.
Do we control our own administrative accounts? If your MSP can lock you out of your own systems, your new hire will eventually face the same problem.
Are vendor responsibilities clearly defined? Ambiguity here creates finger-pointing later, usually during an outage, when it matters most.
Is cybersecurity policy written down and current? “The MSP handles that” is a comfort, not a policy.
Can someone internally explain your technology environment in plain language? If not, your new hire will be starting from zero on their first day.
What outcomes do we expect this person to deliver in year one? If the answer is vague, the job description will be too, and so will the results.
Are we hiring to close a skills gap or a documentation gap? These require very different solutions and confusing them leads to frustrated hires and repeated searches.

None of these questions require a technical background to answer. They require someone to actually go looking for the answers, which is precisely the step many organizations skip in the rush to fill a role.

Key Takeaways

How should tech talent be hired? Instead of starting with job postings, start with organization discovery.
Inadequate documentation, ambiguous ownership, or confusing vendor responsibilities cannot be compensated for by a decent job title.
Understanding your own infrastructure, even at a high level, is a prerequisite for hiring someone to manage it well.
Good recruitment reduces business risk. It is not only about filling a seat quickly.
The candidates who succeed fastest are the ones who walk into clearly defined roles with realistic expectations from day one.

Before You Post Your Next IT Job

Do you know, in specific terms, the technology environment you would be asking someone to manage? Could you describe your infrastructure, your vendor relationships, and your security posture to a stranger in ten minutes?

If the honest answer is “not really,” that is not a hiring problem. It is a discovery problem, and it is worth solving before a job description ever goes live.

If you are weighing your first internal IT hire, or planning a transition away from a managed service provider, Lambert Nemec would welcome an objective conversation about where your organization actually stands, not just about the role you think you need to fill.

Unlocking Canada’s Top Sales Talent Why Indeed Postings Fall Short and Recruiters Like Lambert Nemec Group Deliver Results

April 17, 2026