On August 1, 2012, Knight Capital deployed new trading software. Within 30 minutes, the firm lost $440 million. The stock dropped 75% in two days. The company never recovered.
The post-mortem didn't point to bad code. It pointed to management pressure creating unrealistic deadlines, which caused the team to push test code into production.
A leadership failure dressed up as a technical one.
And it happens every single day. Not at the $440 million scale. But in your standup. In your sprint planning. In the architecture decisions being made by people who haven't written a line of code in years.
The False Dichotomy
We love sorting problems into neat buckets. "People problem" goes to HR. "Technical problem" goes to Engineering. And the root cause sits in the gap between the two, grinning.
Andrew Graham-Yooll nailed this in his piece The False Dichotomy. He calls the separation of people problems from engineering problems "one of the most persistent and counterproductive myths in software engineering."
He gives the example of a database performance issue traced to indexing decisions made years earlier under different constraints. The fix wasn't technical. It was coordination. Understanding the stakeholder contexts and preventing future misalignments.
Here's the pattern I see over and over: engineers raise concerns. Leadership ignores them. The system fails. Leadership blames the engineers. New engineers are hired. The cycle repeats.
As the team at piechowski.io wrote: "Every time, leadership decides it's a people problem. So they reorganize, add process, sometimes let people go. Then the next team hits the same wall. Because it was never the people. It was the codebase."
One company they documented cycled through six engineering teams over ten years without solving the underlying code quality issue. Six teams. Ten years. The same problem. Leadership kept looking at the people instead of the system.
The Graveyard of "Technical" Failures
The history of technology is littered with projects killed by leadership, not by code.
The FBI's Virtual Case File burned through $379.8 million and 700,000 lines of code before being scrapped entirely. The root cause? Poorly defined requirements, an overly ambitious schedule, and 400+ change requests. Management failures, every one.
FoxMeyer Drug tried to implement an ERP system with an 18-month timeline decided by executives, not engineers. They assigned junior consultants instead of seniors. The new system processed 10,000 orders a night versus 420,000 on the old one. The company went bankrupt. A $500 million lawsuit followed.
The Airbus A380 racked up $6 billion in corrections and a two-year delay because dispersed global teams used incompatible CAD software. The parts designed by different divisions didn't fit during assembly. This wasn't an engineering failure. It was a communication failure between leadership silos.
And government tech? The Standish Group found government technology projects over $6 million succeed only 13% of the time. Not because governments hire bad engineers. Because governance structures make failure the path of least resistance.
Your Team Already Knows
Here's what leaders don't want to hear: your people already see the problems coming. They see them months before the deadline. They raise them in retros, in one-on-ones, in Slack messages flagged with yellow triangles.
DDI's Frontline Leader Project found 57% of employees have left a job specifically because of their manager. Not because of the tech stack, not because of the product, not because of the salary. Because of the boss.
A Perceptyx study showed 24% of employees currently work for the worst boss they've ever had. These employees are three times more likely to be disengaged and four times more likely to quit within 12 months.
My own research found 99.5% of survey respondents said they've had one or more types of bad bosses. Ninety-nine point five percent. The bad boss isn't the exception. It's the norm.
And 70% of frontline managers didn't expect to be promoted to leadership. They were thrown into the role because they were good at the previous one. Good engineers don't automatically become good leaders. We all know this. We promote them anyway.
It's Not a Tools Problem Either
The latest version of this mistake is the rush to adopt AI. MIT's 2025 "GenAI Divide" report, cited by CIO.com, found a 95% failure rate for enterprise generative AI pilot projects... those without measurable financial returns within six months.
Ninety-five percent.
Nick Kramer of SSA & Co. told CIO.com: "I have seen more projects fail because of poor change management than poor technology implementations."
A METR 2025 study found experienced developers were 19% slower when using AI coding tools. Not faster. Slower. Because typing was never the bottleneck. Understanding the system was. Understanding the people was.
Dan McKinley's classic essay "Choose Boring Technology" argued every business gets three "innovation tokens." Choosing shiny technology is a leadership decision disguised as a technical one. Most teams have already spent their tokens before breakfast.
What To Do About It
I'm not going to tell you to "communicate better" or "build a culture of trust." You've heard all of it. Here's what I'd do instead:
Stop promoting your best engineers into management without training. 70% of new managers didn't expect the role. Give them the skills before you give them the title. Stephanie Neal at DDI put it well: "We should stop using the term 'soft skills' to describe what are critical leadership skills."
When a project is late, ask "who decided the deadline?" before asking "who missed it?" In almost every case study above, the timeline was set by executives, not the people doing the work.
Listen to the engineers warning you. If three people on the team are raising the same concern, treat it like the fire alarm it is. Do not cover your ears.
Measure the real cost of leadership decisions. Knight Capital's $440 million loss started with a deadline decision. FoxMeyer's bankruptcy started with a timeline decision. The Airbus A380's $6 billion overrun started with an organizational decision.
The worst technical decision you'll make this year won't be about which database to pick, which framework to adopt, or whether to use AI. It will be about who decides, who listens, and who gets ignored.
And by the time you realize it was a leadership failure, you'll have already blamed the engineers.