Episode 13 - Design Driven SRE

Karel Vredenburg: It's actually a skill, I think, enterprise design thinking, that everybody should have. It's truly like learning how to read, learning how to write, those kind of fundamental skills, that this creative problem solving is really what this is.

Kevin: Hi everyone, welcome back to another episode of the Making of the SRE Omelette Podcast, where we explore the positive business and client success outcomes from site reliability engineering, and how experts influence the cultural and mindset shift that led to those results. Enterprise design thinking has positively influenced how companies build products that deliver happy user experiences. Can this same practice and mindset be applied to SRE? And if so, how? Joining us to discuss this topic is Karel Vredenburg. Karel is a VP of client insight and research at IBM. He's a great champion of tech vitality and has tremendous industry experiences improving the user experience of human interface to technology. Welcome to the show, Karel.

Karel Vredenburg: Thanks so much, Kevin. I'm really looking forward to this conversation.

Kevin: Hi, Karel. I can think of no better person than you to speak on the subject of design. Besides having led IBM design, you also have over 100 conferences, publications, have also taught design at universities and colleges. Can you start by sharing with the audience what is enterprise design thinking?

Karel Vredenburg: It basically is an approach to use the kind of thinking that designers use, that anybody can then actually use. It starts with really trying to understand the problem deeply, especially from a human point of view. That might be the user, might be a stakeholder. But, fundamentally understanding deeply what the problem is. Then, figuring out what the most important problems are of all the problems you've seen. Then, going into a session of ideation, where you get ideas for how to address the problem. Very importantly, you don't just do that out loud, you do it quietly by yourselves, if there's a group of five to 10 people. It's really important to do it that way because you will get that quiet person that doesn't necessarily say a lot might have the best solution to a problem.

Kevin: That's true.

Karel Vredenburg: Then, once you determine some of the ideas, then you vote on which of those may be the most impactful and also the most feasible. Then, go into prototype what a solution might look like, and then get feedback on that as well. It's basically that simple. It's easy to say, harder to do.

Kevin: I know that makes a lot of sense, but it's not always been like that. Karel, can you take us back to what was it like building software before enterprise design thinking?

Karel Vredenburg: We had, before enterprise design thinking, we had user- centered design actually. Which, I also introduced into IBM in the 1990s. That had lots of the same attributes actually, of it. But what was really different... We ended up doing things like task analysis to understand the user, we would prototype, get feedback and the like. What's different with enterprise design thinking is really what we call the modeling methods and the collaboration methods. It really was a super fast way. If you're doing a whole bunch of interviews with people that are your users, or your stakeholders, or colleagues for that matter, in the past it would be really slow and you'd end up having to document all this stuff. Now, we do something like an empathy map, where everybody just takes either digital or physical sticky notes, and write down a few ideas on the board, you can move them around and the like. After a few minutes, you've actually done what used to take months before.

Kevin: Right, right.

Karel Vredenburg: It's really the collaboration methods and the ways of capturing, and modeling, and mapping the ideas, and moving ideas around and the like, that really is the unique contribution of the enterprise design thinking method.

Kevin: I remember not that long ago, five, 10 years ago... Well, some may think that's a long time.

Karel Vredenburg: Right.

Kevin: Building the software is not weeks and months effort, it was years.

Karel Vredenburg: That's right.

Kevin: The time we finished design, it took the team months to iterate through the different testing phases before we finally released to the customer. Often, I remember, " Oh, wow, that's not what customer wanted."

Karel Vredenburg: No, that's a really good point, that it would take a whole release. The other addition to enterprise design thinking is agile methods. Where you're not now what we used to do with waterfall. You do this understand the problem, build for a year, year- and- a- half, or whatever, and then find out that it wasn't actually what users wanted. Now, we can do that way more iteratively.

Kevin: Was there an aha moment to you when you said, " We should do this differently?"

