Hey, listeners. Welcome back for another episode of Pivotal Conversations. My name is Dorme Andrewitz, and this week I'm happy to bring you an interview with Terry Miles and Jason Nash of Entrato. This interview was actually recorded back in April of 2019 when Terry, Jason, and their colleague Don gave a presentation at CF Summit about modernizing and migrating 170 plus applications in 18 months. Now, a lot's changed since April of 2019. One, you'll notice that Terry and Jason refer to West Corporation. West Corporation has since rebranded to Entrato, so you'll just have to map those types of references in your head, and you'll be able to find ongoing information if you look for Entrato. Second, you'll hear Jeff Kelly as the interviewer. Jeff Kelly was one of our esteemed co-hosts here at Pivotal Conversations. He's now an esteemed Pivotal alumni, but we get to hear his great interviewing skills one more time. And finally, there's been an update in the form of Terry's presentation that he actually gave in October of 2019 at SpringOne Platform. And it's got a very similar title to the talk that he, Jason, and Don gave back at CF Summit. But I got to tell you, they're very different presentations, both worth listening to independently to get different levels of insight. And on that note, I hope you enjoy this particular interview because there's a lot of great insights for teams that are working on large-scale transformation. So with that, enjoy. But why don't we start with, just if you could introduce yourselves, just kind of your name, your title, what you do, and then we can get into a little bit about the story of the application transformation that you're doing. Sure. Terry Miles, product manager with West Corporation, the platform owner for PCF. Responsibilities include that, and also the broader aspect of change management for the entire enterprises that adopts PCF and related services. Great. And I'm Jason Nash, product engineering manager, and I lead a dev team that was the first or
2:00one of the very first to jump onto the platform and shake loose what wasn't bolted down. Got it. And for those listening who don't know too much about West, tell us a little bit about the company. I understand you were acquired and kind of changing your model from a holding company model to more of an operations or operational model. Tell us a little bit about that and how that impacts your application portfolio. That's exactly the case. We average about $2 billion annual revenue. That has been primarily historically through a series of acquisitions. We have always let those acquisitions lie. And while there have been previous attempts before the adoption of Pivotal Cloud Foundry to at least unify some of our infrastructural resources, we haven't gone very far in that direction. And it's not just a matter of practice, but a matter of policy. We just saw it to be more efficient to leave those lie as they were. We are now owned by a private equity group. And among the mandates they brought is greater platform consolidation primarily for the purposes of efficiency. That is the first explicit phase, the justification for the adoption of Pivotal Cloud Foundry at West. But there is also the greater idea of platform consolidation, greater efficiencies, more rapid release cycles, and the usual types of business value. So that's our size. That's our lineage to a certain degree. Offices in, I think I counted about 14 different countries. Time zones all over the world. Distributed teams, not just by business unit, but many of our project teams are distributed around the globe too. Okay. And so I understand, you know, part, as you mentioned, it's part about gaining efficiencies. You've got quite a fairly large application portfolio. So a lot of folks that I talk to, they often start very small and they'll pick one or two applications, kind of experiment, learn the culture a little bit there, and then kind of expand to the larger application portfolio. Tell us a little bit about your approach because you're coming in knowing, you know, hey, we have a mandate to really move all these apps over. What's, what was the strategy? I think Jason's going to have a good story to tell in there, but I'll start with the broad strokes. We tried for a combination of initial application selection for A, low-hanging fruit, B, bang for
4:05buck, value, size, impact. And the commercial outbound platform that Jason manages is one of those early candidates because they fit both criteria. Is that how, from your experience, how it went, Jason? Yeah. I mean, we were really trained to kind of kill two birds with one stone on it. We wanted to get the, the developmental efficiencies and, you know, not have to worry about that stuff. But we were also dealing with a ton of operational sprawl and snowflakes all over the environment that really slowed our dev cycles down and made our systems fragile. And, and even if you were just lifting and moving something that was fully functional and you weren't really transforming it into something that was more cloud native and we took advantage of the platform, there was still benefits to us for doing that. So we pushed really hard on anything that will fit, let's shove it in there and we'll figure it out after. Okay. And, and so I know you're, you're speaking tomorrow at the conference. So, and you're going to share some lessons learned. I mean, if you give us a little preview of that. So what, what, actually, why don't you tell us a little bit about where you are now in the journey? I think it's about a year and a half. I've, if I'm reading correctly, tell us a little bit about where you are now and then maybe we can get into a few of the lessons learned. We're gaining traction now. We have gone from about a total of, with a, with a, with a final projected total of about 5,400 AIs in our respective founders. That's the end state that we would expect near the end of this calendar year, sometime first quarter of the next. We had struggled for a large part of 2018. We were sitting only at about six, 700 AIs through last October. And that number had been static through most of the summer and the early fall. But now we are to the point of 2200 application instances. We've seen rapid growth in the first quarter of this year. And it was just due to a lot of hustle, you know, a lot of, you know, product, project management driven, um, making teams identify why they can't get through and doing whatever we had to do, begging, borrowing resources, but getting as creative and as pragmatic as possible to at least get them in to their first initial
6:08customer cutovers. So in terms of our project status, we, uh, we, we saw things darkly about six months ago. Things were a lot better than they used to be. Most of it was due to just our own organization's ability to lift itself out. And a few of the people that sit around this table that you don't hear that work for pivotal too. Um, we feel it's a particularly good client relationship, professional services story to tell. Great. Um, so yeah, why, why don't you tell us a little bit about why you think you were kind of stuck around that 600 AI mark? What were some of the things that were making it challenging to kind of take that, that leap to the next level? We really had a lot of problems with last mile, right? Like you got all the way through and then there was something in the greater ecosystem that was missing, right? Whether it was database, whether it was, um, you know, caching layer, whether it was logging and, you know, those types of things, like we made it work. And then when it was time to productionalize it and take it to scale, there was some piece of the external ecosystem that had to be brought online. And as an organization, we did a pretty good job about six months ago of really, um, identifying what those blockers were and creating like executive level kind of task forces to go knock those blockers out as enablers for the rest of the team. I think that's what broke the dam. That's, that's, that's when you started to see the AI count really go up. So getting that executive buy-in? It was, you know, it was, it was, uh, uh, acknowledgement that there were holes in our solution stack and they weren't pivotal holes, right? They were, they were, they were things that you needed in order to make your applications run, you know, an acknowledgement that, man, we really need to address those. And then the executive will to kind of do those because a lot of times those things tend not to have owners, right? Like who owns this thing that doesn't really exist? That's a really difficult question to, to, to answer. But if you can put it in an executive who's got the ability to form groups to attack those problems, then that, that's a huge enabler. Adopting Pivotal Cloud Foundry was not the most radical transformation going on at West in 2018.
8:08Right. So there was more of a culture and, and process and, uh, approach to computing versus the actual technology that was underlying it. That was more of the challenge, sounds like. Correct. Any, any re-platforming project of this scale, um, must impact all parts of the business and must, you know how Jason referenced, uh, prying loose anything that isn't bolted down. You could sort of extend that analogy to fixed processes, um, functioning relationships cross-functionally within West. So it's not simply a tale about moving to agile. It's, it's, it's not even that simple to say, but it's, um, process of, of governance of, uh, workflow of change control. Every single thing about that last mile that involved people and or technology has been changing. We had preceded the PCF adoption with the, uh, continuous integration, continuous deployment effort, a very familiar tool stack to most, um, and enterprise-wide adoption of New Relic is also concurrent to all of these. So all of these are change agents to that culture and process. Meanwhile, a lot of turnover and a lot of churn among our existing teams. So that's a lot to manage. Yeah. When you've got a, the kind of history that we had of all these snowflakes in this environment, all these systems that were different, right. It's really difficult to throw, to throw automated process and technology at a problem like that. Right. So our, our governance mindset became slow down, think, get everybody in a room before you touch anything and make sure that everybody agrees that it's safe to do it. Right. And that our, our gut response to stability was to slow down and think, and then to flip that on its head and say, the way to get to stability is to go faster and be able to react faster to problems. It was, it was just a real kind of epiphany that a lot of people had to go through. And some people really had trouble with that, right? People are wired different ways. Um, but the, that, that tide is turning, right? The culture is starting to, to wrap their head
10:12around going faster is how you actually get the stability. Even one other layer to that change, I forgot to mention, but I think it's significant is we've migrated from, from our, uh, from service desk to service now. And just switching tools is not the half of that story that, um, a much more comprehensive form of managing our time tracking, our respective projects, how we handle all of these related processes is another layer and opportunity. It's, it's, it's complexity, but it's also opportunity. But we, we created a lot of chaos for ourselves, but looking back, I'm not even sure how we could have avoided it. Yeah. It was, it was good because it forced us to examine the organizational structure and the processes that we had put in place and that we're enabling with this old tool and then go, man, do we really want to repaid that cow path in the new tool? No, let's simplify things. And that kind of broke a lot of logjams. Mm-hmm. And talk about how you extend the culture change throughout the enterprise. I mean, it's a large company, uh, you mentioned there was some turn, turn over because some folks just kind of couldn't, couldn't grok the, uh, the fail fast and agile mentality. Um, but how, what were some lessons learned in terms of reaching out and winning the hearts and minds, uh, of those different constituencies within the, within the enterprise? It's an essay question to me. I'm trying to think of the right way to sequence it, but some little wins, some early wins, um, basic responsiveness. Um, the people who would manage the legacy platform for application teams might not easily be available to teams trying to push an application through. And it could sincerely have been, I mean, Jason and I know, and his team have often had to wait several weeks for somebody to push a deploy button that they knew dang well was going to work, right? The first time. But, um, so that kind of access, um, and real-time responsiveness
12:13by the operators team of Pivotal Cloud Foundry at West is probably the most significant early win. Um, um, even if the answers weren't always there and weren't always right, they knew that somebody was engaged in dialogue with them. And I think you take a little win like that and then you apply something beyond West or beyond Pivotal, uh, lots of different ways to look at it, but how an innovation diffuses itself across an organization. There's lots of different handles and disciplines can, can use the language differently, but basically the mechanics are you find eager adopters, early adopters, you enable them, you put the machete in their hands so they can hack the forest floor a little bit, and then you try to learn from their lessons and keep publishing, stay responsive throughout, even if that responsive means taking it on the chin one day. And, you know, some very ugly system failures. I can think last year of a, uh, dev test site failure, you know, that took a few days and we were all just, it was just, every day was fingernails on blackboard all day long. But we, we had to face that fire and keep communicating. So I think that's the, the single most important tactical factor. Since then, it's been a little bit more of an enterprise change management approach. Um, we talk to each other a lot better than we used to. There's lots of different discussion forums that are now, because our project is far enough along focused and detailed. We don't just bring in somebody who worked for Pivotal, works for Pivotal talking about the value propositions of the platform. We can now bring in survivors like Jason and his team who can tell their specific tales about it. We've had enough .NET applications try to go through where we now have kind of a support group there that can talk to the next ones who are going to come through it. So it is pretty much an oral tradition. You know, there's a, there was a lot of cultural drive kind of from the top down, from the bottom up. The way we tried to drive it is just winning cures a lot of ills. You know, you know, we were a good candidate to go first because we already had full CICD. We already had, you know, a lot of
14:15those tooling in place, but we were holding it all together manually, right? We spun up our own Ansible instance, you know. Things like that, you know. The dev team doesn't want to deal with, but we were dealing with it. So moving from that environment into, you know, our managed, foundry-based, you know, corporate CICD, all that kind of stuff, made our developers really happy, right? Because now they didn't have to deal with all that stuff that they used to have to deal with. And now all of a sudden we were going faster, and we were pushing things into product faster, and we were getting scale that was difficult to achieve because it took me two weeks to get a VM before, and now I could not get the smash button and get more instances, right? And then we saw groups that were less down the path of kind of being cloud native and ready for that kind of thing go, "Oh, there's a path of least resistance. I'll follow that," right? So somebody has to be a wake-breaker and make a wake for those behind them. Finding a good candidate that's willing to take a couple shots on the chin and make a wake and who's probably going to see immediate benefit from just being in the ecosystem is a really good strategy. Right. Well, and it sounds like you picked a good candidate because, as you said, you had a need there. So it was definitely going to benefit your group. Your developers were going to have a better experience. And so that sounds like one criteria in terms of when you're looking for that early win, a potential group to embrace would be someone like that or a group like that. Yeah. I mean, we really, you know, we needed to learn PCF, but we didn't need to learn agile concepts. We didn't need to learn how to use Jenkins. We didn't need to learn, you know, all those kind of things. Like, it can be really overwhelming for a new team. So having a team that's gone through a bunch of that kind of learning already, so that their delta in learning is pretty small and that it makes what they're already doing easier, like that there's no friction there, right? One other aspect of change management I think important to bring up is we made sure we walked everything through the front door. And what I mean is the team operating and building PCF
16:17in early stages was part of a transitional authority. So on an org chart, it's isolated, but that isolation could have lent the opportunity to change the way we push applications through to production to avoid existing processes like our change control. The back door was there. We could all see it, but we committed at a very early stage to, if we want to see procedural reform within West, we had to have existing authorities and existing procedures see and confront again and again these decisions to have to make. So that by about the 15th or 18th time they're saying no to something, they might ask themselves, "Maybe there's a different answer here." We had to let them decide to make that change and give them the confidence that they were going to be able to be in control of that change. And I thought that was, engagement is control and interest. And to get engagement from these teams, to be able to take this project seriously because similarly large investments have fallen to dust before, to know that this one was not going anywhere, I think that engagement was important. You know, little things that facilitated that, like the original PCF box group that was putting together at the initial counters, we sat them right next to my team. And my team's on the progressive end of the spectrum as far as managing to process and things like that and being able to pick up and have a conversation human to human and challenge, "Is that really how we want to do this again? Or man, this is a real pain, can you help me?" There were some real wins on just having human face-to-face, working together kind of stuff going between the app team and the Foundry team. Got it. And so, as we wrap up, I wanted to hear a little bit about your experience working with Pivotal. My understanding is you also worked with Cognizant to help with some of the scaling. Cognizant and Stark and Wayne. And Stark and Wayne. Tell me a little bit about the role.
18:19Maybe we start with Stark and Wayne and Cognizant and those kind of consultancies. What role did they play and how did they help you take this approach from kind of those that first successful engagement to starting to scale this out throughout the enterprise? Stark and Wayne has provided through Pivotal generally a series of platform reliability engineers at different stages of the project, particularly early on. They were there. They have also staffed a recent platform dojo hosted by Pivotal but involving some Stark and Wayne resources. Cognizant has been on the application transformation side, leading a series of dojos, particularly when the location of those dojos is a little bit far afield for say Pivotal resources or our own West resources. I should add to Cognizant leading dojos, Pivotal leading dojos. We use the engagement plan with Pivotal. There's also been our own West internal center of excellence team that we call the cloud native enablement team, that it's the same idea as the center of excellence. They went through pal training at Pivotal and they represent different disciplines, different business units. They and so they are a third and ongoing source of the dojos. Pivotal has supplied ongoing account people, product managers, a general platform specialist, human spackle and polyfill that fills almost any possible role for us at any time. Including ventriloquism too and a zero-diversion X style that I greatly appreciate from time to time. So the help from all of those groups has been vital to success. I think the closest to home has been primarily pivotal and secondarily Stark and Wayne because they have had a direct impact on what the platform looks like now, how we automate, how we push things through and how we deploy. Right. And so it's a lot about, as you mentioned, enablement. The dojos are essentially helping you, helping your teams learn some of the concepts and how to run the platform, those kinds of things. And
20:23then they can take that and hopefully spread that throughout the rest of your organization through some of your enablement, internal enablement efforts. Great modeling. They model. They show you how they modeled. They're willing to tell you explicitly why they do the things they do. And they're willing to walk with you to sell the concepts to your supervisors and senior leadership. And like any sophisticated mature service provider and professional services organization, which Pivotal is in part to us, is it's a consultative practice, at least as much as it is a technology platform for us to adopt, that they have successfully engaged West at all levels, analyst to C-suite, up and down. The Rolodex is there and they know who to talk to. And they, and so I greatly appreciate their ability to pragmatically help us manage change within our own organization. Um, that's, that, they'll sound like broad strokes. A couple of more specific things I'd say is, uh, um, when things were dark, I'd say about six to eight months ago, they weren't shy and they behaved like a very responsible project manager in much the same way our own project management team responded very ably and, and valiantly at times to identify critical blockers and remove them. And I could think back to every one of those critical blockers, a list of about 13 to 15 that we've mowed down since then. Um, every single one of those were either identified by at least partially a pivot and resolved by at least partially a pivot. Great. Um, so as we wrap up, what's, what's the future hold? So you're about a year and a half into the journey, maybe take us another six months to another six months to a year out. What, what's, what are you hoping to accomplish? Let's go with the app first and then I'll go to the platform. Yeah. I mean, you know, as we've, as we've completed app migrations, right, to differing degrees,
22:25we've also become more cloud native. Um, and I think probably less transformation than, than, than we probably anticipated that we would have, right? More, more lifted move than, than actually taking advantage of what's there. So there's, there's a lot of stuff in the platform. It's like auto scaling, um, that a lift and move application just doesn't really do very well. Um, so the transformation of what is in the foundry to take advantage of the, the stuff that, that the platform offers, I think is kind of the next, the next big iteration, the next transformation that, that teams that have adopted will be there. Like, okay, now I'm here. Like, I, I got my CICD stack working. I, I, I, I still, I still have, you know, all these shiny things that I want to take advantage of that I can't yet. So let me transform my app to do that. Mm-hmm. And do you have a plan to, uh, kind of, kind of determine and prioritize which, which applications and which, which, uh, suite of applications get, you know, get top, top billing and are going to go first? And how do you think about that? Revenue wins the day in general. So you look for revenue and you look for, um, the direction of that revenue too. And you make sure that we're going to get the return of investment, um, for the choices that we make, because we know that, um, while we are definitely not a homogenous portfolio of applications, there are lessons to be learned from an app transformation adventure by one team that could be shared to others. There are enough commonalities where even to the teams we don't target for that immediate, um, next level at transformation opportunities are there. Tactically, uh, what we're doing with the center of excellence team internally, the West is looking into the rest of this calendar year and doing, um, second dojos at transformation dojos with them. Let's pick a fight. Let's pick one about auto scaling, for example. And let's see if we can get you to avail yourself of that important service. So that's kind of where we are in a, in a, in a project perspective. We have metrics that we look at, uh, not just the
24:27applications we've onboarded, but application teams. And just as a change management metric, have you, have you had a representative from this team attend a dojo or had significant correspondence, um, to be able to get ready to conceive of how to transform their application. We've talked to all but two of the teams that we know exist in the project of West, almost everybody in the two teams that remain. We know very well, and we already know how that conversation would go. So we are at a relative luxury now of being able to focus on those second dojos with us. Yeah, I think the, the reality is that this migration has consumed a lot of development cycles, um, over the last year and a half. And that's created a pent up demand for product features. So I think, you know, our success going forward will be dependent upon our ability to, to prioritize applications that have both a combination of pent up feature demand to take advantage of revenue and are ready to take advantage of the transformative steps. Right. So like when you squeeze, where are you going to get the most juice? When we're fortunate, we'll have a backlog item that aligns with the transformation. That's exactly right. Those are the ones that should bubble to the top because again, they'll make a wake for the ones where the transformations are harder behind them. All right. Well, I think that's a great place to wrap up. Thanks so much for joining us. Appreciate it. And perhaps next year at this time, we can do this again. And I would love to hear how it went. You're most welcome. We'll do the next one from the beach because all of our apps will be in. Exactly. We'll be sipping pina coladas and having a grand old time with our feet in the sand. All right, gentlemen. Thank you so much. Thank you.