Building Consensus in a Biotech Organization

Image by Niek Verlaan from Pixabay

In my last few posts, I’ve been exploring how differences in mental models can get in the way of integrating data teams into a biotech organization. It’s been a lot of doom and gloom. But it’s finally time to shift gears and start exploring solutions. So in this post, I want to describe an approach that I’ve found effective to get a diverse group of people onto the same page about a specific decision or plan that will address the sorts of problems I discussed in my posts on sharing data between the bench and data teams, and sharing insights from the data teams back to the lab. I’m going to use three examples below, though this approach can work on all sorts of issues:

Getting bench and data teams to agree on consistent standards and better tools for collecting and sharing lab data.
Defining machine learning projects that can help answer your lab teams’ key questions.
Adopting a collaboration model that ensures your data teams have input into experiment design and data collection.

This isn’t a series of steps, so much as a way of framing the task and a box of tools that you can apply depending on the circumstances. It’s also fairly time consuming and not necessarily what you want to be doing all the time. But if you can apply this to a few key decisions, you can plant the seeds for shared mental models and build momentum that will mean you don’t have to do this as much in the future.

If these ideas resonate 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.

Collective Story Building

The basic idea of this approach is to structure your conversations around building a story with stakeholders that everyone can get behind. Through different conversations with the different teams, you’ll work out the details of a story that works for everyone, then communicate this story back to them.

This section gives an overview of how the process works, and the rest of the post goes into details and tips that will make the process more successful.

The first step is to break down the ideas around which you want to get consensus into the blocks of a story. For example, you might break it into four blocks: a pain point, a diagnosis, a desired outcome and the actions needed to get there. Depending on your own situation, a different set of blocks may make more sense. But no matter what, the logical progression of the blocks should tell a story that your stakeholders can either agree or disagree with. The rest of the process is to update the blocks until everyone agrees.

Next you need to decide who are the stakeholders that need to agree with the final shape of each block. Start with the people who need to take action once you all agree to the story. Then work backwards to who they would want to have on board before they can get to work: Their managers. The people and teams who support their work. The experts they look to for guidance. Then go back another layer to add the stakeholders’ stakeholders, and so on. Expect this list to evolve as you get a better understanding of the story. But the sooner you can pull stakeholders into the process, the more straightforward it will be to build a story they can get on board with.

Finally, once you have an initial idea of the story blocks and your stakeholders, you’ll need to go through three steps with all your stakeholders, for each block:

Merge information and feedback from everyone involved into a clearly defined proposal.
Convince all the stakeholders that it’s a good proposal. (Return to step 1 if you discover it isn’t a good proposal. Expect to do this a few times.)
Show each stakeholder that all the stakeholders have agreed to it along with them. (Return to step 1 or 2 if you discover they don’t actually agree. Expect to do this a few times too.)

A more detailed explanation of these three steps is below. In an ideal world, you would go through all three steps for each block before you move on to the next. In practice, things are almost always much more messy. There usually just isn’t enough time to hold off discussing the diagnosis until everyone is solid on the pain, and so on. And as the steps indicate, you’ll often need to jump back within each block. But in general, you’ll want to be farther along on the earlier blocks before you work on the later blocks. If you’re running into issues on the later blocks, it may be a sign that you need to make more progress on the earlier ones.

At this point, the process probably still seems a bit vague. That was just the overview – the rest of this post should help make things clearer.

Why Stories?

I wrote previously about how stories aren’t about time, but rather about causality. What makes a sequence of events into a story isn’t that they happened one after another. It’s that the events are logically and causally connected to each other. So you can tell a story about the ideas that will allow your organization to solve a problem, even if these ideas aren’t a sequence of events.

Stories typically aren’t the most efficient way to communicate information, but they’re incredibly effective for creating a framing that allows others to understand the information. I wasn’t thinking about shared mental models when I wrote those posts about storytelling, but there’s a lot of overlap between the ideas. If you can get everyone to tell the same story, the framing that it creates can be the foundation for a shared mental model.

The basic structure I like to think of for a story is Context -> Tension -> Epiphany -> Action -> Outcome. For example, here’s what this looks like for our story about agreeing on data sharing conventions:

Context: Our lab teams do experiments to generate data. Our data teams need to use this data to do analysis that helps interpret results and define future experiments.
Tension: Data is shared via inconsistently formatted Excel sheets that data scientists need to clean up, delaying them from getting analysis results back to the lab teams.
Epiphany: If the lab teams adopted consistent data collection standards, we could implement software that makes data collection easier for them while enforcing the consistency that the data scientists need.
Action: The lab and data teams will form a working group to define and implement new data collection standards.
Outcome: Data scientists are able to turn around analysis significantly faster, and spend more of their time working on higher-impact problems.

