Improving Software Development & Overcoming Modernization Challenges

ABOUT THIS EPISODE

Though the platforms have changed, many of the same application challenges still exist. Namely, finding alignment between the people who build the applications and the people who own and operate the platforms.

In this episode, Michael McCormick, Vice President of Technology at Artium, shares his perspective on these age-old challenges and provides advice on how to make modernization projects more effective.

We discuss:

  • The services offered by Artium
  • The practice of extreme programming
  • Lessons learned from multiple modernization projects
  • Tips for building a pipeline of exceptional talent

Resources mentioned during the podcast:

Want to hear more stories from high growth software companies? Subscribe to Application Modernization on Apple Podcasts, Spotify, or check out our website.

Listening on a desktop & can’t see the links? Just search for Application Modernization in your favorite podcast player.

You're listening to application modernization, a show that spotlights the forward thinking leaders of Highgro software companies. From scaling applications and accelerating time to market to avoiding expensive license and costs, we discuss how you can innovate with new technology and forward thinking processes and save some cash in the process. Let's get into it. Welcome to part two of our conversation with Mike McCormick of artium. In this section we're going to talk about extreme programming, building great teams, how to effectively develop talent. New Perspective on that. That's near and dear to my heart, as we continue to help develop great engineers at will. We do a chat US soft. It's a really thoughtful conversation. It's probably a bit more theoretical than tactical, but I think it's probably the best part of the podcast and really excited about it. So give this a Liston, make sure you subscribes and thank you, red hat, for continuing to support the podcast. I always like to jump in and, you know, ask about, you know, an interesting story, you know, like a lesson to learn or something you know the listeners can really grab onto and go, oh, that's I learned something or I never thought of it that way. I know you've got a few stories up your sleeve, so I want to, you know, take this time to see see if you'd share one of those with us. You know how how you know maybe you made a large impact with a customer. All sleep, you know, remain nameless for confidentiality, but you know some of the core concepts and the lessons learned around that. Sure, I've been part of a number of modernizations over the years of it and I think it's really fortunate. I think it's really for me, interesting to to work at places that are hugely impactful for the people that are that are working around that software that kind of live and breathe every day. And so one of the one of the modernizations I was thinking about talking about, you know, with you was, was one that was running on a mainframe.

The the crew had kind of gotten to the point where it was taking somewhere between six and twelve months to implement a new feature. You know, largely the age of the main frame. It kind of got no place where nothing was nothing was simple anymore. Everything, everything took a lot of thinking, a lot of planning. The backlog was was was Harry as well. So figuring out, you know, if everything takes six to twelve months, you know, how do we think about what's what's a priority, what's not a priority? And you know, mainframe. So finding folks that can continue to coball or folks that were like, Oh yeah, I'd love to do more coball. I'm young, I'm early in my career and the thing I really dreamed of doing coming out of college was coball to teach me more. But all of those things were becoming challenges for them and the main frame was running sort of a core, core component of their business. The seei at one point and said, Oh yeah, I've got we didn't use source control back then, but if we had source control you'd see commits for me in the main frame from back when I started here. Wow. So it was it was driving, you know, chunks of business from from his early career, which would have been about twenty, thirty years, you know, previous two when we stepped into the picture and and they just kind of realize like hey, this is, you know, we as a company. They'd started working much, much more closer together as business and technology. They as as a crew had acknowledged. Hey, software is foundational to who we are. Right like we want to make sure that we're thinking that way. We want to start putting you know what, what might traditionally be the business thinking about how we're working and technology thinking about how to support it. You know, we want to break that paradigm. We want to put people together and just start to think about you know, technology is our business, right the the way that we make money is through the technology that we have. And so they had somebody in it Org who'd been shepherding this program for a long time.

We'd sort of raise our hand and said enough is enough. We you know, we can't move very quick we know this is problematic. We're just not serving you know, we're not serving our customers and we're not serving the company in the way we want to do it right. So I'll be courageous, I'll put a you know, I'll draw line in sand and say no more and say like this is we want to go change this somehow right. And so, as a group working together, the that person, she ended up working with one of our business partners and saying, here's all the reasons why I think this needs to change. Modernizing this main frame is not going to be easy task. Folks are going to be nervous about it. How we do it technology wise, might allude most of us. Right now. We don't we don't really know what the Path is, but we think we want to. We think we want to go down the path of fixing it right. So first thing we did was come to work with us on. Hey, this is the here's the challenge we have, here's what we want to change. How do we break it down right? And so the the company I was with at the time, we, you know, we we stepped in said, okay, great, let's start to look at this from a perspective of like, how do things interact, you know for the business? What are we doing? We we took a very dumain driven design approach, right. So, so approaching it and saying, okay, well, how does business flow? What does that work like? Let's map that out and start to talk through it, and from that we can extract out a notional architecture over time. And so we, in a relatively short period time, over course of about two months, came up with kind of a notional architecture of what is what is happening inside of the main frame and how might that map to a more modern architecture? For for they wanted to bring it forward as a series of Java services. So how might that, you know, get pulled forward into job Alva and the more spring services really the we then sort of said, okay, now let's start to implement that, right,...

