Sometimes, you need to build one to throw away.
Those of you who were reading this newsletter back in March (before it was cool?) may recall that I announced I was starting an independent consulting firm called Merelogic to help early stage biotech startups get their data under control. Since then, I’ve been thinking about how to describe my approach, and how it’s different from less effective approaches that I’ve used in the past and seen others use. I recently wrote this up on my Merelogic site, but I wanted to share it here too. (So yes, this is kind of an ad.)
Startups in general, and biotech startups in particular, are in a constant state of trying to build the train tracks ahead of the speeding train. So they feel an urgent need to quickly build data infrastructure that will accelerate what they’re doing while simultaneously cleaning up the mess they’re making along the tracks.
This urgency often pushes them into one of two failure modes:
They rush to build an all-inclusive, broadly scoped system that will make all their problems go away, but it’s so complex that by the time they get to something that’s usable (if they ever get there) the problems have changed and it’s no longer relevant.
The idea of building such a system is so overwhelming that they never start, and end up stumbling into an arbitrary set of processes and tools that don’t really work.
Failure Mode 1 ends up leading teams unintentionally into a strategy that’s sometimes called “Build one to throw away.” The idea is that it’s very difficult to figure out what the technical requirements of your data infrastructure are in abstract. If you ask the team what they need, they’ll tell you what they think they need, which is almost never what they actually need. On the other hand, if you give them a system that almost but not quite works they will be able to tell you exactly why it doesn’t work. You can usually translate this into a much more detailed and accurate assessment of what they need. So you end up throwing away the first system and building a better one.
When you go about things this way, you end up wasting huge amounts of time and money building that first system. Plus you generate resentment and frustration from the team that’s trying to use it. But the problem isn’t actually the “build one to throw away” strategy. It’s the fact that you blindly stumbled into it, investing resources as if you were building a long term solution, and setting those expectations with the team and with leadership.
In other words, “build one to throw away” can actually be an effective strategy if you do it deliberately: Build something light-weight that you can spin up quickly on the cheap, that’s flexible enough to iterate quickly. Set expectations that you will replace it with something that scales better and is easier to use. Then gather data about what the organization really needs so you can deliberately design the next one. This also helps fix Failure Mode 2, since it drastically lowers the cost of getting started.
This is how I approach projects with Merelogic, and I’m actively building tools and techniques that enable this approach for early stage biotech startups. If you want to discuss how this might apply to the problems you’re facing today, send me an email at jesse@merelogic.net.
Next week we’ll be back to our regularly scheduled programming, with more on metadata.