Part of The Ego Tax series — stories on how overconfidence and inexperience quietly bankrupt software projects.

Seventy percent of software projects fail or fall short. In the United States alone, the cost of software failure — projects abandoned, systems that don't work, money spent building the wrong thing — runs past two trillion dollars a year. That's not a typo, and it's not a fringe estimate. It's larger than the entire U.S. defense budget. Somewhere behind every one of those failures is a team of smart, credentialed people who were completely certain they were getting it right.

I've seen this up close, more than once, in different companies, on different projects. And I can tell you exactly what it looks like from the inside, because I've watched it happen in real time on a project that should never have gotten as far as it did.

The Setup

A large consulting firm had acquired a small startup — a workshop tool meant to let teams anonymously vote and collaborate. The acquisition itself cost real money. What followed was a multi-year investment worth tens of millions more, meant to turn a half-built idea into something that could compete with Microsoft Teams.

I came in about a year into this, hired into a leadership role. What I found wasn't a team executing a plan. It was a group of people who had never been handed something this consequential before, now in charge of tens of millions of dollars, discovering in real time — often in front of actual clients — that a title and a budget aren't the same thing as judgment.

What Ego Actually Costs, Line Item by Line Item

The product was missing a chat thread, image uploads, and video calling — while being pitched, out loud, to prospective clients as a real alternative to platforms that had shipped all three years earlier. I built several of the missing pieces myself, in a short stretch of time, because none of it was hard. It just hadn't occurred to anyone that it needed doing before the sales calls started.

Meanwhile, the product's help documentation had logged something like 50,000 visits. Actual users of the product: nowhere close to that. Nobody treated this as the five-alarm signal it was. What did get real attention, in meeting after meeting, was the exact placement of a button — championed by a project manager with an MBA who never once, in my hearing, asked why 50,000 people needed help using a tool almost nobody was using.

A procurement officer set up a vendor account on the free tier, using her own personal email instead of a company one, then went on vacation. The tool started cutting out mid-meeting after ninety minutes, and it took several days and several thousand dollars in engineering time to figure out why — because nobody had thought to ask basic questions like "whose account is this" before building a client-facing feature on top of it.

More than fifty offshore developers spread across Eastern Europe over-engineered nearly everything they touched, modified code without asking, and never developed a working understanding of the product. The contract was eventually canceled and an entirely new team stood up in the Philippines to start over — an extraordinarily expensive sentence to have to write about a workshop-voting tool.

Near the end, I brokered a deal with a major voice/communications vendor. Everyone assumed there was a serious budget behind it — six figures, easily, for a product that had already consumed tens of millions. The number that came back: $2,500. Total. The salespeople on the other end were audibly stunned. So was I. Nobody above me had been tracking it either.

A team capable of losing track of a $2,500 line item is the same team that burned through tens of millions without ever asking what 50,000 confused help-page visitors were trying to tell them.

This Is Not a Process Problem

None of what I've just described gets fixed by a better sprint cadence. It doesn't get fixed by more standups, a new certification, or a fresh coat of Agile paint. I want to be direct about this because it's the part most organizations get wrong: Scrum ceremonies don't correct for inexperienced leadership, and no framework was ever designed to counteract ego.

What actually happened here — and what I've now watched happen at more than one company — is a specific, recognizable failure of judgment: people promoted or hired past their actual experience level, propped up by enough capital that the consequences take two years to surface instead of two months, surrounded by others equally unwilling to say "I don't think we know what we're doing here." Narcissism doesn't always look like arrogance shouting in a meeting. Often it looks exactly like this: quiet, confident, well-funded, and completely unbothered by the data sitting right in front of it.

What Actually Fixes This

If your organization has ever watched a help page outperform its own product, or discovered a vendor account was set up on someone's personal email, or spent a planning meeting on button placement instead of the number that should have scared everyone — that's not a symptom of needing more process. It's a symptom of needing people in leadership who've been trained to recognize the difference between confidence and competence, and who have the technical grounding to ask the right question before the money's gone, not after.

That's a different kind of training than most organizations invest in. It's not a two-day certification that produces a badge for a LinkedIn profile. It's building real technical judgment in the people making million-dollar calls — the ability to look at a burn rate, a support-ticket volume, or a vendor contract and know, immediately, when something doesn't add up, regardless of how confident the person presenting it sounds.

Software will keep failing at roughly the rate it's failing now — 70% of the time, trillions of dollars a year — for exactly as long as organizations keep mistaking a senior title for senior judgment. That gap is trainable. Most companies just aren't training for it.