 I'm going to get started, partly because while I only have 76 slides for a 30-minute spot, it's probably imperative that I move quickly, because I actually do have probably about 30 slides for a 30-minute spot. My name is Dormey Andreewicz, Senior Director of Product Marketing, Customer Marketing, Business Forms of Partner Marketing, and other things at Pivotal. So this is the talk that's the secrets of successful Cloud Foundry users. I realized that my slide with the fire escape reminders somehow didn't make it into this version, so I will just verbally tell you that those are the exits, and to proceed in an orderly fashion, so as to not trample each other, and successfully evacuate the building. With that, what do I mean by successful Cloud Foundry adopters? I picked a handful of examples. A lot of this really began after Sea of Summit North America last year, which if, how many folks were there? Show hands, barring rotator cuff injuries that prevent people from raising hands whenever asked questions in public presentations. Okay, so some of you were there. I was also a track chair for the enterprise track then, as I was this year with Greg Otto, and listened to a lot of the customer talks, and just started to put together some patterns that I noticed, and this grew over time throughout the course of the year. You know, I'd Sea of Summit in Basil, and then at Springland Platform in San Francisco in December, you know, various other interviews and case studies and whatnot that I had the opportunity to work on. I sort of extended the set of patterns that I had, so all these are based on some kind of publicly referenceable talk or podcast or video or what have you. But just to kind of frame what I mean by successful, there were things like Garmin, who was highlighting how, you know, hey, we're at 1100 deploys per month, and this was as of last June, so I want to hear what the update is now that it's been 10 months. Comcast cites things like a 50% improvement in time to market, Liberty Mutual highlights their four-week MVPs. Now, as you've probably noticed, a lot of this is inextricable from, you know, not just technology, but practices that have to go along with it. And so really when you look at this set of patterns, it's all about much more the people and process side of things and less about the technology. So one of the key takeaways is when you look across all these really successful examples that we have in the Cloud Foundry community, I was just in listening to the Air Force and the government track, and, you know, they're now, the median time to deliver in the Air Force was eight years, and, you know, they now have four examples of projects that they've gone from, you know, concept to operations and an average of 124 calendar days. And so, you know, just a huge transformation in the speed at which they're able to deliver to warfighters. And then you heard some of the examples that I just said. You know, the take away of that is like, listen, it's not a technology problem. It's a solve problem. What's preventing the rest of the world and the rest of organizations to see those types of results? So the first secret, something that I kept hearing from a lot of customers starting back at the CF Summit last year, was they mentioned the dojo. And, you know, this is something I started to dig into and learn more about Kevin's here in the room. The pivotal has a dojo practice that's part of the onboarding of the actual platform itself. And as I started to poke around and learn and listen and actually garment, I'm pointing to Jonathan because he's in the third row here, talked about doing it twice. And, you know, really that they kind of weren't ready for the first time and they came to it a second time with a much more prepared mindset. What I realized is that, you know, a lot of enterprise software purchasing, you have kind of that line item that gets sort of tacked on there. That's the installation consulting service from the vendor. And that usually works where, okay, we bought some software and now some consultants from the vendor are going to come in. They're going to go install it and then they sort of slide the keys across the table like have fun kiddo and, you know, you're going to go use this software. That might work for certain types of software but that doesn't really work for the platform and that's not the pattern for really successful adopters of the platform. It's an immersive experience. So this kind of like going from the black and white to the full color was sort of what we were going for with this part of the infographic. But getting out of the kind of the tickets and the steps and the back and forth and the meetings and the, you know, daily interrupts, et cetera and letting the team that's actually going to be the platform operators work in a new way and that the dojo experience as part of that onboarding process is really critical. And I think of it sometimes as like, you know, if you've done study abroad to learn a language, you know, if you went and you studied abroad in Spain but you're on the phone with your buddies back home speaking in English assuming that you came from an English speaking country because I do or I speak California speaking. It's really similar to a good dialect. You know, you're always like watching, you know, American movies and talking to your buddies back home like at the end of your whatever six months abroad like how much Spanish did you learn? Right? Because you weren't really there. So when you show up for something like the dojo or you whatever it is that you do when you're setting up the platform, you want to give that team like that full immersive experience. You want to let them have that space, you know, physically and temporally from their old jobs so that they can take on a new way of working. And actually the panel that was here just before me is a fantastic example of, you know, a lot of that mindset that has to be adopted. So you got to let that team kind of take that on. And this is a quote from the interview we did with Kevin and Parker who, you know, operate that dojo practice at Pivotal about kind of that idea of giving this gift for sustaining change. And that's really just talking about that platform team that's going to be a really critical part of the overall success of adopting the platform. So then the next secret was something I noticed where the folks who were kind of talking through their journey, they often told the story through an application or they mentioned a particular application in particular like what was that first app. And there's a couple of different things within that. But the idea of focus, right, when you show up and you're going to adopt something like Cloud Foundry, you can't just, you know, paint brush that on top of some existing applications. You really need to know what are you going to be moving on to the platform? What's going to be that first app? And, you know, that provides start, know where you're going to start. That is your MVP, really. And that's part of your adoption of the platform. Now, it could be a new app. So there's some great examples from Liberty Mutual where, you know, they're building net new mobile apps for, you know, in this case, it was the Australian market, another example where they built it for the motorcycle insurance market. You know, these are brand new green field applications. Great. Totally acceptable options. Another example that I came across over the course of last year was at Orange that one of the first applications they put on the platform was a brand new mobile app for their business-to-business market, right? So they had a great opportunity where, you know, they wanted to improve customer satisfaction. They wanted to reduce some of the costs, you know, for, you know, to their call center in terms of support to their customers. And, you know, especially down the road, they wanted to be able to create a new channel to cross-sell and upsell those customers. And, you know, they talked about in the interview, they're incredibly hard to read, URL at the bottom there is the podcast where you can hear the full story. You know, they talked about how, you know, this would have taken us 18 months, but we were able to do it in six months. And it's a combination of, you know, adopting some of the Pivotal Labs methodologies as well as having these services available, back-end services for the mobile app on the platform. And, you know, taking a, you know, a more agile and iterative and feedback and user-driven approach to designing it. So, and it's great that they got it out earlier in six months rather than 18 months, but what's also really interesting was that nine months into the availability of this new app, they had really high adoption rate, which is the other sort of asset test for especially a mobile application. So, you know, just to illustrate the point that, you know, having focus and saying, okay, we want to, we've got to start that thing when we want that first app to be successful, right, because that's going to pave the way, both, you know, from a technology perspective as well as from an organizational perspective in terms of how do we justify this platform and this approach to the rest of the organization into more development teams. Now, it doesn't have to be a greenfield application. So, there were some interesting stories from T-Mobile where they were talking about how they had an existing Java monolith with a thousand Java functions that was taking them seven months and 72 steps to make a change to that software. So, again, they engaged with Pivotal, working with both our app transformation teams and moving it on to the platform and so they actually rewrote that particular application and had 100% of the production traffic on the platform within three months and so they saw a lot of benefit from doing that. They were able to have, you know, no human intervention when they needed to scale that application, same day bug fixes, no downtime, really just a night and day experience from what they had been dealing with with this application. So, not a greenfield application, also really great focus that they brought in terms of, okay, we're going to stand some, we're going to stand the platform up and we're going to stand up an application on it, we're going to go after this really gnarly Java monolith that we need to modernize anyways, because it's really getting in the way of us and our ability to respond to the business. And then another sort of tidbit within that concept of, okay, so you could use, you could be new, it could be existing, was listening to Comcast and how they cited how they focused on bringing three applications that were taking 40% of the traffic. And so in that kind of like mocked up pie chart example, right, they didn't go for one of the little slices, they went for these big slices of the pie. So I think of this as like the needle movers mentality, right? And so another way to approach coming onto the platform is go for high value services. So in their talk, this was actually Greg's talk from last year, he highlights how what worked well looking back to 2015 was that they went after those high value services. So the focus is the important piece, right? You can't go into it without a clear plan and agenda about which applications are going to move on. And then within that, there's a couple of different things that that could look like. Okay, third secret. For this is like making the platform go viral with developers. It's a combination of virality, I don't know if that's even the right word, making it go viral, right, in terms of just interest as well as also making sure that those developers are properly enabled to deploy onto the platform. And this is really where having a structured and systematic enablement approach to preparing developers to understand building 12 factor applications. And one thing I've kind of learned is that it's dangerous to go to your developers and say, so do you know what a 12 factor application is? Cuz it's kind of instantly adversarial. And if they don't, then they'll kind of say something dodgy and then immediately go Google it, or maybe they do, right? The point is you haven't gained anything by that confrontation. What you do stand to gain is providing a mechanism to just assume everybody needs a little bit of an exposure and enablement and training and an opportunity to get that hello world experience really quickly. And then to be able to go from there and understand what additional patterns and resources they need. So Garmin actually took an approach of building their own internal labs program where different teams would rotate through on these sort of four to six weeks rotations. And that would give those teams an opportunity to be really immersed in a different way of working, understand these different patterns and paradigms and starting to push applications to the platform. T-Mobile offered monthly 101 classes, at least as what they described in their talk last year. And so this was a day long class, where in the morning they were kind of given the lecture style instruction on, this is what 12 factor is. This is microservices architectures and API design, continuous integration pipelines and pushing to the platform. And then in the afternoon they had a lab environment where they could get that hello world experience, right? If you can't get to that dopamine hit in about two hours, you're probably gonna start getting frustrated. So they provided that space and enablement for developers to do that. And then they left those labs available I think for about 90 days or so to allow those teams to continue to experiment and gain more and more skills. So that when they show up and they're pushing apps to the platform, they're pushing healthy apps to the platform that are well designed to run there. And then there were some folks that kind of alluded to like, well, we didn't do any formal marketing of the platform, we just saw nice adoption. But if you kind of look at what they're doing, they're actually creating an environment that's very hospitable to developers. So things like at Comcast, there's no tickets on the platform. So one of the things that developers tend to get really annoyed with is when they have to put in a ticket for everything. And so moving on to the platform is inherently a more self-service environment. And a lot of the support is really provided through, in their case it's a Slack channel and they've seen really healthy growth in the Slack community. That provides a lot of peer support and then the operations team is there providing their support as well. And then Verizon had a really funny anecdote in their talk about similarly like kind of luring developers in with the promise of faster deployments and then hitting them with the 12 factors. So kind of this notion of figuring out what's gonna be attractive to developers. What are the things that are really irritating and painful for them? That if you're providing a different experience, they're gonna want to come and they'll be more willing to invest, to learn about what it takes to deploy to the platform in a healthy way. And adhere to some of those structures that you get the payoff on the other side with a lot more speed and security. Okay, so the fourth secret, we're now breaking away from the infographic. The fourth secret was kind of staring me in the face, but it took me a couple months to wake up and realize it. It was really around measurement. And so what I mean by it was staring me in the face is I've been showing you numbers this whole time. And especially at the outset about what's the measure of a successful Cloud Foundry adopter. So there's a couple things as I started to noodle on measurement. I was at the same time I was at a Gartner show, a Gartner conference in the fall. And one of the talks, the Gartner analyst was talking about how a lot of these executives, right, with all the arm, wavy, big D, big T, digital transformation talk out there. And by the way, this is Arm Wavy. I don't know why it's not up here. It's just down here. With all of that, buzzword hype out there. There's an alarming number of executives that have no digital business metrics. And as you kind of listen to their description of a digital business metrics, my laywoman description is if you can tie it back to the P&L, so an example would be how much revenue is coming from a digital channel? Or what percentage of cost? Or what dollar chunk of cost is tied to this digital self service mechanism or something? So when you're tying it to the P&L, now you're talking about a business metric. So I'm not going to argue with Gartner by any means. And I think there's a ton of validity in the notion of, yeah, at a certain point, you need to have some digital business KPIs. However, I think you would be overlooking a lot of other important measurement if everything had to be tied back to the P&L. So at the same conference, I was listening to Adrian Kockroft, and he kind of spouted off some brilliant thing as he's wanted to do about how do you go faster? Will you figure out how many tickets and meetings it takes to get something out? Publish that number and make it go down. I'm going to spend roughly the next three slides unpacking what's in this pithy little statement, because there's a lot of really good stuff in there, especially when you think about the types of metrics that you need to include that balance out those digital business metrics that aren't tied to the P&L, but are really important directional indicators. How do you know I'm going in the right direction? I haven't yet launched that new app that's contributing tens of millions of dollars in revenue. I'm not there yet, and I don't have direct line of sight into it because I'm trying to take a more agile approach, and I'm going to have to try things that fail. So how do I know if I'm creating an environment that will let me move faster, which is figure out how many tickets and meetings it takes and make the number go down? The fewer meetings and tickets it takes to get something out, the faster you're going to be able to get stuff out. So to that extent, there's a certain element of needing to kind of understand how ugly you are today. And so this is like you pour yourself a stiff drink and you look in the mirror, and because it's Tuesday or whatever, and you're like, yeah, this is real right now. This is what it looks like. So there's a process for this that's actually been honed for, I was going to say like generations, but I think that might be overstating it. It's been honed for decades in the manufacturing industry that's tied to lean manufacturing practices, and it's value stream mapping. And so this is something that, and a colleague of mine published a really great paper, short, easy read that's all applied to software development, which I think is really helpful to keep it really relevant for folks who are working on this kind of stuff. And I'm just going to zero in on one tiny piece. If you look at this whole kind of waterfall picture that they have of all these different groups and the chunks of time in terms of getting something done, right? How many meetings and tickets does it take and make the number go down? First, you have to understand like, yes, what are all the steps in a process? And you have to accurately measure what that looks like in your current organization. And so one of those things where you can turn a dial and see something collapse and the number go down is in something developer self-service, which folks here who are already looking at or using Cloud Foundry already know that that's a powerful aspect of the platform. But just to illustrate what that means is to, this is from quote from Andy Zittany, back when he was at Allstate from a couple of years ago where the wait time for a new environment goes from 90 days to 15 minutes, right? So in the spirit of figure out how many meetings and tickets does it take to get something out? Well, that's how long does it take to get a new environment set up? And there's a bunch of different steps along the way that need to be mapped and then each one dialed down. Now the second part of that pithy statement that Adrian Cocroft made was publish it and make the number go down, right? Now the process of making the number go down is all the work that has to go in to actually set up an environment where there's self-service or if it's about collapsing the Dev and QA then that's about adopting test-driven development and continuous integration. I'll get to that, that's secret number six. Don't worry, we'll get there. But publishing it is an interesting aspect of communication internally within an organization. So when you think about those workplace safety campaigns that folks have in manufacturing, so this is actually, this is really meta. It's a tweet from Dr. Pepper Snapple, the bottling, Pepperdream bottling company with a picture of their workplace safety. I was like Googling for pictures of workplace safety. And you can see it's 132 days, right? Everyone coming in sees that number and it's an indisputable number. It's not like what is our ROI on this thing? How many people here can calculate an ROI? Right? What discount rate do you use on your ROIs? 11%? Okay, what do you use? Someone up back there? Fed bank rate? Okay. Who here doesn't know what a discount rate is? Don't be shy, right? Yeah, yeah. Not only is it something that like most people don't know what a discount rate is in terms of calculating the net present value of cash. And two, it's actually, it's a number that you can make a judgment call on. You could take 11%, you could take bank rate, you could be conservative, you could take Silicon Valley venture capital rates at like 18%, right? Why open up that debate, right? Make it a super simple number that no one can poke at. The number of days since an accident. It's a hard number, right? So the number of days since something was deployed, I don't know, I'm just throwing stuff out there, where as soon as it starts to be like a ratio and a percentage or if there's some kind of extra decision that goes in there, like eh, it's too hard for people to understand, like in a snap judgment sense. So anyways, this is super meta because they're not only posting it and making sure that everyone internally in their organization who's walking in the door that day understands like this is how we're doing. Are we doing well? Are we not doing well, right? And we all know that this is important because we look at this thing every day. They're actually signaling to the world that this is important because they're now tweeting it from their corporate handle. So that's why I think it's super meta. Okay, so then looking at some of those directional metrics just a little bit more of what some of these successful adopters have done. This is a bunch of metrics shared from Comcast and I'm actually not gonna focus on the numbers that they're sharing. I wanna focus on the categories that they've put these in, right? As something to think about in terms of you might need directional metrics whether you choose these or you choose other ones, but these categories, right? The notion of resiliency run the business. It's great to be able to move things faster and that is an important measure of success but if you wanna know if you're going in the right direction, one of those things you need to measure is are we getting out of the firefighting business? So how resilient your environment is is an indication of like, yeah, we're spending less time firefighting stuff which means we have more capacity to innovate. So that's just, it's important, right? Then there's the sexy time to market speed and changing the business and doing new stuff and that was a lot of the metrics that I set up at the beginning in my introduction and so there's a number of stuff there. Also great, right? You wanna have something in that category. So understanding what are the categories of metrics and then from there figure out simple, easy to collect numbers that you can constantly refer back to, use those to communicate internally, how are we doing now? I also wanted to call out CSA insurance from Cal Campus's talk at CF Summit Basil last year. This was the first time I saw someone talking about patch frequency, right? So this is an important, another one of those categories of metrics which especially like people are super squishy about any kind of security measurement that like might anyone have to say a firm, are we more secure yet, right? People don't wanna go there but this is something that you can't debate, right? Like we used to patch this frequency and now we are patching at this frequency. And so it's neutral but it's indicative of a healthier, more secure system. And so if that's one of your goals then that's something that you're gonna wanna measure to make sure it's going in the right direction. It also means you have to kind of know how ugly you are right now in terms of how frequently you're patching. So, you know, get the stiff drinks ready. I'll be right there with you. All right, fifth secret. Don't launch with the Avengers. I tried really hard to figure out a way to word this that didn't have a negative in it but you'll see why I couldn't get away from don't launch with the Avengers. There's a couple things in here in terms of that first team. And in this case, we're not talking about the platform ops team. That you know, secret number one was you gotta give them time and space and let them kind of do study abroad even if it's in your own four walls. In this case, we're kind of talking about that first app team that's gonna be the first ones to move an app onto the platform, whether it's new or whether it's being modernized. That was secret number two, if you recall. The team is one that if they are a bunch of hero mentality and known rock star personalities, you are setting yourself up for people to negate the success, right? And you want to end up with a kind of joke here with like the office space crew. It's like, but you want people that everyone can relate to, when they succeed, folks are in a position to say, oh, well, if they succeed, then I can do it, right? When Tony Stark and his band of merry, mostly men defeat the aliens, it's like, well, sure, like I could never do that. I'm just dormane. Like, you know, I don't have those skills or superpowers and Thor's hair. Therefore, I probably could not defeat the invading alien species. And so, you know, that's kind of the mentality that you gotta get around. This is all from a really great talk from John Osborn from the Great American Insurance Company that he gave in December. But some other things in terms of, you know, this team that you're putting together, you want these different experience levels. You want folks that have been developers for 20 years. You want some folks who are just out of school. Like, what the folks are learning just out of school is different now, right? They actually, they do bring an interesting perspective to the table. Different skill types. Later I went back and did a podcast interview with John and Matt Curry from Allstate. And one of the things that John mentioned was like, they planted a .NET developer on a Java project. Which kind of like, that's crazy. Why would you do that? And then he explained like, well, we wanted, we knew we eventually needed to go modernize a bunch of .NET applications also. So, we wanted to start to incubate the .NET team with even from the get go, right? Begin as you mean to go on. So some just really interesting ideas in terms of that first team being really thoughtful about the team that you assemble and avoid the hero mentalities, the ideas that it's sustainable, and a team that everyone can recognize themselves in. Okay, number six, just checking on time. I think I'm just about done. I'm gonna have to go a little bit over. I'll talk really fast. Secret number six, you've heard about it at some of the other talks and the keynotes as well. Really embracing and investing in test and released automation. I'm kind of gonna harp on the investment kind of analogy with this one. The idea came from Matt Curry from Allstate who talked about how he thinks of his test suite like his bank account and you don't get to park a million dollars on day one. You gotta put $10 a day and let the compound interest do its thing, right? But you will get dividends on all those incremental investments. The reality is people want an easy button when it comes to digital transformation but there is work that has to be done. You can automate a lot of stuff but you can't automate writing tests. You can automate the test themselves and you should but you can't automate writing the tests. So there's this kind of equation if you will. We talked about how deployment frequency is a really great superpower when it comes to digital transformation. It allows you to do the course correction. You can sort of relate it to things even like your patching frequency. It's what helps you have that kind of iterative feedback loop from a product perspective. Great, now how do you get there? How do you get those big numbers, the 1,100 deploys per month, the 3,000 deploys per month, right? So it's a combination if you break it down while microservices, well if you have more things to deploy, right, even if you're deploying at the same frequency, the number is gonna go up at the other end of that equation, right? So if you start to decompose things and they get their own release cycle, you could still be releasing each one of those incremental services at the same once a quarter cycle and it's just gonna be a bigger number so let's not ignore that. On the other end, self-service infrastructure, that kind of goes back to that value stream mapping example I gave of instead of waiting 90 days, I get my self-service in 15 minutes, right? When that happens, folks can deploy a lot more frequently. And then the one in the middle, the automated pipelines, that's really that investment in test writing and test automation. And so this is kind of something like that value stream mapping paper I think does a nice job of breaking down these different categories where automating tests assumes that you have tests and so if you don't have tests, you need to start writing them. And there's been some great stuff written up by Matthew Kane Parker recently about why test-driven development. I recommend it, if you're not already familiar, it's a great succinct piece to kind of frame up why that's so important. And then the test automation, continuous integration, this is hugely important when you look at all these successful Cloud Foundry adopters, they're all doing it, right? They're all automating their tests and always having their code ready to push to production. Now they might be using different tools to do that and that's fine, the point is that you do something in that category. And then visibility I think is also a really nice aspect which is as things fail in that test pipeline, how do you quickly get the team aligned with the right context of what failed and what do we need to go back and fix? So that's all about collapsing that dev to QA process. So that you end up with higher quality code going out the door, but you're minimizing the cognitive overhead every time a test fails for those developers. Okay, seventh one, forgive me. Just getting a little thirsty. The seventh and final secret is to be bold. We talked a little bit earlier how Comcast specifically attributed some of their success to going after high value services. And if you think about why, higher value services, the ones that are taking more traffic that have more things depending on them, the process of working through modernizing those services means you're gonna touch and bump into a lot more potential problems. And as you work through those, you actually pave the way to do the easier stuff later. Some other things that Neville George talked about also from Comcast, but six months later that added into my understanding of this is there's the whole concept of selling this initiative internally within your organization. And so by having those higher value services, you inherently have more visible wins. You don't have to go back and explain to every development team, like we move this one on this service onto the platform and they're like, what service? I've never heard of that. Like, I don't use that. When it's something that's actually like, oh yeah, that's a big one. Takes a lot of traffic. Like now you've got my attention. So you get some additional benefit by being bold in terms of going after those higher value services. You can help pave the way for promotion later on down the road. And then there's kind of more of the top down mentality which I thought Liberty Mutual had a lot of interesting ideas that they actually kind of wrote a whole manifesto. And John Hevron, speaking at Springlin Platform last year, was talking about, yeah, you've got to have this ambitious thinking. And so some of the ambitious types of things that they've put out there, we're going to modernize and replatform 10 apps in 10 weeks. Let's just be bold about it. In the process of doing that, they developed the cookbooks to go and do a lot of replatforming because they had this really focused period of time when they just decided they're really going to tackle and understand what it takes to do that. They also have a notice between their June talk and their December talk. They had two different senior leaders speaking. And they had the same goals that they were pointing out. Coming back to measurements of success and making those really visible, consistency is really helpful, too. OK, so that's the seven secrets. Quick poll, there's no way to do this cleanly. I was going to see what the most surprising secret was for folks. If anyone wants to volunteer. Not enough fingers, so it's probably six or seven. Anyways, since we're out of time, I won't try to do that awkward social experiment. There's a number of resources, in addition to the individual presentations and replays that are embedded links in my slides, which are already on the summit pages. I've written up some of these summaries. We're kind of all the background thinking that went into this presentation all came from. And some of my colleagues have written some of these other papers that are useful. And then my final plug is just a reminder that we've got Springland platform coming. We have a special discount code and effective tomorrow. I'm not sure maybe I'm not supposed to be talking about it yet. But as we're celebrating our five-year anniversary as a company, we're offering an extra discount. So go ahead and grab that code. It's only good for a week. So birthday parties can't last forever. So take advantage and blow out some candles with us. Thanks.