Every MSP owner I talk to has the same headache: finding good technicians. Not warm bodies who can reset a password, but people who can walk into a mess nobody has seen before and work out what’s actually going on. So here’s a question that’s been nagging me. If we keep pushing our techs to lean on AI for every problem, are we quietly eroding the very skill we’re struggling to hire?
The fix that works until it doesn’t
Picture a fairly typical morning. A junior tech gets a ticket about mail not flowing for a shared mailbox. They paste the error into Microsoft 365 Copilot Chat, ask for a PowerShell fix for Exchange Online, run what comes back, and the ticket closes. Great outcome?
Maybe. But ask that tech why it broke and there’s a decent chance you’ll get a shrug. They solved the symptom without ever building a mental model of the system. Do that a few hundred times and you have someone who is fast on familiar problems and lost the moment the answer is wrong, the situation is unusual, or the AI simply isn’t available.
That’s the risk as I see it. Copy-paste fixes. No root-cause understanding. A growing dependence on a tool that can be confidently mistaken. And, longer term, a junior pipeline that never matures into the senior people who can mentor the next lot. If nobody struggles any more, where do the next seniors come from?
But I’m not going back
Let me be clear, I’m not arguing we ban AI from the service desk. Copilot summarising a long ticket thread in Teams or Outlook saves real time. Having it explain an unfamiliar Intune policy setting or draft a script you then review is genuinely useful.
The problem isn’t the tool. It’s how we’re letting people use it. An answer engine makes you dependent. A tutor makes you better. Same technology, very different result.
What I’d do as an MSP owner
A few practical things I’d put in place:
- Explain the why before applying the fix. If a tech can’t tell you, in plain words, why a command will solve the problem, it doesn’t get run on a customer tenant.
- Use Copilot as a tutor, not just an oracle. Encourage prompts like “explain what this error means and what could cause it” rather than “fix this”. Ask it to walk through the reasoning, then challenge it.
- Review AI-assisted tickets. Have a senior skim a sample each week. Look for thin understanding and coach it.
- Practise without the safety net. Run regular no-AI troubleshooting sessions. Break something in a lab tenant and let the team work it out the old way.
- Document the reasoning, not just the resolution. “Ran script, fixed” teaches nobody anything. “Mailbox permissions were inherited wrongly after a migration, here’s how I confirmed it” builds team knowledge.
None of this is complicated. It just requires deciding that skill development is still part of the job, even when a faster shortcut exists.
The real question
AI will make good technicians better. I’m fairly confident about that. What worries me is whether it will make new technicians good in the first place, or just make them look good until the day it matters. The MSPs that win the skilled labour fight won’t be the ones that use the most AI. They’ll be the ones that use it to grow people rather than replace their thinking.
So I’ll put it to you: in your business, is AI building your techs’ problem-solving muscle, or quietly doing the lifting for them?