...let's let's pick a pattern on how we're going to pick this apart, because we're what we don't want to do is, you know, if there's eight services that we think we're going to get built, we don't want to go build all eight at the same time, right, and and just sort of say how us going to do this and get it going? You know, the biggest part of communication. Well, I had said, you know, my theory is that the hardst part software is communication, right, and so if you get eight, ten teams going at the same time on that, communication is going to be really stretched that right. So, right, so we said we're going to let's let's prioritize these, we're going to pick one and we're going to start there and we're going to just build with you, right, and we're going to we're going to build it, and what we're going to do is we're going to build it in a way that we can wire it in parallel to how the main frame is operating and we're going to take data on it right, inputs and output, and make sure that we can kind of get everybody on the same page. But we like it, we're happy with it, we're good with what we're doing and we're going to decommission that's sectional a code from the main frame right and and swap in our service. And that turned out to be a really good pattern for us in terms of how we were doing it, because the first service we built really only was about four weeks worth a backlog to to get it built where it could start to take weight. But it was not in in in their process for to playing evaluating services into playing code. It actually took another three months for us to be able to like put that service live and take traffic on it right. Like the code kind of set still for almost twelve weeks as we were, you know, waiting to kind of get it live and get going. And lots that was just overhead, right. Lots of that was sort of barriers that they put in place to their deployment pipeline so that they didn't make a mistaken ship, something that would would break the world, compromise the business. Right. So we were. I think the the important thing for us is we were cautious, you know it, as we built the software. We had good confidence, right, we were fine XP practices.

We had, you know, very healthy deployment pipeline, CICD for us, right, like making sure that, like, we trust them what's going on. We need to go make sure that everybody has trusting what's going on right, you know, from a product perspective. Does it behave like we expected to? Is there anybody that's still, you know, nervous about what we're what we're deploying our the idea that we would switch over the small chunk, you know, from from the mainframe over to this new spring service. The as we got some confidence around that, we started said, okay, great, one, now that we've got this going, let's spend up team two, three, you know, four, and so we started to kind of trickle in more teams over time. And that first team who had built something right and I got it running, they they said, okay, cool, well, backlog on. That is done. Right now we're kind of we're just running that. We could take on backlog for another service, and so we're able to start to pick off more of the notional architecture. But the important thing was that, you know, for us, as we got services in a production that that working software in production really changes the way that you think about how something's going to go. You learn quite a bit through the act of getting it into pride and so right the architecture for us, while, again it was kind of notional up front, we evolved it over time. We continue to dialog about what makes sense with some makes sense. What do we learned? How we how do we want to change? Where we have corruption layers? which things can we start to deprecate as we go and and it's a very kind of living, breathing process of the architecture of the running services themselves as we go along the the other thing that was interesting is that as we added more teams, we found that there were common things that we wanted to have. So we didn't start from a perspective of these these will naturally be the common things. Let's go extract those and we'll have a whole team that just builds that. We let the teams themselves start to tell us like hey, we're starting to duplicate here. How do we do these patterns? You know what, we have enough places that were kind of duplicating some of these patterns. Let's make a common team those tracts of stuff out and starts to make it available. And so it was was a much more organic evolution to the structure of the program and who was supporting what versus,...

