Jeremy Brown

This talk is around some of the experiences we've had as a group, Red Hat Open Innovation Labs. I'll tell you more about us helping companies that we work with, Red Hat customers, change their culture as they adopt DevOps.

The main thing that I'll revisit during this presentation is really the idea that high-performing teams are the result of the context that they operate in. And the context, the environment that that team operates in, is really, really important. And it's not limited to just the leadership, but it could be the physical office space. It can be the tools that they have to use. There's a lot of different things that affect that.

And I just wanted to come and level set on how I see culture, because we're talking about creating culture bubbles or APIs for teams. Culture isn't a real thing. It's like this shadow in this picture. Culture is really just, ultimately you express culture in how we do things in our environment, how we get stuff done.

Think about how stuff gets done in your organization. That is probably the expression of your environment. If you want to know more about some of these concepts, I highly recommend a guy called Niels Pflaeging. He's written some really interesting books on this.

But essentially, what we found is that in order to change culture, you need to change how you do things in a place. I'll tell you a little bit about how quick people can adapt. We've seen people adapting to changing environments.

So why is Red Hat talking about this, right? We're supposedly a Linux company or something. Well, we're more than a Linux company today. We're an open-source software company. We have tons of different products.

One of the really exciting things about our products is that people are not just asking us today to talk about kernel features or, "How do I do real-time kernel in financial trading?" and all these kinds of things, but they're actually saying, "Well, we love the way that you build software, and we want to actually introduce a lot of the same principles and culture within our own organization."

So our team, the Open Innovation Labs that I'm part of, is really focused on that. I'll tell you just briefly what we do.

But first, I wanted to touch on this concept of an open organization. Red Hat uses the term "open organization." You might use some other terms for it. Different organizations use that. And to explain what it is, we've drawn up within Red Hat and with our Open Organization ambassadors a definition of that, and we've got five different pillars.

So what are the five pillars of open organizations?

Transparency. The idea that you can actually see what's going on around within the organization, that you have visibility into decisions that are being made, why those decisions are being made.

Inclusivity. The fact that everybody's opinions are valued, and that actually the more diverse set of opinions you have, the better some of the decisions are going to be.

Open organizations need to be adaptable. Once you start telling people, "This is the decision that we're making," and that people can actually contribute to that decision, you actually have to change. You have to actually change. When people give you feedback, you've got to actually start adapting to the feedback that you get.

And obviously, collaboration is a vital part of that: getting people across different silos and groups within the organization to actually collaborate.

And a community: shared purpose within an organization. Why are we here?

Red Hat recently went through, I guess, almost a year exercise to understand why we exist. So we already had our mission statement. Our mission statement is to be a catalyst within communities of customers and partners, building open-source software or building stuff the Red Hat way.

But why did we exist as a company? So we went through a long, long process where we started telling stories about why we love the company and some of the moments that have really stood out for us. And ultimately, at the end of that whole process, we kind of articulated our why as "open unlocks the world's potential." And we really believe that the reason we exist as a company is because open unlocks the world's potential.

And the really interesting thing about these five pillars, when you start to look at them, is they're actually self-reinforcing and interrelated to each other, and they create these amazing feedback loops. And the more you have of this, the more your organization and your culture changes.

So going back to this idea of high-performing teams are the result of the context that they operate in. I hope you start to understand this idea that if we can create a different culture of the way things are done, if we can move to being more of an open organization, we can actually change some things within the way that teams work.

So why am I working on this? Why is Red Hat working on this? Actually, because our customers asked us to. About two and a half years ago in our customer advisory board, they actually said, "We love you, Red Hat. We love your technology. But show us how the sausage is made. Help us actually adopt this same way of working within our organization."

And that's actually what the Open Innovation Labs does. We're part of Red Hat's consulting, and we actually help our customer organizations as they're adopting tools that support DevOps. So Kubernetes, OpenShift is our Kubernetes distribution. As they're adopting some of these transformational, potentially transformational technologies, actually the way of working on top of that needs to change as well.

The previous speaker from ABN AMRO really said that. The culture needs to change as well. It's not about the tools.

So what is it and how do we work? What does that mean from Open Innovation Labs? Well, I'll use an analogy to tell a very simple story.

If you want to cook better, you can read a lot of different books about cooking. You can actually even spend an evening in a restaurant cooking with a chef. I don't know how many of you have done the team-building experience where you go to a restaurant with a chef and cook something as a team. It's really cool. I highly recommend it. You learn a lot.

