Digital Transformation Detours: Unpacking the Organizational Hurdles Behind the 70% Failure Rate.

Kasey Canlas, Sudev Balakrishnan, Alberta Soranzo, Adrian Trenaman at UXDX EMEA. Video: https://youtu.be/4i1HdSXTPEg

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introductions and the 70% failure rate

[00:00:00] Alberta: This is really awkward, because I'm here talking to you, but I'm also on the panel. I will not introduce myself, but I will introduce Adrian from Google, and I will introduce Kasey and Sudev, who you might have seen on the other stage, to talk together with me about transformation: the good, the bad and the ugly. Give them a round of applause.

[00:00:28] Adrian: Giving us a round, fantastic. This is my first time doing a silent disco. Can you give me a wave if you can hear? Fantastic. Okay, great. We're here today to talk about digital transformation, and that can manifest itself in a number of different ways for all of you. It could be that you're working on, for example, an infrastructure project, a big change, for example from data center to cloud migration. It could be a big revamp of your user experience, or it could be something that is really disruptive to an industry, and we have some people here on the panel who can really talk about that level of major transformation.

[00:01:08] Now, the sad news, though, is that there's a reported 70 to 80% failure rate on these kinds of projects. That means there are about 100 people in the audience right now, and between 70 and 80 of you are probably working on something that might fail. Now, this is a well-known and well-understood problem. I think we all have some battle scars here, and we're looking forward today to talking through what we have seen that works and what we have seen that doesn't work across different industries. We'll be talking to our panel, and we'll also welcome questions from you all as well, through the app on the phone.

Starting with the user: Kroger and McGraw Hill

[00:01:54] Without further ado, I'll get started. My first question is going to be to Kasey. Kasey is a manager of research ops at Genesys, but has also done some work at McGraw Hill. I'm wondering, can you share some insights on the challenges, and maybe the solutions, for digital transformations that you've seen across those different sectors?

[00:02:18] Kasey: I think sometimes it's not always just one thing and saying, "This is the perfect thing." You're never going to get it right the first time, so you've got to be able to iterate. I worked at Kroger, and it was at the time where they were like, "We're going digital, we're doing it all, we're just going straight digital." And my grandpa was like, "I don't even have a phone. What about me?" There are so many people that we forget did not grow up with technology and do not have access to that, so they're going to be left behind. They might be a significant portion of your audience. They might be those people that use your product the most.

[00:02:51] You really have to think what is the alternate solution. Maybe it's keeping both, maybe it's doing it at a reduced rate. All of the people that you send the mailers out to, several of them are going to be like, "Oh, look at my phone." But what if you can't zoom in? At first they couldn't zoom in, so I was like, "I'm just looking at all these random products, this is terrible." Now I can zoom into the app and it works really well.

[00:03:13] We also did that with McGraw Hill, where they were like, "We're going digital." I was hired to be the digital media producer, and then they were like, "Oh wait, we can't do this, because not all school districts can afford non-stop using a laptop, using a phone, however it might be." Not everybody has access to that. You have to realize what is your customer audience base, what access do they have, what funds do they have, and if they don't have those funds, how can you get around that? How can you think about offering access to both, but maybe in a limited quantity?

[00:03:44] Adrian: I love that, because I think one thing you pointed out there is it starts with the user. I think a lot of organizations get very complacent, and they think that the user is working one particular way. What you're saying is we need to really, really listen and understand what's happening there for the user.

[00:04:01] Kasey: If I did not talk to any of you right now, I would be like, "Clearly headphones are in this year. We should all get headphones, because they're going to be a huge seller." But I don't know the context, without talking to each of you, that you've been told to wear headphones. You have to think of that in the moment, and you do have to go and find out who your user is. And it might not even be, "Oh, they're this type of role, or they're at this type of company." It's what do you need them to do, and look at it by task.

[00:04:27] Adrian: And maybe particularly in the print industry, when you think of McGraw Hill: everybody loves it, and the prices.

[00:04:33] Kasey: Yes, it's always great.

[00:04:36] Adrian: Did the company really grok that moment, that that change was happening and that the digital transformation was critical and important?

