Creating and Sustaining a Culture of Innovation

Why this recording exists

(0:00) So if you're watching this online, what I'm doing here is recording a talk to give at an online conference. It's the culture talk that I give. I'm just going to give it straight and chop this intro off for submitting it to the conference, but I'll upload it here and you can see a sample of what this talk is like. This is the 30 minute version - there's a 45 and a 90 minute version, just a lot of content to go over, but I've compressed things down. As always, if you want to see more things like this, I do a show twice a week and all sorts of other little videos. If you go to TanzuTalk.com you can find the archives and all sorts of things like that. I try to broadcast on Tuesdays and Thursdays at 10:30 AM Amsterdam time. So with that, let me roll into here and we'll see what happens.

What we're driving towards

(0:47) Well, thanks for having me here. I want to go over the talk that explains what it is we're driving towards when we talk about improving the way that we do software - the reason we install Kubernetes, and the reason we're interested in application development and DevOps and product management, all of these kinds of things. Not only to go over what the goal of that is, but more importantly, when it comes especially to large organizations, what that culture looks like. And also how you scale that culture in a large organization.

(1:17) First of all, just a tiny bit about myself. I'm pretty lucky that I get to spend pretty much all of my time in a professional capacity studying how large organizations get better at software, how they transform from a project way of doing things to a product way - and interview people, talk with them, and put them in book form. Here's two books that you can get for free if you want to, you can go to cote.io/books. And I do a lot of podcasts and other things.

Why we care about culture

(1:48) In our industry there's always a lot of talks about culture. I talk with a lot of management and executive people, and one of the top things they want to know about is: how do I change the culture of my organization? What I've found over the years is that in this conversation, in the talks that people have about it, there is this definite idea of what the end goal is - we want to have an innovative, creative, DevOpsy kind of culture. But there's really not that much talking about how to get there. How to get from where you are now to that kind of fully finished owl. Over the years I've found it pretty unsatisfying to figure out exactly what that is, so I've spent some time researching it. This is a brief overview of some of the things I've found, and the way that I frame this notion of what culture is.

(2:32) The first thing is to ask this question: why do we care about culture? If we're in a large organization, we already have plenty of culture, lots of stuff going on, lots of software that we're working on. In recent years, what companies and organizations are focusing on is that instead of just delivering a project way of doing software - a set of features - they're really thinking about software as a storefront, as their primary way of interacting with their customers or with their internal employees. What they've found is that the more they can improve that customer experience, that user experience, the more it will allow them to improve and innovate their business.

(3:04) You hear a lot about people wanting to be like tech companies - "we're not a bank or a car company, we're a software company." What they're expressing is this idea that we can start using software as the primary engine of how we do business. Getting to where you can indeed be like a tech company, where you have this product way of thinking about software, is a lot of what people are driving at when they're talking about changing culture. They're not just talking about installing VMs, like we were in the 2000s, making something more efficient and easy to manage. They're talking about fundamentally changing the way they think about software, the way that they do software - so that software becomes that expression of the business they have and how their business functions. And then, in an advanced way, allows them to innovate what their business does.

(3:57) Now the problem is that the way we've been doing software thus far doesn't really match this product way of doing things. Organizations that are not tech companies tend to deliver software in a different way, and where they are at the moment - as you can see from these sad donuts - is not quite at the point where they can rely on software to be that core thing that runs their business.

(4:19) One of the primary ways I judge this is the frequency that they release software. Because the more frequently you're releasing software, the more you're evolving it, and the more of a chance you get to discover what the market is, discover what customers are doing, and really evolve and innovate. As you can see from surveys, many organizations don't deploy improvements to their software very frequently - just about half, which is an astonishing amount.

(4:51) What that means is that your software is static. Your software can't really be relied on to evolve and innovate your business. You can see some other sad things there too: a lot of organizations are really stuck with what they call legacy apps - their existing application portfolio, their existing software - and just the inability to change it and evolve it is really holding them back from changing how they operate, from improving the way they do their software, and from changing what their business looks like.

(5:12) So most organizations, many organizations, are in this state - this land of sad donuts. A lot of what this changing culture gets to is: how do we get ourselves out of these sad donuts and get to some happy donuts?

A happy donut: Daimler and the Sprinter vans

(5:24) Let me give you an example of a happy donut, and that is from Daimler, the company that makes Mercedes and many other things - they've got trucks and things like that. There's a team there that has this culture that we're looking for, this culture of innovation. They're in charge of a storefront for buying cars. There's a search engine, you can go customize the car, kit it out however you want. They tell me that a lot of people go in and build this ultimate sports car, and then, like me, they end up getting realistic and configure a station wagon in the configurator. And depending on the geography you're in, you can schedule to go talk with a dealer, all sorts of things.

