One of the nice things about working in a tech company is that project goals tend to be pretty straightforward. You want your software or hardware to work according to its requirements. To pass its unit and integration tests. You want users to adopt it. You want to solve a neatly scoped technical problem in a context where you have effectively complete control.
In a biotech organization, the neatly defined scope that made those tech company problems straightforward goes straight out the window. Your analysis pipeline only works if the bench scientists follow consistent data collection processes. You can only validate your model if you can convince one of the scientists to run the validation experiment. To make sure your app solves a real problem, you need someone in the lab to explain what their problems are.
To work effectively in this context, it’s not enough to focus on your immediate technical problems. You need to drive changes in other teams as well - how they plan experiments, collect data, and even how they fundamentally conceptualize their work. This is a very different kind of work from what you’re probably used to. In many ways it’s harder. And it’s often one of the biggest sources of frustration.
The biggest hurdle is usually to nail down what change you’re actually looking for. These are nebulous problems that require complex and often subtle solutions. The best place to start is to turn it into something more concrete by defining exactly what a solution looks like. How would you know that the problem is solved? Maybe it’s that the data from every experiment meeting certain criteria from a certain list of lab teams is made available in a particular form. Maybe it’s that a particular set of experiments are run. Maybe it’s that a particular lab team no longer spends a third of their time wrangling excel templates.
Whatever the outcome, the clearer you can “see” it, the easier it will be to identify who needs to be involved in the change, what they need to agree to, and what they need to do.
I’ll be writing more on this in my next few newsletter posts, and in my blog post in three weeks.