[00:04:43] Kasey: It's actually funny that you say this, because we didn't always have a UX team. We didn't have a UX research team, so they were going, "Yeah, we think this is the great way. It's all digital, we should definitely do that." But it wasn't, I believe you said, that the juice was worth the squeeze, because now all of a sudden you're alienating so many school districts that buy your books, and even college students. Yeah, you have a laptop, but did you buy one that's really old and maybe doesn't run the product as well? They were trying to get these huge graphics and animations, and they had to veer and change directions and go, "Wait, it needs to be able to run on shoddy Wi-Fi."

Transformation touches everyone in the company

[00:05:19] Adrian: Okay, let's move on a little. Sudev, you've got this stellar background in finance, obviously through the work at Worldpay, but also through Grubhub, and that's from the financial industry to the retail industry, and obviously quite a lot of disruption in both spaces. Tell us about it.

[00:05:38] Sudev: Definitely. Just to start off by saying: transformation is an interesting word. Applied to each industry vertical, it means different things. It's not one thing to all. I've been watching this word for over two decades now, and it's evolved. Digital transformation, in most contexts, typically refers to the use of technology to solve a problem or improve a customer's experience in some particular way. It permeates not just the front-facing stuff; it permeates all the way down to the back end of how your company works.

[00:06:13] When you talk about digital transformation, you're talking about a company in aggregate, and most companies, when they do this, tend to make the mistake of giving digital transformation to perhaps one group. That pretty much becomes the most loved and feared group in the company, because they'll run for years and years with their budgets, and they will not have the capability to go across the organization and effect the change that you're looking for from them.

[00:06:35] But it's not possible to avoid digital transformation, and that's being driven by the consumption of your service. I worked at Grubhub, food delivery. You want to do what's right for your customer, and to do what's right for your customer you have to be effective at every touch point that you have with that customer. It could be the presentation of the things they see on your front end, whether you talk about the menus, the restaurants, the food you look at. It could be the back end, it could be customer service, it could be operations, it could be marketing collateral material.

[00:07:11] When you talk about digital transformation, you're talking about something that touches pretty much everyone in your company, and that's important to realize, because the way you actually start spearheading that change in your organization needs to be well understood. It is not an isolated team that picks up and does this thing, and it's not just an updated website kind of thought process. You need to be holistic about that thought process.

[00:07:33] I've seen it roll out across multiple companies, and I've seen it work really well, an example of which I'm going through right now. I take a lot of heart from all of you being in the room, because UX and product and design are to me the foundation for proper digital transformation. If you want to get it right, you all have to be in the mix. That's what I would say.

[00:07:58] Adrian: That's really great. And I think you pointed out there a big anti-pattern: there's one core group that's driving all of this. That creates the group that's driving the change, and then the rest of the group, who are looking on from the sidelines and hoping that it doesn't work out. I think one of the biggest things that drives success is having a very strong coalition of people across the entire company who are driving this, and certainly without that coalition you're setting yourself up for failure.

[00:08:29] Sudev: Definitely. You sometimes have to take out fear in the organization too, because digital transformation means certain things to certain groups. Like we talked about AI earlier. So yeah, the coalition is important.

[00:08:40] Adrian: It's a real challenge. I've seen, from my own battle scars, cases where you think that you're driving the change, but if you don't have the cover from above and across, it's not going to happen.

Culture, the model office and the call center

[00:08:51] Alberta, let's talk about your work: end-to-end customer service experiences with Sage. I'm curious to know, do you have any examples perhaps of where addressing organizational culture and behavior was the key to unlocking, to getting people all aligned?

[00:09:18] Alberta: Yes, and I actually lied before, when I introduced myself and I said I don't know what customer experience is. Customer experience is change, whether you call it change or transformation. I see what I do as the driver. The reality is that, especially if we are not in a position to design a system from scratch to support a service or a product, we're going to run into technical issues, or technological issues, technical debt, et cetera, et cetera. But primarily it's a cultural thing. And to piggyback on what Sudev was saying and what you were saying, the perception is often that there is a special group of cool kids who do all the change, and they do it to people. It becomes about an us versus them.