(6:01) If you think about it from the standpoint of selling cars, this is a lot of the first interactions that you have with your customers. It's your storefront. So you would want the software you use to do that to be very good, and to be evolving, to always be adapting to what customers want to do.

(6:17) The team doing this had a very product-mentality way of doing things. They noticed on their site - the front end for doing car searches - that a lot of people were searching for these Sprinter vans, which are not normally part of that line of business. This is what ice cream people will drive, or plumbers, things like that. A completely separate part of the business, so obviously their software is done on their own and doesn't work with the people selling station wagons. Again, completely separate part of the business, so it sort of makes sense.

(6:45) But the team there, because they had this culture of innovation, saw that people were interested in finding these vans. So they put a theory in place. They said, "well, despite the fact this is a separate type of business, why don't we integrate the backend for the Sprinter vans and allow people to look at these vans, not just the sedans and cars that we have?" As we'll get into, having a team who are even curious enough to look for that kind of data and think about something to do is part of this culture, and is valuable.

(7:12) But the tool that they use to pursue those theories and evolve the business, to innovate, I think is equally valuable. I call this loop the small batch loop. It's nothing that I've come up with - it's like the lean startup loop, it's a design loop, it's even the scientific method if you think about it. But following this loop, in this product way of doing culture, is very important because it makes it more disciplined, instead of just creative and exploratory.

(7:41) In this example, there's a theory that people looking for station wagons will every now and then look for a Sprinter, and there might be a reason why they want to find a van. So what kind of theory would we come up with, that they're looking for a van and that they would buy one, even if they're not an ice cream truck driver or a plumber?

(8:01) In development, the way that we run an experiment is we write code. You have to write the code for it, and you put that code in front of a user, and then - this is the vital part - you somehow measure what's happened. Do people end up buying those vans? And if they do, then you've validated your theory and you've come up with a new innovation, a new feature. Going through this loop over and over again until you discover what works, and backing it up with the rigor of measuring and looking at your assumptions, of validating and invalidating things - that's really at the core of how I see the software teams that we're aspiring to be, these product teams, really explore what their software can do to help their business out.

(8:44) So lo and behold, as you might be guessing, what the team found when they integrated with the Sprinter backend is that there were many people who wanted to buy one even though they were consumers, not professionals. They wanted to buy Sprinter vans to use for RVs or caravans, or whatever you want to call them, so that they could go on trips.

(9:05) Like many great examples, it seems ridiculously obvious in hindsight. But if you recall the situation - these were two separate lines of business that felt like they had no reason to integrate with each other. Until you had this kind of culture of innovation playing out in a team, no one had really thought to merge the two together and explore the possibility that they could sell Sprinter vans in the same channel, the same way they're selling these other cars. That there might actually be, in the view of us, the people buying this, a sense that we don't care that they're separate lines of business - and so therefore the way the software is managed and delivered should be merged together.

(9:42) It's going through that small batch loop that you can discover this, and also prove out that this is a good idea and a way of doing business. And then, as in this example, you get pretty much free revenue. This isn't something where - you're just integrating systems together, which costs some money, but then long term you don't have to create a brand new business.

What even is "culture"?

(10:04) So that's kind of the end goal, that description. I'll give you a couple more examples, but let's talk about how we get to that end goal, which is by putting in place this culture of innovation - as I like to call it, a product way of thinking about software.

(10:16) As I was saying earlier, I've always found it hard to define what culture is. I started thinking about this when the DevOps reports started coming out and they went over the Westrum way of thinking about things. It's a good way of describing what a culture looks like, so you can diagnose what kind of culture you're in. I will let you guess which ones are the undesirable ones.

(10:44) This is fine. But this is more like a state that something exists in, attributes that you have. I've always wanted more than just this, because it describes what something looks like.

(10:57) Thankfully, back in the 90s there were a whole lot of books written about changing the corporate culture, when another gigantic notion of how organizations work was changing over. Digging through those books, and some other ones that are fun to look through, there are some references for you, and some quotes from there to summarize the way those books looked at culture.

(11:19) What these ideas of what culture is boil down to, in a very tactical, pragmatic way for me, is: culture is how we do things around here. It's the processes that we have, the norms that we have, the expectations. You can think of them as thought technologies, or meatware.

