What employers actually hire for in IT — and the gap with what we're teaching

If you teach IT, you've probably noticed the disconnect.

A job posting lists CompTIA Security+, three years of experience, and a list of acronyms. Your students get the cert. They look the part on paper. They don't get hired. Or they get hired and don't last.

Meanwhile your colleagues at industry advisory boards keep saying things like "we need people who can communicate" and "we need people who don't need hand-holding." You write that down. You don't know how to teach it.

This post is about that gap — what's actually happening between job posting language and hiring decisions, and what CTE IT programs should do about it.

I want to take a position that some readers will disagree with: the certifications are not the problem. They're the entry ticket, and your programs are doing fine on that front. The problem is the un-listable skills that surround the technical work. Hiring managers select on those skills, but they don't write them down because they've never had to articulate them. So your students arrive credentialed but not ready, and everyone is confused about why.

Why job postings don't tell you what employers want

Job postings are written by HR. HR writes them by copying the last similar posting and updating the title. They list certifications because certifications are the only thing HR can verify by looking at a resume.

But the actual hiring decision happens in interviews — and what hiring managers select on is almost never what HR wrote down.

A network admin manager isn't choosing between candidates based on which one has the freshest CCNA. They're choosing based on:

• How the candidate explained a past problem
• Whether the candidate asked clarifying questions or jumped to answers
• How the candidate talked about disagreements with previous managers
• Whether the candidate seemed teachable

These are the actual hire criteria. They don't appear in postings because no HR person knows how to write them as bullet points.

The gap between posted requirements and actual selection criteria is the gap your students are falling into.

What hiring managers select for, specifically

Drawing from interviews with IT hiring managers and the patterns they describe, the un-listable skills break into roughly five categories. These are the things that get rejected for, more often than the technical skills.

1. The ability to explain technical problems to non-technical people

A help desk hire who can't explain why a printer isn't working without using the word "spooler" will be moved off the help desk in three months. Hiring managers know this. They test for it in interviews by asking "how would you explain X to my mom" and watching the candidate's face when they realize they don't know how.

CTE programs assume this skill comes for free with technical knowledge. It doesn't. It's a separate skill that needs separate practice.

2. The willingness to look stupid by asking questions

Junior IT hires who pretend they understand when they don't will break things expensively. Junior hires who ask "wait, can you go back, I don't follow why we do this step" become senior hires.

Hiring managers test for this by deliberately introducing a small contradiction or confusion in their explanation during the interview. Candidates who notice and ask about it are flagged positive. Candidates who nod along are flagged negative.

Your students are probably losing this test. They've spent years in classrooms where asking questions in front of peers is socially expensive. Workplaces require the opposite skill.

3. The judgment to know which problem matters

Every IT environment has 10 things going wrong at any moment. The hire who runs around fixing all of them in random order is exhausted and unproductive. The hire who can look at the queue, identify the one that affects revenue or safety, and ignore the rest until that one is solved is valuable.

This is judgment, not knowledge. It's hard to teach because it requires real stakes. Most CTE labs have low stakes — a broken VM doesn't actually break anything. So students never practice prioritizing.

4. The discipline to document while the work is happening

The single most cited frustration from senior IT staff is "I asked them to document the fix and they wrote two sentences." Documentation is not a separate task done after the work. It's a habit done during the work. People who learned the habit late never quite learned it.

CTE programs that require documentation as a separate assignment after every project miss the actual skill. The skill is documenting as you go. Different muscle.

5. The temperament to handle being wrong publicly

IT work involves being publicly wrong. You said the server was the problem, you reset it, the issue persisted, the meeting watched you be wrong in real time. The hire who handles this gracefully — owning the mistake, redirecting the diagnosis, moving forward — is the hire who gets promoted.

The hire who gets defensive, blames the user, or shuts down doesn't get promoted, and often doesn't get rehired into the next contract.

Your students are getting almost no practice with this in school. School is structured so that being wrong is private and graded. Workplace IT requires being wrong in public and continuing to function.

What this means for curriculum

If the un-listable skills are the actual hire criteria, your programs need to teach them as deliberately as you teach the technical content. Three concrete moves:

Move 1: Build "explain it to a non-technical person" into every assignment

Every technical assignment should require a deliverable for a non-technical audience. Not "describe your solution." Specifically: "explain your solution to your grandmother. She is not stupid. She doesn't know what a router is. She's a smart person who isn't in your field. What do you say?"

Grade the explanation as rigorously as you grade the technical solution. Half the points.

Move 2: Create deliberate stakes in the lab

Stakes drive judgment. If a broken VM has no stakes, students never practice prioritizing.

You can manufacture stakes:

• Multiple simultaneous failures the student must triage
• Time-limited diagnostic exercises with a "production downtime cost" attached
• Lab partner roles where one student depends on another's work being correct

Real-stakes practice in school means lower-stakes mistakes when stakes get real.

Move 3: Run weekly "what I got wrong" debriefs

End each week with a 20-minute session where students share something they got wrong that week and how they recovered. Make it a normal part of the program, not a remedial activity. Faculty model it first by sharing their own mistakes.

Programs that do this consistently report graduates who handle workplace mistakes more gracefully. Programs that don't get students who freeze the first time something goes wrong on a real network.

The thing employers want to say but won't

When I ask hiring managers what they really want, after the formal categories have been listed, they almost always say some version of: "I want someone I don't have to babysit."

That's the actual hire criterion.

It's not on the job posting. It's not in the certification rubric. It's not testable on a written exam. But it's the thing that decides who gets hired and who keeps the job.

You can't directly teach "don't need babysitting." You can teach the components — communicate clearly, ask questions, prioritize, document, handle being wrong. Each of those is teachable. Together they produce graduates who don't need babysitting.

CTE IT programs that teach the technical skills well but ignore the un-listable skills are producing certified graduates who can't get hired. Programs that teach both produce graduates who get jobs and keep them.

The certifications matter. They're the entry ticket. But the entry ticket alone hasn't been enough for years, and pretending otherwise sets students up to lose interviews they were technically qualified for.

What to do this week

Three small moves you can make in the next five days, no curriculum committee required:

1. Audit one assignment. Pick the next assignment your students will turn in. Add a 200-word "explain this to a non-technical person" component. Grade it.

2. Run one mistake debrief. End one class this week with: "What's something you got wrong this week, and what did you do about it?" Go first as the instructor.

3. Introduce one judgment exercise. Give students three simultaneous IT problems and 20 minutes. Make them tell you which one they'd address first and why. Don't tell them the right answer — there often isn't one. The skill is the reasoning.

These cost you nothing. They take a week to deploy. They start changing what your students practice every day.

The certifications will continue to matter. So will every other technical skill you teach. The un-listable skills don't replace the technical content — they make the technical content actually useful in the workplace where it gets used.

If your program has been teaching some version of the un-listable skills already and seeing graduates land jobs faster, TechEd Analyst would like to know what you're doing. Reach out at hello@techedanalyst.com. We're trying to assemble a clear picture of what's actually working in 2026, and educators in the field have data we don't.

TechEd Analyst publishes monthly posts for CTE and IT educators navigating workforce changes. Subscribe to get them in your inbox, or browse recent posts.