Karel Vredenburg: It was. I've done this kind of work for most of my career. But about 10 years ago, very close to here, we had a new CEO that came into IBM in 2012, Ginni Rometty. She came internationally on the second day of her job, to go international from New York. The fastest way to do that is come to Toronto, so she was actually in our amphitheater that second day on the job. I heard her say, second thing out of her mouth was the client experience was going to be the key focus for her. I basically, right away, sent an email off, start to do the very thing that she said. We were going to have a supportive CEO on this work. To make a long story short, and it is a long story, we basically had a set of alternate methods we were looking at and evaluating, and we were also looking at, I did an assessment of a number of designers we had at IBM at the time, designers and researchers. We had a total of 230 for the whole company. The company, at the time, was about 400,000 employees.

Kevin: Right, fractions of a percent.

Karel Vredenburg: That's right. And also looked at, we didn't have dedicated designers. Some 58% of the designers worked on more than one product. So you think okay, here's a problem. We did make the proposal that we should hire a number of designers, we said maybe 1000, 2000. We now have 3000 designers in IBM, as well as researchers. More recently, and that's my current role, also looking to increase the number of researchers, UX researchers, to really are the ones that are specialists at understanding the problem. But getting back to your aha question. It was when I started to teach, or we call it activate because it's actually experiential learning. You're not being taught, but you're learning to do it while doing it. With enterprise design thinking, initially around the various product labs around the world, and then with our consulting organization, and then the sales organization and the like. But, the earliest experiences in starting to teach this stuff was that there was no pushback on it. Everybody was, even the most ardent people that were against the importance of design, let's say, when we were going through this, were saying, " This makes perfect sense."

Kevin: Right.

Karel Vredenburg: "We should be doing it like this." One person, actually an architect from the Toronto location, during one session in Austin, Texas, pulled me aside and said, " You know, Karel? I've been working on this product for 15 years. In a 15- minute exercise, I got more clarity on what we need to be doing with the product." That was an aha.

Kevin: No, that's fantastic. Karel, I used to joke with my team. You know a product or offering's important when they got designers.

Karel Vredenburg: Very true.

Kevin: Enterprise design thinking has took us to new level of building software, and I definitely see great outcomes from that. However, I haven't seen many cases of that being applied to solving SRE problems, to solving operation problems. First of all, do you think enterprise design thinking can help us solve those problems as well? And if so, how can we change our mindset or how can we get started there?

Karel Vredenburg: I've been saying for years, like I said I teach this stuff too, and I challenge students and also even faculty to come up with something that enterprise design thinking is not appropriate for. I'll give you one example.

Kevin: I love that question.

Karel Vredenburg: I had one session, I was at Brown University with the senior faculty there. This one woman who ran theoretical math and said how about that? I said, " Tell me a little more about what you do." She would run a session once a year, where she would invite the brightest mathematicians around the world to solve key problems that the world had. She had this building, it was like the white board wall here but three stories high, with moveable ladders and the like to go up there, and it was all equations.

Kevin: Wow.

Karel Vredenburg: Anyway, she said, " That's what we do." I said, " Well, how do you determine what problems to work on?" She said, " Well, we send emails around to one another." I said, " Okay, here's the solution for doing that kind of work." Taught her how to do this stuff, she now does that in order to come up with the most fundamental problems. Same thing with sales. I work with the the sales team, tech sales. They're like, " Well, how's this relevant to us?" Basically, did sessions with them and think about it from the point of view of too much of the time, we try to sell what's on the truck. In the sense that, here's our product, we're going to try to convince you that you need this.

Kevin: I built it, you need it.

Karel Vredenburg: Exactly. As opposed to really trying to understand the client really well, and then determining, " Well yeah, I think this product would be..." You know what, some of the time, being honest and saying, " We don't have the solution for that," or whatever... That actually, in the work that I did there, we had one year I worked with the part of the company that is now Kyndryl, and we looked at the sessions that we did with enterprise design thinking with clients, versus the ones that we didn't, in terms of a sales pursuit. We made$ 5 billion more in one year with the ones that did. That's what was the-

Kevin: Wow.

