How to close the IT skills gap on your team

Every IT team has a version of the same bottleneck. One senior engineer’s queue fills up with escalations from technicians who have done the training and passed the IT certification, but still can’t finish the task alone. A software deployment fails halfway, or a script behaves differently on one server than on the other forty, and the ticket moves up the chain instead of getting resolved.

That bottleneck has a measurable cost. In an IDC survey of more than 800 North American IT leaders, nearly two thirds said a lack of skills had resulted in missed revenue growth objectives, quality problems, and a decline in customer satisfaction.

More courses rarely clear it, because understanding a task and executing it unsupported on a live system are different capabilities. Here’s how to build development into the tickets, incidents, and maintenance work your team already handles, so knowledge turns into independent execution.

The IT skills gap you might not have noticed

A skills gap is just simply a technician lacking the knowledge or practical capability to perform an expected task correctly and consistently. That definition rules out a lot of what gets reported as one. A technician who can’t complete a firewall change because they don’t have admin rights on the appliance isn’t short on skill.

Before you classify anything as a gap, remove environmental blockers by verifying these aspects:

• Permissions
• Tooling
• Documentation
• Connectivity
• Access to the target system

If performance still falls short once the technician has everything they need, you’re looking at a genuine gap.

How to find the layer that’s missing

Once you’ve confirmed a real gap, work out which layer is missing. Test progressively with these steps and stop at the first stage where the technician fails:

• Ask the technician to explain the task, including its dependencies, risks, and expected outcome. If they can’t, the gap is theoretical knowledge.
• Give them access to a staging environment and have them perform the task with guidance available. Failure here means the knowledge hasn’t translated into hands-on capability.
• Remove step-by-step guidance and have them complete the task from preparation through validation on their own.
• Introduce an unexpected condition, such as a failed dependency or a service that won’t restart, and have them diagnose and resolve it. Failure at this or the last step points to an independence gap.

The last layer is where most gaps hide. Knowing the correct command doesn’t mean a technician can work out why it failed and finish the job safely.

Pro tip: A less obvious risk is having a concentration of critical knowledge in one senior technician. Documentation captures commands and procedures, but it rarely captures the diagnostic reasoning behind them, such as why one symptom matters, which checks can safely be skipped, or when a familiar fix is the wrong call. A quick way to find this gap is to look at which incident types always end up with the same engineer. If only one person can still diagnose the difficult cases, the team hasn’t closed its skills gap.

What needs to be in place before upskilling starts

Before committing to closing a gap, you need four things in place:

• Protected time: Block recurring development time on the team schedule and cover it the way you’d cover on-call, so it isn’t the first thing dropped when the queue spikes.
• Systems access: Provision a lab, staging tenant, or non-production VM set where technicians can break things safely. Grant the permissions the target task requires before the first practice session.
• Senior support: Name the senior engineer responsible for each gap, and reduce their ticket allocation to reflect the supervision time you’re asking for.
• Application opportunities: Identify the recurring tickets, changes, and maintenance tasks where the new skill will actually be used, so practice continues after the formal learning ends.

Without these, technicians can complete the training and still struggle to carry it into daily work. Ticket pressure, restricted access, or an unavailable mentor quickly displace learning. What’s left is theoretical knowledge without practical competence, and the original gap stays open.

Prioritize gaps by operational risk first

When several gaps compete for attention, trying to handle them all at once will just get people confused and make it difficult to actually close them. Prioritize by operational risk rather than by how many technicians need training.

Assess each gap against five factors:

• Criticality of the affected system
• Security and compliance exposure
• How often the task requires intervention
• Service impact when it’s done badly or late
• Whether experienced backup capability exists

A deficit affecting identity, security tooling, or production infrastructure takes precedence over one affecting a low-risk administrative platform, even if the second gap is more widespread.

Match the remediation method to the gap type

The diagnostic layers from the previous section map directly to different fixes. Treating every gap as a training-course problem wastes time on the wrong intervention.

» Don’t miss our guide to building a modern IT troubleshooting framework for technician training

How to close the gap, verify it, and adjust when it isn’t working

With the gap diagnosed and the groundwork in place, closing it is an operational process. That process has three parts: building capability through progressively independent work, confirming the result holds, and changing course when it doesn’t.

Follow these steps:

1. Move development out of the classroom and into the workflow

The most common execution mistake is treating upskilling your IT department as a training event rather than a capability-development process. A one-off course, a certification push, or an information-heavy classroom session with no practical application afterward produces technicians who recognize the terminology and procedures but still need a senior engineer to execute or troubleshoot real tasks. Generic training also consumes operational time without addressing the specific deficit you diagnosed.

The course correction is to move development into operational work. Here’s what that looks like:

• Define the specific capability required
• Assign suitable real tasks under supervision
• Give feedback after each execution
• Reduce assistance as competence improves
• Measure success by consistent independent performance, not course completion

2. Take technicians from deficiency to independent execution

The framework below takes a technician from a specific skill deficiency to consistent, unsupervised execution. Make sure senior guidance is highest at the start because you can withdraw it stage by stage as their capability builds.

