The CEO's Tech Literacy Problem Isn't What You Think
A few years ago, a large retail brand I worked with decided they were going to build their own customer data platform. Hand-built by an in-house team. Managed by an in-house team. Proprietary insights that would live on forever and give them a competitive advantage no vendor could match. The pitch was clean. The CEO bought it.
Multiple years and a hyperscaler environment later, the tool was technically ready. By then, half the people who built it had left. The data inside was so vast that nobody could actually use it efficiently. The team responsible for managing it kept making interpretation mistakes when they tried to give the business a clear view. The front office teams who actually needed the data couldn’t get to it. They had to file requests with the data team and wait weeks. The numbers that came back were often wrong, and worse, they were inconsistent. The same question asked by two different teams produced two different answers. Nobody could agree on which version was right or where it came from.
Eventually the business broke. Speed and accuracy mattered more than the dream of proprietary anything. They went and bought a best-in-class third-party tool. But, even the buying decision turned into a fight with real political casualties. IT wanted an upstart product they could extend and customize. The business wanted a leading off-the-shelf platform that just worked. The business won. Years of personalized customer engagement lost. Millions spent on the build, millions more on maintenance, millions in lost revenue, then a big check to the vendor at the end of it.
Did the company learn? No. They’re still building custom apps and tools that almost nobody uses, because being perceived as a tech company matters more internally than the fact that they’re a mass retailer.
This pattern is everywhere. I have watched some version of it play out at most of the large enterprises I have spent time inside. And the lesson most people draw from it is the wrong one. The lesson is not that the CEO needed to be more tech-literate. The lesson is that the CEO did not have a single tech-literate peer in the room when the decision got made.
That distinction matters.
When a CEO greenlights the capex for a multi-year custom build, they are almost never approving it on the technical merits. They cannot, because they do not have the depth. What they are doing is choosing to trust the framing of the person who brought them the recommendation. And the person who brought them the recommendation is almost always a senior tech leader whose career, team size, budget, and internal status all depend on the answer being build rather than buy. That is not a moral failing. It is the org chart working exactly as designed. The CIO or CTO is incentivized to make their domain look essential, complex, and worth defending. They are rational people responding to the incentives in front of them. The problem is that the CEO is hearing from one rational actor with one set of incentives, and there is no other tech-literate voice in the room with different ones.
This is what real tech illiteracy looks like at the top of large enterprises. It is not the CEO being unable to read a system architecture diagram. It is the CEO not having access to a tech-literate person whose interests are aligned with the company’s instead of with the tech function’s.
The way this shows up in the room is subtle. The senior tech leader is not lying. They are presenting build versus buy as a clean binary when it is actually a spectrum. They are calling something a strategic differentiator when it is actually table stakes that every competitor is also building. They are framing the question in a way that points to one answer. The CEO is not really being given a choice. They are being given a framed decision, and the framing came from the person whose job depends on the framing.
By the time the build fails, the original decision is unkillable. The team that built the thing has institutional knowledge nobody else has. Killing the project means admitting the original call was wrong, and the people who would have to admit it are the same people whose status depends on it succeeding. So nobody kills it. They pour more money in. They keep promising it is almost there. Eventually the business gets impatient and goes and buys the vendor solution anyway, which now runs alongside the custom thing rather than instead of it. The company is paying for both. The CEO has not made a clean decision. They have accumulated a mess.
The structural fix is not to make the CEO more technical. That is not going to happen, and frankly it should not. The CEO’s job is not to understand data pipeline architecture. The fix is for the CEO to have a tech-literate peer whose career does not depend on the tech function looking essential. That person can sit in the room when the recommendation gets framed and ask the questions the CIO will not. What would a company with no legacy tech do here? Who outside this company would you call to pressure-test this? If we walked away from this build in twelve months, what would actually break? What does the buy option look like at one third the cost and one tenth the timeline, even if you do not love it? These are not gotcha questions. They are the questions that surface whether the recommendation is shaped by the company’s interests or by the recommender’s.
Most CEOs do not have anyone in the room asking these questions. Their board is not deep enough on tech to do it. Their other functional leaders are not in a position to challenge their peer’s domain. Their consultants are not going to do it because their next engagement depends on the relationship with the same tech leader. So the framing goes unchallenged, the decision gets made, and three years later everyone wonders how it happened.
If you are a CEO reading this, the question worth sitting with is who in your organization is actually telling you the truth about your tech function. Not who is loyal, not who is competent. Who has nothing to lose by being right. If you cannot name that person, you do not have one. And the next big build sitting on your desk is being framed by someone whose interests are not the same as yours.
This is the most expensive problem at the top of large enterprises that nobody talks about. Not because it is hidden. Because the people in the best position to talk about it are exactly the people the system trains not to.
And it is about to get worse. Much worse.
The arrival of AI-assisted code generation has done something dangerous to the build-versus-buy conversation inside large enterprises. The senior tech leader who, six months ago, would have had to justify why a 30-person team and a three-year timeline made sense, can now make the same pitch with the timeline cut in half and the headcount cut by two thirds. The economics of building have genuinely changed. That part is real. What has not changed is the underlying dynamic that produces bad decisions. If anything, AI has made the pitch easier to sell, because the friction that used to slow down bad build decisions, the cost and the timeline, has been partially removed.
You are about to see a wave of internal build initiatives across the Fortune 1000 that would not have been approved two years ago. Custom AI agents. Proprietary copilots. Internal LLM applications. Hand-built tooling that vendors are already shipping in shrink-wrap. The pitch will sound compelling because the build cost looks lower than it used to. And in some cases, the build will actually make sense. But in many, probably most, the decision will be framed by the same person with the same incentives, and the same structural problem will produce the same outcome three years from now, except this time the company will have spent the years that mattered building instead of deploying.
The SaaS backlash is real and some of it is earned. Vendor lock-in is a real cost. Per-seat pricing at scale is sometimes irrational. The case for owning more of your stack is stronger than it was. But the response to a real problem has become a license for a bigger version of the old mistake. And ultimately, a much larger potential mess. The CEO who hears “we should build more of this ourselves now that AI makes it possible” is hearing a pitch that is partly true and partly the same pitch they heard ten years ago, just dressed in new clothes.
The question that matters has not changed. Who in the room has nothing to lose by being right about whether this build is real or whether it is the tech function defending its own relevance in a market where vendors are getting dangerously good? If you cannot name that person, the next thing you build just may cost you the next three years...three of the most pivotal years we may see for another several decades to come.
No Limits,
Bennett