...you know, kind of prescribing it up front and saying, well, obviously we're going to want to common team, like, let's put the common team there and get them to build, build the common things right in large air quotes, not knowing exactly what those common things might be. Yeah, so you're building some continuity within the customers team. You know, they're seeing the work that's being done, they're getting involved when it's their turn and then they see some of them momentum around it and then they're like we should focus on do this type of thing. And when it's the customers idea, it's always the best idea, right. Well, the I mean the customer was pairing with us the entire time, right. So, you know, most of our team composition was mix a match between the customer and our folks. As we went and and we were bringing the expertise in xp and we were bringing the comfort in disciplined modernization, right. But they had folks who were good at programming, who could drop into the teams and go who knew a lot about their own systems right, who understood, who've been working in this section of the business for a long time and new you know, knew why it took six to twelve months to implement something new on the main framer, knew when you were going to do. You know, when somebody said, well, what if we put a coruption into coruption layer here and we do you know Xyz over here, one of their architects could say, well, that sounds pretty interesting, but here's this thing that we need to be aware of and maybe we wanted to try this other thing instead to sort of like work that out right. So there was a high amount of collaboration. I think one of the things that we were you know, one of the things that we were really good about was making sure that everybody was kind of talking about the work that was there in the decisions that had to be made, so that so that the people were really aware. I mean, I think it grew too. If I remember correctly, kind of six teams working in parallel. So I mean that's that was probably about like fifty, fifty ish, fifty sixty people kind of working together in this thing, which is, you know, that's not a small amount of overhead to kind of communicate across the...

...group. But I think that the winds that were pretty cool were that, you know what, that that first I mentioned out for service. It took four weeks to build, four months to get into production. But by the time we were a year into working on this thing and adding new services, spending up a new service at the twelve month mark and getting it into production took less than four days. Right. So it was really easy to like wet as a crew. We were improving all the time what we were trying to do. Well, that one took four months and everybody agreed that that was not not optimal. We don't want to do that again. So how do we start to pay down the time it takes to they get something into prop right, right, but twelve months to four months, to four days. That that prescription seems to heal. That's the days. It's significant and really interesting thing that happened on the business side for that was that the you know, the business stakeholder sort of said, this is blowing my mind. This kind of changes the way that I think about releasing software because now when I want to do something, you know, when I wanted to do something before, I had to make sure that it was really something I wanted to do because it was going to take six to twelve months and compete with other things for, you know, where it was at in priority. Now I'm empowered to do things, you know, almost more an experimental level, because I can run the thing, you know, I know it's going to get implemented quickly and get out there relatively quickly and I have to worry about it. And so that's a huge win. And the other thing that dawned on them was that, hey, you know, when when we were working in a in a format where took six to twelve months to get a feature out, all the roles supported the compliance needs of the customer had tons of time to do their job. Oh, we need to work on copy, oh we need to get that approved by legal though. This has to go to this group over here and make sure that it's ready to go. You know, in a six to twelve months time frame, you could say great, like, you know, we agreed to do it. It's been prioritized in the backlog. The team thinks are going to pick it up seven months from...

...now. So you know, we can back out of that and say let's go get it to you know, let's get it to copy four months from now and get it to legal five months from now. We'll still have plenty of time before the development. He puts it up, but the stakeholder had to turn around and bring, you know, those supporting roles into a room and say, hey, crazy thing that we're going to have to work through here. It doesn't take us very long to get new ideas in a production anymore. Right, we can do it sort of sub week, and I know that breaks your world because, like if I'm just giving you, you know, new copy, new copy, new copy, all the time. You know, your process is your processes aren't set up for that and that's going to hurt. But we have to acknowledge that this way of like getting things in a production is really the way that we want to go for the business. And so now that we can kind of see that this is the way it's working, question I have is how do we start to work as a group to not stress you all out, you know, because the timetables have changed. But what, you know, what do we want to change about our processes to kind of make the make this flow of software, you know, be the thing, which is for me that was kind of a very eyeopening moment where the software had pulled, you know, out of what started as a modernization because we were struggling to get software into production, struggling to hire the right folks for it right. Had cost some things to come all the way to the business being like, we want to make process changes to how we've thought about the business over the years because, you know, we've gone from slow to fast in the way that we really software right now. That's pretty advanced. Right when you're when you're putting a lot of pressure on like, you know, the GNA of the business to move as fast as it is. Yeah, it's never really been the case. It's super cool to see that happen and I think the trust that has to happen to get there is pretty immense. Right, like the the initial stakeholder in it...

