Stop missing the bus
*** A quick note/ad: I've noticed that many of the software companies who are trying to make Biotech more data driven struggle to communicate what they do to the users who need them the most. So I've started offering services to fill this gap. If you're one of these software companies, send me an email at jesse@merelogic.net to learn more. ***
It’s week three of my series on problems that come up at specific points in the evolution of a biotech data team, and this week I want to focus on something that can happen when you’re trying to introduce new tools or capabilities. Particularly tools or capabilities that require coordination with other teams. And by other teams, of course, I mean wet lab teams.
Many of you who read this newsletter have probably experienced this: After some time trying to understand what your bench scientist colleagues do and how they work, you start to notice ways that you could help them - tools that could make their work in the lab easier, better models to analyze their data, you name it.
So you start putting together a proof-of-concept, or maybe even a full-fledged solution. Writing code. Trying out off-the-shelf software. Of course, you keep the bench teams in the loop, explaining how it will work and how it will help them. They seem cautiously optimistic, sometimes bordering on skeptical, but overall encouraging and open to trying it. Finally, you get something ready. You give the bench team a demo. They seem excited to try it out.
And then nothing.
The problem is that the next few experiments are already underway - it’s too late and too urgent to make the changes that the new approach requires. Maybe the next one? But of course, by the time you hear about the next one, it’s too far along as well. And this can go on indefinitely.
The cadence of a biotech lab is very different from software engineering, data science, or pretty much anything else. To an outsider, each experiment feels like a snowball rolling down a mountain - It starts small and unnoticeable as informal conversations between bench scientists. By the time it’s grown in size and picked up speed to the point that you notice it, the momentum has turned it into an unstoppable force.
But while that analogy is good at capturing the feeling, there’s another analogy that I think is better for understanding the solution. And, in fact, I wrote about it a little over a year ago as one of the Reciprocal Development Principles. (Number 12 to be exact.)
Catching an experiment in time for the bench team to try out your new approach is like catching a bus. If you start walking to the bus stop when the bus is already there, it will have left by the time you arrive. If you then walk towards the next stop that the bus is heading towards, you’ll miss it there by even more. But more importantly, you’ll miss the bus behind it when it eventually comes to that first stop. And that’s why people who take busses don’t catch them like that: They look at the bus schedule and plan to get to the stop before the bus.
Of course, this is where the analogy starts to break down: Bench teams generally don’t keep a centralized schedule of all upcoming experiments. That’s the whole point of the snowball analogy.
So, given that there’s no schedule, how do you catch that bus (that’s also a snowball)?
In my experience, the best approach is a subtle shift: Instead of asking “Can you use this in the next experiment?” it’s much more effective to ask “What’s the next experiment we can try this with?” In other words, what’s the next bus that we can beat to the bus stop?
You may have to ask this question more than once. In fact, you’ll probably have to ask it over and over again. But the point is that it puts the burden on the bench team to think about which experiments that are currently just small unnoticeable snowballs will be best suited to try something new. Low stakes. Not too urgent. Otherwise boring.
Of course, this all assumes that the change you’re making is something that they actually want. It’s possible that their cautious optimism bordering on skeptical was actually just polite skepticism. It’s possible that the difficulty in finding a suitable experiment was a non-confrontational way to stall until you got distracted with something else. And this new question is a great way to get past the polite avoidance: If they can’t commit to an upcoming experiment, you can push them to have an honest conversation about why.
This is one reason that I always start asking about the next appropriate experiment as early as possible - long before your new tools are ready to use. In fact, the best time to start asking the question is before you write your first line of code. If you know the target experiment, you can often trim down your MVP even smaller. And, of course, if you can’t figure out that first experiment, you can have that conversation about what the bench team really wants before you write that first line of code.