I have been in this industry for a long time, longer than I care to admit in polite company, and I have watched the same conversation play out in boardrooms and standups and vendor briefings for three decades now. The executives say they cannot find the people they need. The recruiters say the market is bone dry. The hiring managers say nobody has the skills anymore.
Everyone nods solemnly, as if we have all just discovered that the sun rises in the east, and then everyone goes back to doing exactly what they were doing before, which is hiring people to untangle systems that should never have gotten that tangled in the first place.
I want to say something that is going to make a lot of people uncomfortable. Most of what we call the skills shortage is not a skills shortage at all. It is a complexity problem wearing a disguise.
Let me back up and tell you what I actually see when I walk into enterprises these days. I do not see a shortage of talented people.
I see an absurd surplus of accidental architecture. I see twenty years of applications bolted onto applications, of data replicated into a dozen inconsistent copies, of security models layered on top of security models until nobody can say with any confidence who has access to what. I see a cloud migration that was supposed to simplify everything, but instead produced 500 microservices, 40 of which do the same thing as the others, none of which anyone fully understands end-to-end.
And then I hear the same lament. We cannot find anyone who knows our systems.
Of course you can’t.
You could not hire the person who built this because the person who built this retired, or left for a startup, or simply stopped answering questions about the three stored procedures that only they understood.
The problem was never that there is no talent in the world. The problem is that you built something that only a handful of people on the planet could possibly maintain, and then you expected the hiring market to magically produce more of those people on demand.
I have spent my career on both sides of this table. I have been the architect trying to simplify systems so that ordinary, competent engineers can work on them without a year of tribal knowledge. And I have been the consultant called in precisely because a system had become so complicated that the organization had essentially outsourced its own memory to a few irreplaceable individuals.
You are buying complexity, and you are paying for it later in the form of hiring pain.
What I have learned is that there is a direct and uncomfortable tradeoff, and almost nobody wants to talk about it. Every time you defer a refactor, every time you accept that one more workaround is fine for now, every time you choose a new tool instead of fixing the old one, you are not saving money. You are buying complexity, and you are paying for it later in the form of hiring pain.
Here is the part that genuinely frustrates me. The industry has decided, almost unanimously, that the answer to the skills shortage is to train more people: certifications, bootcamps, upskilling programs, apprenticeships.
I am not against any of these things. We should absolutely invest in people, and I have spent enormous energy trying to bring people up in this field. But if you train ten thousand new engineers and then drop them into systems that require nine years of accumulated arcana just to change a field in production, you have not solved anything. You have just made the onboarding queue longer.
The answer is not to create people who tolerate complexity. The answer is to remove the complexity so that ordinary people can do the work. And I say ordinary with great respect, because that is what most of us are.
Give a smart, motivated engineer a clean, well-bounded system with clear interfaces and honest documentation, and they will be productive in weeks. Give that same engineer a spaghetti architecture that has accreted for two decades, and they will flounder for a year, and then you will call them a bad hire when the real problem was the system they inherited.
I have seen this exact dynamic enough times I can predict it.
An enterprise will spend millions trying to hire a unicorn, someone who knows their mainframe and their microservices and their legacy ETL and their three different cloud providers, as if that person exists and is sitting idle waiting for a phone call. They will pass over perfectly good candidates because the candidate does not know some framework that only matters because the system was built so badly in the first place.
The hard truth is that the fix is mostly internal, and mostly architectural, and mostly unglamorous.
Then they will declare a skills shortage and ask the government to fix it or the vendors or anyone but themselves. The hard truth is that the fix is mostly internal, and mostly architectural, and mostly unglamorous.
Let me give you a concrete example from my own experience. I walked into a financial services firm that had what they described as a catastrophic inability to hire cloud engineers. Every conversation with a recruiter ended the same way: nobody qualified, nobody available.
When I actually looked under the hood, I found that their move to the cloud had been done in a way that preserved every legacy dependency. Their new cloud applications could not run without a connection back to a 30-year-old back-office system whose documentation existed only in the head of one engineer nearing retirement.
The shortage they were experiencing was not a shortage of cloud engineers. It was a shortage of people willing to spend five years learning a system that should have been retired a decade ago.
Once we committed to the unglamorous work — documenting the dependencies, abstracting the legacy system behind a clean interface, retiring what could be retired — the hiring problem mostly evaporated. All of a sudden, plenty of qualified engineers were available.
Not because the market changed. The market did not change. The system changed, and with it, the actual skill required to work on it dropped to something a normal, talented person could realistically acquire.
I do not want to be misread here. Real skills gaps exist in this industry, and some are genuinely hard to fill.
Security expertise, for instance, is not something you fake, and the demand for people who genuinely understand adversarial thinking is real and growing. Data engineering talent is scarce, and good architects are worth their weight in gold because so much run-of-the-mill work has been mediocre.
I am not arguing that the shortage is entirely fiction. I am arguing that a large portion of it, the portion everyone complains about loudly, is self-inflicted.
Before you tell me there is a skills shortage, show me your system. Show me your dependency graph.
So here is what I tell the executives who ask me about this, and I will tell you the same thing. Before you tell me there is a skills shortage, show me your system. Show me your dependency graph. Show me how long your onboarding takes. Show me how many of your production applications require knowledge that is not written down anywhere.
If the answer to any of that is alarming, and it almost always is, then you do not have a skills problem. You have a complexity problem, and the good news is that a complexity problem is something you can actually fix. It just requires doing the hard, boring, expensive work that nobody wants to do, instead of hiring your way around it.
The companies that win in this environment will not be the ones that hire the most people. They will be the ones whose systems are simple enough to be run by the people they can actually find. That is the whole game. Everything else is just a very convincing distraction.
Five checks before declaring an IT skills shortage
Before blaming the hiring market, CIOs should examine whether their own systems are making otherwise qualified people difficult to hire or onboard.
- Map the dependencies. Identify connections among cloud applications, legacy systems and back-office technology that require specialized knowledge.
- Find the undocumented knowledge. Determine which production systems depend on expertise held by only one or two employees.
- Examine onboarding time. Measure how long capable new hires need to understand the environment and become productive.
- Identify what can be simplified. Document dependencies, refactor unnecessarily complicated components, establish cleaner interfaces and retire systems where possible.
- Reconsider hiring requirements. Ask whether exceptionally specialized skills are truly necessary or are compensating for avoidable architectural complexity.
David Linthicum is a globally recognized thought leader, innovator and influencer in AI, cloud computing and cybersecurity. He has more than 30 years of experience in enterprise technology and, until early 2024, served as managing director and chief cloud strategy officer at Deloitte Consulting LLP.