...who said I think it's kind of draw line, and it's and like the courage that she had to say I don't know how to do it, but I trust the people I work with that we can go do this together. Like we trust each other enough to be able to go do it together. Let's go work through that and do it together. I know it's going to be scary. I know we're working on the system that makes us a lot of money. Like let's go figure out, but let's go figure these things out because life's going to be better on the other side. To Watch that sort of paid a kind of happen. You know, we, I think we are kind of eighteen months in at the point that that stakeholder pulled, pulled the GENEA folks together and said we won't change how we're working, check this thing out. It's really amazing, you know. That's the it was super cool to sort of see people figure out how to do that in the middle of all the technology that it was an aging right. Sure now that's that's that's really cool and I think a great story about, you know, project succeeding. Sometimes, we heard you, we hear a lot about a lot about projects that don't. Lessons Learn Post more rooms. You know, hearing those here in the good stories can be tough. Because you know some of it is confidential or you have to abstract it away so much that you can't really see the path that went through. So always good to hear things like that. Well, I'm not necessarily calling out sort of individual customer names or who the customer is. I think if I didn't point out there's a felony Shaun Anderson, and he's got his site is swift bird, and when we were working on this customer he hadn't quite formalized a lot of the the methodology around notional architecture and how to figure out like how do we extract something and then continue to evolve it. He's got a lot of publication up on swift right about how to do that because over the years he's he's refined how he talks about it and I think it's a pretty interesting read. If you and yeah, you got a few hours in some curiosity for it, that's that's it's good recommendation. Shawn regularly toxic the domain driven to design conference that is held in Colorado over year as well. Gotcha? Well, we'll make...

...sure to dig that up and send that out to the listeners as well. So I always like to there's two things, so we'll go quick on this. You know, your people side of the business is kind of interesting. Maybe. What's a couple of takeaways that you found as you are, you know, building a pipeline of great people with, you know, skill sets that are in demand. You know, what's something you guys have learned through that process? You know, obviously not secret sauce, but I don't think the building of teams and people really is secret sauce. It's usually intention. Well, exactly exactly and I would say exactly the same thing right. We there. I'm not worried about giving out secret sauce. It's the it's the intention in the discipline to kind of work on the hard things that help you figure out how to get there right. And I think a lot of times with our customers the hard things for them don't just include the hiring right and there's a lot of business problems that they're trying to figure out along the way. And and hiring and learning how to be a good hiring manager, learning how to identify good talent take weeks and awful lot of work. Right even in our talent labs we have processes that we like in terms of sourcing we have processes that we like in terms of first round interviewing and with a customer, helping them figure out how to get that stuff going. But we we don't swap out, you know, while we'll suggest, hey, here's the here's the process that we would suggest. Let's help get that in place with you. Let's let's, you know, for interviewing, right like. Here's what we could use as a first round gating interview. Here's what you can use as second round interviews, right like. We find these things to be very productive. For these reasons, we can help build some stuff together with you in that regard. The the core piece of that is still, Hey, you know, let's build this capacity inside of your team, because the person is not you know it, at least when we're working with customers and persons not interviewing, to work with arty in the person's interviewing, to work with that customer person. They're interviewing you. They want to know how your...

...team works, they want to see how you get on, they want to know that the stuff that they're going to be doing is is meaningful and challenging and cool and all the ways that they're looking for. And so it's a lot of like well, let's go help you build the muscle for doing those sorts of things so that you can you know whether you're using us to help source in the pipeline or you already have a logo for yourself. That kind of attracts playing of folks and you just need to start filtering, you know, all those folks. That the core piece is making sure that your team like, knows what they're looking for, knows how to advertise the himself, knows how to differentiate, you know, between candidates and we focus a lot on craft, and so we definitely want to know, like hey, like we let's interview for what those skills are and let's start to see those, you know, let's let's see the skills. Let's sit down a pair together so that we can program and reason about things together as we go. That's going to give both of us a really clear picture of you know, do I see the that they apt to to the interest, the ability to deliver that that I seek, whether I'm the interviewer or the candidate for that matter? Right now? That makes sense. I think it's a there's a lot of ways to try to, you know, build teams and get qualified candidates through a process and there's not like one simple method for it other than digging in right, and that's right. And that's the hardest part, because we're all strapped for time. We have deadlines of yesterday when you know, we're hiring for something that we need to get done in four weeks, logically, because that's what the Candida Pool looks like. So, yeah, it's you know, we run into that as well. When you're strapped for time, it's hard. Thinking about how you want to interview means that you have to go Meta, right. You have to start to think about like, what are the things I care about, kind of formalize how I talk about them. If you're inside of a culture that doesn't, hasn't, prioritize those things previously, it's like it's super hard to step aside and say, okay, well, what do I think about, you know, in terms of software...