(11:36) So when we're talking about changing the culture, and the type of culture that we want in an organization, we're really talking about how that organization functions and the mindsets that people have. Are you more command and control, where people wait to be told what they're doing and someone has to tell them what to do? Or is it more like that Sprinter example?

(11:54) Now let's focus on the area of software development, and managing that whole software capability you have in your organization to be the main way that you're running your business. How would we do things around here in this kind of product-driven culture of innovation that we're shooting for?

What the team does: innovative, risk takers, people-centric

(12:06) I want to go over what the individuals - we would normally call them developers, but let's call it the product team: the developers, the product managers, the designers, the people working on the software - what attributes they have, how they do things. And then I'll go over, maybe even more importantly, what management does. The context, the system that management sets up so that these teams can be successful.

(12:32) First of all, these three things. There are other attributes, but these are the three I think are the most important, and they're all kind of the same thing. If you look at how people who are on teams like the Sprinter van team do things around here: they're innovative. They want to come up with new ways of doing things. They want to apply that small batch loop to explore and imagine new ways of running their business, of what their software looks like.

(12:57) Now, to do that, they're comfortable taking risk. They're risk takers - or, if you prefer something safer, they like to learn. Learning is all about taking risks and failing. I think about when my kids are learning to read and do math and other things: they're constantly failing at it. But because they're failing, they're learning, validating and invalidating things, and they're learning the way to go about doing things. They're taking risks. There's a reason why I'm bad at learning things, and it's that I don't want to take the risk of failing, so I just do the things I know over and over again. But people on this team will try out things. They'll go through that small batch loop and try out a new way of doing things, and if it doesn't work, they try out a different way.

(13:36) Another attribute they have is that they're very people-centric. That doesn't necessarily mean they need to be extroverts, but they think about a person using the software. I move pixels around on the screen; a person is using the software. So I want to get into their head and think about what that person is doing, what their motivations are, how I might help them out. I'm curious to observe what they're doing, because I'm helping that person. Their focus is not on features that they're implementing, or just doing their job. Their focus is: I want to make this person's interaction with my software, their time spent with the software, better.

(14:13) Now, in order to have a team like that in place - a team of people who are allowed to use software to go through that small batch process, to innovate, be curious and explore - if you think about what's required for that, most software organizations are not set up that way. They're set up where the developers, first of all, don't necessarily have product managers or designers. They're just developers who are told what to code. They might even be given wireframes: code exactly this screen. So they're not really given the opportunity to explore and innovate. They don't really have those attributes.

What management gives: autonomy, trust, voice

(14:48) So management, or leaders, need to change what they're doing. They need to rewrite the way that they are doing their system of management. You can think about it as the context, the system they set up - but I like to think about it as what management gives these teams.

(15:04) The first thing is that managers give these teams a huge degree of autonomy. You can think of this as ownership. If you go to that Daimler example, they're giving that team ownership of that interaction, of this idea that we could add in the Sprinter vans. They have the autonomy to make a decision about what features should be in the software and what to do next.

(15:24) Now this requires a huge degree of trust in the team. Management has to trust that the product teams - the developers, product managers, designers - care and will do a good job. This is a huge, huge issue for most people in large organizations, to actually trust that people are doing things, which takes some time to get to. And it's also, if you think about it, kind of a failure of management: if you have this organization and you don't trust it, you've done something poor.

(15:52) The other thing is that the team needs to have voice. Again, these are three aspects of the same thing. That voice is: because they have autonomy, because they're curious, they can voice that I think we should do this thing. I think we should pursue - even though it's a separate line of business - showing Sprinter vans to people.

(16:10) So if you're in management, think about these, in addition to other things you need to do to set up your system. You want your developers to start doing their software differently. You need to think about how you're programming the meatware of your organization, so the teams of people have this and they can start doing that more culture-of-innovation way of doing things.

The industrial kitchen: they went for recipes and found mayonnaise

(16:32) Let me give you another example of what this ends up looking like. This is from an industrial kitchen management company, also food service. They deliver food and they'll run the kitchens for you. This is a great example of all of those six attributes. This organization - like all organizations that want to run things more efficiently, have better customer experience - you can outsource your kitchen at a campus or a business. And they were using paper recipes. You'd have three-ring binders full of the recipes of how to cook pasta and stuff like that.

(17:02) So the idea of management was that to be more efficient, to have more consistency in the recipes, and to have newer ones, of course what we need to do is digitize these recipes and put them on an iPad.

(17:13) They got together a team of people, and thankfully it was one of these product-driven teams that had this kind of culture of innovation. In a very command-and-control way, they said: go digitize these menus. Despite this, they gave the team autonomy and they trusted them, and gave them voice, to do the following.

