You know that sinking feeling when your team just repeated the exact mistake that cost your company $2 million last year? The one buried in a dusty email chain nobody reads? That’s not bad luck. It’s a broken system. And the worst part? Your ‘fail fast’ culture is the reason it keeps happening.
I’ve spent hours inside NASA’s Lessons Learned Information System (LLIS). It’s not a dashboard. It’s a graveyard of every engineering failure, every near-miss, every ‘we should have known better’ moment since the 1960s. And it’s searchable. Unlike your company’s collection of buried post-mortems, NASA actually uses this database.
The greatest innovation isn’t a new rocket. It’s a database that remembers what you tried not to forget.
Here’s the paradox: individuals are incentivized to hide their mistakes to protect their careers. But the organization must share them to protect the mission. Most companies pretend they solve this contradiction by chanting ‘fail fast’ while actively destroying the documentation of those failures. They celebrate the idea of learning, but they never build the infrastructure for it.
NASA’s LLIS is that infrastructure. Every engineer, every project manager, every intern can search it before starting something new. They ask: ‘Has anyone else tried this and died?’ And the database answers. No ego. No politics. Just a cold, hard record of what went wrong and why.
You think you want to fail fast. You actually want to fail forever — but only if you learn from it.
You’ve probably noticed that the same problems keep popping up in your meetings. The same integration bugs. The same supplier delays. The same miscommunication between teams. That’s not a people problem. That’s a memory problem. You don’t have a system that holds the lessons so humans don’t have to.
I’m going to tell you something uncomfortable: your company’s ‘fail fast’ culture is actively destroying the very thing that could save it. By treating each failure as a discrete event to be quickly forgotten, you’re guaranteeing that the next team will make the same mistake. And the next. And the next.
NASA’s system isn’t perfect. It’s clunky. It requires discipline. But it’s been running for decades because it works. The Apollo 13 disaster? They had a lesson from an earlier test that saved lives. The Challenger explosion? The database had warnings about O-ring failures — but they weren’t heeded because the system wasn’t mandatory. NASA learned that lesson too. Today, LLIS is a mandatory check before any major decision.
A database of pain is worth more than a library of success stories.
So what can you do? Start small. Pick one recurring failure your team keeps repeating. Document it — not as a blame session, but as a technical note. Share it. Make it searchable. Next time someone starts a similar project, force them to check that note. Build a culture where asking ‘what have we already learned?’ is not a sign of weakness, but a sign of wisdom.
Your company doesn’t need to fail faster. It needs to remember better. Start building your own LLIS. Or keep paying for the same lesson over and over.
FAQ
Q: What's the downside of a centralized failure database?
A: If not designed carefully, it can become a blame tool that discourages reporting. NASA's system works because it's anonymous, non-punitive, and mandatory for decision-making. The key is to focus on technical causes, not people.
Q: What's the practical first step for building this in my company?
A: Pick one recurring failure. Document it in a single shared document with a clear searchable tag. Make it a rule that before any similar project starts, the team must read that document. Then build from there. Even a simple spreadsheet is better than nothing.
Q: Doesn't documenting failures make people afraid to take risks?
A: The opposite. When you know what went wrong historically, you can take calculated risks instead of blind ones. NASA's system gave engineers the confidence to innovate because they knew what boundaries not to cross. It's a safety net, not a straitjacket.