...development? What do I think matters? How do I want to focus on those things? How would I recognize those into a candidate or how would I prompt to sort of see those things in a candidate? Right? And so, if your crushed for time, Metas the last thing that you're starting to get at right there, right right, and and whether that's, you know, from a hiring manager position or or an interviewer position right, like you know, most organizations, you're hiring manager is also relying on several other people in the interview process. That's help think a decision about, you know, the candidates that are there. And so how you can kind of get to those places is either dependent on having the space and time to do so or having a bunch of folks who have had the space and time to do so at some point in time, right, and they can get together and talk about things, and so I think, you know, helping one of the things that we focus on is sort of if you're kite on those things and you haven't had space to do it, how can our team pop this with as part of the process? Gosha. So last thing, what do you think's next in technology? Like what are you most excited about maybe seeing come to pass or new ideas, new things? You know, what's your prediction? I guess that's probably what I'm getting that. Yeah, I'm going to talk a little bit about the software that we're building internally, because I think that's that's some of what we're seeing is very contemporary and think it's going to sort of continue to be part of the process over the next ten years or so. I think we've had a lot of opportunity be over the last I know, maybe decade and a half, right, to watch a lot of change happen in the nature of deployed software right like we've we've gone from you know, hey, I'm running a lamp stack and I'm going to put that on my own server to like, you know, full bork cloud computing accepted by, you know, anybody that's doing software right, like modern cloud native computing. It is just the norm pretty much at this point. I think there's been a lot of tool development that's enabled a lot of that and I...

...think the tool development has been very engineering centric. You know, as we work with different teams, we're seeing a lot more development continue to happen in the product side of the House. How do we think about the work we're doing? How do we release stuff that's meaningful and so at least in the application space, right in the application build space, the software development life cycle and then the people that are participated and how do we make it work? There's a lot of folks that are starting to ask like. How does it all fit together? How do we know that we're how do we how do I, if I'm looking at this giant machine in front of me, you know, where do I start to tune the machine? How do I how do I approach it and work effectively with, you know, my colleagues and get folks to things they want? I think the pandemic is fast forwarded that in a lot of ways because the the ability to go remote has changed paradigms of how we communicate. The fact that, you know, folks are working distributed to change of paradigms of how we communicate and so and end. I think, you know, the folks that are in the generation it's just hitting the workforce like, they're looking for more, more and more meaningful stuff right like they're they want to know that the things that they're doing has an impact, because that's part of their career identity. And so I think the communication aspect between, you know, folks have a participants and software development life cycle is going to continue to come forward and and be important and how we do it. I think we're going to see a lot of products that start to come out to dress that right and start to say well, what does that look like? How do we start to get from from idea out to production, right? How do we continue to evolve and make things better here? And I think, you know, the Dora metrics are a good example of folks starting to talk more formally about, you know, where do what behaviors lead to kind of a smoother experience there, and I think Dora kind of lives at the at the at the end of, you know, if you talk about like a idea to production, you know, cycle, Dora lives...

...very close to that end of like the to production part of the cycle. Right. It's like to production in production. I just think that we're going to have a lot of a lot of activity headed more towards that idea space, right, a lot of applications. There are a lot of thinking and community development around that as well. Interesting I could see that. You know that. That being you know, the idea side of everything is, you know, a lot. There's lots of good ideas. How you execute or how you get that through a workflow to something that's meaningful or tangible is the hardest part. So that's right. That's an interesting insight. You know, how does you know? How does the world you know, start to build around that. We're good at taking something and smashing it, you know, onto a bunch of servers. But how do we how do we take ideas and smash them into a framework that create offerings for customers or people or products or tools? So, yeah, that's the place that we're really like there's lots of lots of noise mixed in with the signal there, right, and anything we can do to start to tease out the signal more clearly and understand, like what is it like at just how do we work that process is going to be really helpful because people, you know, technology problems. We've seen it over the last, you know, fifteen years. Like you put up technology problems some in front of some team and eventually someone's going to figure it out right, like Oh, we've exceeded our ability to use the tools that are available. Let's go right at a thing that solves that problem right and then, you know, thankfully, open source has been just a huge boon in that in terms of, like I write this thing that solved the problem. We then, you know, we want to make sure to give back. Until we've open sourced to that technology, we've needed a part of of, you know, being available to everyone else and folks start to soak it up right, like I think that form of how we've been working in engineering, you know, in side of the community. I think is going to continue to move towards that idea part of the spectrum and start to say,...