You can watch celebrity chefs. You can watch all these things. You can practice some of that in your kitchen at home. But ultimately, if you really want to transform the way you cook, it would be great to go into a really high-performing restaurant and actually work in their kitchen for one to three months.

And if you come out of that experience of having worked in that kitchen for one to three months, you're going to come out of that experience and you're going to look at your kitchen and go, "I need to buy some new knives. Some of the equipment that I have in here needs to change to support the way I cook." The process that you apply in your kitchen is going to be different. And hopefully, the end result, the food, the thing that we care about, is also going to change.

So that's what we do within the Open Innovation Lab. Our customers come to us with a business problem and a team. And we actually take that team and that business problem into one of our labs. So we have labs in Boston, London, and Singapore. Or we actually create pop-up labs. So we've done pop-ups on site with customers in their offices. We've done pop-ups in co-working spaces in the same city, 10 minutes' walk from their typical place of work.

And taking people out of their environment into another environment is a key part of this process. We also match them one-to-one with Red Hat folks. So that's a key part of this as well, that seeing right behavior being modeled rubs off onto other people.

And we work for 4 to 12 weeks, so one to three months within that environment. And we build this thing. We're either working, typically, on some new application that you're just about to start working on, or we're actually working on transforming an existing application, going from monolith to microservice or something of that nature.

The really powerful thing about this is some people have asked me, "Well, how long does it take to change the team? How long does it take to change our people?"

It's really funny. When I first got asked this, it was really hard for me to think about. When I actually look and reflect back in each one of these residencies that we've done, it's about 24 to 48 hours. It's not really a long time for people to start changing their behavior when the environment supports it, when there's a different culture, the way that people are interacting.

And we do a lot of work within this facilitated residency to take people through that forming, storming, norming, and performing stages to accelerate that. But I have to tell you that just a change in scenery really makes a big difference.

For us, the next question then is, well, okay, but when they come out of this experience, they come back to our environment, what happens? And I get asked that pretty much every time we talk about this.

So what we've discovered is our end result at the end of these things is on the demo day, we want to create the working software. The working software is really important. That's what justified spending money on this thing in the first place. We want the customer's team to demonstrate that working software.

But we don't just want to show it working. We want to show the stakeholders that come in on that demo day how they did it, the way that they worked to produce it. Because typically what happens is the stakeholders from the business go, "Wow, using continuous delivery and all of this modern tooling and ways of working really allowed us to build something far faster than normal."

And we've had teams tell us that, "This would have taken us 18 months within our organization to build this simple thing." And we're like, "Oh, dear." Some others will say, "This would have taken us double the time." And it really varies depending on the organization.

But one of the key things that we want at that demo day is that the stakeholders say, "I want this team to stay together. This is a high-performing team. I want them to stay together back in our environment, and I want other teams to perform like this."

When we've created that team, they're actually quite capable of working in that way back in their own environment. The thing that usually stops them is their, let's say, the leadership often, or the management that they are working for, doesn't know how to interact with that team in this new way of working.

When you talk about, you hear a lot of this in the talks here about creating autonomous, self-correcting teams. Actually, leadership needs to change their way of working to support that. You might hear things like push management versus pull management. Most typical command-and-control hierarchical organizations, leadership and management are taught to be push. They push down what should happen.

Whereas actually, when you're changing and you're creating a context for people to operate in, you need to create an environment where it's pull. You're saying, "This is our intent of where we're going as an organization and why we need to do this," but you're allowing the team to pull that intent and actually implement the solution themselves.

So we've started to deliver leadership coaching for execs to actually help them understand how their behavior should be for this team and then for other teams.

And so the idea behind this culture bubbles thing is really, in a sense, if we're introducing a team back into their own organization and we don't have control over the whole organization, we're only maybe speaking to executives that run a division, or sometimes even just a leader that's responsible for a single part of it, we need to help them create that better context for at least that team.

So as I started to Google culture bubbles and things like that, I came across this guy called Michael Sahota. I really recommend just checking out some of the stuff he does, the leadership training course. He does a bunch of things.

He's pointed out there's this thing called-- There's a couple different things, but he's articulated this quite nicely in a diagram. So I've taken his diagram for this, and the URL is on the bottom of the slide. Or if you tweet me, I can link you also to him.

