IT skills crisis: build your team

Three years ago, I had what I thought was a solid IT team. Strong on infrastructure, reliable on support, capable of keeping the lights on for our e-commerce operation. We had good people doing good work.

Today, that same team composition would leave us dangerously exposed. The issue is that the business now needs different skills. IT leaders should assess those requirements against their team's capabilities.

The ground has shifted

Cast your mind back to early 2023. ChatGPT had just launched. Most organisations were still mid-way through cloud migrations. Cybersecurity was important but not yet the board-level obsession it has become. Automation was something you did with a few PowerShell scripts and maybe some Ansible playbooks.

Now look at where we are:

• AI is embedded in operations. Not as a novelty, but as a core tool. Your team needs to understand AI integration, prompt engineering, data pipelines, and the governance frameworks around AI use. If you need a starting point, my guide to building an AI enablement framework lays out a practical approach.
• Cloud is the default. On-premises infrastructure has not disappeared, but the centre of gravity has shifted. Your team needs deep cloud-native skills, not just "we can spin up a VM in Azure" competence.
• Security is everything. Post-quantum cryptography, zero trust architecture, supply chain security, AI-powered threat detection all require security expertise.
• Automation changes routine work. Ticket routing, user provisioning, monitoring response, patch management can be candidates for automation when the process and controls are understood.

The traditional IT operations role, covering server management, tickets and email, is being compressed from both sides. Automation handles the routine work. Specialist skills are needed for the complex work. The middle ground is shrinking fast.

The roles that have changed

Let me be specific about what I have seen shift in our own organisation and across the industry.

The traditional sysadmin

Three years ago, we had dedicated system administrators managing on-premises Windows and Linux servers. Today, most of that infrastructure runs in the cloud. The skills needed are no longer about racking servers and managing RAID arrays. They are about Infrastructure as Code, container orchestration, cloud networking, and cost optimisation.

A sysadmin who cannot write Terraform or navigate Kubernetes is increasingly limited in what they can contribute. Training programmes need to keep pace with the role's requirements.

The helpdesk technician

First-line support has been transformed by AI-powered service desks, self-service portals, and automated resolution workflows. The volume of tickets that require human intervention has dropped significantly in most organisations. What remains tends to be more complex, more ambiguous, and more cross-functional.

The helpdesk role is not dead, but it has morphed into something closer to a customer experience and technical problem-solving role. Soft skills, analytical thinking, and the ability to work across multiple platforms matter more than knowing how to reset a password in Active Directory.

The network engineer

Software-defined networking, cloud-native networking, and zero trust architectures have transformed what it means to manage a network. Traditional knowledge of switches, routers, and VLANs is still valuable, but it is no longer sufficient. Network engineers now need to understand API-driven configuration, microsegmentation, cloud connectivity, and security policy as code.

The new hybrid roles

What has emerged in place of these traditional roles are hybrid positions that blend disciplines:

• A cloud security engineer combines infrastructure, cloud and security expertise.
• A DevOps or platform engineer connects development and operations through automation. See how platform engineering is evolving beyond DevOps.
• An AI operations specialist manages model deployment, monitoring and governance.
• An identity and access management specialist manages identity controls for a zero trust approach.
• A data engineer manages pipelines that supply business intelligence and AI systems.

These roles did not exist in most IT departments three years ago. Now they are critical.

The retraining vs hiring dilemma

This is the tension every IT leader faces. Do you retrain your existing team or hire new people with the skills you need? The honest answer is both, but the balance depends on your situation.

The case for retraining

Your existing team knows your business. They understand your systems, your culture, your customers, and your quirks. That institutional knowledge is enormously valuable and cannot be replicated by a new hire, no matter how skilled they are.

Retraining is also significantly cheaper than hiring in most cases. The average cost of replacing a technical employee (recruitment, onboarding, lost productivity) is typically one to two times their annual salary. A structured training programme costs a fraction of that.

And there is a loyalty factor. People who feel invested in tend to stay. In a market where good IT professionals have plenty of options, retention matters.

The case for hiring

Some skills gaps are too wide to bridge through training alone. If you need a senior cloud architect and your most experienced infrastructure person has never worked outside on-premises environments, that is a two to three year development process, and you might need the skills in six months.

There are also roles where bringing in outside perspective is genuinely valuable. Someone who has implemented zero trust at three different organisations brings experience of recurring problems that no training course can provide.

My approach to the 70/30 split

In our team, I work roughly to a 70/30 split. Seventy per cent of our skills gap is addressed through retraining and upskilling existing team members. Thirty per cent requires strategic hiring, bringing in specialists for critical capability gaps that we cannot develop fast enough internally.

This ratio will be different for every organisation. The key is being deliberate about it rather than defaulting to one approach.

Building a skills matrix

Before you can close the gap, you need to see it clearly. A skills matrix is the tool that makes this possible. Here is how I built ours.

Step 1: define the skills you need

Start with your technology strategy, not your current team. What does the business need from IT over the next two to three years? Work backwards from that to identify the skills required.

For us, that analysis produced five priority skill areas:

1. Cloud-native infrastructure - Azure and AWS, IaC, containers, serverless
2. Cybersecurity - zero trust, threat detection, incident response, post-quantum readiness
3. Automation and DevOps - CI/CD, scripting, platform engineering, monitoring as code
4. AI and data - AI integration, data pipelines, ML operations, AI governance
5. Leadership and communication - vendor management, stakeholder communication, strategic thinking

Step 2: assess current capabilities

For each person on your team, rate their current skill level across each area. I use a simple four-point scale:

• At level 1, awareness, the person understands the concept but cannot execute the task.
• At level 2, developing, the person can execute with guidance and support.
• At level 3, competent, the person can execute independently.
• At level 4, expert, the person can lead others and handle complex scenarios.

Be honest. Use this assessment to identify development needs. I involve the team members themselves in the assessment. They often have the most accurate view of their own capabilities, and involving them builds buy-in for the development plan.

Step 3: map the gaps

Plot your current capabilities against your required capabilities. The gaps become immediately visible. In our case, the biggest gaps were in cloud-native skills, AI integration, and advanced security, which is exactly what you would expect given the industry trends.

Step 4: build individual development plans

Each team member gets a personalised development plan based on their current skills, their interests, and where the business needs are greatest. This is where the human side matters enormously.

Not everyone wants to become a cloud architect. Not everyone has the aptitude for security work. The best development plans align organisational needs with individual motivation. Forcing someone into a role they have no interest in is a recipe for poor outcomes and eventual resignation.

The practical framework for upskilling

Having identified the gaps, here is how I structure the actual upskilling programme.

Dedicated learning time

We allocate one half-day per fortnight as protected learning time. No tickets, no meetings, no interruptions. Team members use this time for structured learning, including online courses, lab exercises, certification study and hands-on experimentation.

This sounds expensive. It is. But it is cheaper than hiring replacements when your team leaves because they feel their skills are stagnating.

Certification pathways

Certifications are not perfect, but they provide structure, motivation, and external validation. We fund relevant certifications for every team member, typically two per year. Current priorities include:

• Azure/AWS cloud certifications
• CompTIA Security+ and CySA+ for the security track
• Terraform and Kubernetes certifications for the infrastructure track
• AI and data certifications as they mature

Project-based learning

The most effective learning happens on real work. I deliberately assign stretch projects that push people into their development areas. A sysadmin who is learning cloud gets to lead the migration of a non-critical workload. A helpdesk technician who is developing automation skills gets to build a new self-service workflow.

This requires accepting that things will take longer and might not be perfect the first time. That is the investment.

Mentoring and knowledge sharing

We run fortnightly technical sessions where team members present what they have learned to the rest of the team. This reinforces the presenter's learning, spreads knowledge across the team, and creates a culture where continuous development is routine.

Where we have hired specialists, part of their role is explicitly to mentor and upskill existing team members. A senior cloud architect who hoards knowledge is not doing their job.

Supporting people through the transition

Skills matrices and development plans are the easy part. The hard part is the human element.

Dealing with resistance

Some people will resist change. That is normal and human. They have spent years building expertise in certain areas, and being told those areas are declining in relevance feels like being told they are declining in relevance. The two are not the same, but it can feel that way.

The key is empathy combined with honesty. Acknowledge that the change is difficult. Validate their existing expertise. It is still valuable. But be clear that the world is moving and standing still is not an option. Frame development as investment in their career, not remediation of their deficiencies.

Managing morale during transition

A team in the middle of a major skills transition is a team under stress. People are learning new things (which is uncomfortable), doing their existing job (which still needs doing), and worrying about their future (which is uncertain). That combination is corrosive to morale if not managed carefully.

Regular one-to-ones focused on development, not just delivery, make a significant difference. Celebrating achievements such as passing a certification, deploying a first cloud resource or automating a manual process builds momentum and confidence. For more on the human side of organisational change, see my piece on the psychology of digital transformation.

Career pathways

The most powerful thing you can do is show people where the path leads. If a helpdesk technician can see a clear route from where they are today to a cloud engineer role in two years, with specific milestones and support along the way, they have something to work towards. Without that visibility, development feels aimless.

We have mapped three career pathways within our team: infrastructure and cloud, security and compliance, and automation and platform engineering. Each has defined skill milestones, certification targets, and typical progression timelines. People can move between these pathways, which provide structure and direction.

When it does not work out

Not everyone will make the transition. Some people genuinely do not want to change direction, and no amount of training or encouragement will alter that. In those cases, honest conversations are essential. Sometimes the right outcome is helping someone find a role elsewhere that better matches their skills and interests. Discuss that possibility respectfully.

What good looks like

Eighteen months into our skills transformation, here is where we stand:

• Cloud capability has moved from mostly level 1-2 to a mix of level 2-3, with two people at level 4 (one hired, one developed internally).
• Security skills have improved significantly across the board, with three team members now holding security certifications they did not have in 2023.
• Automation is becoming embedded in how we work. Manual processes that used to consume hours are increasingly scripted and scheduled.
• Team morale is actually higher than it was before we started, because people feel they are growing rather than stagnating.

We are not done. The skills the business needs will continue to change. But we have a framework that works, a team that is engaged, and a capability set that matches what the business needs today rather than what it needed three years ago.

Key takeaways

• Audit your skills honestly. If you have not assessed your team against current requirements, start there.
• Blend retraining and hiring. Neither approach alone is sufficient.
• Invest in structured development. Dedicated time, certifications, real projects, and mentoring.
• Address the human side. Resistance, morale, and career pathways matter as much as technical content.
• Accept that it is ongoing. The skills your team needs will keep evolving. Build a culture of continuous learning, not a one-off programme.

Compare your team's current skills with the next two to three years of business requirements, then agree development priorities. If you need support developing an IT skills strategy or building a high-performing team, my IT management consulting practice can help.

---

Daniel Glover is an IT leader with over a decade of experience managing technology infrastructure, cybersecurity, and digital transformation for e-commerce and retail businesses. He currently oversees IT operations for 250+ users, focusing on security-first infrastructure, cloud strategy, and building high-performing technology teams. Connect with him on danieljamesglover.com.