Your Next Hire Is Clarity, Not Headcount

Projects are stacking up faster than your team can deliver. Security work is getting riskier. QBRs are still reactive. Escalations keep landing on the same two people.

Welcome to managing an MSP!

Then someone says, “We need to hire a senior for this.”

It feels decisive. It feels responsible. It feels like you are protecting the business.

The next week is predictable.

A job description appears with a clean list of requirements. You debate whether the role should be an engineer, an architect, or a lead. A recruiter gets pulled in. Comp gets debated. Everyone feels momentum.

At the same time, inside your MSP, all of this is happening:

• A mid-level engineer is already doing a big portion of the work when things break.

• Someone has been asking for more responsibility in that exact area.

• Another person has been building scripts, documentation, and workflows that the new role is supposed to own.

None of that shows up in the headcount discussion.

You passed “post the job” before you asked “who do we already have?”

You think you need a headcount. Most of the time, you need a clearer picture of the work and who is already closest to it.

Most MSPs are not understaffed. They are “under structured.” Leaders hire before they understand the work, the gaps, and the bench they already pay for.

Fix clarity first, and hiring becomes a decision rather than a reflex.

Why headcount becomes the default move

External hiring feels clean. The job description is tidy. It has bullet points. It feels like control because you can point at it and say, “This is what we need.”

You can hand it to a recruiter. You can compare candidates. You can feel progress.

Internal reality is harder.

Titles do not match how work actually flows. The best capabilities are rarely documented because they surface in incidents, escalations, and messy client situations. So leaders do what leaders always do when the picture is unclear.

They pick the option that looks most defined.

External candidates also show up with labels.

Senior security engineer. Cloud architect. TAM with ten years. Project manager with MSP experience.

Those labels feel like risk reduction. You can put them on the org chart and tell yourself, “This area is covered now.”

Internally, you see “engineer” and “tech” and “analyst.” You do not see “future security lead” printed anywhere, so you assume you do not have one.

Here is the real issue.

Most MSPs hire externally first because internal capability is not visible in a way that leadership trusts. This results in opinions, not facts, driving critical decisions, and leaders default to the market because it seems easier to evaluate.

External becomes the default not because it is right, but because internal is too unclear to bet execution on.

If you cannot define the work, you cannot define the role

This is where most hiring goes wrong. Not at recruiting. Earlier.

Leaders jump straight to “who do we need” without forcing the hard part first.

What is the work?

• What is failing?

• What outcome is missing? 

• What responsibility is unowned? 

• What is recurring and constant versus one-time and noisy?

If you cannot describe the work cleanly, you cannot hire for it cleanly.

You end up hiring for a feeling.

Then you are surprised when it doesn’t work.

A few examples:

• Security pressure rises. Leadership says, “We need a senior security person.” But the work is really a mix of risk management, tooling, client expectations, documentation, internal standards, incident response, vendor and compliance demands, and accountability for decisions. Those responsibilities are scattered across the org, and nobody owns the whole thing.

• Projects slip. Leadership says, “We need a project lead.” But the work is really intake, scoping, scheduling, client readiness, internal handoffs, resourcing, and stopping engineers from getting dragged back into tickets mid-project. Hiring a project lead does not fix broken intake or unclear ownership.

• QBRs are reactive. Leadership says, “We need a better vCIO function” or “we need a TAM.” But the work is discipline, reporting, account ownership, and the willingness to have real conversations. You can hire a TAM and still run reactive QBRs if you never define what strategic looks like in your MSP.

• Escalations are a bottleneck. Leadership says, “We need more senior engineers.” But the work is documentation, repeatable troubleshooting paths, and a structure that spreads complex work and teaches it, not hoarding it by the same two people.

If you cannot define the work, you cannot define the role. If you cannot define the role, you will hire the wrong person and blame the market.

Internal capability is almost always underestimated

Walk your floor. Sit in on escalations. Read through the tickets that actually hurt. Listen to client calls when things are tense.

You will see internal capability that never makes it into leadership conversations.

It shows up in predictable ways.

• Mid-level engineers are quietly doing senior-level work. They are the ones who get pulled in when a client is on fire. They carry key environments in their head. They solve the hard parts of incidents and then disappear back into their title. They keep projects moving when someone senior is overloaded. They are already making decisions that you think only a senior can make. On paper, they are “System Engineer” or “Level 2.” In reality, they are halfway into the next role.