Karel Vredenburg: Part of the inspiration for the client engineering organization that we now do. But, getting back to your SRE question, I'm basically saying it's relevant to any. I think that, when you think of what SREs do, when you have a challenge and you have a problem, really understanding it deeply from everybody's point of view. If you've got a problem, you're like, "Oh my God, we've got some outage or whatever that we need to deal with," trying to get to the cause of what that problem was from a variety of different perspectives. If you've got five people working on the team, or whatever, quietly get their input. Then, in terms of even coming up with ideas for how to solve that problem, having those ideation sessions, and doing them like I said before, without the loudest person in the room speaking.

Kevin: Right.

Karel Vredenburg: But instead, actually ideating with everybody coming up individually saying, " How about this?" Encourage them to even come up with crazy ideas. Because the crazy ideas, a lot of the time, will still get you to the point where it's like, " Wow, I had never thought of that before."

Kevin: Right, right, right.

Karel Vredenburg: I'll give you an example. After this session with a utilities company that was talking about... The problem that they had was that the power lines that they had were breaking because they had snow and ice on them.

Kevin: Right.

Karel Vredenburg: I do this exercise to get them to ideate on crazy ideas, and somebody drew a picture of a bear climbing up the pole and shaking it. But when that person presented it to the group, then somebody else said, " You know what, we fly helicopters across that all the time. Let's test to see if we can fly them close enough, safely," and it would blow the water, or the ice and the snow off. That's what they do now. It's those same principles, then applied to the SRE domain, I would think as well.

Kevin: Taking perspectives of everyone involved to build service and consume the service, and that really opens up opportunity to challenge the status quo. I love that perspective.

Karel Vredenburg: Then, you could also get brand new things. My understanding, in terms of where SRE started, with that team in Google.

Kevin: Yeah.

Karel Vredenburg: I think they're innovating. Well, we could be innovating in this whole space by not just doing things that were always done, but to have brand new ways to do it. You can get that with these kind of methods.

Kevin: That's a great perspective. Karel, suggestions on how we get there?

Karel Vredenburg: It's actually a skill, I think, enterprise design thinking, that everybody should have. I said before that I challenge people to come up with something that it's not relevant to. I think it's truly like learning how to read, learning how to write, those kind of fundamental skills, that this creative problem solving is really what this is. It really should be taught in elementary school, and high school, and universities, and the like. Certain jurisdictions are doing that. Like in public school, for example. I teach it in university, I teach it to executive MBA students, so that they can inject into their companies, boards or directors as well. Teaching a class this Saturday actually, on that. I've been involved in this initiative, together with one of the biggest design gurus in the world, Don Norman, who wrote the book on this area. He actually is the one that inspired me first to develop user- centered design at IBM. He wrote the book, 1989, on that, that I adopted. He and I are now working together. We launched an initiative called The Future of Design Education. We had some hundreds of academics and people from business to design what the curricula should be for the future. For not just design education for designers, but in business schools, engineering schools. Everybody should really have this understanding of how these creative problem solving methods should work.

Kevin: I think you just inspired many listeners to start learning how to embrace design thinking to problem solve. Karel, do you have suggestions on where they can start that journey?

Karel Vredenburg: Yeah. A really good way to get started actually is we have, right on IBM.com/ design/ thinking, will take you directly to a website, free education. There's a two- hour module that will also give you a practitioner badge.

Kevin: Oh.

Karel Vredenburg: That you can put on LinkedIn and the like as well.

Kevin: inaudible

Karel Vredenburg: Then, we have upper level ones as well. Yeah, you can start there.

Kevin: Karel, enterprise design thinking has given us tremendous benefit that led to business and client success. Any thoughts on what's next?

Karel Vredenburg: What I'm leading now at the company, I've been in this new job for about eight months, and really looking at when we mention in really understanding humans that we're trying to improve the lives of, understanding the problem deeply, and then gathering feedback on it and the like. That activity is done by trained people in what we call user experience research. Some designers get a little bit of education in that and can do it, but you really need specialists in it.

Kevin: Right, yeah.

Karel Vredenburg: It's typically also done with people that have PhD education in that. My new team, there's basically 100 researchers in the software and cloud organization, they will report directly to me. There's a total of about 350 researchers across all of IBM. That's a whole discipline that is really getting into it's ascendancy now, realizing that the more we can deeply understand, for example, the unmet needs of, let's say new logo clients. We want to now go to clients that we haven't had before, that don't know how to spell IBM.

