1 00:00:00,080 --> 00:00:04,480 Hey, listeners. Welcome back for another episode of Pivotal Conversations. My name is Dorme 2 00:00:04,480 --> 00:00:08,740 Andrewitz, and this week I'm happy to bring you an interview with Terry Miles and Jason 3 00:00:08,740 --> 00:00:13,900 Nash of Entrato. This interview was actually recorded back in April of 2019 when Terry, 4 00:00:14,020 --> 00:00:19,020 Jason, and their colleague Don gave a presentation at CF Summit about modernizing and migrating 5 00:00:19,020 --> 00:00:27,240 170 plus applications in 18 months. Now, a lot's changed since April of 2019. One, you'll 6 00:00:27,240 --> 00:00:32,340 notice that Terry and Jason refer to West Corporation. West Corporation has since rebranded 7 00:00:32,340 --> 00:00:37,480 to Entrato, so you'll just have to map those types of references in your head, and you'll 8 00:00:37,480 --> 00:00:42,920 be able to find ongoing information if you look for Entrato. Second, you'll hear Jeff Kelly 9 00:00:42,920 --> 00:00:47,100 as the interviewer. Jeff Kelly was one of our esteemed co-hosts here at Pivotal Conversations. 10 00:00:47,400 --> 00:00:51,700 He's now an esteemed Pivotal alumni, but we get to hear his great interviewing skills one 11 00:00:51,700 --> 00:00:59,340 more time. And finally, there's been an update in the form of Terry's presentation that he 12 00:00:59,340 --> 00:01:05,280 actually gave in October of 2019 at SpringOne Platform. And it's got a very similar title 13 00:01:05,280 --> 00:01:12,040 to the talk that he, Jason, and Don gave back at CF Summit. But I got to tell you, they're 14 00:01:12,040 --> 00:01:17,360 very different presentations, both worth listening to independently to get different levels of insight. 15 00:01:17,360 --> 00:01:23,300 And on that note, I hope you enjoy this particular interview because there's a lot of great insights 16 00:01:23,300 --> 00:01:27,380 for teams that are working on large-scale transformation. So with that, enjoy. 17 00:01:29,880 --> 00:01:33,660 But why don't we start with, just if you could introduce yourselves, just kind of your name, 18 00:01:33,720 --> 00:01:38,800 your title, what you do, and then we can get into a little bit about the story of the application 19 00:01:38,800 --> 00:01:39,780 transformation that you're doing. 20 00:01:40,280 --> 00:01:46,560 Sure. Terry Miles, product manager with West Corporation, the platform owner for PCF. Responsibilities 21 00:01:46,560 --> 00:01:51,640 include that, and also the broader aspect of change management for the entire enterprises that 22 00:01:51,640 --> 00:01:53,660 adopts PCF and related services. 23 00:01:54,040 --> 00:01:54,260 Great. 24 00:01:55,000 --> 00:02:00,860 And I'm Jason Nash, product engineering manager, and I lead a dev team that was the first or 25 00:02:00,860 --> 00:02:05,860 one of the very first to jump onto the platform and shake loose what wasn't bolted down. 26 00:02:06,200 --> 00:02:10,760 Got it. And for those listening who don't know too much about West, tell us a little bit about 27 00:02:10,760 --> 00:02:15,440 the company. I understand you were acquired and kind of changing your model from a holding 28 00:02:15,440 --> 00:02:19,280 company model to more of an operations or operational model. Tell us a little bit about that and 29 00:02:19,280 --> 00:02:21,000 how that impacts your application portfolio. 30 00:02:21,000 --> 00:02:27,040 That's exactly the case. We average about $2 billion annual revenue. That has been primarily 31 00:02:27,040 --> 00:02:31,160 historically through a series of acquisitions. We have always let those acquisitions lie. 32 00:02:31,880 --> 00:02:35,780 And while there have been previous attempts before the adoption of Pivotal Cloud Foundry to 33 00:02:35,780 --> 00:02:40,120 at least unify some of our infrastructural resources, we haven't gone very far in that 34 00:02:40,120 --> 00:02:45,540 direction. And it's not just a matter of practice, but a matter of policy. We just saw it to be more 35 00:02:45,540 --> 00:02:50,900 efficient to leave those lie as they were. We are now owned by a private equity group. 36 00:02:51,000 --> 00:02:55,840 And among the mandates they brought is greater platform consolidation primarily for the purposes 37 00:02:55,840 --> 00:03:01,260 of efficiency. That is the first explicit phase, the justification for the adoption of Pivotal 38 00:03:01,260 --> 00:03:06,320 Cloud Foundry at West. But there is also the greater idea of platform consolidation, greater 39 00:03:06,320 --> 00:03:10,580 efficiencies, more rapid release cycles, and the usual types of business value. 40 00:03:11,240 --> 00:03:16,920 So that's our size. That's our lineage to a certain degree. Offices in, I think I counted about 14 41 00:03:16,920 --> 00:03:21,940 different countries. Time zones all over the world. Distributed teams, not just by business 42 00:03:21,940 --> 00:03:25,840 unit, but many of our project teams are distributed around the globe too. 43 00:03:27,040 --> 00:03:32,200 Okay. And so I understand, you know, part, as you mentioned, it's part about gaining efficiencies. 44 00:03:32,460 --> 00:03:38,240 You've got quite a fairly large application portfolio. So a lot of folks that I talk to, they often start 45 00:03:38,240 --> 00:03:42,020 very small and they'll pick one or two applications, kind of experiment, learn the culture a little bit 46 00:03:42,020 --> 00:03:47,060 there, and then kind of expand to the larger application portfolio. Tell us a little bit about 47 00:03:47,060 --> 00:03:51,420 your approach because you're coming in knowing, you know, hey, we have a mandate to really move all 48 00:03:51,420 --> 00:03:53,200 these apps over. What's, what was the strategy? 49 00:03:53,700 --> 00:03:56,760 I think Jason's going to have a good story to tell in there, but I'll start with the broad strokes. 50 00:03:57,240 --> 00:04:05,520 We tried for a combination of initial application selection for A, low-hanging fruit, B, bang for 51 00:04:05,520 --> 00:04:13,220 buck, value, size, impact. And the commercial outbound platform that Jason manages is one of 52 00:04:13,220 --> 00:04:16,900 those early candidates because they fit both criteria. Is that how, from your experience, 53 00:04:16,980 --> 00:04:17,440 how it went, Jason? 54 00:04:17,600 --> 00:04:22,600 Yeah. I mean, we were really trained to kind of kill two birds with one stone on it. We wanted 55 00:04:22,600 --> 00:04:27,260 to get the, the developmental efficiencies and, you know, not have to worry about that stuff. But we 56 00:04:27,260 --> 00:04:31,720 were also dealing with a ton of operational sprawl and snowflakes all over the environment that really 57 00:04:31,720 --> 00:04:38,300 slowed our dev cycles down and made our systems fragile. And, and even if you were just lifting 58 00:04:38,300 --> 00:04:42,700 and moving something that was fully functional and you weren't really transforming it into something 59 00:04:42,700 --> 00:04:46,860 that was more cloud native and we took advantage of the platform, there was still benefits to us 60 00:04:46,860 --> 00:04:52,180 for doing that. So we pushed really hard on anything that will fit, let's shove it in there and we'll 61 00:04:52,180 --> 00:04:52,980 figure it out after. 62 00:04:53,860 --> 00:04:58,720 Okay. And, and so I know you're, you're speaking tomorrow at the conference. So, and you're going 63 00:04:58,720 --> 00:05:02,500 to share some lessons learned. I mean, if you give us a little preview of that. So what, what, 64 00:05:02,600 --> 00:05:07,400 actually, why don't you tell us a little bit about where you are now in the journey? I think it's 65 00:05:07,400 --> 00:05:11,940 about a year and a half. I've, if I'm reading correctly, tell us a little bit about where you 66 00:05:11,940 --> 00:05:14,140 are now and then maybe we can get into a few of the lessons learned. 67 00:05:14,140 --> 00:05:20,160 We're gaining traction now. We have gone from about a total of, with a, with a, with a final 68 00:05:20,160 --> 00:05:26,380 projected total of about 5,400 AIs in our respective founders. That's the end state that we would expect 69 00:05:26,380 --> 00:05:31,680 near the end of this calendar year, sometime first quarter of the next. We had struggled for a large 70 00:05:31,680 --> 00:05:39,900 part of 2018. We were sitting only at about six, 700 AIs through last October. And that number had 71 00:05:39,900 --> 00:05:45,920 been static through most of the summer and the early fall. But now we are to the point of 2200 72 00:05:45,920 --> 00:05:51,160 application instances. We've seen rapid growth in the first quarter of this year. And it was just due 73 00:05:51,160 --> 00:05:58,040 to a lot of hustle, you know, a lot of, you know, product, project management driven, um, making teams 74 00:05:58,040 --> 00:06:03,920 identify why they can't get through and doing whatever we had to do, begging, borrowing resources, 75 00:06:03,920 --> 00:06:08,940 but getting as creative and as pragmatic as possible to at least get them in to their first initial 76 00:06:08,940 --> 00:06:14,400 customer cutovers. So in terms of our project status, we, uh, we, we saw things darkly about 77 00:06:14,400 --> 00:06:20,000 six months ago. Things were a lot better than they used to be. Most of it was due to just our own 78 00:06:20,000 --> 00:06:24,280 organization's ability to lift itself out. And a few of the people that sit around this table that you 79 00:06:24,280 --> 00:06:29,000 don't hear that work for pivotal too. Um, we feel it's a particularly good client relationship, 80 00:06:29,000 --> 00:06:33,680 professional services story to tell. Great. Um, so yeah, why, why don't you tell us a little bit 81 00:06:33,680 --> 00:06:39,040 about why you think you were kind of stuck around that 600 AI mark? What were some of the things that 82 00:06:39,040 --> 00:06:43,600 were making it challenging to kind of take that, that leap to the next level? We really had a lot of 83 00:06:43,600 --> 00:06:48,120 problems with last mile, right? Like you got all the way through and then there was something in the 84 00:06:48,120 --> 00:06:55,000 greater ecosystem that was missing, right? Whether it was database, whether it was, um, you know, 85 00:06:55,000 --> 00:07:01,300 caching layer, whether it was logging and, you know, those types of things, like we made it work. And then 86 00:07:01,300 --> 00:07:05,980 when it was time to productionalize it and take it to scale, there was some piece of the external 87 00:07:05,980 --> 00:07:10,300 ecosystem that had to be brought online. And as an organization, we did a pretty good job about six 88 00:07:10,300 --> 00:07:15,740 months ago of really, um, identifying what those blockers were and creating like executive level 89 00:07:15,740 --> 00:07:19,920 kind of task forces to go knock those blockers out as enablers for the rest of the team. I think 90 00:07:19,920 --> 00:07:24,940 that's what broke the dam. That's, that's, that's when you started to see the AI count really go up. 91 00:07:25,060 --> 00:07:26,300 So getting that executive buy-in? 92 00:07:26,920 --> 00:07:34,000 It was, you know, it was, it was, uh, uh, acknowledgement that there were holes in our 93 00:07:34,000 --> 00:07:38,060 solution stack and they weren't pivotal holes, right? They were, they were, they were things 94 00:07:38,060 --> 00:07:42,760 that you needed in order to make your applications run, you know, an acknowledgement that, man, we really 95 00:07:42,760 --> 00:07:46,220 need to address those. And then the executive will to kind of do those because a lot of times those 96 00:07:46,220 --> 00:07:51,920 things tend not to have owners, right? Like who owns this thing that doesn't really exist? That's a 97 00:07:51,920 --> 00:07:56,720 really difficult question to, to, to answer. But if you can put it in an executive who's got the 98 00:07:56,720 --> 00:08:02,760 ability to form groups to attack those problems, then that, that's a huge enabler. Adopting 99 00:08:02,760 --> 00:08:07,660 Pivotal Cloud Foundry was not the most radical transformation going on at West in 2018. 100 00:08:08,080 --> 00:08:15,880 Right. So there was more of a culture and, and process and, uh, approach to computing versus 101 00:08:15,880 --> 00:08:19,780 the actual technology that was underlying it. That was more of the challenge, sounds like. 102 00:08:19,780 --> 00:08:28,700 Correct. Any, any re-platforming project of this scale, um, must impact all parts of the business 103 00:08:28,700 --> 00:08:34,740 and must, you know how Jason referenced, uh, prying loose anything that isn't bolted down. 104 00:08:35,080 --> 00:08:42,480 You could sort of extend that analogy to fixed processes, um, functioning relationships cross-functionally 105 00:08:42,480 --> 00:08:47,740 within West. So it's not simply a tale about moving to agile. It's, it's, it's not even that 106 00:08:47,740 --> 00:08:56,100 simple to say, but it's, um, process of, of governance of, uh, workflow of change control. Every single 107 00:08:56,100 --> 00:09:03,260 thing about that last mile that involved people and or technology has been changing. We had preceded the 108 00:09:03,260 --> 00:09:08,120 PCF adoption with the, uh, continuous integration, continuous deployment effort, a very familiar 109 00:09:08,120 --> 00:09:13,280 tool stack to most, um, and enterprise-wide adoption of New Relic is also concurrent to all 110 00:09:13,280 --> 00:09:19,080 of these. So all of these are change agents to that culture and process. Meanwhile, a lot 111 00:09:19,080 --> 00:09:23,800 of turnover and a lot of churn among our existing teams. So that's a lot to manage. Yeah. When you've 112 00:09:23,800 --> 00:09:27,580 got a, the kind of history that we had of all these snowflakes in this environment, all these 113 00:09:27,580 --> 00:09:32,260 systems that were different, right. It's really difficult to throw, to throw automated process 114 00:09:32,260 --> 00:09:38,780 and technology at a problem like that. Right. So our, our governance mindset became slow down, 115 00:09:39,140 --> 00:09:43,140 think, get everybody in a room before you touch anything and make sure that everybody agrees 116 00:09:43,140 --> 00:09:49,660 that it's safe to do it. Right. And that our, our gut response to stability was to slow down 117 00:09:49,660 --> 00:09:56,140 and think, and then to flip that on its head and say, the way to get to stability is to go faster 118 00:09:56,140 --> 00:10:02,120 and be able to react faster to problems. It was, it was just a real kind of epiphany that a lot of 119 00:10:02,120 --> 00:10:06,340 people had to go through. And some people really had trouble with that, right? People are wired different 120 00:10:06,340 --> 00:10:12,420 ways. Um, but the, that, that tide is turning, right? The culture is starting to, to wrap their head 121 00:10:12,420 --> 00:10:17,260 around going faster is how you actually get the stability. Even one other layer to that change, 122 00:10:17,260 --> 00:10:23,880 I forgot to mention, but I think it's significant is we've migrated from, from our, uh, from service 123 00:10:23,880 --> 00:10:30,340 desk to service now. And just switching tools is not the half of that story that, um, a much more 124 00:10:30,340 --> 00:10:35,620 comprehensive form of managing our time tracking, our respective projects, how we handle all of these 125 00:10:35,620 --> 00:10:41,820 related processes is another layer and opportunity. It's, it's, it's complexity, but it's also 126 00:10:41,820 --> 00:10:48,100 opportunity. But we, we created a lot of chaos for ourselves, but looking back, I'm not even sure 127 00:10:48,100 --> 00:10:53,760 how we could have avoided it. Yeah. It was, it was good because it forced us to examine the 128 00:10:53,760 --> 00:10:58,300 organizational structure and the processes that we had put in place and that we're enabling with this 129 00:10:58,300 --> 00:11:02,120 old tool and then go, man, do we really want to repaid that cow path in the new tool? 130 00:11:03,300 --> 00:11:07,460 No, let's simplify things. And that kind of broke a lot of logjams. 131 00:11:07,460 --> 00:11:14,480 Mm-hmm. And talk about how you extend the culture change throughout the enterprise. I mean, 132 00:11:14,520 --> 00:11:18,460 it's a large company, uh, you mentioned there was some turn, turn over because some folks just 133 00:11:18,460 --> 00:11:24,020 kind of couldn't, couldn't grok the, uh, the fail fast and agile mentality. Um, but how, what were 134 00:11:24,020 --> 00:11:30,060 some lessons learned in terms of reaching out and winning the hearts and minds, uh, of those 135 00:11:30,060 --> 00:11:32,740 different constituencies within the, within the enterprise? 136 00:11:36,420 --> 00:11:40,240 It's an essay question to me. I'm trying to think of the right way to sequence it, but 137 00:11:40,240 --> 00:11:48,220 some little wins, some early wins, um, basic responsiveness. Um, the people who would manage 138 00:11:48,220 --> 00:11:55,320 the legacy platform for application teams might not easily be available to teams trying to push 139 00:11:55,320 --> 00:12:02,460 an application through. And it could sincerely have been, I mean, Jason and I know, and his team have 140 00:12:02,460 --> 00:12:06,900 often had to wait several weeks for somebody to push a deploy button that they knew dang well was going 141 00:12:06,900 --> 00:12:13,480 to work, right? The first time. But, um, so that kind of access, um, and real-time responsiveness 142 00:12:13,480 --> 00:12:19,700 by the operators team of Pivotal Cloud Foundry at West is probably the most significant early win. 143 00:12:19,700 --> 00:12:26,660 Um, um, even if the answers weren't always there and weren't always right, they knew that somebody 144 00:12:26,660 --> 00:12:33,120 was engaged in dialogue with them. And I think you take a little win like that and then you apply 145 00:12:33,120 --> 00:12:39,000 something beyond West or beyond Pivotal, uh, lots of different ways to look at it, but how an innovation 146 00:12:39,000 --> 00:12:45,000 diffuses itself across an organization. There's lots of different handles and disciplines can, can use the 147 00:12:45,000 --> 00:12:51,640 language differently, but basically the mechanics are you find eager adopters, early adopters, you 148 00:12:51,640 --> 00:12:56,840 enable them, you put the machete in their hands so they can hack the forest floor a little bit, and 149 00:12:56,840 --> 00:13:02,440 then you try to learn from their lessons and keep publishing, stay responsive throughout, even if that 150 00:13:02,440 --> 00:13:08,360 responsive means taking it on the chin one day. And, you know, some very ugly system failures. I can think 151 00:13:08,360 --> 00:13:13,720 last year of a, uh, dev test site failure, you know, that took a few days and we were all just, it was 152 00:13:13,720 --> 00:13:20,040 just, every day was fingernails on blackboard all day long. But we, we had to face that fire and keep 153 00:13:20,040 --> 00:13:25,560 communicating. So I think that's the, the single most important tactical factor. Since then, it's been a 154 00:13:25,560 --> 00:13:31,960 little bit more of an enterprise change management approach. Um, we talk to each other a lot better 155 00:13:31,960 --> 00:13:36,440 than we used to. There's lots of different discussion forums that are now, because our project is far enough 156 00:13:36,440 --> 00:13:41,800 along focused and detailed. We don't just bring in somebody who worked for Pivotal, 157 00:13:41,800 --> 00:13:46,200 works for Pivotal talking about the value propositions of the platform. We can now bring 158 00:13:46,200 --> 00:13:51,880 in survivors like Jason and his team who can tell their specific tales about it. We've had enough .NET 159 00:13:51,880 --> 00:13:56,520 applications try to go through where we now have kind of a support group there that can talk to the 160 00:13:56,520 --> 00:14:00,680 next ones who are going to come through it. So it is pretty much an oral tradition. 161 00:14:00,680 --> 00:14:04,280 You know, there's a, there was a lot of cultural drive kind of from the top down, from the bottom 162 00:14:04,280 --> 00:14:10,040 up. The way we tried to drive it is just winning cures a lot of ills. You know, you know, we were 163 00:14:10,040 --> 00:14:15,720 a good candidate to go first because we already had full CICD. We already had, you know, a lot of 164 00:14:15,720 --> 00:14:23,000 those tooling in place, but we were holding it all together manually, right? We spun up our own 165 00:14:23,000 --> 00:14:27,720 Ansible instance, you know. Things like that, you know. The dev team doesn't want to deal with, 166 00:14:27,720 --> 00:14:34,520 but we were dealing with it. So moving from that environment into, you know, our managed, 167 00:14:34,520 --> 00:14:40,280 foundry-based, you know, corporate CICD, all that kind of stuff, made our developers really happy, 168 00:14:40,280 --> 00:14:43,560 right? Because now they didn't have to deal with all that stuff that they used to have to deal with. 169 00:14:43,560 --> 00:14:47,480 And now all of a sudden we were going faster, and we were pushing things into product faster, 170 00:14:47,480 --> 00:14:52,120 and we were getting scale that was difficult to achieve because it took me two weeks to get 171 00:14:52,120 --> 00:14:57,640 a VM before, and now I could not get the smash button and get more instances, right? And then we saw 172 00:15:00,760 --> 00:15:06,600 groups that were less down the path of kind of being cloud native and ready for that kind of thing go, 173 00:15:06,600 --> 00:15:13,000 "Oh, there's a path of least resistance. I'll follow that," right? So somebody has to be a wake-breaker 174 00:15:13,000 --> 00:15:17,960 and make a wake for those behind them. Finding a good candidate that's willing to take a couple 175 00:15:17,960 --> 00:15:22,680 shots on the chin and make a wake and who's probably going to see immediate benefit from just being in 176 00:15:22,680 --> 00:15:26,040 the ecosystem is a really good strategy. Right. Well, and it sounds like you picked a good 177 00:15:26,040 --> 00:15:30,680 candidate because, as you said, you had a need there. So it was definitely going to benefit your 178 00:15:30,680 --> 00:15:34,280 group. Your developers were going to have a better experience. And so that sounds like one 179 00:15:35,480 --> 00:15:37,880 criteria in terms of when you're looking for that early win, 180 00:15:39,720 --> 00:15:43,160 a potential group to embrace would be someone like that or a group like that. 181 00:15:43,160 --> 00:15:46,920 Yeah. I mean, we really, you know, we needed to learn PCF, but we didn't need to learn 182 00:15:46,920 --> 00:15:50,360 agile concepts. We didn't need to learn how to use Jenkins. We didn't need to learn, you know, 183 00:15:50,360 --> 00:15:54,280 all those kind of things. Like, it can be really overwhelming for a new team. So having a team that's 184 00:15:54,280 --> 00:15:58,920 gone through a bunch of that kind of learning already, so that their delta in learning is pretty 185 00:15:58,920 --> 00:16:03,800 small and that it makes what they're already doing easier, like that there's no friction there, 186 00:16:03,800 --> 00:16:10,440 right? One other aspect of change management I think important to bring up is we made sure we 187 00:16:10,440 --> 00:16:17,080 walked everything through the front door. And what I mean is the team operating and building PCF 188 00:16:17,080 --> 00:16:22,040 in early stages was part of a transitional authority. So on an org chart, it's isolated, 189 00:16:22,040 --> 00:16:31,320 but that isolation could have lent the opportunity to change the way we push applications through 190 00:16:31,320 --> 00:16:37,560 to production to avoid existing processes like our change control. The back door was there. We could 191 00:16:37,560 --> 00:16:45,320 all see it, but we committed at a very early stage to, if we want to see procedural reform within West, 192 00:16:45,320 --> 00:16:53,240 we had to have existing authorities and existing procedures see and confront again and again these 193 00:16:53,240 --> 00:16:58,440 decisions to have to make. So that by about the 15th or 18th time they're saying no to something, 194 00:16:58,440 --> 00:17:03,960 they might ask themselves, "Maybe there's a different answer here." We had to let them decide 195 00:17:03,960 --> 00:17:10,600 to make that change and give them the confidence that they were going to be able to be in control of that change. 196 00:17:10,600 --> 00:17:18,440 And I thought that was, engagement is control and interest. And to get engagement from these teams, 197 00:17:18,440 --> 00:17:24,520 to be able to take this project seriously because similarly large investments have fallen to dust 198 00:17:24,520 --> 00:17:31,160 before, to know that this one was not going anywhere, I think that engagement was important. 199 00:17:31,160 --> 00:17:35,640 You know, little things that facilitated that, like the original PCF box group that was putting 200 00:17:35,640 --> 00:17:41,800 together at the initial counters, we sat them right next to my team. And my team's on the progressive 201 00:17:41,800 --> 00:17:46,920 end of the spectrum as far as managing to process and things like that and being able to pick up 202 00:17:46,920 --> 00:17:54,600 and have a conversation human to human and challenge, "Is that really how we want to do this again? Or man, 203 00:17:54,600 --> 00:18:00,920 this is a real pain, can you help me?" There were some real wins on just having human face-to-face, 204 00:18:00,920 --> 00:18:04,680 working together kind of stuff going between the app team and the Foundry team. 205 00:18:04,680 --> 00:18:09,240 Got it. And so, as we wrap up, I wanted to hear a little bit about your experience working 206 00:18:09,240 --> 00:18:14,680 with Pivotal. My understanding is you also worked with Cognizant to help with some of the scaling. 207 00:18:14,680 --> 00:18:17,880 Cognizant and Stark and Wayne. And Stark and Wayne. Tell me a little bit about the role. 208 00:18:19,320 --> 00:18:24,200 Maybe we start with Stark and Wayne and Cognizant and those kind of consultancies. What role did they 209 00:18:24,200 --> 00:18:30,680 play and how did they help you take this approach from kind of those that first successful engagement 210 00:18:30,680 --> 00:18:34,680 to starting to scale this out throughout the enterprise? Stark and Wayne has provided through 211 00:18:34,680 --> 00:18:40,680 Pivotal generally a series of platform reliability engineers at different stages of the project, 212 00:18:40,680 --> 00:18:47,160 particularly early on. They were there. They have also staffed a recent platform dojo 213 00:18:49,240 --> 00:18:54,760 hosted by Pivotal but involving some Stark and Wayne resources. Cognizant has been on the application 214 00:18:54,760 --> 00:18:59,880 transformation side, leading a series of dojos, particularly when the location of those dojos 215 00:18:59,880 --> 00:19:05,000 is a little bit far afield for say Pivotal resources or our own West resources. I should add to 216 00:19:05,480 --> 00:19:12,440 Cognizant leading dojos, Pivotal leading dojos. We use the engagement plan with Pivotal. There's also 217 00:19:12,440 --> 00:19:16,920 been our own West internal center of excellence team that we call the cloud native enablement team, 218 00:19:16,920 --> 00:19:24,680 that it's the same idea as the center of excellence. They went through pal training at Pivotal and they 219 00:19:24,680 --> 00:19:30,680 represent different disciplines, different business units. They and so they are a third and ongoing 220 00:19:30,680 --> 00:19:41,080 source of the dojos. Pivotal has supplied ongoing account people, product managers, a general 221 00:19:41,640 --> 00:19:48,760 platform specialist, human spackle and polyfill that fills almost any possible role for us at any time. 222 00:19:49,800 --> 00:19:54,520 Including ventriloquism too and a zero-diversion X style that I greatly appreciate from time to time. 223 00:19:56,200 --> 00:20:02,520 So the help from all of those groups has been vital to success. I think the closest to home has been 224 00:20:02,520 --> 00:20:07,960 primarily pivotal and secondarily Stark and Wayne because they have had a direct impact on what the 225 00:20:07,960 --> 00:20:12,520 platform looks like now, how we automate, how we push things through and how we deploy. 226 00:20:12,520 --> 00:20:17,320 Right. And so it's a lot about, as you mentioned, enablement. The dojos are essentially helping you, 227 00:20:17,320 --> 00:20:23,080 helping your teams learn some of the concepts and how to run the platform, those kinds of things. And 228 00:20:23,080 --> 00:20:26,840 then they can take that and hopefully spread that throughout the rest of your organization through 229 00:20:26,840 --> 00:20:28,760 some of your enablement, internal enablement efforts. 230 00:20:28,760 --> 00:20:35,560 Great modeling. They model. They show you how they modeled. They're willing to tell you explicitly why 231 00:20:35,560 --> 00:20:44,440 they do the things they do. And they're willing to walk with you to sell the concepts to your supervisors and 232 00:20:44,440 --> 00:20:50,600 senior leadership. And like any sophisticated mature service provider and professional services organization, 233 00:20:50,600 --> 00:20:57,560 which Pivotal is in part to us, is it's a consultative practice, at least as much as it is a technology 234 00:20:57,560 --> 00:21:04,840 platform for us to adopt, that they have successfully engaged West at all levels, analyst to C-suite, 235 00:21:05,560 --> 00:21:12,840 up and down. The Rolodex is there and they know who to talk to. And they, and so I greatly appreciate 236 00:21:12,840 --> 00:21:17,000 their ability to pragmatically help us manage change within our own organization. 237 00:21:17,000 --> 00:21:21,720 Um, that's, that, they'll sound like broad strokes. A couple of more specific things I'd say is, uh, 238 00:21:23,160 --> 00:21:27,960 um, when things were dark, I'd say about six to eight months ago, 239 00:21:29,160 --> 00:21:37,720 they weren't shy and they behaved like a very responsible project manager in much the same way our 240 00:21:37,720 --> 00:21:46,600 own project management team responded very ably and, and valiantly at times to identify critical blockers 241 00:21:46,600 --> 00:21:51,480 and remove them. And I could think back to every one of those critical blockers, a list of about 13 to 242 00:21:51,480 --> 00:21:59,320 15 that we've mowed down since then. Um, every single one of those were either identified by 243 00:22:00,040 --> 00:22:07,320 at least partially a pivot and resolved by at least partially a pivot. Great. Um, so as we wrap up, 244 00:22:07,320 --> 00:22:12,360 what's, what's the future hold? So you're about a year and a half into the journey, maybe take us 245 00:22:12,360 --> 00:22:15,960 another six months to another six months to a year out. What, what's, what are you hoping to accomplish? 246 00:22:15,960 --> 00:22:18,680 Let's go with the app first and then I'll go to the platform. 247 00:22:18,680 --> 00:22:25,880 Yeah. I mean, you know, as we've, as we've completed app migrations, right, to differing degrees, 248 00:22:25,880 --> 00:22:33,240 we've also become more cloud native. Um, and I think probably less transformation than, 249 00:22:33,240 --> 00:22:38,920 than, than we probably anticipated that we would have, right? More, more lifted move than, 250 00:22:38,920 --> 00:22:44,200 than actually taking advantage of what's there. So there's, there's a lot of stuff in the platform. 251 00:22:44,200 --> 00:22:49,400 It's like auto scaling, um, that a lift and move application just doesn't really do very well. 252 00:22:49,400 --> 00:22:56,040 Um, so the transformation of what is in the foundry to take advantage of the, the stuff that, 253 00:22:56,040 --> 00:23:01,640 that the platform offers, I think is kind of the next, the next big iteration, the next transformation 254 00:23:01,640 --> 00:23:06,520 that, that teams that have adopted will be there. Like, okay, now I'm here. Like, I, I got my CICD 255 00:23:06,520 --> 00:23:12,760 stack working. I, I, I, I still, I still have, you know, all these shiny things that I want to take 256 00:23:12,760 --> 00:23:15,880 advantage of that I can't yet. So let me transform my app to do that. 257 00:23:15,880 --> 00:23:22,120 Mm-hmm. And do you have a plan to, uh, kind of, kind of determine and prioritize which, which applications 258 00:23:22,120 --> 00:23:27,400 and which, which, uh, suite of applications get, you know, get top, top billing and are going to go first? 259 00:23:27,400 --> 00:23:32,120 And how do you think about that? Revenue wins the day in general. So you look for revenue 260 00:23:32,120 --> 00:23:38,200 and you look for, um, the direction of that revenue too. And you make sure that we're going 261 00:23:38,200 --> 00:23:44,200 to get the return of investment, um, for the choices that we make, because we know that, um, 262 00:23:44,200 --> 00:23:49,800 while we are definitely not a homogenous portfolio of applications, there are lessons to be learned 263 00:23:49,800 --> 00:23:55,320 from an app transformation adventure by one team that could be shared to others. There are enough 264 00:23:55,320 --> 00:24:01,480 commonalities where even to the teams we don't target for that immediate, um, next level at 265 00:24:01,480 --> 00:24:06,280 transformation opportunities are there. Tactically, uh, what we're doing with the center of excellence 266 00:24:06,280 --> 00:24:12,120 team internally, the West is looking into the rest of this calendar year and doing, um, second dojos at 267 00:24:12,120 --> 00:24:17,320 transformation dojos with them. Let's pick a fight. Let's pick one about auto scaling, for example. 268 00:24:17,320 --> 00:24:22,680 And let's see if we can get you to avail yourself of that important service. So that's kind of where 269 00:24:22,680 --> 00:24:27,800 we are in a, in a, in a project perspective. We have metrics that we look at, uh, not just the 270 00:24:27,800 --> 00:24:33,880 applications we've onboarded, but application teams. And just as a change management metric, have you, 271 00:24:33,880 --> 00:24:38,200 have you had a representative from this team attend a dojo or had significant correspondence, 272 00:24:38,200 --> 00:24:43,960 um, to be able to get ready to conceive of how to transform their application. We've talked to all 273 00:24:43,960 --> 00:24:49,160 but two of the teams that we know exist in the project of West, almost everybody in the two teams 274 00:24:49,160 --> 00:24:54,520 that remain. We know very well, and we already know how that conversation would go. So we are 275 00:24:54,520 --> 00:25:00,680 at a relative luxury now of being able to focus on those second dojos with us. Yeah, I think the, 276 00:25:00,680 --> 00:25:06,920 the reality is that this migration has consumed a lot of development cycles, um, over the last year 277 00:25:06,920 --> 00:25:13,880 and a half. And that's created a pent up demand for product features. So I think, you know, our 278 00:25:13,880 --> 00:25:21,080 success going forward will be dependent upon our ability to, to prioritize applications that have 279 00:25:21,080 --> 00:25:27,880 both a combination of pent up feature demand to take advantage of revenue and are ready to take 280 00:25:27,880 --> 00:25:31,960 advantage of the transformative steps. Right. So like when you squeeze, where are you going to get 281 00:25:31,960 --> 00:25:37,320 the most juice? When we're fortunate, we'll have a backlog item that aligns with the transformation. 282 00:25:37,720 --> 00:25:40,920 That's exactly right. Those are the ones that should bubble to the top because again, 283 00:25:40,920 --> 00:25:43,960 they'll make a wake for the ones where the transformations are harder behind them. 284 00:25:45,160 --> 00:25:48,760 All right. Well, I think that's a great place to wrap up. Thanks so much for joining us. 285 00:25:48,760 --> 00:25:53,160 Appreciate it. And perhaps next year at this time, we can do this again. And I would love to hear how 286 00:25:53,160 --> 00:25:57,160 it went. You're most welcome. We'll do the next one from the beach because all of our apps will be in. 287 00:25:57,160 --> 00:26:02,360 Exactly. We'll be sipping pina coladas and having a grand old time with our feet in the sand. 288 00:26:02,360 --> 00:26:08,760 All right, gentlemen. Thank you so much. Thank you.