• Service desk techs acting like specialists. They write scripts that everyone quietly uses. They build their own runbooks because the official docs are behind. They coach new hires through tricky issues. They know patterns other people miss. Their title says “Service Desk.” Their behavior says “future automation specialist” or “platform engineer.”

• Emerging leaders without the title. In incidents, they start organizing the room. They assign tasks. They keep the story straight. In client conversations, they translate technical detail into language that lands. People go to them with questions, even when they do not “own” that area. The capability is there. It is just not captured in a shared way.

Leaders miss this for reasons that are boring and consistent:

• There is no current view of skills by person.

• There is no clear pattern for who handles complex work well.

• There is no shared place where managers can compare notes and keep them up to date.

• Performance reviews lag reality and are written in generic language that does not help with staffing decisions.

And then this one - the big one:

Managers rely on habit, not visibility. “I know who is safe. I send it to them.”

When the same names get the hard work every time, it creates a loop. The loop hides who is ready next, it overloads your best people, and it convinces leadership that the bench is weaker than it is.

Concrete examples I see all the time:

• The ticket grinder who knows a key client environment better than anyone, but never appears in planning or QBR conversations.

• The quiet engineer who resolved the last three nightmare issues, yet is still treated as backup.

• The automation tinkerer whose scripts save hours every week, but still sits in a generic role and never gets pulled into project planning.

In most MSPs, internal capability is at least one level higher than titles suggest.

The real gap is not the bench. It is your ability to see that bench clearly enough to give it responsibility.

A hard truth leaders avoid

If every initiative turns into a senior hire, that is not a strategy. That is avoidance.

It is the avoidance of defining the work. Avoidance of redefining ownership. Avoidance of fixing the internal structure that causes the pain in the first place.

Hiring feels like action. Diagnosis feels like friction.

But hiring without diagnosis is how MSPs add payroll and keep the same problems.

Hiring without clarity creates two predictable outcomes

External hiring has its place. There are times when you genuinely need experience you do not have.

But when your core problem is clarity, hiring externally does not fix the root issue. It adds a new person to the same fog.

Leaders hope an external hire will do three things:

• Plug a capability gap.

• Reduce pressure on the existing team.

• Own a messy area that nobody has owned well.

What happens instead is usually one of two outcomes.

1. The new hire becomes the new overloaded hero. Everything hard gets routed to them. Escalations. Project rescues. The worst client issues. The work you hired them to do never stabilizes because the business keeps feeding them the next fire.

2. The new hire stalls. The lane is unclear. Ownership is fuzzy. Responsibilities overlap. Decision rights do not exist. They spend their first months trying to find a clear scope and getting pulled in ten directions.

Either way, your execution problems persist.

Now you are paying a higher salary, recruiter fees, and ramp time while the original issue remains.

And the costs are not only financial.

Culturally, your bench watches what happens when every interesting opportunity goes to an outsider.

Mid-level engineers stop raising their hands. The people who have been stretching quietly decide it does not matter. Your best performers start looking elsewhere because they do not believe growth is real inside your MSP.

You did not just fill a role. You sent a signal.

If you cannot see and deploy the people you already have, adding more people usually multiplies confusion. It does not reduce it.

What clarity first actually means

Clarity first is not a slogan. It is an order of operations.

Internal first does not mean “never hire externally.” It means you change the order of questions.

When a new need shows up, the sequence becomes:

1. What is the work, specifically, that is failing or unowned?

2. What does “great” look like day to day?

3. Where does this work live today? Who is already doing parts of it?

4. Who could grow into ownership with six to twelve months of focused support?

5. What has to move off their plate to make that real?

6. What pairing, shadowing, or training is required?

7. Only then, if you still cannot cover it, what exactly is missing that you need from an external hire?

That sequence does two things.

1. It makes hiring more accurate.

2. It makes internal growth real because you stop pretending people will “develop” without time, support, and intentional changes in what they own.

What you need before internal first works consistently

You cannot run internal first consistently if your view of your team is:

• An org chart.

• Job titles.

• Sporadic review notes.

• A few managers’ mental lists.

That is not a system. That is a collection of partial memories.

You need a shared, current view that leadership trusts.

Not a giant HR exercise. A practical view of the things leaders actually make decisions on.

