Ivanna Rosendal

My name is Ivanna Rosendal, and I'm speaking to you from Copenhagen, Denmark. I'm a leader in the life sciences industry, and I'm on a mission. No patient should have to wait for treatments because our uptake of new technology is slow or because we have distrust in our teams. Today, I'll share with you a journey of transformation of how a technology team in a biotech company created a common culture in a very volatile environment. I will share with you our victories and our struggles, but also the specific methods that helped us progress. This may be useful for your organization too.

Now, let's start with some context. So we are in the life sciences industry. That is important because the life sciences industry is heavily regulated, especially when it comes to software. So there are also a lot of requirements for the software that we developed, but that has also led to some ingrained ways of operating and working that may be different from other industries and that make us slower in how we approach technology. We are in the biotech part of the life sciences industry, which is different from the big pharmaceutical companies that have been around for hundreds of years. And specifically, this company is a clinical stage biotech, at least in the beginning. And within that clinical stage biotech company, we are in the global IT organization. And within that global IT organization, there are two units that we'll get back to. So we are in an IT department in a biotech, and that biotech is about to undergo a very aggressive expansion. So our story starts in 2019. And in 2019, this biotech company gets some very good news for the first drug in its pipeline. The results that it gets is that the drug is effective in humans, and actually it is way more effective than anticipated. And since this biotech company has developed a biological technology that can be applied to multiple different areas, this is amazing news because this first drug validates the whole platform. So the investors' expectations for what this biotech company can do suddenly skyrocket, and so does the courage of this biotech company to invest in internal things such as technology, for example. So in the beginning of our journey in 2019, this company has about 150 employees in three different countries. By the end of the story that I'm going to tell you in late '21, start of '22, this company has over 600 employees. Just imagine adding 500 people to your organization during the course of two years. That is massive. Also in the beginning of our journey, this company has about two live applications and some IT infrastructure. By the end, all the different areas of the company are technologically enabled from the research part to production, to the quality side, to the commercial part. So all end-to-end processes are technologically enabled going from zero. That is a lot of activity in two years to undergo in a very complex environment. Also, the amount of products that this company operates with expands from having, well, zero in the marketplace to having one already launched in a market and more products approaching this vital phase three clinical stage. Massive growth. Also, well, COVID comes along and makes everything a little bit more interesting during this period. Well, I'll give it a shout-out, the couple places where it's relevant to mention that. So we're in a technology organization in a biotech in the very regulated life science industry, experiencing massive expansion and growth.

Now let's take a look at global IT. Global IT at this point was organized in a very classic way. We had our CIO, and then we had a delivery organization and a maintenance organization called Application Services. We also had a third leg, IT Operations, which was responsible for end-user computing and infrastructure, but for the sake of this story, I'll leave them out of it, even though they have also been through a very interesting journey. So the IT delivery organization mainly employed project managers and business analysts. And this department made sure that applications were selected, validated, implemented, ready to go for the users. And the application services organization would take these applications and maintain them throughout their lifecycle. Very classic way of organizing IT, with some of the very classic struggles that that provides. Now, the IT organization was also distributed in all three geographical locations that this biotech was in, in California, in the US, in Copenhagen, in Denmark, and in Heidelberg, in Germany. A nice time difference there between California and Denmark also. Now, in the beginning of 2019, there are about seven people in global IT, a very small organization in a relatively small biotech company.

And what happens in the beginning of '19 is that we have, yay, we have an application that is live. A quality management system, which is one of the backbones of a pharmaceutical company, where all the quality events and documents are managed. So this application was implemented, validated, ready to go, and the project manager was eager to give this beautiful new application to the maintenance team and say, "There you go. Take this and maintain it."

There was only one problem. The application manager that was supposed to take this application into use did not take it. There was no going there. The application manager did not feel safe to take this application into use. Ooh, what do we do?

We tried to do the classic pharma route and create a nice long handover checklist. A very standard approach, I think, in many industries, that when you go from delivery to maintenance, that you create a checklist with all the items that have been delivered, and that is reviewed with the project manager and the application manager, and they agree and shake hands and say, "Now this application is ready to go." One of my colleagues had a checklist that she had used in her previous job, which was 53 items long, and we tried using that to resolve the situation. That created even more tension. The project manager was miserable. The application manager still denied taking this application into use, and we were going nowhere. And this was a problem because remember the crazy growth graph I showed you before? That meant that this project manager was supposed to start implementing three other systems at the same time if he were to keep up with the growth of the company. So we couldn't have this person maintaining an application on the side of his actual duties.

