 Live from San Francisco, it's theCUBE. Covering Red Hat Summit 2018. Brought to you by Red Hat. Okay, welcome back everyone, we're live here in theCUBE in San Francisco, California, Moscone West. CUBE's exclusive coverage of Red Hat Summit 2018. I'm John Furrier, co-host. But John Troyer, my analyst co-host, he's the co-founder of Tech Reckoning, an advisory and community development firm. Our next guest is Marco Bill Peter, Senior Vice President, customer experience, engagement at Red Hat. Welcome back to theCUBE, good to see you. So, see, you guys have a great track record with customer support. You guys through the gold standard and open source, you've done it for years at RAL, very reliable. It's a changing world, you know, open shift now, certainly the centerpiece, CoreOS, new acquisition, a lot of things happening within the portfolio, cloud native, new capabilities are on the horizon. And so, you know, you got to figure it out. So, what, you know, what's the support strategy? What do you guys do? How are you looking at them? I'm sure it's challenging, but never too much of a challenge for you guys. You're smart. What's the support strategy? Well, I think the recipe is really like not getting stuck in a way, right? I mean, and be open to, you know, like I think Jim Wighters and his keynote talk quite a bit about, you know, you used to do all the plan, describe, and execute. That thing just doesn't work, right? Because supporting customers on Linux, supporting them when they move to open shift or even application development. It's a whole different piece. So, as a leader, you got to be flexible as in, okay, this is here, we do it this way. Let's put more money in this, let's say, open shift support, open shift, you know, kind of how, what's the customer experience there, right? And kind of figuring out how it works, right? And it's just, there's a lot of things that scare me in the daily business, as in like, okay, can't do that. But I think Red Hat is really good in reconfiguring. Jim talked about that in the keynote as well, reconfiguring the organization. So, we move, for example, quality assurance into my organization and combining that with support. All of a sudden it gives you more opportunities realizing, well, this product may be not ready yet for the market, right? We cannot support that. Or you augment it with, I wouldn't call it AI capabilities but more like those capabilities. All of a sudden, stuff gets done automatically, right? And multi-cloud is, again, just like multi-vendor environment, but it's a little bit different, obviously. Multiple clouds, you have different architectures. You guys do some progressive things. What's new architecturally within the support group? Because you have deals announced here with IBM and Microsoft. One of them is a joint, I think, integrated program where you guys are teaming up. Microsoft is interesting, right? We've teamed up last three, four years, right? With the first deal and going further. You're like putting, you're like, funny, right? I've been at Red Hat so long and you put people to retiment on premise, right? It's kind of funny. But it's good, right? And that's what you got to glue together. Sometimes it's people, sometimes it's also more having the data, right? I mean, if you go multi-cloud, difference between multi-vendor, multi-cloud, multi-vendor, you just call the vendor and tell them, hey, you handle it here, hot potato, you handle it. Or maybe you do it a bit better. But multi-cloud is, well, it's running there. How do you get access to that? And then the whole privacy loss comes in. So you got to be more instrumentation, telemetry that you get into. In fact, to help you guys out. That's what you're referring about AI. I actually think in the next 10 years, you will see support changing quite a bit. In what way? But also you have to staff this up, right? You need to up-skill your folks, as well as technology. Can you talk a little bit about what's up? Up-skill the people, right? That doesn't go away. But I think it will go more and more that you really need deep skills. But if you want to support OpenShift, you got to, either you understand it from the middleware side, from the application side, or from the bottom, from the infrastructure. But you need both skill sets. So you need really highly skilled people. But on the other hand, if it's really like real-time and people don't have patience, wait two weeks, still, especially if you're on the cloud. So more and more tooling. I see the vision as in, it would be less and less, well, maybe based on the scale, but I think it's less and less people involved and more and more automation, tooling. You kind of see that now with bots, kind of just tipping the iceberg. But you got automation built into the culture of Red Hat. You bought Coro-West. They want to automate everything. They got its operator framework. Ansible as well, right? I mean, like, you see insights, right? We launched insights three years ago out of support, right? It was basically take support data, find out what's really happening, create rules that if you match it to customer systems, hey, you have this and this issue, right? And now it's in the center stage of the strategy as in we can automate this. And then you connect it to Ansible, you can automate it. You have a problem, you want to have it solved. It's like provisioning a service. You're provisioning a support service. Exactly. Eventually, it will not even tell you, hey, that it may be hindsight will tell you, hey, you had this network issue configured the wrong way. We fixed it. Have a good time. Well, it came up in Kubernetes conversations we had last week in Copenhagen. We were in Denmark for KubeCon around, you know, things, obviously Kubernetes de facto standards. So great stuff. That's certainly great. Istio's service meshes is a topic that's highly discussed. And one of the things that comes up is the beautiful thing about automation and the downside potentially is it fixes things, right? So you could have a memory leak, for instance, that you never know gets fixed, but it just crashes every day and reboots itself. So the new kinds of instrumentation is emerging. And so this is really the tough job. Yeah. How do you get in there? Also have automation not work against you, right? That's not a... And you as the central provider, right, are pulling in data from across the world and across the customer base. So how do you take that, sift it to be more proactive about decision-making and support? Yeah. So we capture all the support data and you're like, it's fascinating. We have some AI capabilities, some machine learning capabilities go through that. But it's fascinating. Sometimes we see new issues coming up. What we do is then we go, well, let's look who is exposed to that just to get a footprint. And then you actually inform customers, hey, you had this and this issue. You have this and this. It's really, it's a different, and that's where I want to get more proactive or more automated. Just with the automation, I just want to be, it got to work, right? So we installed over the last, I would say 18 months, like a bot. Simple bot, basically. His name is Edmund and he works on support cases. And we started slow, very slow. We didn't let it go as in totally machine learning. But now I gave some stats earlier today. In one use case, it's 25% faster solving a customer issue using Edmund. And he participates in 11% of all support cases. Edmund is, it is a busy guy. And the game's changing too. I mean, the old days, first line support, second line support, offline support, you know, escalation. These things are older IT mechanisms. With this, you're talking about completely doing away with, in essence, first line support. But also a first line support might come in from, say, a Microsoft or an IBM. So you got to be ready for anything. It's actually, I think it's not just first line support and it's not replacing them. It's helping them, right? It's really making them faster, right? When the frustrating piece is like, customer opens a support case, some data is missing, right? And so, you know, if you have a queue, it gets to that engineer looks at, oh, this data is missing. Edmund sees that and says, hey, I need this data piece. Based on all the support cases, we fixed similar issues. This is the data we need. So Edmund gets the data ready, engineer looks at it. In some cases, Edmund actually... Hose it out. Hose it out. Tell the customer, hey, there's a better solution here. Do it this way. I'd love to pull the camera back a little bit, right? You are not the SVP of support. You're the SVP of customer experience and engagement, right? That's an entirely different role in some ways, in that you're responsible for customer success at some level. That is correct, yeah. Can you talk a little bit about reconfiguring your organization to be that, like that? I think when we dive in a little bit on the customer success, right? So we have an organization that called Technical Accounting. It's part of the customer success organization. That's another way. That's a human business, but it's fascinating, right? We put these times on clients and have them work together. They understand the business. It's an old business, but trust me, having still a human in their understanding, okay, this is customer X, Y, Z. That's their business objective. I talked about this today as well. Not to forget, hey, this customer actually wants to do whatever, whatever on the business, an SAP, LifeGo, to actually take that further to actually support case. Doing that, the time helps quite a bit. And then also the commitment, right? There's in, we don't want just to do support cases and then that's why you renew with Red Hat. We want to make sure you actually get value out of it and that's why you want to renew, right? And so that's why we configure different. And it's bigger, right? It's bigger as in really making sure the product is correct. So that's why quality assurance is in my team with support. That's why I run internal IT for the engineering team. So we run the stuff that we sell actually earlier and some of my team is always like, Marco, why do we have to do that? Because we learn and we give, I much rather have you feel the pain than the customer feel the pain, right? And so that's why we configure different. And I've been 12 and a half years at Red Hat and it's exciting that we're still able to change around and the quality assurance piece is big too because you're in there as well. Looking at the QA, making sure that's good too. So you get, you're testing out the products and doing QA all within the mindset of customer experience. And exactly. And you got to move that in the agile is more and more. You see developers actually submitting test cases with that. So that's the component testing and the basic test. What we got to do more is what you mentioned is like, if somebody does serverless with OpenShift or containerize that thing together with like some software defined storage, that together to bring together work, that's the art, right? So I want to move more and more that we take use cases from customers, work closely. This is how we do it, like XYZ customer and apply that. At the end of the day, it's the same game with different playing field. Customer wants choice, best possible solution and experience for them. You guys got to enable that and then support it and make it happen. And it was clouds. It just gets more microservices. And you see how, yeah, well you saw the demo yesterday when they show basically, I think Azure or Amazon was slower and every traffic got routed. This is reality as well, right? I mean, if you look at one press release we did yesterday, I just find it a fascinating story. Forework, they have kitchen appliances. I don't know if you saw that, but they have over a million kitchen appliances, cooking appliances connected to the internet. And it's a German Swiss company. When they got to upgrade this system so they get recipes down, they actually spin up instances in Azure, in Alibaba, in Asia, and I think in Amazon in the US, they spin it up, they scale out, all the appliances connect, then they shrink it together. And you're like, how do you support these customers? It's a whole different use case, right? It's great for the customer. Yeah, that's more of a challenge for you guys. But again, with preparation of the right integration testing before with the right setup that we know here, this is what the customer is doing this week. And Amadeus as well talked at the keynote, right? We've worked a long time with Amadeus. They're a smart team. As part of your customer role, you were involved with the innovation awards. They were up on stage this morning. What struck me was they were both about time to value and speed of deployment as well as scale, right? Often these were global companies, like we had Amadeus on yesterday, spanning the globe, huge number of transactions. Anything stand out to you in those innovation awards this year and perhaps maybe that's been different in previous years? I think the scale is actually interesting that you say. I think we have much quicker now. I think that's awesome, technology matures. I think we used to have more smaller skunk work projects than getting to a certain scale, but it just goes faster. I think, well, I think the cultural piece is probably a bit more accepted, right? This whole containerization is not magic anymore. I think a lot is being moved, is coming from the development side, but also from the Linux side. So I think there's a less struggle of that. But I do see still some cultural struggles. You talk to customers, maybe not the innovation award winners, but even then they say, hey, it took us a long time to convince internal structures, how we change things around. But- Talk about the open source role, because you mentioned before we came on about you guys are all in the open with open source. Is there like a project that you're part of that supports Centric? Is there certain things you're picking out of open source as you guys do the QA and build your own stuff? Yeah, we do a lot. We submit a lot to basically the open. There's very few, we don't share data. Like we can't share customer data for obvious reasons. But like tooling, most of the tooling we share, if it's like data collectors, we are an open source world. There's not much that we don't, there's nothing proprietary, right? And engineers, that's why they're coming to write that. That's the configuration. They want to see, hey, how does this stuff get applied, right? And they own the packages, right? And some stuff we ship, right? If it's tied to the customer portal, the AI pieces, maybe we open source parts of it, but... What's it like this year for the folks watching who couldn't make it? What's the vibe here at Red Hat Summit 2018? What's the hallway conversations like? What's some of the dinners? What are you talking about? What's the chatter? I think the big chatter for me is kind of like, there's open shift containers, agile development, and then the agile development comes back and back and really like, how do we do this, right? And that connects obviously, how do you take application development or how do you take the applications, put them in a container? That is the vibe, that's what I... And then you see these demos, right? They're with multi-cloud. And new applications, it's not standalone Linux anymore. Yeah, yeah, yeah. So I think that's the enablement that we have with containers and then to be able to run in public cloud or multi-cloud on-premise, it's the options are endless. And I think that's the strength from Red Hat. We proved that with Linux, we can have a solid API. We don't screw up the applications. And if we can guarantee that across the four footprints, that's, I mean, Paul's vision five, six years ago and I think we are there. You talked about a bit of a cultural shift. How can Red Hat help its customers come up to speed? And I don't know, that's a little bit pejorative. Maybe, you know, but be more agile, be more, you know. Yeah, it's a good example. I think we do a lot of these sessions. I actually think even our sales motion, they are pretty aware what open source is, what the culture is. They do a lot of these sessions with customers. Jim Wyters is actually awesome when he comes to clients. We did a C-level event at a bank, I'm based in Zurich and it was in a Swiss bank. And I think they got like 140 C-level, you know, CIOs, Group CIOs. And Jim did a talk about the open organization, about breaking down the barriers, right? And that's, I think is a role that we play. It's not, I think, well, some is Red Hat's role, but we got to do that stuff, because we can share quite a bit on how we are configured, how we are different. I think that kind of thing is high on all this, every CIO's list of agendas, right now. And everything in the open is proven, open is winning, open beats closed, pretty much every time there's now, it's pretty standard. Operating wise, just trying to see if it will operationalize it, not just for software development, but as a practice. I actually think for practice and how to run the company, when some stuff is transparency, right? It's like, if you work in a company that you're not transparent with your associates, can you really do this in 2018? Is that okay, right? And so I think those are elements that I, I think we do well at Red Hat. And we got to keep internally as well, reminding ourselves these core principles from open source are really important for the company. Because you're hiring, so you're bringing new Red Hatters in, so. Yeah, with the rate we're hiring, it's actually, it's big concerns. How do we maintain this culture, right? Meritocracy is not always polite, but it's the way we function. You guys are humble, it's good. You're playing the long game. I love that about Red Hat. So congratulations, Mark. Thanks for coming on the show and sharing your insights. It's theCUBE live here in San Francisco for Red Hat Summit 2018 here in Moscone West. I'm John Furrier with John Troyer. Stay with us for more live coverage after this short break.