At a minimum, you should be able to answer these questions quickly:

• Who can do what, beyond their title?

• Who wants to grow into what next?

• Who is overloaded and why?

• Who is doing the hard work today?

• Who gets pulled into the complex issues and resolves them well?

• Who is one step away from owning a function if supported properly?

If you cannot answer “who is already doing this work” in 30 seconds, you are not ready to hire for it. Without a shared view, internal first stays a guess.

With a shared view, the conversation changes from:

“Do we have anyone who could do this?”

to:

“We have two people who are close. Here is what they are already doing. Here is what they want next. Here is what we need to change to give them a fair shot.”

That is when internal first stops being a poster on the wall and becomes how decisions get made.

Execution improves when leaders can see the team clearly

Most people are already trying to stretch inside the constraints you set. They read. They tinker. They take on a bit more each time you let them. They are already partway toward the roles you are posting.

The issue is that your system does not capture it, and your decisions do not reflect it.

When leaders can clearly see skills, load, and growth direction, execution improves quickly.

• Projects get staffed with people who can actually deliver and grow into the work, which reduces rescues.

• Single points of failure start shrinking because you stop hoping the same two people will always be available.

• Training turns into capacity because when someone learns something new, you change what they own.

• Engagement improves because people see a real connection between effort and opportunity. Not just certificates. Responsibility.

If you fix how you see your team, you improve execution, hiring decisions, and culture simultaneously.

Moves to shift toward clarity first in the next 90 days

Here are 6 habits that will help you make this shift:

1. Diagnose the work before you write the job description
   Before you write requirements, write the work.

• What outcomes are missing?

• What responsibilities are unowned?

• What does ownership look like weekly, not theoretically?

• What should stop happening once this role exists?

If you cannot describe the work clearly, do not post a role. You will get confused.

2. Run an internal bench review before any external posting.
   Before you post any new role, identify three internal people who could cover most of it within six to twelve months.

Then answer these questions as a leadership team:

• What moves off their plate so this is real?

• Who picks up their current responsibilities?

• What support do they need in the first ninety days?

If the answer is “no one,” fine. Go to market with your eyes open. If the answer is “actually we do have someone,” you just found a faster path with less risk.

3. Build a simple “next up” list by function
   Pick the functions that always become bottlenecks in MSPs.

Security. Cloud. Account ownership. Projects. Team leadership.

List who is in the wings today. Use input from service managers, project leads, and your own observation.

Review it monthly.

• Who stepped up?

• Who outgrew their current scope?

• Where do you still have no pipeline?

This creates a simple internal succession view instead of relying on memory.

4. Tie training to deployment, not just certs
   The next time someone completes a course or earns a certification, decide in advance what changes will be made.

Examples:

• Certain ticket types move to them first.

• They own a slice of a project.

• They become primary or secondary for a client.

• They lead a portion of a QBR.

• They take the first pass on a security or cloud review.

Make one concrete change within thirty to sixty days.

If training does not change deployment, it will not change execution.

5. Design one shadow and handoff path with intent
   Pick one critical role that is currently a single point of failure.

Security lead. Cloud lead. Senior account owner. Project lead.

Name a successor or at least a second.

In the next ninety days:

• Put them in the right meetings.

• Give them defined parts of the work.

• Debrief what went well and what they need next.

• Increase scope intentionally, not accidentally.

This is how you build internal leaders on purpose, rather than hoping they show up when someone leaves.

6. Add one standing question to leadership meetings
If you want internal first to be real, you have to talk about it when decisions are made.

In leadership and service management meetings, ask:

• “Where did we default to external when we could have looked internal first?”

• “Who did we stretch this month and what did we learn?”

The goal is not guilt. The goal is better decisions.

Remember - you already have this in place…and have already paid for it!

You have already paid for more capability than you think you have.

You paid for it in salaries, benefits, training, mistakes, late nights, and hard client lessons. 

The return on that investment depends on whether you can see what you built and whether you are willing to back it.

External hires will always have a place. Some gaps really do require outside experience.

But if every new problem triggers the same reflex to post a senior role, and your internal bench still feels like a black box, you are carrying more cost and risk than you need to.

If you are trying to shift toward clarity first and want to compare what you are seeing with what I am seeing across other MSPs, I am always open to that conversation.