 It was ServiceNow. Live from Las Vegas, it's theCUBE. Covering Knowledge 16, brought to you by ServiceNow. Here are your hosts, Dave Vellante and Jeff Frick. Welcome back to Knowledge 16, everybody. This is day three for theCUBE here, ServiceNow's big customer conference. 12,000 people here, just an amazing event, growing like crazy. Pat Casey is here as the Vice President and General Manager of Create Now, and platform development at ServiceNow and the host of the keynotes today. Pat, welcome back to theCUBE. Good to see you. Nice job this morning. Thank you. That was great. So, big audience. Have you ever spoken to an audience that large before? I was part of the day one keynote last year, which is similar in terms of the audience count, but I think I had about a 15 minute section. It's a lot different process to be kind of the master of ceremonies and have to work through the full, you know, 90 minutes worth of it. But I was just super proud of the guys doing the demos today. They did a fantastic job. You were introduced as employee number one. Surprise some people. How'd that happen? Well, the surprise is actually, you could argue about what my employee number was. A little corporate history here. Before there was a corporate entity, there was Fred Lutty, and he was writing code. And I literally ran into him because we lived in the same town. I was driving down the street and he was crossing the road and I bumped into him with my car. And he kind of got all upset and then he realized it was me. Pat, Fred is one of those. And I ended up working on the code with him for about six months before there was a corporate entity. But what we found is that we both have a personality flaw in that we both fundamentally want to be in charge. And when there's only two people in the company that doesn't work out too well. So I actually went and I was working on something else for about a year. And by the time I really joined service now as an official like paid employee, I was employee number nine. So you can maybe average them on like four and a half or something. So. Okay, I'm not sure I get that, but all right. That's good. It continues. Fred feels good. He's good at his position, number one. He's got a dent in his leg. I want to also ask you, so you and Fred, I mean, you've got this passion for simplicity. And as developers, you've been around for a while. It's, you know, normally you think of startups and young kids coming out and changing the world. You guys are passionate about bringing this consumer like experience to the enterprise and you've been able to somehow bottle that and create a culture around it. You talk about that. Well, you're passionate about things you believe in. You know, that's sort of been my perception on it. And I fundamentally believe that people deserve to have a pleasant experience, a positive experience when they use technology. And we go through these phases where something new comes out and people master the skill and they get very proud of themselves for having figured out how to do something obscure. And then they fight efforts to kind of lower the barriers to entry. It becomes almost a guild of people who figured out how to use a 3270. They're like, why should we use a GUI? And what you actually find, though, is that sort of it's almost like a technological elitism. You're trying to keep people out of it. My view is actually exactly the opposite. I mean, you wanna get technology out to the broadest possible number of people in a way that they can consume it. And that inevitably means making it easier, making it simpler, but I would call it making it better because anybody can write technology that works for themselves. The trick is to make it work for everybody else. And that's really the passion that I have, that Fred has, and that we try to build in our engineering teams. And we want to make the same generational shift you've really seen in the consumer world. We wanna bring that to the enterprise world. Because I'll be honest with you guys, I don't like some of the apps I use inside of ServiceNow. We use ServiceNow for a lot of stuff, but there's some stuff we don't do yet, so we buy other products. I don't like them all. I wanna like everything I personally work on and I want everybody out there who's working in a company to feel the same way. One of the things you talked about today, you talked about four key attributes, and one of those was single system as part of the design goals. Can you explain the difference between your approach of single system and philosophy of single system versus what others might say is, oh, well Salesforce is a single system. Oracle Fusion creates a single system. SAP is a single system. I'm sort of laughing as I say it, but explain the difference. So there's kind of two different vectors that are worth kind of looking at there. And one is, I think Dan mentioned this architecturally on day two. ServiceNow, it's a multi-instance architecture. So every customer out there, it's a unique software stack. It's actually one for your development, one for your test, and one for your prods. So usually you have three distinct stacks rather than one. Whereas you mentioned Salesforce, they're a more monolithic architecture. It's a multi-tenant architecture, so it's one big software stack. If you really wanna geek out, it's a bunch of JVMs on top of an Oracle Rack Cluster. That's what one of their pods is. And when Salesforce goes into transact with a company, they will generally want to transact at the departmental level, because that's what they're good at, even if they're looking to sell an overall deal to the company as a whole. But what you'll do is you'll go to the HR department or the sales department's a great place to start and say, you need a Salesforce instance to support your sales department. They'll sell you one. Then they'll go to another group and say, hey look, you need a Salesforce instance to support customer support, and they'll sell you one. And you end up with a kind of family of instances which are distinct. You log into this Salesforce instance or this Salesforce instance or this one. And be honest, you get some benefits out of it in that you have easy billing, it's easy to understand who's doing what, it's easy to control access, but as soon as you have business processes which wanna span those boundaries, you get sort of the classic IT silo problem. And they're not unique in that. That's pretty bog standard the way our industry as a whole has solved the, how do we get multiple groups doing multiple things in systems. ServiceNow has made the fairly aggressive choice to try to solve it a different way in that we are investing super heavily and you saw some of that today in tools, functionality, control mechanisms to let you run a single system and have multiple groups inside of it. And we feel like because we've generally been selling to IT departments, historically that's been, I think Frank said 65% of our sales or something like that. Generally speaking, they're well-positioned to go to other parts of the company and say, hey, we have a great platform here. We can help you bring your products into this platform and be more of a service provider rather than kind of the 1990s year conunded and control IT model. One of the other pillars you talked about was the delightful experience. And you hear a lot of talk in enterprise software about the experience, CX, UX, et cetera. You also see a lot of sort of overlays of the UI and UX, maybe not a lot of backend changes that's very common. How important is the platform in terms of that delightful experience and why is it important? Well, ServiceNow actually was started as a platform company. Back when we were telling the early story, it was Fred sitting in an office and there's Fred and me sitting in an office. We didn't have apps. We actually thought we were gonna go to market selling an application development platform. And what we found out when you go on those first sales calls is that that's a really horrible sales call to have when you're two people working in the basement of a VC firm because you go to a large enterprise and say, hey, let me show you my platform. And they say, well, what does it do? And you say, well, what do you want it to do? And their usual response is, it's your sales call, guys. So that tended not to work all that well. So we actually expanded, we wrote a bunch of apps on it but we've always had that platform underpinning underneath ServiceNow. So all the applications that you buy from us whether it's customer service or ITSM or our ITOM suite or our security tools they're all built on the ServiceNow platform. We don't have a separate kind of set of cheater tools that we use to build the apps. So we keep investing in the platform really for two reasons. One is we absolutely see a lot of our customers building their apps on it. But the other is just purely self-interestedly that's how we make our apps better. So in this day and age those investments into user experience and UI it's not optional anymore. It's really mandatory to stay abreast of what people's expectations are on modern apps. So we're investing there not just for the custom app development but also because our apps will benefit from the same things. And another kind of theme that you talked about in the keynote about you can appeal to professional coders, heavy duty coders, low code I think was your mid tier segment and no code. To give everyone the ability to not necessarily know that they're writing apps but to create apps that are actually manifestations of this workflow. It's a pretty unique perspective to be able to handle kind of all three of those scenarios from a user perspective and as I think Fred just said in our last segment people are building apps, they don't even know they're building apps. They think they're just getting stuff done and stitching stuff together. It's a pretty unique philosophy. What is, honestly you would like to say that we're brilliant market theorists and we thought about this 10 years ago and had a strategy. It's really more organic. We've always been very good at that kind of low code segment but our goal, because we're like parents, we really just wanna put our kids' art up on the refrigerator and the customer's building stuff, they're our kids. We wanna see cool stuff get built. So we heard a lot of people kept coming to us and saying, hey look we wanna build apps on the platform but and sometimes the but was I don't wanna do any coding. Maybe I can but I just don't want to. So you end up building no code tools or sometimes the but is I'm used to Java and I'm used to Eclipse, I want an IDE. Okay, we're gonna do that as well. So over the years we've really broadly expanded that kind of developer base that can work on the platform. And for us that's really just, it's a virtuous cycle. The more people who build on it, the more excited we get about the possibilities people building on it and the more excited we get about adding even more functionality. One of the other things you talked about was speed, gotta go fast. It seems like today every three months you have to go faster than you did three months ago. When you started developing service now, the platform, was speed as important to you as it is now or did you just again, was it sort of your present nature or was it just luck, organic? Talk about how that's evolved. I mean there's two different ways to look at it. One is how quickly could service now term product? And when we were a very small company we had basically a very small customer base which meant we could turn product very, very rapidly. There was early in the company's lifespan we used to push out code every night. Literally we'd upgrade like our three customers every night and they would get magical new functionality and it was great for them. But even once we got from three customers to 30 customers to 300 customers, what you find is the customer base is less willing to get changed without having control of that. So just a natural side effect of market success is that we have gone from literally nightly upgrades for everyone to a six month cycle at this point. And that's largely because that's what the customer base has told us they can consume. We've actually trial ballooned like what if we came out more rapidly? Generally people have come back to us and said we don't wanna upgrade that frequently. Six months seems like a good kind of velocity vector there for us. The second piece of it though is how quickly do we want our customers to be able to develop on top of the platform. And the answer there is we have always been very motivated to make it quick and efficient for people but I think it was less relevant to the customer base five or eight years ago. What I'm seeing these days is that the expectations of delivery turnaround being made on development organizations are much more aggressive even in the last five years. So whereas 2007, 2006, you might have six months to build an app. Now your sponsors are gonna expect the same quality level in two months. That's been good for us because we've always been a very high productivity platform. So it's getting a lot of people to say well, I could have this with other tools in six months but I can actually build the same thing or better in service now in a third of a time. So it's something which didn't used to be kind of a meaningful differentiator if it's kind of really comes to the foreground as the market sort of matured. So that need for speed has been yet another tailwind for you guys? Well, and I think like Chris Beatty said, enabling your customers to do everything they do faster. He said it was right at the top of the priority list be really using automation as well as defined process and getting it out of email to really use velocity and process as a competitive advantage for your customers using the platform. Yep, and I think you'll find also there's two different ways to look at speed. One is raw, how quickly even developers bang something together. The other is can you test it? Can you guarantee quality? Can you push it to production without regressions? Can you have a process around it? We've been really trying to make sure we're solving both sides of that because if you just solve for developer productivity, you end up generally with a sort of inmate run in the asylum sort of failure mode where code keeps going to production rapidly but it's not always the right code or meeting people's expectations. So we've tried very hard to make sure we've got those kind of manageability tools in there as well. Pat, you talked today about delegated development. What is that? What are the benefits? What are some of the headwinds to rolling that out? So let's start by kind of framing the problem. We have a large number of very large enterprises who use ServiceNow. And generally speaking, there's a nice central ServiceNow instance, like we described, that's used for a set of mission-critical applications, incident management, change management, problem management. And I had one customer come to me about two years ago. And they said, hey, look, we use ServiceNow for all these critical processes. And we also use ServiceNow for knowledge management. And we're in a regulated industry. So when we want to change ServiceNow, we've got to go through a 90-day QA cycle to make sure we don't break the mission-critical processes. We're actually pretty sane human beings, though. If we break the knowledge base, it's totally fine. We'll just fix it. We would like to iterate the knowledge base on a two-week cycle. But we don't feel like we can safely do that because we're afraid that they're going to break one of these mission-critical applications when they change the knowledge base. So we've been investing in trying to solve that problem really along two different lines. One is something you probably heard about last time called application scoping, which actually lets the knowledge base application be completely independent of the others. So if it goes to production, it just breaks itself. But the other vector is delegated development. And that's really aimed at making sure that the knowledge base team can be different human beings from the ITSM team and that you as the system owner can control what they do. You can set them up such that they can only work on the knowledge base so that there's no possibility of a fit of ambition or bad manners. They won't be tempted to change some other process that they don't own. And even beyond that, you can restrict the specific tools they're using. You can say, well, you guys are great developers. Knock your socks off. But this other team over here, if they're a little newer on the platform, we're not going to let them do complex scripting. Just list in forms. And once they learn that, maybe we'll expand it. So that's the design time control part of it. There's a reciprocal function, too, something called local administration, which is aimed at letting people who build applications on the platform have private data. So it's data which exists within that application, which is visible to the administrator of that application but not visible to the global service now administrator. And that's critical if you have departments like human resources or legal who generally have data which is proprietary. You don't want everybody's salary available to the service now administrator, for example. With the combination of delegated development and local administration, you can deploy those apps. They can be managed by HR, but they can still be run in that central system so you get all those benefits of centrality, sharing, efficiency. So it's aligning the capabilities with the skill sets as well as restricting access to certain data that shouldn't be accessed. What it's really doing is it's letting whoever in the company made the decision to purchase ServiceNow, expand their user base. Generally speaking, but not exclusively, is IT who bought it. So it's letting IT who own the ServiceNow instance go to other departments inside the company, many of whom have asked to get on ServiceNow and been told, I'm sorry, we don't trust you. They can go back to them and say, yeah, we can absolutely get you on ServiceNow. In fact, we'll help you do it. We'll set up an application for you. We'll sign up your developers. Then you guys can build your apps, push them to production, and we in IT can be comfortable that you're just going to build inside the little box we built and that you'll have control over it. So it's a great way for the people who own ServiceNow to bring it up more broadly across their enterprise. So we do a lot of these events, as you know. And many times there are events within the events aimed at developers. And a lot of times it feels like pushing a rock uphill for some of the organizations that we cover, because everybody covers developers. You guys just kind of threw your glove in the field a couple of years ago, or maybe last year, and it was just got swamped with interest. Talk about your developer program. Well, you always never know how you're going to do on something like this. And we launched the first CreatorCon last year. And we actually set it up. We thought we'd maybe get 1,000 people there. We ended up having to expand the room twice, and we still had some overflow people. We ended up with 1,500 in change registrations. And we were expecting, let's say, about 1,500. It's more or less the same thing this year. My recollection is we budgeted for about 2,000, and we blew through that number of people who signed up. Likewise for our developer program, I think you heard this morning, we had something like 36,000 people signed up on it at this point, of which just a tiny bit less than 10,000, they're actively developing. Like, we can demonstrate that they've done development tasks within the last two weeks, which to me is the most exciting statistic, because you're right, companies love developers. They also love to quote statistics about developers. So you know, it's the joiner developer program. We'll give you a t-shirt. We'll give you a mug. You get a hoodie. There's various tchotchkes people will give you. We don't do any of that. We just say, please join. But the reason they do it is they want to build up a big number. But what the worm in the apple is, that most of the time they join, they get their hoodie, they never develop anything. Just about a third of the people who have ever touched our system are actively developing within the last two weeks in the developer program, which is a huge number. Which means when people are getting to the platform, and they're getting their hands on the keyboard, they're liking what they see, and they're building real stuff, and they're getting value out of it. So that's been extremely exciting. And as a side effect too, it also makes it fascinating to do things like visit our community sites. Like, so far as I know, the single most active part of the ServiceNow communities is the developer section. Because all those 36,000 people are asking questions, answering questions. It's fun to just go there and look at all the activity inside of the forums, inside of the feeds. So last question. Don't hate me for putting it on the spot because it's like 35,000 developers and 10,000 have done stuff with it. But some of the apps that you're seeing that are exciting you, I mean, can you share with us a couple of those that really... We mentioned one on stage. I've been just really fascinated to see we've got this mini vertical building out inside the higher ed space. So it's a very boring corporate answer, but I really love seeing people use us for kind of university management systems. It's just, it's exciting. It's not something I ever would have thought of when I was kind of young. Once the company was younger. You know, I think on the kind of more fun answer, I'm not sure I can save this on stage, but I'll do it anyway. Archer Daniel Midlands, they're the agriculture business in the Midwest. I believe it was them, but some one of our kind of Midwestern agriculture companies built a pork insemination tracking application on top of the service now. It's a real live app. And we had a big debate amongst ourselves as to whether we could put it on our application law. And so we decided we could. But I told this story actually to a bunch of guys from I think from Harley Davidson. They asked me the same question. And one of the guys is like, yeah, that's a real app. I've used it. I said, what? It's like, yeah, actually, I'm an IT guy, but I also run a farm. There really is a real live need for software to track that and somebody solved it on service now. So to me, it's, I never even knew that problem space existed, but it's been solved with the software. It's a big business if you watch the pregame at the Kentucky Derby when they talk about was American Feral last year. It makes good money on that. So maybe we just have to say it's thoroughbreds, not pork, maybe it'll have to be higher profile. Well, the cube in 780 knowledge to our audience, Pat Casey employee number 4.5 at service now. Thanks so much for coming on the Cube. Appreciate it. Appreciate it, guys. All right, keep it right there, everybody. The cube will be back at knowledge 16 from Las Vegas right after this short break.