And the idea here is you have to create a bubble because you cannot change the whole organization. So there may be parts of the organization which you're strongly coupled to. So thinking about it from an architect's perspective, strongly coupled and loosely coupled.

If you're loosely coupled to some parts of the organization, that's kind of easy because you can give them what they need when you're loosely coupled, but they're not going to directly affect your day-to-day work. Whereas actually there's some parts of the organization where you have to deliver business value directly with them. So you really want to make them allies, and you want to really work quite hard in your relationships with those teams.

But some of the loosely coupled ones, you might not have to work as hard, but you still may have to do certain things. So I'm going to talk about some of these, the ideas of these adapters, some of the things that we've helped teams do to adapt as they're making their change in their bubble.

So work with the system. When you look at the existing way that your organization does project funding, it probably doesn't support the three horizon investment model that you read about in lean transformation, right? So you need to work somehow within that.

Time tracking might be a thing in your organization. The way that projects report their progress is important to other people in the organization. So having that team understand that what allows them to work in the way that they like to work is they have to do some stuff that they don't like to do in order to just continue working the way they do.

So we've had teams that do their time reporting. They actually have done far better time reporting because they know that the rest of the organization somehow cares about that. So they say, "Well, as long as we really radiate the work that we do in these tools that management use, we can then operate in our own way because they don't understand the way we work. So we just have to give it to them, but that will then continue to empower us to work in our way."

Now, this requires leadership to buffer that a little bit. But we've seen this a lot. I'll give you some pictures and examples of people then also doing some other interesting things.

So your office might look like this, it might look better than this, but ultimately, most offices are classically like this. But one way that you can start to radiate this new way of working is actually to use physical boards to radiate the actual work that you're doing.

So we love these things here. These are like foam boards. They're really light. You can carry them around, and you can get them in different sizes, different colors.

But we've had some teams that come out of residencies with us, and all they have are these foam boards, and the office is like this. And one particular team recently finished a residency, and the organization promised them, "You're going to be our first team working really in this agile way. We're going to give you a new space to work in, and we're going to bring everyone to come and see how you're working."

And then the CIO changed, and there was this whole, like-- This always happens. There was a pause. And what happened with them was they moved. They had to move every day from one meeting room to another. But they walked with these boards to every new meeting room, and they were like, "We as a team are going to keep working like this." And they did that for about two weeks until they got their own dedicated space, and then they were tweeting and sharing online their new space.

But it's funny how these physical artifacts, even though often these teams are actually putting the same-- When they change their stories, they're also changing them in Jira because maybe the rest of the organization really cares about Jira and the burndowns and all the stuff that PMO office want to apply from old-world thinking to this new DevOps agile world. So they still do it. But for them, the conversation happens on the physical boards. That's a really powerful thing. So for them, this is their lifeline as they come back into their organization.

Things that we do, and these are pictures from real residencies, is radiate everything. Your architecture, your sprint. This is an example of an actual sprint board. This is our backlog. We've decomposed it into tasks. This is the team burndown. There was the sprint goals that we have that we're trying to achieve.

Anyone that comes into your physical workspace can actually see what you're working on. That's really, really powerful. One of the things we teach executives and management to do is just to be able to walk into an environment like this and read that. That changes leadership, because suddenly, if you have a whole floor of people working like this, and each team is using a common language for their backlog, you can quickly walk around an entire building every morning and actually see what's the status, what are the blockers.

Those are the infrastructure challenges on a particular project we worked on recently. These are the target outcomes. These are the priority sliders. There's really interesting information that you can actually share within your organization by doing this.

Some other pictures of us using different tools. Impact mapping, it's a really powerful strategic planning tool. I highly recommend it. It can be really powerful when you have multiple teams coordinating together, working on similar or shared business outcomes, or sometimes you might actually be working on different aspects of a business outcome.

This is another example of impact mapping in progress. This is an example of one of the team actually talking about the impact map that they've used.

Target outcomes. So not output, but outcomes. What is the outcome that you're focusing on? Actually having some outcomes written about what it is you, as a team, are actually trying to deliver.

We also use things like priority sliders. Some of these tools are for the team to have shared understanding. So when people come in, in this case, skills acquisition was the number one thing that people were focusing on within this residency, and the number two was functional completeness.

This was a funny one because the product owner and the team had a really good discussion, argument, about what they thought was the most important thing. And at the end of the day, the team said, "After this four-week residency, we want to be able to keep building this product without the Red Hat folks there."

