Building an IT Talent Pipeline

Most internship programs start when a company has budget to spare and open roles waiting to be filled. I started mine during a downsizing, with a shrinking team and no management title, while most of the support work for four of our six manufacturing sites was landing on me.

The situation

This was 2018, and the company was cutting staff. After the cuts, support across four of our six sites consolidated to me. The infrastructure team had its own workload to carry, and coverage that used to be spread across more people now ran through fewer of us. Around the same time, my manager left, the person who had been over both the server admins and the support side. In the reorganization that followed, the server admins moved under the Network Manager and became “Infrastructure,” and I started reporting directly to the VP.

My title stayed the same. On paper I was still a Senior Support Administrator. In practice I was responsible for support across most of the company, with no team and no headcount to build one.

Building a team I couldn’t hire

Hiring wasn’t an option, since the company was reducing staff rather than adding it. The one kind of team I could actually stand up under those constraints was a part-time internship program. It cost little, gave people real responsibility, and let me grow capability without a full-time requisition that wasn’t going to get approved.

I started at a single site to see whether the model held up. It did, and the VP approved expanding it. I brought it to two more sites, three in total, and ran it from 2018 until 2025, when I moved fully into infrastructure and handed the service desk to a dedicated manager.

How it worked

I didn’t treat the interns as cheap labor, because a program run that way falls apart fast. They handled real tickets and real escalations, and moved from break-fix into imaging, deployment, and administration as they were ready for it. Since people rotated up and out over time, mentoring and documentation had to be part of the everyday work instead of an afterthought.

The program earned its place by solving two problems at once. It kept support coverage steady across the sites I was responsible for through some lean years, and it gave people a path forward instead of a dead-end support role.

What it produced

Three interns came through the program and into full-time roles on the team. I hired them after already watching them do the work for months.

Beyond that, the program made a strong enough case for itself that the company created four new full-time positions it hadn’t carried before. An organization that had been cutting headcount decided this was worth adding to.

And through the leanest stretch, support across most of the company held steady on a staffing model that cost a fraction of what full-time hires would have.

Not everyone stayed, and that was always part of the point. People who came through the program have gone on to roles as an IT manager, a systems and controls engineer, and an engineer at a large cybersecurity company. Their success is their own. What the program gave them was a first real shot at production work, and seeing where they took it from there is one of the things I am most proud of.

Looking back

For a long time I described this as “I ran the internship program,” which undersells what it was. With no direct reports and no change in title, I built and led a people-development program across multiple sites for most of a decade, and it worked well enough that the business added headcount around the results.

The mentoring was worth doing on its own, and it is the part I am proudest of. What I kept leaving out was the scale of what it added up to. I should have been telling both sides all along.