Now, there are several ways we could have gone about resolving this. One obvious way would be to pull out the boss card and say, "Dear application manager, you're going to take this into use or else." We did not go that route. Instead, we looked at the people that we had in our organization and why they were behaving like they were behaving. These were good people, highly specialized in what they were doing in applications in the pharmaceutical industry. And the grief that they were having was because of their experiences in this industry. Life sciences is a special industry with a set of rules and norms that we have in common. But different pharmaceutical companies interpret the rules in different ways, meaning that even though we're all in the same industry, big pharmaceutical companies have a big variance in how they interpret the rules and how they behave in their organizations. And here we had two people from two different big pharmaceutical companies, who both felt that they were right and that they were acting according to the best that they have learned from their previous jobs. So this was not really a personal issue. This was a structural issue. Here we have two people doing the best that they can but not succeeding in the situation that they suddenly were in. Because we were not even in a big pharmaceutical company anymore. We were in a clinical stage biotech, and just using some of the tools that they have learned in their previous jobs was not working.

So what to do about this situation? Well, we chose to come together as the IT delivery organization and the application services part and try to define, well, what does it mean to be an IT organization in a clinical stage biotech? And what came out of this was five behavioral principles about how we expect people to conduct themselves in this new organization. We're very well aware that during the next years, we would have to rapidly onboard new people to this organization. Again, all coming with flaming hearts from their previous company and their set way of addressing issues. We had to be a little bit proactive in making sure that people gelled well together in this very, very stressful expansion phase.

Now, we defined these five behavioral principles, and to the trained eye, you may recognize that they may remind you of something you've seen before, such as the agile values, the Scrum values. But at this point in time, we actually had no idea that there was something called Scrum values. So this is what we came up with on our own. And we were very excited about our progress here. Yay, we're coming together. We're looking for the root of the problem and not just treating the symptoms. How clever we all are. And we wrote out these new behavioral principles as you would do in any other big pharmaceutical company. We created posters, we created water bottles, and other swag to inform everyone that this is now how we expect people to behave. And can you guess what happened? Absolutely nothing. No behavior changed at all. People continued going on about their work as they have always done. Again, these are clever people from big companies. They've all seen attempts at cultural transformation before, and no one was biting. We went back to the drawing board and said, "Okay, so how could we make this safe for people to try? How could we actually impact their behavior?"

And we invented a concept called the cultural simulation game, where we would try to train people very specifically on how would it feel to behave differently. What is the difference between acting one way and another way? And principle by principle to help people understand what we actually expect of them. And we had plans. The first event, we planned to fly everybody into the same location, do a two-day workshop where we would really bond and bring people together. Of course, that's not quite what happened because this was 2020, and, well, COVID struck, and we couldn't fly people in. So we had to rethink the whole concept for a virtual session instead.

So the first simulation game we wanted to try was about flow. And we wanted to try this game to show people that when we work together, we can deliver faster. This speaks to the principle of being business-minded, that we focus on the outcome more than we focus on how we achieve that outcome. So the original intent was to do some of the games that you may have heard of before, such as the paper plane game, where a team works together on folding an airplane, and everyone can only do one fold, and you kind of get this feeling of working together towards creating a common product. There's also a different game where a team comes together and have to move a set of balls from one bucket to another bucket, and everyone on the team needs to touch all balls that go to the second bucket. Virtually, we did not have any balls or buckets or paper airplanes.

What we did instead was bring everyone together in a virtual space, divide people into teams, and create a number of spreadsheets where our teams would move numbers around. Now, if that sounds a little bit dry to you, then imagine how I was feeling the day before this event, as the organizer, feeling responsible for putting 20 people to move numbers in a spreadsheet to achieve a different cultural behavior.

So the principle is more or less like this. We have four people in a team. Only person one can initiate a ball, and a ball, in this case, is a number. And the person next to that person, person two, can grab the ball and add the number two to the ball, and so on until person four. And then once person four adds the four, then the ball is done. Only person one can initiate balls, and we'll see how far the teams get, how many balls they get all the way through. And we did a number of iterations on this game where the teams could do a retrospective and adjust their strategy. And this was a surprising success. People were very engaged and very quiet in moving their virtual balls through the spreadsheet. And afterwards, a number of our team members really realized this concept of flow, of getting work through the pipeline towards the very end, instead of just focusing on their little part in the team.