And the product owner went, "Oh, that's really good. I like that. Okay, so let's put that as the number one priority, that you all have the same skills that the Red Hat team have, and functional completeness will be the second thing. I'll compromise."

So this is a great tool for you to have a discussion. You can put any headlines you want on here between yourselves as a team and the business. Security is always an interesting discussion when you have that.

Social contract. This is also powerful, that you radiate how you, as a team, want to work. Social contract's a brilliant tool because it allows the team to say how they are going to work together, and we have a bunch of different things that we always put up that each team is kind of different, but there's typically some themes.

And we actually sign the social contract, and it stays up there for the whole team. If a new member of the team joins, or if someone new comes in, they have to sign that, too. They have to sign up for that. And that's really powerful. People can come in and see these are the things we signed up for. We can talk about that in every retro we do. Are we following the social contract?

Interesting thing about this is it gives the team the ability to self-govern when they have a misbehaving member of the team without someone from management dealing with it. It's a really powerful tool for helping teams self-manage.

Pipelines. These are not the most awesome set of pipelines, but that's okay. That's good, too. That radiates some information there that we've got some failing builds. We set up our build pipelines all over the place everywhere we go because that's really vital. In fact, we actually swarm around broken pipelines at a certain point, when we're moving closer to where we want to go to production or something like that.

Retrospectives. Having your retrospectives on-- These are examples. The Elvis retro, you can actually do a retro on all the songs that Elvis has done. That's a pub retro, example of us doing a retrospective in the pub. Pubs are great for getting people talking. This is another retrospective happening.

And we actually keep some of our retros-- Most of these retros actually stay up on the wall so that we can share with the rest of the organization. Now, that sharing is really important.

Walk the walls. Ask people to come into your new environment and actually tell them the story. Oh, sorry. I'm skipping forward. I'll go back. Yeah. Walk the walls.

Actually, the sprint reviews are also really powerful. I have a picture of a sprint review. In this particular residency with a customer that hadn't really experienced Agile and DevOps, we did a pop-up 10 minutes' walk from their office. We ended up with 120 people from their organization come and do a tour of this space of the team.

So that's some examples of people from the business coming to see this working. Invite people into your sprint reviews and to walk the walls so that you can actually educate them on this new way of working. It's really, really powerful. And these are ways that you can build those friendly adapters and win other people over to the way that you're working.

Sprint reviews are really powerful as well.

And the bottom line for all of this is really this context, this bubble that you've created, it does allow this team, or maybe multiple teams, to operate in a better way. But leadership ultimately sets that context, and this is where we've had to repeatedly educate management and executives of these teams, and we've actually had to start building experiential-based training for executives.

So if you come to our booth, you'll see a Lego city. We actually do a four-- We've adapted this Lego for Agile kind of workshop that you can do. And so we've created a four-hour Lego DevOps experience where anybody can experience Agile and DevOps through Lego. And some of the exciting things we do are seven-minute sprints. But each sprint is team-based, and it's really, really powerful.

But giving people that experience, giving executives the experience of how these teams are working, will actually start to change their behavior with the teams and help them create a better context.

Now, I want to point out something obvious. This cultural bubble thing is a bodge. It's a hack. It's not a fix. It's not something that you should live with permanently.

Talking to people who've built these bubbles within organizations and seeing some of these teams in place, this is a great first step, or as you create a wave, and these teams are kind of the evangelists for this way of working. And you want to roll that out within the organization.

But ultimately, if you don't get all the way there and the leadership changes, organizations are like that memory foam. They just kind of return to the way they used to be. So you've got to keep going with the change and the transformation that you're on to make it long-lasting.

And obviously, for me, one of the key things here is that this really needs to be a board-level initiative and down. But ultimately, the change that we do in the residency is actually very bottom-up. The unit of transformation is the team.

For us, that's the key thing. We want to change team by team. We want to give your internal transformation initiatives. We are an open-source software company. We want to show you how we work and to share all the tools that we use, and we want to create a community of other people who are doing this transformation in your organizations. And to use our tools, to use our practice library and some of the things we've done within your organization, and we're kind of there to support you on that journey.

So if you want to build something with us, come and talk to us in the booth. We're also hiring, so if you want to work with us, really work with us, and do this with us, we're also hiring.

Yeah, I think I'm close to the end of my time, so any questions?

Oh, no questions.

Okay. Thank you.