Bad software is a symptom, not a cause

When I started working in biotech, my plan was to design software that would allow my organization to work more efficiently and accelerate discovery. I quickly learned that "build it and they will come" may apply to baseball fields, but not to enterprise software.

It turns out there's already plenty of better software options out there, and plenty of people working on even better ones. The problem is that the teams that would most benefit often aren't looking for a better solution and wouldn't like it they found one.

So what's going on?

If software doesn’t conform to the way a team works, the team will find another option that does. Usually that option is Excel, because Excel is designed to conform to any conceivable workflow. But even if it's something else, most of the things you find most frustrating are probably features, not bugs.

Lousy software results from lousy processes, not vice versa. Fixing the software won’t fix the process. But if you can fix the process, you’ll have the opportunity to introduce better software.

As I argued in my last blog post, bad processes are usually the result of inaccurate or outdated shared mental models. Until you fix that, no software is going to save you.