Breaking down the other two problems like this is left as an exercise for the reader.

Depending on the story, it often makes sense to merge or split some of the five components. For example, the pain point and diagnosis in the four blocks I described at the beginning are both part of the Tension. Many story structures end up with just three parts because people like threes. But no matter how you break it up, your story should define a sequence of logical blocks such that understanding each one leads naturally into the next.

Bringing Everyone Along

As you go through this process, you’ll want to get through building the story as quickly as possible so you can get to work. But unlike writing code or training models, the pace that you go isn’t determined by you alone. The whole point of this process is to bring the other people in your organization along with you. It doesn’t matter when you personally figure out the solution. It matters when everyone else finally gets it.

Chances are that this is going to take longer than you would like. That’s the nature of an organization with so many perspectives and mental models. But if you move too fast – say, jumping to solutions before your colleagues are sold on the diagnosis – you’re going to have to go back and pick up the people you left behind. If it turns out your solution is based on an incorrect understanding of the diagnosis, you’ll have to start all over again on defining the solution. So rushing can end up slowing things down.

It’s better to be sure you’ve brought everyone along, even if it feels like it’s slowing things down.

Changing your Mind

In this process, you decide what each block should look like before you begin selling it to stakeholders. But to make sure the block that you’re selling is reasonable, you need to be open to changing your mind. For a complex problem that no one person has a complete understanding of, some of your assumptions and beliefs are going to be wrong. You will have a much easier time getting other people to change their minds if they see that you’re willing to change yours first. It would be hypocritical not to.

I’ve seen two big reasons people are often reluctant to change their minds: the psychological cost of admitting you’re wrong and the fear of losing control. The psychological cost comes from the clash with your self image as a smart person, and from recognizing the bad decisions you may have made as a result of being wrong. But as a rational person, you should always consider the long-term practical cost of staying wrong, relative to the short-term discomfort of admitting you were wrong and becoming right. The book Thinking in Bets does a great job of exploring this. Whether you’re motivated by your organization’s mission or your stock options, you need to get over your ego and change your mind.

The second reason, the fear of losing control, is a tougher one. The decisions you make about both your day-to-day work and the long-term plans that you’re building consensus around need to be built on top of a strong foundation. If you allow yourself to change your mind about the things that make up that foundation, all those decisions suddenly become less certain. The space of problems you could work on and solutions you could pursue is so complex and amorphous, allowing yourself a flexible foundation could lead to going in circles and being overwhelmed by scope creep.

Focusing on a story helps you limit this by making sure you’re constantly rebuilding the foundation by returning the framing in terms of context and tension. This only goes so far, and to some extent, this uncertainty is an unavoidable part of the job. But the ability to work through this is what makes great leaders.

Pain to Action

This approach to building consensus is designed for decisions that require a lot of different people across your organization to coordinate with each other. Bench scientists and data scientists and computational biologists and IT staff and all the others. It’s usually to address a vaguely defined problem that’s closely related to other vaguely defined problems that you’d rather not get distracted by. And the solution probably involves all these people doing things that you don’t completely understand.

To make this complex, amorphous problem as concrete as possible as quickly as possible, your understanding of the tension that the story builds off of needs to be specific about the pain you want to address. Notice that pain is the first of the four story blocks I suggested above. And pain is explicitly distinguished from diagnosis, with no mention of problems. When people talk about problems, they often mean some combination of pain and diagnosis. But once you start talking about diagnosis you move into the realm of problem solving, which opens you up to differences of interpretation and scope creep.

The diagnosis is that you’re still relying on excel for lab data, but the pain is that your data scientists spend half their time cleaning up spreadsheets. The diagnosis is that your ML team isn’t clearly explaining their analysis to the lab teams, but the pain is that the lab teams can’t answer their most important questions. The diagnosis is that your computational biologists aren’t involved in experiment planning but the pain is that experiments aren’t generating usable data.

It’s easy to disagree about the diagnosis, but very hard to disagree about the pain. The pain is an anchor that allows you to change your mind about everything that comes later without the risk of going in circles and losing sight of what matters. If you start by getting everyone to agree on the pain you want to address, it can focus the conversation as you move towards diagnosing the problem and defining a solution.

Once you do get to a solution, you’re still not done until you get to action. People often interpret a solution to mean the state of things that will address the pain. The action is much more concrete – the specific steps that individuals will take to get there. Thinking about action focuses the solutions conversation because a solution isn’t feasible if there isn’t action that will get you there.

The solution is a database and a UI, but the action is to build it, train the bench scientists to use it, and integrate the output into the data science platform. The solution is for data scientists to explain their work better but the action is for them to adopt a new reporting template, schedule review meetings with bench scientists and hold regular office hours. The solution is to include computational biologists in experiment planning but the action is for program leads to only plan experiments in designated meetings that include the computational biologists.