[00:10:14] The thing that I found worked really well, and this was in financial services, but it's applicable to any other industry, was what in systems thinking we call normative experience: help people understand exactly what impact the decisions that they make have on the customers and the bottom line. In this specific case we were looking to transform a fairly highly regulated process, a financial process. I can't share too many details. The issues were, "Historically this is how we've done this thing. You cannot come and tell me how to do it." Which is fair. I think it's fair, and I think that as product and design people we may have been guilty of walking into an organization like cowboys and saying, "I know what's wrong with you, let me fix you."

[00:11:17] In this case we took the people who were responsible for the service and exposed them to the impact, in this case what was coming back to us through our inbound channels, and said, "Okay, let's make a map of how it works right now. And then you help us, because you're the expert on your thing, whether it's regulatory, whether it's compliance, whether it's risk or payment or whatever it is. We'll set up a model office. You'll be in there with us, you'll see customers coming through in real time, and you'll see the effect of what you're telling me to change in real time." And this stuff is contagious. Once you see it working... It's incredibly difficult to pull off, because it requires that air cover from the top, someone to trust the experiment. But if you manage to do it, and I've done it, you can do it, it's incredibly powerful.

[00:12:25] Adrian: It's amazing, and I'm reminded of a company I worked for once. They insisted that all engineers and product managers listened in, at least once a year for a day, on customer service calls. I think it was a huge education, because it showed the massive delta between what the product managers and engineers thought was important and what the customers actually thought was important.

[00:12:53] Alberta: But you know what's even more powerful? When you take the execs into the call center. There's one particular incident, not incident, event, that stuck in my mind. We took the MD of a financial institution into his call center, double headset, and the customer was particularly frustrated. They had strict instructions not to say anything. The agent went through the script, bouncing this poor customer around, and when the call finished, issue not resolved, so your FCR goes down the drain. The exec was furious, saying, "Why didn't you do this?" "I can't, the script tells me this." "But you should have done that." "I can't, this is what my policy says." "Who wrote that policy?" "You wrote it."

[00:13:48] Adrian: Fantastic. There is nothing quite like that.

Research ops: put something wrong in front of them

[00:13:51] Okay, this is awesome. Let's go deep, then, into maybe some of the ways to shift the culture and the behavior. Maybe a question for Kasey. We've already been talking about our customers and really understanding the user. You've got four years of leading and establishing research ops. What methodologies and practices have you found most effective in influencing organizational or cultural behavior?

[00:14:21] Kasey: One of the best things, because I often work with the team, like my customers are the UX team or the UX research team: you may say, "All right, can you tell me your process end to end?" and they're going to think about it. As you heard from Sudev, you're more likely to get bad feedback than you are to get good feedback. So why don't you throw something a little wrong in front of them, and then they'll point out all of the issues that you've made, because they love that. Then you can say, "Okay, here's where we're really having some issues," and we can pull that out and make that a little bit better. It's hard to start from a blank slate, and you don't want to prescribe something for them. You just want to say, "Do I understand this right?" It's really about just putting something there.

[00:15:02] And making sure you say it in their language too, because just because I'm research doesn't mean I can't talk to design, and just because I'm design doesn't mean I can't talk to PM. I just need to know what you care about, and then figure out how to say it in your own words, because it doesn't make sense if I'm not speaking plain language.

[00:15:18] Adrian: I sometimes think of this detachment. I sometimes think of user research as being so far ahead, working with the user, and really ahead of the engineering teams and the product teams. Is there a disconnect there, and how do you bridge that disconnect sometimes? How do you build a really strong relationship?

[00:15:42] Kasey: UX goes across the board. The earlier you can get in, the better, because why are you solving a problem if you don't know it's actually a problem? That's not what you want to be doing. You want to know that you're actually doing something that's worthwhile and not just throwing paint at a paper. Not that that's what you guys do, I know. Unless you're an artist, and maybe that is; you could be Jackson Pollock for all I know.

[00:16:04] It's really about making those connections and talking to PMs and saying, "Here's where I'm coming from, here's what I want, what do you want?" Or even talking to design, because as research it's saying, "I need to know what you need from me, and then I need this from you," and having a good working relationship. Research is not there to slow it down. It's there to inform you, so you're going the right way and you're not going 80 miles an hour down the road, or I guess it'd be kilometers, 80 kilometers down the local alley, I don't know, and all of a sudden you're like, "Wait, we went the wrong way, we missed a turn."

