Leading Biotech Data Teams

Introduction

When I joined my first biotech startup as head of software engineering, after years in the tech world, I thought my job was to build an internal software platform so intuitive and powerful that it would revolutionize how the bench and data teams worked, both individually and together. But after months of working to build this vision, I realized I would first need to solve a bigger problem: how the organization fundamentally thought about experiments, predictions, and data. And a technology solution alone, no matter how brilliant, wasn’t going to solve it.

Today’s biotech organizations are increasingly adopting research programs that rely heavily on data. They sometimes call themselves tech biotechs or just techbio startups, but large pharmaceutical companies and everyone in between is joining in too. I’ll use the term “data teams” to mean both the teams tasked with driving these new capabilities, whether they call it bioinformatics and computational biology or machine learning and data science, as well as the data and software engineering teams building the tools that make it all possible. This doesn’t include explicitly service-oriented teams such as traditional IT that aren’t expected to play a driving role.

Note

While the term “development” often has a very specific meaning in the context of biotech, referring to drug development or the second half of the R&D stage (the “D”), the term here is used more broadly to refer to the development of technical tools and resources such as analyses, pipelines, and analytical tools.

Like me when I joined my first biotech startup, the members of these data teams are used to solving problems by writing code, whether it’s machine learning (ML) models, data pipelines, or digital tools for themselves and their colleagues. And like I did, they all eventually run into the same realization that their biggest problems won’t be solved by any amount of code.

This has become a kind of mantra for me: Bad software is a symptom, not a cause. In other words, if your organization has a problem that seems to be technical, often in the form of slow, confusing, inaccurate, inadequate, and generally bad software, this is usually a symptom of some deeper underlying problem. It’s processes and mindsets and all those fuzzy things that turn out to be much harder to fix. In particular, if you try to fix them with a technical solution, your users will just resist or keep using the lousy old tools that support their familiar ways of thinking and working.

Who This Report Is For

This report is for leaders of data teams working on early-stage biotech research who are ready to take on the challenge of helping their data teams, their bench scientists, and everyone in between work more effectively with data and digital tools.

Maybe you entered biotech from a tech background. Or maybe you became a data expert starting from a background in biology or chemistry. Either way, you were hired for this role because you understand the “tech” side of biotech. You know how to write code, build predictive models, and turn data into insights. You understand digital technology better than anyone in your organization. But the most important thing you know is how organizations can use data effectively. I want to teach you how to apply that knowledge.

In the pages that follow I focus on early-stage biotech research where there is the most flexibility to explore. Solving these problems in more highly regulated contexts requires a very different set of tools that I won’t cover here. I will also focus on drug development startups because that’s what I know. This approach may be effective for other types of biotech research organizations, but you’ll have to decide that for yourself.

I don’t assume the reader is familiar with any particular technology, but I will use some biotech-specific terminology such as the distinction between a bench scientist and a data scientist. And most importantly, I’ll assume that you know what an organization that uses data effectively looks like and want to help make your own organization work that way too.

What You Will Learn

This report is not about technology or software or data. It’s about how organizations interact with these things, how they can be nudged to interact with them more effectively, and the role that data teams can and should play in doing the nudging. And because these data teams need to nudge their colleagues just as much as they support them, I call this new approach Reciprocal Development. In particular, I present what I call the Reciprocal Development Principles, modeled on the Agile Manifesto but tailored to the context of data teams in biotech organizations. The goal of these principles is to reframe the way you think about your role, your team’s role, and the tools at your disposal to fulfill that role.

After reading this report, you will begin to see the underlying process and organizational issues whose symptoms look like technology problems. You will begin to recognize how addressing these underlying causes will help you solve your technology problems. And the Reciprocal Development Principles will give you a toolbox to nudge your larger organization in the right direction.

A Need for Specificity

As a leader of a data team in a biotech organization, it isn’t enough to build technical tools and systems that will support your organization. You need to build an organization that can use those systems to become more than the sum of its parts. The Reciprocal Development Principles will help you do this. But before I introduce them, it’s important to understand why you can’t just directly apply the Agile principles.

While the Agile Manifesto is now used in a wide range of contexts, some even beyond software development, the original authors wrote it to address a relatively narrow context—software teams writing applications for external clients—and in response to a specific approach that was hindering them—the process-heavy, classical engineering approach to software development that is often called the Waterfall method. Many of the ideas in the Agile principles, such as favoring individual communication over process, are more broadly applicable and have been applied in a variety of settings. Others are more specific to the original context, such as measuring progress by working software.

Because of this specificity, the Agile Manifesto and the various tools and methodologies it has inspired have been the driving force in making modern software development teams more efficient and effective. To be effective in other contexts such as biotech, however, it’s necessary to make changes to get back the specificity. That’s what we’re going to do here.

Each of the chapters that follows presents four of the Reciprocal Development Principles centered around a common theme, with the first two chapters building a solid foundation that enables more concrete practices in the third. The first chapter, “Defining Objectives,” explores how to broaden the way your team views their work, shifting from purely technical objectives to organizational-level scientific objectives. The second chapter, “Building Collaborations,” encourages your team to focus more of their energy on collaboration with partner teams, rather than guarding their time for technical work. The third chapter, “Deploying Tooling,” explains how to build an effective development cycle by coordinating your team’s work with the cadence of experiments and lab work.

Each of these chapters introduces the general theme, discusses each of the principles, then concludes with more specific suggestions for how to implement them. This is not a methodology like Scrum or Kanban with specific practices and rituals. You can follow the Reciprocal Development Principles using sprints or scrums or any other tools that fit your team’s preferences. The important part is that you use the principles to change how your team thinks about their work and their role within the larger organization.

Let’s take a look at them now.

The Reciprocal Development Principles

This report is organized around the following 12 principles, with each chapter covering four principles defining a common theme.

Defining Objectives

1. Your highest priority is to drive progress towards your organization’s scientific objectives.

2. Design projects around deliberate scientific objectives coordinated with the overall organization.

3. The primary measure of progress is data-driven scientific discovery.

4. The simplest technical solution that will reliably meet scientific objectives should be chosen over complex or novel approaches with marginal improvements.

Building Collaboration

5. The most effective form of communication across functions and specialties is direct communications between individuals in each team.

6. Collaboration across teams is more important than technical excellence within any one team.

7. The key to successful collaboration is empathy for team members with different perspectives, priorities, and responsibilities.

8. Delegating decisions and accountability as far down as you can is the only way to continuously adapt to an unknown and changing environment.

Deploying Tooling

9. Information should be captured in a FAIR system as early as possible and anything derived from it should remain in a FAIR system.

10. Technical tools can only be effective when deployed in the context of good processes and communication patterns.

11. Evolve processes and tools incrementally, in parallel, based on continuous feedback, rather than introducing major changes all at once.

12. Development timelines should be deliberately coordinated with experiments to maximize opportunities for feedback.

In the chapters that follow, you’ll learn how to begin using these principles to make your data team as effective and successful as you need them to be.