If you stop at the solution, before you get to the action, the people who you need to implement the solution may end up waiting for someone else to do it, or waste their time because they misinterpreted what they need to do.

The pain and the action give you concrete places to start and end the story, both in how you think about the process and how you communicate it to others. In between, there are many different ways to break down the story, depending on the situation. But no matter what, you need to start with pain and end with action.

The Three Stages of Consensus

However you choose the blocks of your story, the three steps described above will be the same:

Merge information and feedback from everyone involved into a clearly defined proposal.
Convince all the stakeholders that it’s a good proposal.
Show each stakeholder that all the stakeholders have agreed to it along with them.

The third step is easy to forget about and often harder than expected. Because these decisions typically require a high level of coordination between different teams, the people on these teams aren’t going to start something new until they know that everyone else will be changing along with them. (I recently wrote a newsletter post exploring this.) If you get to the point where everyone agrees on a solution but no one is doing anything about it, it’s probably because you stopped at Step 2.

Step 3 is also particularly important for verifying that you did steps 1 and 2 right. Because these decisions are often too complex for you to understand all the details, you’ll need to rely on your stakeholders to identify the details that your proposal leaves out, or where they still don’t agree with each other. There’s no better way to make people find their differences than to accuse them of agreeing.

You’ll also notice these missing details as you start to move on to later blocks of the story. If you’re running into inconsistencies with the solution, there might be a bug in your diagnosis. If you can’t come up with reasonable actions, it’s probably time to revisit your solution. So you’ll often need to bounce back up to earlier steps or earlier blocks. There’s no shame in it – it’s part of the process.

Picking the right sized conversations

All three steps in the process require a lot of conversations with different stakeholders, and these can come in all shapes and sizes. Not just synchronous vs asynchronous, but also the number of people involved. Just because you want all your stakeholders to agree to something doesn’t mean they all need to be in the conversation at once. For each step of the process, you’ll need to be strategic about how you design the conversations.

In general, smaller groups are better for identifying individuals’ concerns and changing their minds. If a group of people are very far apart in their thinking and you pull them into a single conversation, all the different issues will get confused and send you in circles. But if you split that conversation into a handful of one-on-ones, or at least into conversations with one stakeholder group each, you can address the issues systematically, either to incorporate them into your proposal or to explain how your proposal addresses them.

These smaller conversations are useful for the first two steps – merging different perspectives into a single proposal, then getting all the stakeholders on board with the proposal. Splitting up the conversation like this can be very time consuming, but having more meetings that eventually get you to a conclusion is better than a small number that recur endlessly without getting anywhere.

Once the different stakeholders are closer together, big meetings are effective for stage 3, either to show the stakeholders that they all agree or (the first few times) to identify the details that still need to be ironed out. Letting stakeholders look around the room (or the video feeds) and see each other nodding is often the only way to get final approval for your proposal.

Choose your Anchors Wisely

You may start this process with a fully baked, crystal clear vision of the story you want to get consensus on. Or you may start with nothing but a vague notion of the pain you want to address. Most likely you’re somewhere in between.

But no matter how clear of a draft you start with, you should be very deliberate about when you begin presenting your current draft to stakeholders. Once there’s a proposal on the table, that will become the thing that all alternatives are compared to. This is called an anchor.

The benefit of an anchor is that it makes the discussion more concrete. Without an anchor, stakeholders may have very different understandings of what the conversation is about. So you can end up circling around general principles without actually addressing real differences in your opinions or understanding.

The drawback of an anchor is that it makes it harder to shift to a radically different option. Not everyone will be willing to say “Oh, that’s not what I had in mind at all.” In fact, once there’s a proposal being discussed, stakeholders may not even look for other options. This is why most brainstorming processes are deliberately designed to avoid anchoring.

So it’s usually best to keep your proposal to yourself for as long as you can stand it, and stay open to changing your mind if a better idea comes along. Only when you notice the conversation devolving into abstractions is it time to create an anchor.

And if proposing an doesn’t do the trick, it may be that describing the idea just isn’t a concrete enough anchor. This is where a Proof of Concept, or even a Minimum Viable Product may be needed. But that’s a topic for another post.

Conclusion

Despite the relatively simple outline of this process in terms of steps and story blocks, building consensus in a biotech organization tends to be a messy process. It may not end up looking exactly like what I described above, but this framework should give you some ideas about how you can make your own approach more effective. If you can get through the uncertainty of the early stages and the stress of getting those final nods, the result will create the foundation for shared mental models and momentum that will make the next time significantly easier.