[00:16:39] That's why you need to have research there throughout the whole thing, throughout betas, all throughout the process. Just pull us in. And even if you don't know if you need us, have a conversation with your researcher and say, "Hey, does this sound like something we should pull research into?" They might tell you, "No, don't," but they might tell you, "Yes, we need to be there, and this is why," because they're seeing different things than you are. You're both great sides of the coin, and you need to be there together in order for it to flip successfully.

Horizons, value drops and balancing commercial and technical

[00:17:05] Adrian: It's great. Okay, let me think. Sudev, obviously you've got a strong background in both business and computer science. I figure that you're balancing in your mind the technical innovation, some great ideas that are going on on the floor, with the behavioral and organizational aspects that need to happen. Talk to me a little bit about that. How do you balance both, and maybe how do you suss out when a technical innovation isn't going to stick, no matter how great it is?

[00:17:39] Sudev: That's a great question, one of the hardest questions I constantly get. I've run product, I've run research and design groups. My background, he said strong, he didn't say good, just keep it at strong, spanned business and spanned product build-outs. The trickiest thing for us to do, and I'll tell you this is not an issue with one person, this is organizations in their collective, is to think about things in the dichotomy those things actually have.

[00:18:09] What I mean by that is, if you think about companies, and I'm not sure how many of you are there, we're in an evolving field. Product, UXR, you're getting tied at the hip to the customer; that's what's happening. But a lot of organizations are still in delivery mode. They want to know what can we get done tomorrow. The concept of using horizons is really important in your organization: what are you going to do for tomorrow, what are you going to do for six months, and what are you going to do for two years. I don't do five years, I do two years; that's the limit of the horizon.

[00:18:42] The concept Kasey was talking about also applies, for example, to thinking about your customers. You have different kinds of research: you have generative research, you have qualitative research, and you need to know how to understand your landscape to be able to level them into those pieces. From a commercial aspect it's the same thing. In any part of your organization, what you'll tend to see is that you don't have a one-size-fits-all approach. You need to have a balanced approach.

[00:19:06] The risk you run as you take a balanced approach is that you don't look sufficiently forward-looking, because a compromise is not always the best positioning for what looks like your product's vision, the company's direction. People want to say, "I will land something on the moon." That's what they want to hear. It's aspiring, it's inspiring. They don't want to hear, "Tomorrow I'll build a little bicycle, in six months I'll possibly get a little car, and then in maybe six years I'll get someone on the moon." That's not how people gravitate towards visions. You still need a collective vision that's really large, but under the hood you need to start compartmentalizing your work.

[00:19:44] You need to understand from a commercial perspective how you are going to triage between your quarterly and your annual. If you're a public company, I do not envy you. I've been in that place as a CPO. Commercial interests have to be married to your technical interests. Any of you in slightly larger companies are going to have debt of significant scale, and you're not going to be able to retire all that debt tomorrow. I'm sorry, no one's going to give you the license. You might be a visionary and you might be really good; you're not going to do that. If you're doing research, same thing. If you're doing design, similar thing.

[00:20:15] I think it's about compartmentalizing these pieces appropriately, creating balance with them, but then tying them together with a narrative around the customer. When you say customer, people say, "Why do people keep repeating this word?" It's simple: we all gravitate towards the emotion of a customer's experience. You have to bundle that whole package back into that storytelling, which inspires your internal employees, and you also inspire outside.

[00:20:45] Adrian: I love that, because I think one of the major reasons why big change initiatives fail is because they actually take too long. Someone has a three-year vision or a four-year vision, and it's probably great if you get there, but the problem is that without near-term milestones or deliverables that really impact the user and show that this path is right, you're doomed to failure. Do you find yourself giving feedback to teams to say, "Hey, I like what you're doing, but what's happening six months from now that I get out of this?"

[00:21:17] Sudev: Absolutely. In my presentation, when I played it, we talked about the concept of value drops. Our roadmap is all value drops. When I joined Worldpay, about two and a half years ago, I said, "I don't want you to talk to me about any project over two years. Not doing it. I want you to tell me exactly the value drops." You can have extensions of time. I've been in software and computer science for a long time, and this perfection that computer companies tend to desire, "I need to know, will you give us this particular feature in February of next year?", is a myth. Software does not work like that. People are prone to fail, and if you do not have acceptance for that kind of culture, you're probably not tapping the potential that you have in your organization.