...like well, what is open source for software or like how do you know? How do we contribute those ideas back? How do people take advantage of it and start to use it? Like but it's the other part, the idea part of the spectrum, is rape for similar paradigms. Yeah, would totally agree. I mean, you know the ideation concepts, frameworks that are out there today. It's all it's all handled very, you know, the very proprietary type model. Right, you go pay thousands of dollars to send in this conference to learn about, you know, framework that you can apply towards an idea. It hasn't you know, that's that's insightful. It hasn't quite taken on that open source notion of the world that we have in software or maybe you know just it engineering in general. How does that continue to diserupt in different ways? You know, we're starting to see, you know, plans for actual, like tangible products be open sourced, right. You know, that's started maybe ten years ago in a way that was small, but you know, will that continue to proliferate? You know, cross ideation and how we build things, and obviously it's taken over from a software perspective. So it's going to be pretty exciting. There's like one of their aspect that I've seen that I think like fits in a really nicely the the in the last maybe two or three years I've had a lot of MBA programs say hey, we'd like to you know, we've got a class with like they all want to be product managers when they're done, right, they're all thinking about being in software when they graduate. They want to come talk and and learn, you know, different perspectives of what it means to be a product manager. Can we bring our you know, can you have someone from your crew that can come talk to all these students? Right? So, if if you have tons of kids going to NBA programs, I see kids right, like you can go to I've got friends that are my age to going NBA program so kids is a missnower. But if you have all these people that are going to NBA programs. They want to come out and they want to work in software and and you know, they're trying to apply the...

...skills that they learned in these programs to how the how then, do I become a product manager? How do I release software successfully? That crew is going to be continue to seek more and more truly and to make themselves effective as they go. So I think there's there's sort of a tide away of folks in in that kind of idea, a backlog section of the world that is going to get a lot of attention coming up. That's really cool. It's good. It's good when education read reaches out into industry. You know, education you be a little lum theoretical when, yeah, when you actually, you know, get out on the road and have to do some stuff, you know you're not learning a lot of that in textbooks, unless you know your professors have spent years in industry teaching other secrets. So that's one of the things that kind of continues to surprise me is that, well, education programs have gotten better. I think by and large most folks would still say, Hey, if I went to school for Software Development, the things I learned in school or not the things I use in the daily day of being a software engineer. Right. And I'll be curious, you know, for the MBA programs, who are usually a little more responsive to like how business is changing and adjusting their curriculum. I'll be interested to kind of watch and see if the the product managers that are out there, they're kind of coming out of the MBA program say, Oh, indeed, you know, I'm learning stuff in the programs that are very applicable, you know, at when I'm on the job, you know, when I own a backlog, when I'm thinking about how to get this thing the market, what I'm thinking about, you know, what is it? What does it mean to make this product successful? Or will they sort of say the same things? That kind of you know, honestly, for like twenty five years now, I feel like folks have been saying, Oh yeah, I want to see this program and, you know, it was cool being in the program at all, but like it's not the thing that taught me how to program. That's not what taught me to be a software engineer, right. Yeah, well, maybe we'll see that change. I mean, I could do it like I do two hours on revamping education. Yeah, yeah, but you know who's got time for that? Yeah, well, I myself. I could...

...come. I did not go to school for Computer Science, right, so I come from a background that is is not computer science. Actually think it's a little bit of a strength for myself because I have a handful of different frames to apply to problem solving, right, and and I can use those very com people. I can switch between them, and so, you know, I think coming to software later and, you know, learning it outside of a school context was actually a benefit for me a lot of ways, because it freed me to actually just fall in love with the programming and do that stuff, and some folks do that well before school context as well. Right, absolutely, it's cool. Well, Mike, Thank you so much for the time. We definitely filled up the hour, so I appreciate you know, you taken some time with us and sharing some stories and helping our audience get new perspectives on age old challenges. Yeah, thank you very much for having me on. It was enjoyable to visit to day and share stories. Awesome. Thanks. Right. Okay, application modernization is sponsored by Red Hat, the world's leading provider of enterprise open source solutions, including high performing Linux cloud container and Coupernetti's technologies. Thanks for listening to application modernization, a podcast for high growth software companies. Don't forget to subscribe to the show on your favorite podcast player so you never miss an episode, and, if you use apple podcasts, do us a favor and leave a click writing by tapping the stars. Join US on the next episode to learn more about modernizing your infrastructure and applications for growth. Until next time,.

In-Stream Audio Search

NEW

Search across all episodes within this podcast

Episodes (29)