Emboldened by this simulation game, we did an experiment. And our hypothesis was, or the question that we wanted to test was, what if maintenance was involved in projects? Could that create more flow? What if we didn't have this big old wall between us? What if we stood on the same side of the wall? And we tried that specifically on a project for a pharmacovigilance system, where the person who would be responsible for the maintenance was involved in the project phase of both selecting, implementing, validating this application.

That was a huge success. The customers were extremely happy because they got a lot of expertise during the project. The handover was a breeze because the person who was taking over the application was a part of making all the decisions alongside the project manager. The project manager was happy because, well, there was no handover work. The person already knew everything that there was. Big success according to all parameters, working together. What a great delivery.

There was only one problem. People are not departments. So after this project was concluded, the application manager, the person responsible for maintaining the system, was very, very angry and very frustrated. And that was a good question. Why would this person be so frustrated after such a huge success?

Well, it turned out the anger this person was experiencing was really dragging down everyone in the team. We're still a relatively small team at this point, about 30 people. And it was just coming out in all conversations that were not even related to the system, major frustration. It turned out that this person, by participating in the delivery part, realized that a lot of the problems that maintenance experiences, they are actually created during the implementation phase. So this person would not accept going back to a more limited role just maintaining the application, but wanted to continue being a part of making the decisions that actually make for a good user experience of the system all the way through its life cycle. So we had a very, very frustrated person who was not necessarily able to articulate why the person was so frustrated after such a successful project.

We did another simulation game. This simulation game focused on conversations. And we altered a bit a tool that is presented in the book, "Agile Conversations: Transform Your Conversations, Transform Your Culture" by Douglas Squirrel and Jeffrey Fredrick. If you haven't read it, that's highly recommended from here.

We divided people again into teams, and we asked them to do a role-play. So we would have someone playing a Bobby and someone playing a Nicole, and we had rigged this game so that Bobby and Nicole would have a huge confrontation. And in the same team, there was a scribe, there was also an observer, and the scribe would write down the whole conversation that Bobby and Nicole had. And our teams did an amazing job. Bobbys and Nicoles were really fighting it out, and some people really got upset during the heated debate. And then afterwards, we had the teams look at what was said, and also had both Bobby and Nicole add in to what were they feeling at the time that they were saying this. We had the whole team come together and analyze. So what triggered the really ugly parts of the conversation? When did Bobby or Nicole ask questions that in fact were statements? But also especially look for unexpressed thoughts or feelings from Bobby and Nicole and see what would have happened if they had actually expressed those thoughts or feelings.

Now, this simulation game made a big impact on our very, very frustrated team member and got her to a place where she could actually state what it was that she wanted and some of the problems that she saw with the way that we were operating as an organization. But for us as the leadership team, this led us to try to rethink the way that we're operating in general, and we wanted to try a new hypothesis.

What if people contributed with all their skills instead of just contributing with the skills that were defined by their role? People are not departments, people are not roles, people are people that can bring multiple different facets to any conversation.

We tried that on some projects, and it was very successful. So we took the big leap and reorganized our whole organization. So we merged the IT delivery and application services part of our organization into a continuous delivery organization. We created teams both from the IT delivery side and the maintenance part that would be responsible for specific value streams in our organization, meaning big chunks of processes that are supported by technology, and they would have the end-to-end responsibility. We also did some major rethinking of the way that we as leaders showed up in this organization, but that is a story for another day. Besides the continuous delivery organization, we also created a number of competency teams where team members across the different value streams would come together and learn.

This led us to the next bump in our road, and that is that when you break up the existing structure of a team and put people into new teams, people are afraid. They are afraid of making mistakes. They're afraid of looking foolish in the eyes of their colleagues. So people start wearing this armor and stop engaging with their work. And this is a problem. Again, we are more or less halfway through the two years time span we're talking about. We are still in the middle of delivering all the applications in all different areas. We have grown to about 40 people. We cannot stop now. We need all the brainpower of each individual person to solve the many very complex problems that we're facing.