[00:21:55] In my world, my product roadmaps are actually customer value drops, and they're all time-bound horizons tied into a story. Even if you're doing a digital transformation that might take three years, I'm going to ask you, what do I get in three months, six months, 12 months? And that's a cultural change, by the way. Where I worked before, we used to have five-year and ten-year projects, and there was fatigue. At Worldpay, when I came in, there was a lot of fatigue around transformations that had happened over five years, ten years.

[00:22:25] One of the first things I had to do was cultural change with the business, to say, "I'm going to set up our trust relationship. We're going to do value drops for the next year, and you can hold me accountable for all the failures of the past. I'll own it, even if I was not there. It's okay, but we're going to have a different culture." And since I've been in a business role, I can stand off against a commercial leader and say, "Okay, my job is not just to build, it's to make sure I build something you can sell, and I'm going to hold you accountable for everything I build. You can't tell me that I need to build more to sell more." It's not that he built 500 features, it's that he built 250 right features, because you're not going to always do it right.

Agile, "fragile" and where it doesn't work

[00:22:58] Adrian: Okay, this is great. A question for Alberta. You've got a lot of experience with agile.

[00:23:06] Alberta: Are you calling me old?

[00:23:08] Adrian: No, calling you experienced. Okay, agile. We're all agile, even when we're not agile. But when you think about it, one of the dreams and goals and promises of agile is weaving in that constant user feedback, and maybe having earlier signals of progress along the way. Does that ring true for you? Does it work? Do you feel that agile has given us something here?

[00:23:38] Alberta: The form of agile I've seen done most commonly, both as a consultant and in-house, I can only define as fragile. The principles are absolutely sound; it makes sense. I am not sure that the implementation of agile, especially in large organizations, has been particularly easy. Agile doesn't work for everything. When you are developing software, when you are producing something, those iterative cycles, the continuous feedback loops, are the best way to go about it and the best way to maintain velocity.

[00:24:37] Where I find agile does not work is when it gets applied to the entire life cycle, including the strategy phases. You can't go faster in thinking. You can't necessarily go faster in researching. You can't go faster in a lot of other things. I think agile works really well when it is just one of the speeds at which an organization goes, and when it's deployed where appropriate. I don't think that waking up one morning and saying, "We're an agile organization from now on," is going to work.

[00:25:22] Especially when you're in corporate, you get sold a lot of consultants on how to do agile: scaled, unscaled. I've seen waterfall agile done, et cetera, et cetera. It is all about applying it where it makes sense to be applied, which is not everywhere. But to answer your question very directly, I've never seen it done effectively.

[00:25:52] Adrian: For me, the most effective agile teams are the ones that maybe start at a team level with a framework and then slowly remove almost everything in the framework that doesn't work for them as a team, and then they land at something that I think does work. The hallmarks of those successful teams: I do think regular iterations, two-week sprints, seem to be a good thing, and then planning for 90-day intervals, because I think you've got good visibility over that, with a reasonable view over the year or the two years, but nothing at a definition level. You can definitely focus on the next 90 days.

[00:26:33] Alberta: Yes. I think agile's strength is, or should be, the ability to pivot and to respond in real time to the feedback loop that you're a part of. When agile becomes just another process, subject to all the risk assessments, then it becomes so rigid that it is fragile. I've seen it work well in certain instances, but done at scale, where risk management is the primary concern, it becomes really tricky.

[00:27:18] Sudev: Got it. Just to add to that: when I first joined Worldpay, they had a version of agile, and they asked me, "What do you think? We are SAFe agile." I responded back, "I think you're very unsafe agile." That's because large organizations tend to bring in agile through a wrong process. It's typically a useless leader like me who attends something and hears about a 30% efficiency gain in output, and decides he's going to take the engineering organization through an agile process, and brings external consultants in to do the agile.

[00:27:53] But to be truly agile, to your point, multiple teams need to be involved in agility. It is not a tech-alone or product-alone exercise. You have to get the organization to rally like a tribe, but on some outcomes, and it's really hard to organize that in large companies, especially companies that are organized by what I call a RACI-like matrix. Each of you are functional: you're a designer, you're a researcher, you're an operations person, you're a customer service person. It gets really hard, because you have waterfalls that start popping up between the functions.

