 Live from Las Vegas, it's theCUBE, covering ServiceNow Knowledge 2018, brought to you by ServiceNow. Welcome to day three of Knowledge 18. You're watching theCUBE, the leader in live tech coverage. Day three is when ServiceNow brings together its audience and talks about its platform, the creators, the developers, the doers get together in the room. Jeff Frick and I, my co-host, we've seen the show now, Jeff, for many, many years. I joked on Twitter today, it's not often you see a full room, and this room was packed on day three, unless Larry Ellison is speaking. Well, Larry Ellison's not here, but Pat Casey is. He's the Senior Vice President of DevOps at ServiceNow and theCUBE alone. Pat, great to see you again. Yeah, absolutely, I'm just glad to be back. My head is exploding with all the innovation that's coming up. I feel like I'm at an AWS re-invent with Andy Jassy up on stage with all these features that are coming out, but, wow, you guys are on it, and part of that is because of the platform, you're able to put out new features, but how's the week going? So far it's been great, but you're sort of right, we are super proud of this year. I think there's more new stuff that's valuable for our customers coming out this year than probably the three years prior to this. You got the chatbot designer, you got some great application innovation, you got Flow Designer, you've got the entire integration suite coming online, and then, in addition to that, you've got the whole new mobile experience coming out, just all stuff that our customers, you know, they can touch. I mean, you can go downstairs and see all that, and they can get all their hands on it. Super exciting. So consistent too with the messaging we've been coming here, I think this is our sixth year, with kind of the low code and no code vision that Fred had way at the beginning to let lots of people build great workflows, and then to see you start taking into some of these crazy new applications like chatbots, and integration platform, it's pretty innovative. Yeah, I think it's a mindset when you get down to it. I mean, the weird failure mode of technology is technology tends to get built by technologists, and I do this for a living. There's a failure mode where you design the tool you want to use, and those tend to be programmer tools because they tend to get designed by programmers. It does take an extra mental shift to say, no, you know, my user is not me. My user is a different person. I want to build the tool that they want to use. And that sort of user empathy, you know, Fred had that in spades. That was his huge, huge, huge strength. Among other things, one of his huge strengths. It's something that we're really trying to keep foreground in the company, and you see that in some of the new products we've released as well. It's really aimed at our customers, not at our developers. The other thing I think that's been consistent in all the interviews we've done, and John talked on the day one keynote, one of his kind of three keys to success was, you know, try to stay without the box as much as you can as a rule. We've had all the GMs of the various application stacks that you guys have. They've all talked consistently. You know, we really try to drive, even as a group, our specific request back into development on the platform level so we can all leverage it. So even within the vertical applications you guys are building, it's still this drive towards leverage the common platform. Yeah, absolutely. And there is, that's what I'm looking for. There's a lot of value in using the product the way it was shipped. For easiest thing is when it advances or when we ship you new features you can just turn them on and it doesn't conflict with anything else you've got going in there. There's always an element of, you know, this is enterprise software. Every customer is a little bit different. You know, GE does not work the same way as Bank of America. So you probably never get away entirely from configuring, but doing the minimum that you can get away with the minimum that'll let you put your business specific needs in there. And being really sure of it, you need to do it. It's the right approach to take. The failure mode of technologists, the other one is we like writing technology. So give me a platform and I'm going to just write stuff. Applying that only when it makes sense to the business is where you really need to be, especially in this day and age. Well, I wanted to ask you about that because you guys talk about many applications, one platform, but used to be one platform, one app. Yep. As you have more and more and more apps, how are you finding it regarding prioritization of features and capabilities? I imagine the GMs, like any company, are saying, hey, this is a priority. Sure. And because you have a platform, I'm sure a lot more overlap than if you're a stovepipe development organization, but nonetheless, you still got to prioritize. Maybe talk about that a little bit. Sure. You end up with two different levels of it, though. At one level, you tend to want to pick businesses to go into which are aligned with the technology stack you have. I don't think we're going to go into video streaming business. It's a good business, but it's not our business. Too bad, we could use some of that actually. I don't know, maybe next year. But when you get down to it, we mostly write enterprise business apps. So HR is an enterprise business app. CSM, SecOps, ITSM, they're all kind of the same general application area. So we don't tend to have something which is totally out to lunch, but you're right in the sense that, hey, what's important to CSM might be less important to ITSM. And so we do prioritize. And we prioritize partly based on what the perceived benefit across the product line is. If something that a particular BU wants that five other BU's are going to benefit from, that's pretty valuable. If only them, not so much. And part of it too is based on how big the BU's are. If you're an emerging product line, you probably get a few less features than like Farrell Hough. She has a very big product line or Pablo, he has a very big product line. But there's also an over investment in the emerging stuff because you have to invest to build the product lines out. The other thing I think is you guys are such a great opportunity is, again, I just go back to those early friend interviews with the copy room and the colored paper because nobody knows what that is anymore. But workflow just by its very nature lends itself so much to leveraging AI and ML. So you've already kind of approached or we'll try to make work easier with these great workflow tools. But what an opportunity now to apply AI and machine learning to those things over time. So I don't even have to write the rules and even a big chunk of that workflow that I built will eventually go away from me actually having to interact with it. Yeah, there's a second layer to it too, which I'll call out. The workflows between businesses are different. But we have the advantage that we have the data for each of the businesses. So we can train AI on this is the way this particular workflow works at General Electric and use that bot at GE and train a different bot at maybe a Siemens, still big industrial firm that's a different way of doing it. That gives us a really big advantage over people who kind of commingle the data together. Because of our architecture, we can treat every customer uniquely and we can train the automation for the unique workflows for that particular customer. It gets a much more accurate result. So thinking about staying on that theme of machine intelligence for a moment. I mean, you're not a household name in the world of AI. So you've done some acquisitions but it's really becoming a fundamental part of your next wave of innovation. As a technologist and you look out at the landscape you obviously you see Google, Apple, Facebook, IBM with Watson, et cetera, et cetera. As some of the perceived leaders, do you guys aspire to be at that level? Do you need to be? What's the philosophy and strategy with regard to implementing AI and the roadmap? If you cast your eyes forward to where we think the future is going to be, I do think there are going to be certain core AI services that are what I call their volume plays. You need a lot of engineers, a lot of resources, a lot of time to execute them. Really good voice to text is an example and that's getting pretty good. It's almost solved at this point. A general case conversational agent, not solved yet. Even the stuff you see at like Google IO, it's very specialized. It does one thing really well and it's a great demo but ask it about Russian history. No idea what to talk about. Whereas maybe you don't know a lot about Russian history as a human with at least something interesting to say. We expect that we will be leveraging other people's core AI services for a lot of stuff out there. Voice to text is a good example. There may well be some language parsing that we can do out there. There may be other things we never even thought of. Maybe stuff that'll read text for you and give you back summaries. Those are the kinds of things that we probably won't implement internally. Where you never know but that's my guess. Where you look at where we think we need to write our own code or own our own IP, it's where the domain is specific to our customers. So when I talked about general electric having a specific workflow, I need to be able to train something specific for that. And if you look at some other things like language processing, there's a grammar problem which is a fancy way of saying that the words that you use describing a cube show are different than the words that I would use describing a trade show. So if I teach a bot to talk about the cube, it can't talk about trade shows. If you're Amazon, you train your bot to talk in generic language. When you want to actually speak in domain-specific language, it gets a lot harder. It's not good at talking about your show. We think we're going to have value to provide domain-specific language for our customers' individualized domains. We think that's a big investment. But you don't have to do it all as well. We saw two actually interesting use cases talking to some of your customers this week. One was a hospital in Australia. I don't know if you're familiar with this where they're using Alexa as the interface and as everything goes into the service now platform for the nurses, so that's not really your AI. It's kind of Amazon's AI, that's fine. The other was Siemens taking some of your data and then doing some stuff in Azure and Watson, although the Watson piece, my takeaway was kind of a fail so there's some work to be done there, but customers are going to use different technologies and you have to pick your spots. As a vendor, we're pretty customer-centric. We love it when you use our technology and we think it's awesome, otherwise we wouldn't sell it. But fundamentally, we don't expect to be the only person in the universe. And we're also not, like you see this with our chatbot. Our chatbot, you can use somebody else's chat client. You can use Slack, you can use Teams, you can use our client. We can use Jabber. That's great. If you want a customer to want to use it, use it. Same thing on the AI front. Even if you look at our chatbot right now, there's the ability to plug in third-party AIs for certain things, even today. You can plug it in for language processing. I think Out-of-Box is configured for Google, but you can use Amazon, you can use Microsoft if you want to, and it'll parse your language for you at certain steps in there. We're pretty open to partnering on that stuff. But you're also adding value on top of those platforms. Absolutely. And that's the key point, right? The operating model we have is we want it to be transparent to our customers as to what's going on in the backend. We want to make their life easy. And if we're going to make their life easy by behind the scenes integrating somebody else's technology in there, that's what we're going to do. And for things like language processing, our customers never need to know about that. We know that customers might care if they ask because we're not hiding it, but we're not going to make them do that integration. We're going to do it for them and just they click to turn it on. I want to shift gears a little bit into kind of the human factors point of all this. I laugh. I have an Alexa at home. I have a Google home and they send me emails suggesting ways that I should interact with these things that I've never thought of. So as you see kind of an increase in chatbots and you see an increase in things like voice to text and these kind of automated systems in the background, how are you finding people's adoption of it? Do they get it? You know, do the younger folks just get it automatically? Or are you able to bury it such where it's just served up without much thought in their process? Because it's really the behavior thing. I think it's probably a bigger challenge in the technology. It is. And frankly, it's varied by domain. If you look at it like voice that's getting pretty ubiquitous in the home, it's not that common in the business world. And partly there, frankly, just you've got a background noise problem, engineering wise, crowded office, someone's going to say Alexa and like nobody even knows what they're talking about. And they're 50 of them all. Exactly. There's ways to solve that, but this is an actual challenge. If you look at how people like to interact with technologies, we've all, I would argue we've already gone through a paradigm shift that's generational. My generation, my default is I get a laptop. If you're a millennial, your default is you get out your phone. You will go to a laptop and the same since I will go to a phone, but that's your default. You see the same thing with how you want to interact. Chat is a very natural thing on the phone. It's something you might do on a full screen, but it's a less common. So you're definitely seeing people shifting over to chat as their preferred interaction paradigm, especially as they move on to the phones. Nobody must fail to form on a phone. It's miserable. Right. I wonder if we could, so when Jeff and I have Fred on, we always ask him to break out his telescope. So as the resident technologists, we're going to ask you, and I'm going to ask a bunch of open-ended questions and you can pick whatever ones you want to answer. So the questions are, how far can we take machine intelligence and how far should we take machine intelligence? What are the things that machines can do that humans really can't and vice versa? How will humans and machines come together in the future? It's a broad question. I'll say right now that AI is probably a little over-marketed in that you can build really awesome demos that make it seem like it's thinking, but we're a lot further away from an actual thinking machine, which is aware of itself than I think it would seem from the demos. My kids think Alexa's alive, but my son's like nine, right? There's no actual Alexa at the end of it. I doubt that one's going to get solved in my lifetime. I think what we're going to get is a lot better at faking it. So there's the classical deterring test. The deterring test doesn't require that you be self-aware. The deterring test says that my AI passes the deterring test if you can't tell the difference. And you can do that by faking it really well. So I do think there's going to be a big push there. First level you're seeing it is really in the voice, the voice to text and the voice assistance. And you're seeing it move from the Alexa's into the call centers, into the customer service, into a lot of those road interactions. When it's positive, it's usually replacing like one of us horrible telephone mazes that like everybody hates. It gets replaced by a voice assistant and as a customer, like that is better. My life is better. When it's negative, it might replace a human with a not so good chat. The good news on that front is our society seems to have a pretty good immune system on that. When companies have tried to roll out like less good experiences that are based on less good AI, we tend to rebel and go, no, no, we don't want that. So I haven't seen that been all that successful. You could imagine a model where people are like, I'm going to roll out something that's worse but cheaper. And I haven't seen that happening. Usually when the AI rolls out, it's doing it to be better at something for the consumer perspective. That's great. I mean, we were talking earlier, it's very hard to predict. I mean, who would have predicted that Alexa would have emerged as a leader and NLP or that we said this yesterday that the images of cats on the internet would lead to facial recognition amid? I think Alexa's one example. The thing I think is even more amazing is the Comcast voice remote because I used to be in that business. I'm like, how could you ever have a voice remote while you're watching a TV and watching a movie with a sound interaction? And the fact that now they've got the integration as a real nice consumer experience with YouTube and Netflix, if I want to watch a show, and I don't know where it is, HBO, Netflix, Comcast, YouTube, I just tell that Comcast remote, find me Chris Rock, the tambourine man was the latest one. And then boom, there it comes. Pretty amazing. There's a school of thought out there which is actually pretty widespread that feels like the voice technology. So they've actually been a bit of a fail from a pure technology standpoint in that for all the energy that we've spent on them, they're sort of stuck as a niche application. You know, there's like Alexa, like kids talk to Alexa at home, you can talk to Siri, but when these technologies were coming online, I think we thought that they would replace, you know, hard keyboard interactions to a greater degree than they have. I think there's actually a bit of a learning in there that people are not as man, we don't mandatory, I'm not sure if that's a real word, but we don't need to go oral. Like there's actually a need for non-oral interfaces. And I do think that's, it's a big learning for a lot of the technology is that there's a variety of interface paradigms that actual humans want to use. And forcing people into any one of them is just not the right approach. You have to, right now I want to talk, tomorrow I want to text, I might want to make hand gestures another time, like you're mostly a visual media, I always say we're talking too, but it's not radio, right? So. You're absolutely right, that's a great point because you know, when you're on a plane, you don't want to be interacting in a voice. I mean, there's, at other times that there's background noise that'll screw up the voice reactions, but clearly there's been a lot of work in Silicon Valley and other places on a different interface, and it needs to be there. I don't know if neural will happen in our lifetime, but I wanted to give you some props on the DevOps announcement that you sort of pre-announced. Yep, we did. It's, you know, CJ looked like he was a little upset there, was that supposed to be his announcement? In my version of the script, I announced it and he's commented on my announcement. It's your baby, come on. You never know. So I love the way you kind of laid out the DevOps and kind of DevOps 101 for the audience, you know, bring it together, the plan, dev, test, deploy, and operate, and explaining the DevOps problem, you didn't really even go into the dev versus the ops thrown it over the wall, but you know, people I think generally understand that, but you are now solving a different problem, you know, 500 DevOps tools out there, and it gets confusing, we've talked to a bunch of customers about that, they're super excited to get that capability. Yeah, well we're super, it's one of those cases where you have an epiphany, because we solved it internally, and we just ran it for like three years, and we kept hearing customers kind of say, hey, what are you guys going to do about DevOps? And we're never really quite sure what they mean, because you're like, well, what do you mean? You want like a planning tool? And then probably about a year ago, we sort of had this epiphany of, oh, our customers have exactly the same problem, we do, duh. And so from that, it kind of led us to go down the product road of how can we build this kind of management layer? But if you look across kind of our customer base in the industry, you know, DevOps is, it's almost a rebellion, you know, it's a rebellion against the kind of waterfall development model, which has dominated things, it's a rebellion against that centralized control, and in a sense it's good, because there's a lot of silliness that comes out of those formal development methodologies, slow everybody down, there's stupid bureaucracy in there, but when you apply it in enterprise, okay, some of the stuff in there, you actually did need that, and you kind of throw the baby out with the bathwater, so adding that kind of enterprise DevOps layer back in, you still do get that speed, your developers get to iterate, you get the automated tests, you get the operating model, but you still don't lose those kind of key things you need at the top enterprise levels. Yeah, most of the customers we talked to this week have straight up said, look, we do waterfall for certain things, and we're not going to stop doing waterfall, but some of the new cool stuff. Well, look at us, if you take the microscope far enough away from service now, we're waterfall, in that every six months we release. Yeah, right. But if you're an engineer, we're iterating in 24-hour cycles for you, 24-hour cycles, two-week sprints, it's a very different model when you're in the trenches than from the customer perspective. And I think that's the more important part of the DevOps story, again, is there's the technology and the execution detail which you outlined, but it's really more the attitudinal way that you approach problems. We don't try to solve the big problems. We try to keep moving down the road, moving down the road. We have a vision where we want to get, but let's just keep moving down the road, moving down the road. So it's a very, like you said, cumbersome MRD and PRD, and all those kind of classic things that were just too slow for 2018. Nobody goes into technology to do paperwork. You go into technology to build things, to create, it's a creative outlet. So the more time you can spend doing that, and the less time you're spending on overhead, the happier you're going to be. And if you fundamentally like doing administration, you should move into management. Like that's great, that's the right job for you. But if you're a hands-on-the-keyboard engineer, you probably want to have your hands-on-the-keyboard engineering, that's what you do. Let's leave on a last thought on the platform. I mentioned Andy Jassy before in AWS. He talks about the flywheel effect. Clearly we're seeing the power of the platform and it feels like there's the developer analog to operating leverage, and that flywheel effect is going from your perspective. What can we expect going forward? For us, there's two parallel big investment factors. One is clearly we want to make the platform better for our apps. And you asked earlier about how do we prioritize from our various BUs, and that is driving platform enhancements. But the second layer is this is the platform our customers are using to automate their entire workflow across their whole organization. So there's a series of stuff we're doing there to make that easier for them. In a lot of cases, less about new capabilities. If you look at a lot of our investments, it's more about taking something that previously was hard, but possible, and making it easier and still possible. And in doing that, that's been my experience, is Fred Levy's experience. The easier you can make something, the more successful people will be with it. And Fred had an insight that you could almost oversimplify it sometimes. You could take something which had 10 features and was hard to use, and replace it with something which had seven features and was easy to use. Everyone would be super happy. At some level, that's the iPhone story, right? I could do more on my BlackBerry. I just, it took me like an hour of reading the documentation to figure out how. Well, I still miss the little side wheel. I just apple-ed that one. I love that side wheel. That was great. All right, Pat, listen, thanks very much for coming up. We are humbled by your humility. I mean, you are like a rock star in this community. And congratulations on all the success, and really thanks for coming back in theCUBE. I think it's been a pleasure meeting you guys again. All right, great. Okay, keep it right there, everybody. We'll be back with our next guest. You're watching theCUBE live from Service Now Knowledge K18. Hashtag no18. We are back.