• Define the deficiency: Name the specific task the technician can’t perform independently and establish what a correct outcome looks like.
• Assess the gap type: Use the progressive test from the diagnostic stage to confirm whether the gap is conceptual knowledge, practical execution, or independent troubleshooting.
• Close foundational gaps first: Address any missing concepts before moving to hands-on work, so practice builds on an accurate understanding of the system.
• Demonstrate the task: Have an experienced technician perform it end to end, covering the correct sequence, dependencies, risks, and expected result.
• Run supervised practice: Have the technician perform the task across realistic scenarios with senior guidance available. Introduce controlled variations and faults to confirm they can diagnose, not just follow a procedure.
• Require independent execution: The technician completes the full task alone, from preparation and troubleshooting through execution, and recognizes when escalation is appropriate.
• Validate: Confirm the technician completes the task consistently and safely without senior intervention before treating the gap as closed.

3. Choose tools that build reasoning, not just speed

The tools that help bridge skill gaps in IT and security teams fall into a few categories:

• Lab and sandbox environments for safe practice
• Knowledge base and documentation platforms that capture resolution context
• RMM and scripting tools that standardize routine work
• AI agents and assistants that surface diagnostic context during live tickets
• Structured learning platforms for foundational knowledge

Evaluate each against operational efficiency and technician development. A tool that standardizes patch management, deployment, infrastructure monitoring, or routine remediation can appropriately reduce complexity where consistency and speed are the priority. Tools used during diagnosis should do more than that because they need to expose enough context for technicians to understand why a condition occurred, weigh the evidence, and decide what action fits.

Atera’s AI Copilot is built for the support-reasoning side of that line. Inside Atera, technicians can run health checks and diagnose device issues, generate scripts and commands from plain-language descriptions, pull instant ticket summaries, and turn successful resolutions into knowledge base articles for approval. Instead of escalating routine work immediately, the technician investigates with the relevant context in front of them and decides what to do with it, which frees senior engineers to focus on complex problems and on the supervision described above.

Some responsibilities still require direct human guidance:

• Architecture decisions
• Security-sensitive changes
• Unfamiliar failures
• Production risk assessment
• Validating AI-generated actions before execution where consequences are significant

Part of the skill being built is recognizing when automated guidance is insufficient and escalation to an experienced engineer is the right call.

» Learn more about boosting IT efficiency with AI Copilot and how AI upskilling transforms career paths

4. Bridge urgent high-risk gaps without creating permanent dependency

When a gap in an area like cybersecurity or cloud architecture creates immediate exposure, treat it as a risk-control problem and a skills-development problem at the same time. Reduce the exposure first:

• Bring in qualified external specialists
• Restrict high-risk changes until capability exists internally
• Strengthen review and approval controls on the affected systems
• Assign critical work only to proven personnel

Then build internal capability alongside the specialists. Internal technicians shadow the external experts, move into supervised execution, document what they learn, and take on progressively greater responsibility. Temporary controls stay in place until internal staff can demonstrate safe, independent execution across realistic scenarios. This keeps inexperienced staff out of high-risk roles while ensuring external expertise doesn’t become a permanent crutch.

» Learn more about IT department roles and responsibilities

5. Adjust when the method isn’t working

If a technician still needs step-by-step assistance after the planned development period, don’t repeat the same training. Reassess the original gap first. The diagnosis may have been wrong, or the method may not match the remaining deficit.

Here are some ways to adjust the workflow accordingly:

• Break the task into smaller increments
• Increase supervision on the stages where the technician stalls
• Add practical exposure, especially troubleshooting variations rather than the happy path
• Follow every attempt with specific feedback on decisions, errors, and outcomes
• Withdraw senior support progressively as execution improves

If performance still depends on step-by-step help, the technician stays supervised on that task while the underlying knowledge, practical, or problem-solving deficit is addressed.

Case study: how Absa built internal cloud capability

Absa Group partnered with AWS Training and Certification to address cloud and generative-AI skills gaps during its digital transformation. Its GenAI Incubator enabled 160 employees to complete 605 AWS Skill Builder courses, while gamified learning increased course completion by 162%. Participants generated 28 innovation ideas, 13 of which were shortlisted for further development.

Absa then launched a 12-week Cloud Incubator for 215 employees, covering application migration, DevOps, AI, and machine learning. Participants completed 1,885 AWS Skill Builder courses and gained the skills to migrate two legacy applications to AWS, and Absa reports the program is reducing its reliance on external partners while lowering costs.

» Here’s our guide to building an IT cost optimization framework

Capability is built on the job

A skills gap is closed when a technician can take a task from preparation through validation without a senior engineer stepping in, and can keep doing it when conditions change. Getting there depends less on the training catalog than on two things during normal work. Senior engineers need time to supervise rather than execute, and technicians need enough context in front of them to reason through a problem instead of escalating it

That’s where Atera fits in. Robin by Atera is an AI technician that resolves Tier-1 and complex Tier-2 technical incidents end to end, diagnosing, remediating, verifying, and closing the ticket autonomously, with no technician in the loop. Up to 92% of those incidents get resolved before they ever reach a senior engineer’s queue, which frees up time for the supervised practice and review that actually builds capability. AI Copilot gives technicians troubleshooting assistance, script generation, and ticket summaries inside their workflow, while they stay responsible for validating what it proposes.

» Learn more about automatic ticket resolution using AI or try Atera for free