Shiny ball bias and too many big rocks

[00:28:21] Adrian: Nice. All right, I think we're getting close to time for questions from the audience. I'm not sure whether we can project that. We have no questions yet. Take those phones out, listen, but write the question. While you're all thinking of your questions, I do have maybe a provocation for the panel. I think that organizations sometimes have what I'm going to call shiny ball bias. This is where we see a vision of the future, and it might be, "Let's rewrite the core product on the cloud," or something like that. Everyone's excited about it, and everybody can see that that vision is definitely a brilliant place to be, but they don't factor the cost of getting there into the vision. When you add the cost into the equation, it just doesn't work. It's a sad no. Have you ever experienced that? Have you experienced those moments when you have to tell a team that the juice is not worth the squeeze?

[00:29:24] Sudev: Yes. I can kick it off and I'll pass it to Kasey and Alberta on this. Your role in an organization is definitely to be the custodian for the right things to do for the organization. That is a product team, whether you research, whether you design; that's your role. Invariably in our job we have the job of filtering through all the inputs that come in, and you have to do things. But frequently I've had the reverse problem, which is that in large organizations there's fatigue with transformation, so there's no trust to be able to complete it, which means every two years a new shiny thing pops up.

[00:30:00] That becomes a problem: "Oh, I've lost the muscle to actually finish this, I'm going to do a new shiny object." It's called shiny, sometimes called big rock; it doesn't matter what nice name you give it, but it's a new big thing. I've found usually the problem is one of underestimating, perhaps, to your point, but also fatigue as you go along the journey. And sometimes you have too many big rocks. Everything, including a little pebble, becomes a big rock that you have to do. That is the thing I've seen. Kasey?

[00:30:24] Kasey: Awesome. And when something doesn't wrap up in a nice shiny bow and it just keeps carrying on, you're like, "Wait, I've got more nice shiny objects I want to get in here," but you can't, because you're jam-packed. It's one of those things where it's good to know priorities, and it's good to say, "Hey, I can move on to this one, but if you want me to, I'm going to have to let go of these two things. Is that worth it to you?" Talking to your PMs, talking to the researchers, saying, "Well, we don't know enough about this. Are we willing to take the risk that this is completely off base? You let us know if you do, and I'll just document that."

[00:30:55] Then when you say, "Well, why did we do the wrong thing?" I'll say, "Hey, look, I wrote it down right here on this date." And they'll love that; they'll really love you for it. But it'll also help inform them the next time that they're trying to do that again, because you'll say, "Remember when we ran into this? Maybe we should add a couple of extra weeks, maybe it should carry over another sprint, and we get this finished before we take on something new, so we're not dividing our time."

Q&A

[00:31:15] Alberta: Okay, I will step out of my panelist seat for a second, because I really want to address... I found myself in the same situation, but I do want to address the questions that are on the screen, and I will step back into my panelist seat to answer the first question that I see on the screen, because it's one of my favorite topics. The question is from Anonymous. There's no shame in asking questions; put your names, we want to know who to address. But Anonymous says: "In my B2B organization, the mantra from the CEO is that we don't sell to users, we sell to buying centers, so we should design to those requirements. What does the panel think of that attitude?" I will respond. Sorry, Adrian, I'm doing your job.

[00:32:06] Adrian: That job and my job. I love it. Go for it.

[00:32:08] Alberta: I will answer that question because I prefer to work in B2B. I don't know where the question came from, but good thing. I prefer to work in B2B precisely because of the complexity that comes with the layering of the roles. Whoever that is: it is true, you do not sell to users, you sell to customers, but users are who are going to use your product. The larger the segment your product or service is sold to, the more layered it's going to be. You may do a soft sell or a pitch to the CEO, then the procurement center does the physical purchasing, and then you've got maybe the CFO, if it's a financial services product, that uses it for certain things. But if you're dealing with a bank, you've got mandates, and there are lower-level users.

[00:33:06] The answer to me is you should design for everybody. You should have distinct journeys, distinct rather than separate, and you should have distinct outputs for all the various audiences that you're selling to. I don't know how you guys feel.