(17:31) The team, being people-centric, said: "all right, well, why don't we go observe the people using this software and see what it is they're doing, so that we can write the software to be most helpful for them?" So the team got up at like 4:00 AM in the morning, got to the kitchen at five or whatever, and for a week or so they observed the people actually going about their duties.

(17:51) What they discovered is that while the paper recipes were maybe not as great as they could be, an activity that took up a tremendous amount of time and task switching was measuring mayonnaise, measuring chicken, making sure that various ingredients were kept at a safe temperature.

(18:09) Because they were people-centric, because this team was curious, because they wanted to take risks and be innovative, they used the voice that management gave them to say: we're not going to digitize the recipes just yet. We found something that we think is even more important, that will make the kitchen run more efficiently.

(18:30) So they went and digitized the temperature taking. They did some Internet of Things stuff, and they kept more of a digital record of it, instead of the piece of paper that tracks the temperatures. Indeed, this saved a tremendous amount of time for the kitchen staff. It made what they're doing more efficient, because they had to spend less time on measuring the mayonnaise. And it also makes compliance - that is, health inspections - a lot easier, because you don't have all these sheets of paper that you have to keep track of. It's all computerized.

(18:57) And then eventually the team went on to digitize the recipes on the iPads and so forth. But overall, because the team had this culture of innovation, because they had this product-centric culture in place and those six attributes were scurrying around there, the team was able to meet the original business goals - and even exceed what those business goals were, because they discovered a whole other problem that originally management didn't want to solve.

(19:23) Those kinds of results, that kind of discovery that really changes the way that you operate - to me, when we talk about digital transformation and "we're a software company, not a food supply company," that kind of mindset really gets down to that thing. Using the small batch process, the software process, to discover new ways to run your business, to optimize it, and really constantly be learning how you can make the way your organization functions better with software.

How do you scale this?

(19:50) So with that, we've got this idea of what a culture is and the kind of attributes that management puts in place to allow for the team there. I want to spend the rest of the time going over how you scale this kind of culture. This is the question. This is what I've been interested in the last few years, because I talk with and work with primarily larger organizations. Their issue is: we don't just have three or four teams over there in Stockholm who we can all go out to lunch together with and sync up and sort out how we're doing. We have tens of thousands of people, thousands of projects, thousands of apps that we need to switch over. How do we hope to scale that kind of thing that's normally done in a person-to-person way? So I want to go over some tools, mostly that management uses, to help scale that kind of culture.

(20:40) The first, often under-appreciated, under-done thing is to really look at something that normally is not very helpful at all: your company's vision. Your vision, your values, your mission statements. These are often very nice and aspirational, but they don't really tell those development teams what they should be doing.

(21:03) Ask yourself: do I know what my company's vision is? The mission statement for my company? And if I had to decide the next task I'm going to go do, does that actually inform how I'm going to make that decision?

(21:15) I think this is a great example of a very pragmatic vision, from DBS Bank in Singapore. It gets to this idea that every time you're making a decision about a feature you're doing - even what Kubernetes distribution you might use, or whether you'd use one at all, all these kinds of decisions - if you have any doubt, or you need some way of guiding it, you can use this vision to determine if you're meeting that need of: I don't want our customers to have to spend too much time with our software getting whatever they need from us. I want them to do it quickly, because they need to get on with the rest of their life.

(21:48) That's easy if you're in the app layer, where you're moving pixels around on the screen. You just constantly go through that small batch loop to make the workflows and interactions that people are doing with your bank as quick and efficient and easy as possible.

(22:01) Think about, especially in the upper parts of management, how you can get a vision that is a tool that can be used - not just something that creates a nice identity or aspiration, but an actual tool that people can use. You can decompose this down into principles and things like that. But really think about codifying those kinds of principles, that kind of vision that you have. That will help you scale, because all of the people in the organization can look at that for guidance about how to act, instead of having to ask about it and being told directly.

Start small, and seed people between teams

(22:33) There are two key things that are really vital to figuring out how you scale. The first is to start small, and slower than you think you should. A lot of people, if they look at the thousands of applications that they have, want to, over the course of the first year or couple of years, have each team be responsible for modernizing it. For the most part, that couldn't be a worse idea.

