To effectively integrate a data team into a biotech organization, you need to simultaneously build the technical infrastructure that will allow them to work and the organizational infrastructure that will allow them to collaborate. But you can’t do this all at once: You need to slowly but surely nudge things in the right direction with a series of changes. In this post, I want to explore what those changes should look like to get you to your goal as fast as possible.
If this idea resonates with your own experience, please let me know in the comments below. Also consider signing up for my weekly newsletter where I send out short ideas to get you thinking about this in your day-to-day, and announce upcoming blog posts that will go deeper into this topic.
Process vs Tooling
If, like me, you come from the data or software world, you probably think about change in terms of technical tooling: Software, Models, Libraries, Pipelines. But the ability of a data team to meet its goals within a biotech organization is determined just as much, or more, by the non-technical components around this tooling: communication channels between individuals and teams, conventions for making decisions, informal processes for recurring tasks, and intangible things like (shared) mental models. I’m going to call these things Process, to distinguish them from the technical Tooling made up of software, hardware and data.
The pain that people feel in an organization can come from bad Process, bad Tooling, or a mix of the two. But there are big differences between them. Pain from bad Tooling tends to be at the level of annoyance. Things take longer. There are more errors. People roll their eyes more. Pain from bad Process can be anything from annoyance to fundamental crisis that causes burnout or worse. People rarely leave an organization because of bad Tooling.
Components of Process also tend to have a wider scope than individual components of Tooling. A piece of software will typically support an individual team or a process. But communication channels will determine how that software can or can’t interact with everything else. So when it comes to changing things, even tightly coupled technical systems are much more modular than pretty much anything you’ll find in the world of Process.
Not someone else’s problem
You probably think your expertise is on Tooling, not Process. In fact, you probably think you were hired to fix the Tooling, not the Process. Your organization may think that too. But that misses a big, important point: The Process that supports a data/software organization is very different from the Process that supports a traditional biotech organization, and both of those are different from the Process that supports a Tech Biotech.
There are probably a number of people in your organization whose primary responsibility is to get the Process right. But very few people have worked in Tech Biotech before, so chances are none of them know what that right Process looks like. You may not either, but you at least have a better understanding of what it looks like for your data team. If you let someone else solve the problem, you’re not going to like the solution.
The Minimum Viable Change
Since you probably don’t know what the best Process for your Tech Biotech organization looks like, you’ll need to iterate on it the same way that you iterate on the Tooling. In fact, you’ll need to iterate on both in parallel since each relies on the other.
However, making a change to Process is a very different type of project than making a change to Tooling. It involves a lot of communicating, reminding, nudging and assisting. If you’re good at multitasking and context switching, you might be able to drive changes to both Process and Tooling at once. But you’re not. (No one is.) So to change both Process and Tooling in parallel without changing both at the same time, you need to alternate between small changes that focus on one or the other.
Each small change to Process should enable the next change to Tooling and vice versa. In analogy with a Minimum Viable Product (MVP), we’ll call each of these changes to Process or Tooling a Minimum Viable Change (MVC). While an MVP is meant to be the first step to improving Tooling, an MVC can address either (or both) and can also be used for later steps. Each MVC needs to be small enough that it’s feasible, and in particular it should focus on either Process or Tooling. But it also needs to be large enough to make a difference that enables the next MVC.
If you’re implementing a new system for collecting sample metadata, don’t spend months developing the software before you start training users. Instead, look for ways to adjust the existing system to follow the workflow of the new system, replacing technical components in the places where the new Process begins to match up with the new Tooling.
If you’re rolling out a new type of analysis, don’t build the automated, production-grade pipeline before you show the results to the wet lab. Push them to incorporate the earliest exploratory results into their own experimental workflows so they can begin adjusting their process as you’re working on scaling it.
Organizational Debt
The problem with MVCs that focus on Tooling is that making them minimal often means starting with a prototype rather than a production system. And the problem with a prototype is that if it’s successful, you throw it away. It can be hard to justify putting a lot of effort into a proof-of-concept project that you’ll just have to redo for the production version.
To understand the trade-offs between prototype and production, it’s useful to think about organizational debt, analogous to what software engineers call technical debt. If the Process isn’t right for an organization’s goals, the short-term fixes that are needed to address immediate needs often just make things worse. This is interest on the organizational debt, and it needs to get paid off eventually.
In the same way that mortgage payments are split between the interest and the principle on a loan, the effort of an MVC needs to be split between immediate needs (interest) and the infrastructure that will address future needs (principle). In particular, an MVC should do some mix of three things:
- Address an immediate, high-priority problem.
- Create a model or template for how a long-term solution could look.
- Contribute to building that long-term solution.
The first one is the current interest. The second is past-due interest. The third is the capital. And just like with a mortgage, you should start out paying mostly interest and a little capital. But as you begin paying down the capital, you’ll have less interest to pay down, so your changes can focus more and more on the long-term solution.
In other words, that prototype isn’t wasted work that will be thrown away. It’s a payment on the principle of organizational debt (though not technical debt) that lowers your future interest payments by preparing the Process for the production system.
Address an Immediate Need
Often, you can’t build the infrastructure that will show the lab teams how awesome your plan is unless they do some work up front to help you build it. Maybe they need to run their experiments a bit differently. Maybe they need to learn a new system for reviewing analysis results. Maybe they just need to try a prototype and give you feedback. But the only way to convince them to do that work, is to show them how that work will lead to a payoff. So how do you show them how great the thing is when you can’t build the thing until you’ve shown them?
One common strategy is to try to build it without them. Design an end-to-end solution that enables a completely new approach. Put your head down. Work as hard as you can. Hope you have something to show before people start asking questions. Not surprisingly, this often doesn’t work out so well.
A better approach is an MVP/MVC: take the smallest possible step that solves an immediate problem in a way that’s closer to how you want things to be than they are now. Make it small enough that the solution is ready when your stakeholder needs it.
It doesn’t matter if it involves manual steps that you could easily automate if you had another couple weeks. It’s fine if you end up throwing away most or all of the code. Don’t worry if it isn’t as perfect as you want it to be. Paying the interest is the most miserable part of a mortgage, but people still do it and this is no different.
Each MVC is a new anchor that helps your organization create a shared mental model that’s better aligned with what you need. When your stakeholders see you solving a problem that they need solved today, they’ll be more likely to come to you with their next problem tomorrow. They’ll be more willing to do the work you need from them. They’ll tell you sooner, giving you more time to build the solution the right way. Next time, you can build something closer to the big vision. You can throw away less code.
Conclusion
Implementing Minimum Viable Changes isn’t easy. It takes discipline to recognize when a plan that looks good on paper isn’t granular enough. It takes creativity to break up monolithic changes. It takes patience to take baby steps towards a vision you know will revolutionize your organization once they’re ready for it. But as you get through the first few MVCs, you’ll start to build momentum. A few more and your team will start to feel it. So will your stakeholders. This approach may not be easy, but it’s absolutely worth it.
Scaling Biotech 