Kevin: Right.

Karel Vredenburg: In order to do that, we need to really deeply understand where they're at. What do they need that we don't currently have that we need to improve upon? That's typically done by the specialists of user experience researchers. Anybody can ask a question and learn something.

Kevin: Right.

Karel Vredenburg: But these researchers will do it in the appropriate, rigorous way. To be able to have a sample size that's appropriate, they'll do the data analysis on it that's appropriate.

Kevin: Right.

Karel Vredenburg: And make sure that we're actually reliably getting information. My biggest worry is that certain product features are put into a product because an executive talked to one client, then the rest of the industry didn't need that.

Kevin: Yeah.

Karel Vredenburg: It was that one client that needed it.

Kevin: Right.

Karel Vredenburg: Well, that's why you need to have user experience researchers.

Kevin: It's the saying the squeaky wheel gets the grease. Yes. Often, some of those change our product roadmap to tailor to the customer that complains the most. There may be others out there that need something different.

Karel Vredenburg: Yeah.

Kevin: Here's a tough question. If we have unlimited resources, we can staff every team with designers and researchers, but the reality is that's not the case. I'm sure many audiences are wondering, " What can we do to scale out this way of problem solving via enterprise design thinking in those cases where staffing is not possible?"

Karel Vredenburg: I think that there are various things that we can do to support teams like that. We typically really want to just staff properly. Right now, if we're not drastically hiring right now, I think we should be trying to support the teams that are doing that. One of the ways that we've done it before is having the occasional critique session, where somebody comes in. I've done that over many, many years, less so in the last 10 years because we staffed up appropriately on certain product. But I think there's also the opportunity to basically have the team do their work best they can, and then have a little slice of time, a couple of hours let's say, of reviewing what's there, and then making modifications. Not just when it's coded, the earliest stages.

Kevin: I like that. Having design thinking office hours, perhaps, where teams can bring in the problem they're trying to solve and get feedback. And doing it iteratively, while we're building versus after the fact, because once it's coded, or worse yet in the field, it gets more expensive to change. Karel, thank you so much for taking us through the fantastic journey of enterprise design thinking. Just one last question. What would be your ingredient and recipe for building products that leads to happy users?

Karel Vredenburg: I think it's basically the things that I've said thus far, but doing that on steroids. Making sure that you are honestly stepping back and saying, " Are we doing things as effectively as we can?" I think that we have this new term that's around the industry called product led growth, and product led growth is all about happy users. What does a happy user do when they start to use a product? Let's say they're just trying one. ChatGPT might be a good example. They're going to share it, they're going to tell everybody all over the place. As a result, you don't actually have to sell the product, this product sells itself. The most important ingredient to doing that is just making it have really, really amazing design. To the point where you are so delighted, that you're going to share this stuff with others. Now, we need to do some things to ensure that we optimize that. When somebody has heard from somebody else that there's this really great product, that we can really make sure that you can try it themselves really quickly, and then buy it, and the like as well. A large part of making something and creating happy users, basically is make sure it's got amazing design, and then ideally, then make sure that it sell itself, and that you can also then have the follow- up directly with them in the future. A good example of that is the product Zoom. When it first came out, I bought a copy, a number of other departments bought a copy themselves. Departmental sales. It wasn't CIO that bought it, initially. It was because everybody, word of mouth went around. That's what we're after. The way you get there is doing the very things that we've already been talking about, enterprise design thinking, but also really importantly, having the best skills in user experience research, and design, visual design, content design, user experience design and the like as well. Amazing software engineers on the product. Really importantly, great product managers. There's a huge focus in the company on that. It's doing everything that everybody has as their responsibility perfectly, and then working together as a team really effectively as well.

Kevin: I love it, Karel. Getting people to love your product with your design, and then amplify it with ease of people trying, and buying. There you go, ladies and gentlemen, the ingredient and recipe for happy users from Karel Vredenburg. Thank you so much for spending the time with us, Karel.

Karel Vredenburg: Thank you so much, Kevin. I really appreciate it.

Kevin: I would also like to thank you, the audience, for listening. See you on a future episode.