(22:56) Instead, what you want to do - you're learning a new way to operate, a new way of thinking, you're using new technologies to run your software on, you're going through that small batch loop on a weekly basis. This is all stuff that's going to be new to your organization and the people doing it. So you want to apply that same learning loop, that same small batch loop: start with one project for a month or two, start with two projects after that, scale it up to five, and go through that line over the course of the first year, where you are learning what works in your organization. You're learning to use this new meatware and software, this new way of doing things. And you're adapting a lot of these standard practices to fit exactly what you're doing. You're also building up a track record that you'll use to prove that this new way works when you're trying to scale it to the rest of your organization.

(23:45) The other key thing is that you identify some of the people in those initial projects, the product teams working on it, who are more people-centric, kind of outgoing. Then as you go to new applications and start up new teams, you take these individuals and you seed them into those new teams, to be someone who already knows how to do things in this new way. So they can help that team do a little bit better than bootstrapping from nothing. They can help train up that team, help build the trust that this new methodology is working - and then they train someone else. So now you've got two people who can be sent out into another seeding, and then four people, and so on. You're slowly but surely training these new people by starting small with some initial applications, instead of doing everything at once.

(24:40) Doing everything at once generally won't work out, because you won't have the chance to learn how to do it and adapt it to what works in your organization. I see this time and time again: organizations methodically start out smaller and they just build up slowly, by seeding people and spreading that knowledge through their organization.

Brand it, and market it internally

(24:51) The final thing I want to cover is: about midway through, when you've validated that this is a good methodology, you've gone through a couple of teams, the next thing you're going to want to do is really brand what you're doing. Now, that sounds kind of like a crass marketing thing. But remember what I was saying: you want to adapt the off-the-shelf methodology to what works in your organization. So you want to codify what that is, write it up, and boil down that pragmatic vision to a set of principles, how you operate.

(25:20) You also want to come up with your own name for it, like you see at BT, British Telecom. They call this whole new way of doing things Canvas. It has the Tanzu Application Platform that runs on it, the Tanzu Kubernetes stuff that they use for it, and they follow the Tanzu Labs way of doing product management. So instead of calling it all Tanzu stuff, or calling it agile or lean product, they've come up with their own name for it. They own that. And they really have the branding around it.

(25:52) This comes up time and time again - you can see it with Duke Energy and Daimler there. It's very important that you own this new process. That it's not some other process, an external thing. It's the one that's yours. I see this over and over again.

(26:07) Another thing that's very important is to have at least one person that is full-time dedicated to being an advocate for it, a marketer for it. Initially, what this person will do is go visit lots of teams and do some educational and awareness driving about what this culture is like, how to use it, and really help spread that word. They'll also get input. If you think about what they're doing, they're treating those developers, those product teams, as customers for this culture. So they're almost advocating for and helping product-manage what that culture looks like.

(26:40) After you get through a few initial teams, what this should turn into - about quarterly, once you have maybe five or six teams, six months or so into this - is you want to start having quarterly internal conferences. They can be online, in which case about half a day, or if they're in person they should be about a day long. You have some of those initial teams that have been successful present at that conference about their experience. You do training at that conference about the platform they're using, about the small batch loop, the product mentality that you're doing.

(27:14) You're using this quarterly cadence of an internal conference to build up awareness and to build up trust, because all the employees are talking to themselves. It's not just fancy pants outsiders like myself who have a bias to make you buy some VMware Tanzu stuff. You're almost talking to yourself, and you're spreading and training this culture. That begins to be a way that you can scale it out. And if you have recordings, it's easier to do this as well.

(27:42) I like to go over this point because this is an amount of training and really marketing that I don't think most IT organizations think about for their software. It's not really just a program office or a center of excellence. It's almost the reverse: these people are going out into the field, if you will, and really working with those teams. You don't get a lot of presentations from the center of excellence - instead you get presentations from the teams themselves in the culture, and they're trying to take ownership and really drive spreading that culture around.

Drawing the rest of the owl

(28:16) So that's just a sampling of, I think, some of the most important things when it comes to scaling culture. There's all sorts of other things, if you want to go read the two books that I have. But I wanted to try to fill in some of those things between the simple circles and the owl. You can see my personal example of the metaphor here - I've tried to show how you go between the circles and the owl. I think that's pretty good. I'm always trying to improve. I'm a risk taker.

(28:44) But hopefully you've gotten an idea of what that culture looks like when people talk about culture, when they're trying to use software as that primary way that they're doing business. And you've got an inkling of the system you need to set up: the attributes that the team has, the attributes that management needs to put into their system. And also a little bit, if you're in a larger organization - or really any size, but especially a large organization - how you can scale that out, how you can be successful enterprise-wide instead of it just being the lucky few teams that are doing it. And with that, thank you.