So we addressed that in another simulation game, which was all about making mistakes. And with this simulation game, we created a standard operating procedure for making mistakes. In our industry, we have standard operating procedures for almost everything. This was also a funny pun on that. We defined it as four steps. Step one is describe the mistake that you made. Step two is to categorize it. Is it a lapse in judgment, or is it just a bad outcome? There's a difference because lapses in judgment, you can work on improving your decision-making skills over time. If it's a bad outcome but you did the best that you knew, well, that's a different matter. Step three is learning from it. How can you apply some learnings that you can use in a different situation that would arise that is similar to this or something you may learn about yourself? And step four, very important, celebrate it. And we brainstormed some very creative ways of celebrating our mistakes together as a team.

Now, as a basis for the standard operating procedure, we took the teams through the Cynefin model, that I think most of you are very well aware of, so I'll not go into detail. But in this biotech, in this IT department, we were in the complex zone. There were a lot of solutions that we would have to rethink from scratch. There was no previous knowledge that we could apply, and so we definitely needed to experiment with the way that we work and think, and that means that we need to be able to make mistakes. We cannot always make the right decision. Also, we took people through Brené Brown's shame concept from "Dare to Lead," also a good read, which is all about explaining why is it that mistakes are so hard. When we make a mistake, the feeling that we feel is shame, which is essentially a fear of being excluded from the group. And that is why it is so important that when we make mistakes, that we come together as a team and face the mistakes together, and also that the celebration step, why it's so important that we change our mental wiring in our brains to stop seeing mistakes as something dangerous, but see it more as something that is just a phenomenon that we observe together. So that was simulation game three about making mistakes.

And after this simulation game, we stumbled onto some interesting aspects of our culture, and this time, not so much our organizational culture as our country cultures.

Because we are in three different countries in this team, and this exercise was received differently depending on where people resided. From the German side of our team, there was some skepticism to accepting that mistakes are in fact necessary. Their general attitude was that we should avoid mistakes as much as possible, except when it comes to science. The scientific process is allowed to make mistakes. In Denmark, the general feeling for mistakes is that mistakes are my fault, that if you make a mistake, that it's a fault with me as a person. And that creates a very interesting dynamic because a lot of our US colleagues had the attitude that, well, mistakes are done by the other guy. And together with the very sponge-like absorption of mistakes by the Danish colleagues, this created a very interesting dynamic. But because we brought mistakes into light, we could also have a conversation about some of these dynamics that people were experiencing in their mixed geographical teams. And also just nudging our Danish colleagues to maybe take a little less responsibility and maybe nudging our US colleagues to maybe take a little bit more. But also making it light and fun for people to talk about these differences.

And at this point in our journey, we also had to address the inner journey of the individual because when we dig so deep that we can see that people are reacting inherently differently to the same kind of information, we also need to talk about the individual responsibility that we each have when we are in a team that is more self-organized than hierarchical, and also when we come together as equals in a team to work together. It requires a certain level of maturity, and not all organizations teach people how to be that.

So for the fourth simulation game, we dove deeper into what it means to be a participant in an equal team. We talked about adaptability, problem-solving, time management, trustworthiness, reliability, and conscientiousness. And for all of these areas, we specified what would that mean? How can you practice that? We had people assess themselves, but also helped people create journeys to developing some of these skills so that they can improve and be better teammates for their colleagues.

Now, we managed to move a lot of mindsets in these two years, and I've omitted completely the whole structural element of this presentation. But often, I feel we focus a lot on what we do to transform and not who we become during the transformation.

This team is not finished with transforming. The journey continues. Even though the application teams and the delivery teams are now really operating as one team, there's still the struggle of how to implement external vendors, how to work with their teams as one team, collaboration over contracts, and also including external partners and consultants in the teams. But also still there is the challenge of onboarding so many people in this organization and bringing them along for this transformational journey even though they start two years later. The journey continues, but we have managed to come far and also really address some of the root causes of behavior and not just their fruits.

I would encourage you to try this at home. I would encourage you to make your culture explicit. But not only your culture, also make your behavior explicit and also define a definition of done. So this specific value, this specific principle, this specific behavior, what does it look like? And how would we observe a behavior that's actually constructive in our team? I would also encourage you to implement that in the way that you review the people working in your organization so that it becomes real and tangible. Also, I would encourage you to let your culture lead your structure, and that also means sometimes looking at the culture that you actually have and not necessarily the culture that you would like to have, and adjusting the structure so that it's the next possible zone of proximal development for your organization.

If you have any stories about culture transformations, I am all ears and would love to hear from you in the Slack channel. And thank you for listening.