Skip to main content

Do IT Certifications Still Build Client Trust?

Gabe Hilado
Founder and CEO, Zenpo Software Innovations

Certifications are a proxy. Back in the late '90s, when career-switchers were flooding into IT from every other industry, certs offered the fast path — a way to prove baseline competence short of going back for a CS degree. They exist because the buyer can't tell the difference between someone who can deliver and someone who can't — not until the system is in production and it's too late to switch vendors.

That's the transaction. The cert says "this person passed a test about the technology." The buyer hears "this person can build what we need." Those are two completely different claims, and the gap between them has been costing organizations money for decades.

What happened at Defense Acquisition University in 1999?

It's 1999. I'm one month out of George Mason. No certifications, no reputation, no leverage. Defense Acquisition University needs to automate the creation of course books — compilations of long-form text documents with embedded PowerPoint slides, assembled programmatically through Word automation. Not a trivial problem. The kind of thing where you're fighting COM objects and praying the Word instance doesn't crash mid-render.

A certified consultant — $100 an hour, which was real money in 1999 — told my boss it couldn't be done. Flat out. The automation was too fragile for long documents, the slide embedding was a dead end, move on to a different approach.

I built it anyway. Long texts. PowerPoint slides. The full compilation pipeline. Working. I showed him — showed the room — that the thing he said was impossible was running on the screen in front of them.

That thing you watch ChatGPT do on screen today — generating documents, assembling content programmatically, automating what used to be manual assembly? I was doing it in 1999 with Word VBA and stubbornness. The $100/hr certified expert said it was impossible. The fresh graduate with no badge shipped it.

That wasn't a fluke. It was the first round of a pattern that's repeated across my entire career.

Why does cert culture keep surviving?

Cert culture persists because it solves a real problem — just not the problem people think it solves. The actual problem: buyers don't have time to evaluate technical competence directly. They can't sit every candidate down and say "build this thing while we watch." They need a filter. The certification is the filter.

And filters work. They reduce the candidate pool. They give procurement teams a checkbox. They give hiring managers a CYA answer when someone asks why they picked this vendor over that one. "They were certified" is an answer that survives an audit. "They seemed really sharp in the interview" is not.

But the filter only tells you who studied for a test. It doesn't tell you who can sit in a room where the requirements are wrong, the timeline is compressed, the previous vendor left a mess, and the stakeholders disagree about what "done" means — and still ship something that works.

That gap — between passing a test and surviving a project — is where the cert narrative falls apart. Every experienced practitioner has watched it happen. The certified team that couldn't deliver. The uncredentialed contractor who saved the engagement. It's so common that pointing it out feels like cliché. And yet organizations keep buying the badge.

Does the pattern repeat across decades?

The 1999 moment wasn't an anomaly. The same dynamic has shown up in every cycle since — every time a new platform creates a new certification ecosystem, the same gap reopens between people who passed the test and people who can ship.

Each time, the sequence runs identically. New platform emerges. Vendor creates a certification program. Consulting firms rush to get their people certified. Clients start requiring the cert in RFPs. And somewhere in the middle of all that credentialing activity, the actual work still needs to get done — and the people doing it best are often the ones who skipped the exam and spent that time building.

The cert didn't lose those debates because the holders were incompetent. Many certified consultants are excellent. The cert lost because it was being used as a substitute for something it can't measure: the ability to solve problems that don't match the study guide.

A certification tests whether you know the platform's intended use cases. Real projects rarely stay inside intended use cases. The moment a client's requirement drifts outside the exam's scope — and it always does — the cert stops being relevant and the only thing that matters is whether you can figure it out.

Will AI certifications change the equation?

Microsoft is releasing a Copilot certification. Bootcamps are already selling AI badges. The credentialing industry has spotted the opportunity and the arms race is accelerating.

Here's what will happen. Enterprise buyers will start requiring AI certifications in vendor evaluations. RFP language will update. "Must have X certified professionals on the team" will appear in statements of work. Consulting firms will pay for bulk exam vouchers and run study groups. LinkedIn profiles will bloom with new badges.

And none of that will answer the question the client actually needs answered: can this team deliver working software with AI tools in a way that holds up six months after go-live?

The Copilot cert will test whether someone knows what Copilot can do. It won't test whether someone knows when Copilot is the wrong tool. It won't test whether someone can recognize when the AI-generated code has a subtle logic error that passes every surface-level review. It won't test whether someone can architect a solution where AI acceleration doesn't create technical debt that compounds faster than the speed gain.

Those are judgment calls. You don't certify judgment. You demonstrate it — or you don't.

What does client trust actually depend on?

Strip away the credentials, the logos, the partner tiers, the badge counts. What makes a client call back?

Two things. Does it work? And will you be there when it doesn't?

That's it. Every long-term client relationship that survives past the first engagement runs on those two questions. Not "are you certified." Not "how many people do you have on the bench." Not "what tier is your partnership."

Does the thing you built actually solve the problem? And when something breaks at 4 PM on a Friday — because something always breaks at 4 PM on a Friday — are you the team that picks up the phone?

The certification can't answer either of those questions. The certification is a promise about knowledge. Client trust is built on a track record of experienced practitioners making good decisions under pressure and standing behind the outcome.

How do you win a technical debate without the badge?

The same way it's been won since 1999. You build the thing. You show it working. You let the output argue on your behalf.

Every technical debate between a certified consultant and an uncredentialed practitioner ends the same way when someone opens a laptop and demos a working solution. The demo doesn't care about your cert. The demo doesn't care about your years of experience. The demo either works or it doesn't, and every person in the room can see which side of that line you're standing on.

This is why the strongest consulting teams are small, senior, and biased toward building over presenting. A team that spends its first week building a proof of concept has more credibility by Friday than a team that spends its first week presenting slide decks about their methodology and certifications.

The credential is the delivery. Not the badge, not the exam score, not the LinkedIn endorsement. The credential is the working system. It always has been.

Is this an argument against all certifications?

No. Certifications aren't worthless. They're a signal — a weak one, but a signal. For junior practitioners entering a field, a cert demonstrates baseline commitment. For procurement teams that need defensible selection criteria, certs provide structure. For platforms with genuine safety implications — cloud security, medical systems, infrastructure — a certification ensures at least a minimum threshold of formal knowledge.

The problem isn't that certifications exist. The problem is that they've been elevated from "minimum threshold" to "proof of competence." Those are different things. A driver's license proves you passed the test. It doesn't prove you can handle black ice at 60 mph. The gap between the test and the real thing is where competence lives.

A badge didn't win the argument in 1999. It hasn't won one since. It won't win in 2026. The teams that keep winning are the ones that show up, build the thing, and answer the phone when it breaks.

That's the only certification that renews itself.