[00:33:29] Adrian: I would add, because I think you said there we have to design for everyone. I don't think that's a cop-out. I think this is a polarity to be managed here. You've got the needs of the buying center, the customer who is writing the check. You've also got the needs of the users. I think most of the time as designers and engineers we care about the users, but we need to be mindful of both, of course.

[00:33:52] Alberta: And then you measure different things. When I was working at Vodafone on the B2B side, we used to sell to, say, banks, or to the Royal Post, sorry, the Irish post here in Ireland. Whoever buys the service will need a certain type of experience, but then the people who actually manage the phone lines, the device management, need different things. So you've got to design for both.

[00:34:23] Kasey: Got it. And how often have you had some product where you're like, "This is great, we definitely love this," and then you go and actually use it and you're like, "This is not so great, and I can't get my people to use this, because they don't know how." The functionality's not there, or maybe it's just not well documented, and you're just clicking around like, "I don't even know where I'm at right now, but I'm trying to use it." You have to have both sides, always. You have to have the people at the top and the people at the bottom, because eventually the people at the top are going to talk to the people at the bottom and go, "This isn't it. We're not even using it, it's not good value for our money, the adoption rate's terrible." So you really have to think about all parties.

[00:35:06] Alberta: Okay, next question. I think we have time for another one. "How do you evangelize transformation within your company when you're not part of the C-suite?" I think this is particularly relevant. Oh shoot, guys, I'm sorry.

[00:35:20] Adrian: No, you're good.

[00:35:21] Alberta: It's particularly relevant because not all of us are in the C-suite. In fact, I would argue most of us aren't. So, Sudev.

[00:35:30] Sudev: Oh, that's for me. That's what you get for being in the C-suite. I'll address this question for sure. There are things where sometimes you stop yourself. It's one of those questions where I truly believe: do not stop yourself from advancing your value propositions. For example, I'm quoting Obama here, where he gave advice to people on leadership. What he said was he looks for people who come with solutions, because the vast majority of people, and I can tell you this even though I'm in the C-suite, come to me with problems, not solutions. If you want to evangelize something, take a solution and frame it in a value proposition to the company, to the customer, and I can assure you that if you can't directly do it, you can find a sponsor in the C-suite to take it forward. But it will all depend on your solution-oriented attitude, your attitude towards success and winning.

[00:36:27] Each one of you touches something which is important to the company. The frequent thing is, "Why am I not important in this moment?" That does not matter. The company has an appetite for a certain number of things in the moment, but the moment will arrive if you are sufficiently a champion for transformation, things like transformation in your area, if you're solution oriented. If you bring AI into the company today, I can bet you're going to get a meeting within five minutes, saying, "I can actually do something." Maybe it won't finish; don't get disheartened.

[00:36:56] That question tells me that you may feel someone else will stop you. I can tell you, the truth is you will be stopping yourself. If you felt the C-suite is the way to go, it's not. Modern product engineering companies follow what I call the inverted power pyramid, which means the grassroots teams, which do all the work and touch the customer, are the most important teams in the company. People like me are called HiPPOs for a reason: highly paid person's opinion. Irrelevant in the modern age, slowly decreasing in time. Our job is to sponsor teams. It's not to pick the ideas that actually matter.

Closing: transformation is here to stay

[00:37:29] Alberta: Amazing, thank you, Sudev. I think that unfortunately these are all the questions that we have time for right now. I see there are a lot of questions.

[00:37:37] Kasey: I can answer them on the Slack, if you all have the Slack.

[00:37:41] Alberta: I would like to thank Adrian, Sudev and Kasey for being here with us, and myself. Thank you for showing up today, thank you for being here. They're also offering their time to answer questions. They're going to be here today, or you can find them online to chat. Please remember to offer them feedback through the QR code. Can we show the QR code on the screen? There we go, same QR code. Oh, someone has already submitted feedback: one submission received. Thank you, whoever you are, love it.

[00:38:27] My takeaway, and I think we've all said the same thing, is that whether we like it or not, whether we officially are in a transformation program, transformation is here to stay. I saw on the screen there was a question about whether it should be continuous transformation. Yes. It shouldn't be; it already is. Change will continuously be with us and around us, and this is the place where you heard it first. Thank you so much for being with us. Don't forget the feedback, and let's give them a big round of applause. Thank you for coming.