Cloud-native at Home Depot, with Tony McCulley (Ep. 45)

Episode 31 · 34:19 · SRT · archive.org · all Tanzu Talk

Well, here we are at the, as I learned, the Gartner Apps Conference, hashtag Gartner Apps, APPS, or the Gartner, what was it, Application Solution Summit Strategy? North American. Syllogism. Right. Yes. Anyways, so we just sat through a talk that you gave, and by sat through, I don't mean that it was a chore, but we just saw the talk that you gave, Richard and I, but why don't you introduce yourself? Yep. My name's Tony McCulley, I'm manager at Home Depot, and my team oversees all the Pivotal Cloud Foundry stuff. So the talk you gave was what I would call, like, I don't know, an experience report? Here's like a case of us trying to do software in a new way and improve stuff, and I mean, obviously for us, it's sort of like, and we use Pivotal Cloud Foundry, which is nice, but that was just a very small part of it. But to that end, can you give us, like, first of all, give us a brief background of you, like what, I mean, you're the certified Scrum Master. Wow. Is that the beginning and end of everything? No, actually. Who are you? Yeah, I went to school late, so out of high school, I actually got involved in IT doing some video game stuff. Oh, as so many people do. Yep. I had to hook up my Quake servers and all of that good jazz. LAN party. Yeah, LAN parties. So that turned into a gig at GameStop, where I started doing that at malls, and then that's turned into, you know, hardcore IT stuff, exchange servers, you know, all the A-plus certifications and Cisco and good jazz. I can see that's a natural progression, LAN party, exchange servers. Just think of that. It's a different type of gaming. Crawling through ceilings, wiring, network cables. We'll have agility on both. That's great. Yeah, so, you know, what I quickly saw was that wasn't going anywhere, right? Like, we're doing remote support. I was a creative person, so I got involved in a startup that was sort of game-related and IT-related, sold my way out of that, paid off all my debt, and it's like, all right, I'm going to start over, and I went into software to learn to make video games. Yeah. So I did computer science, and then I've never made a video game, and then I got into software,

worked for GE, worked for Comcast, Booz Allen, and now I'm at Home Depot. So I have a background in user experience, user research, so I've done a lot of that in my career as well, and then while at GE, extensive, you know, agile coaching and training and stuff like that, so. Right. And then, so, when did you join Home Depot? Was it like two or three years ago? 2014. Okay. Let's see if I can do math. Yeah. Three years. I've been there three years. And so what, like, so when you got there, what were you, not so much, like, what were you hired on to do, but, like, the sphere you were working in, like, what was going on? What was, like, the baseline when you got there, and then what was the mission? Yeah, so the baseline was everyone was trying to be agile, and it was this very disjointed, fragmented sort of approach to it. The particular app team that I was joining was at our pricing space, and they sort of hired me to, you know, to come on and be like, hey, you know, you're going to, you are a lead developer, right, but really what we want you to do is put PowerPoints together and train us on how to do Scrum and Kanban and lean and, you know, teach us about UX, right? But it's a small group. And then once it got time to be like, you know, I can't do this on my own, like, we need funding, let's bring in some people, you know, it got a little frustrated that it wasn't taken as seriously sort of at a higher level. And I sort of had, I don't know if anyone at Home Depot knows, sort of like one foot out the door, about eight months into that. Yeah, I like how every time you talk publicly, basically you're like, HR people, please do not listen. Pause podcast here, fast forward. I think in every talk I've seen you give, that line comes up. Yeah, it's, you know, it's true. Like, this is a new thing for Home Depot, and, you know, it's in jest, but there's a lot of truth said in jest, right? Sure. But about that time is when Paul came in, and... This is Paul Gaffney. Paul Gaffney, right. He came in just a couple months later, and, you know, he's like, hey, I'm going to bring a UX department, and I'm all about XP and Agile. And I was like, holy smokes, like, okay, I should probably stick around for a little bit.

Yeah. Yeah, you know, what's interesting about that part of this story is, to rephrase it in my own way, like, a lot of doing Agile started as a bottoms-up initiative at Home Depot, which is almost like, it's almost a funny case of, like, a hundred different successes are a lot more of a trouble than, like, one big success. Oh. Like, in this instance. And so, the way you were talking about it in the talk is, we had a bunch of, what'd you call them, scrum police, and a bunch of different interpretations of it until, and again, in my phrasing, until we had a tops-down application of it, we couldn't really scale it, and we couldn't have the one plus one equals five. Yeah. So, we weren't getting the results you expected. No, absolutely. And, you know, I joke that we, you know, we had 40 scrum teams, and we were doing it 25 different ways. Right. You know, I think, but I think what Paul brought wasn't, it wasn't, he was very conscious about not being prescriptive. Yeah. It was more about, sort of, like, hey, you know, you're struggling. I think I can help lead you, sort of, to a way of, kind of, discovering a right way to do this on your own, so. Yeah. Yeah. And it's a hard, I think that's one of the hardest things as a leader, is walking that fine line between, you know, being prescriptive and then, sort of, leading you, right? Yeah. Those are tough decisions. Yeah. I zeroed in on that, or keyed in on it, because that's a common pattern I see over and over again at the large companies we work with, is that to scale Agile, it has to be tops down, basically. And it's very hard to have it organically percolate upward. Right. And have it be, as Richard was rephrasing, have it reach the ends that you want. Right. At scale, which seems to happen a lot. I mean, before you got there, I mean, you mentioned you kind of came in and was this focus, and you made a statement early on in your presentation that Home Depot mission would be a great software company. Right. Which might seem mind-blowing to somebody who goes, well, I thought your mission was to sell me lumber. Yeah. And do it really well. Which, of course, it is to some extent. Right. But did that precede? I mean, all of this Agile probably popped up for other reasons, but was there a transformation

saying, we've got to get better at software? Yeah. And then it was just kind of madness for a while, and then finally top down. I was like, all right, we're going to be good at software, but let's be good at software on purpose. Yeah, I think before Paul showed up, you know, like I said, we were there, and all the motivation was sort of from a developer morale, and, you know, like, hey, like, this Agile thing is really great for developers. We would love to do it. And then we would try to find ways to force it in. Like, our business partners were like, I don't care that you write user stories. I have this really big document. And so we would just take it on ourselves to be like, all right, well, I'm going to decompose your document into user stories and report to you in whatever format you need. Right. So we were kind of, you know, trying to fit, you know, square pegs in the round holes. What Paul brought was sort of exactly that. It was like this, it's more of a guidance around, but it was sort of value driven. It wasn't like, hey, we're going to do it this way. It was like, I want you to be, you know, I want you to have hypothesis and think about the value. I don't care about tracking progress. And so we kind of started honing in on those types of things versus, you know, Gantt charts and stuff. Yeah, there's a kind of a funny instance of that in your talk where someone asked, you're going over how you, so the part of the organization you work in supports developers to grossly oversimplify it by providing the services and the platforms and everything that they need. And you're talking about how you support them basically in a Slack channel. And it's very, it looks very informal essentially. And someone in the audience asked, well, how about tickets and tracking things? And so you should play through the answer that you gave because it was, I think it was a good instance of, is, is we only do activities that are valuable, right? Like we don't, we don't dress other stuff around it. Yeah. So, you know, so we basically, we don't have any tickets and we used to have a little bit of email and we try hard to get rid of that. And so really for us, it's about waiting, right? It's about, you know, again, like if you want help with a product and you call Home Depot, right? Or Sam's, whoever the company is, right?

You have an issue with something, like you want a real person to answer. You want to have some sort of engagement, right? You want to have them understand what's going on. And I just don't think you can convey those things necessarily through tickets. Yeah. So no tickets for us, no waiting, no email. We just try to have a conversation. Yeah. And for these developer support scenarios. So again, when a developer needs help and this isn't, again, I think the other surprise is this isn't like 10 rogue devs. This is like 1,700. I mean, this is a lot of people. You're not messing around here with just a tiny pool of people who randomly crash apps. Yeah. And to build up my cheesy characterization of what your group does, tell us kind of like the scale of number of apps and users and stuff that you guys are supporting with the platform. Yeah. So it's about, you know, we try to equate an app team to like an org, which is a good general measure for us with the way we're structured. So it's about anywhere from 120, maybe 140 teams, I'm guessing. It's probably a little less than that. But, and then from there we have, so that's about how many applications. So I would say there's, there's probably, let me rephrase, about 80 or 90 teams, there's probably 120 or 130 big apps. Right. From there it's like, you know, 800, 900 services, I think 1,700 instances, seven foundations. Yeah. And there's 1,800 Cloud Foundry users. Right, right. And then, so, so what are these kinds of apps? Like one you've mentioned a little bit was like pricing, which obviously in retail is a big deal. Yeah. But give us a sense of what these, the other apps are in there. So I've sort of lost track of all the apps. But I know some of the big ones that we tend to sort of use as examples, our payment services, our payment gateway. We're sort of chipping away at portions of that and breaking out certain services. So of that overall workflow, we're trying to slowly move more and more of that to PCF. And then what is a payment service? Yeah. So like, you know, credit card transactions, what's happening, approvals, you know.

Okay. Yeah. Just like the POS system. Exactly. Yeah. Okay, okay. Yeah. So the cash registers and check it, check out. Gift cards, credit cards, debit cards. So there's some aspects of that overall workflow that is now all going through PCF. And we have separate PCI foundations for that type of work. One of the big ones is a lot of our supply chain and logistics. So order management, you know, sending out stuff for vendors and filling those orders and where they get delivered. There's a lot of work in that area. And then, you know, tool rental and the stores, they're one of our early adopters. And they're about to go out to, I think, all 2,000 of our stores this year. Okay. All on PCF. Yeah. In one of your talks, you told a good story about pro-rental where you're kind of like, well, you know, you would think if the tool was late, you would charge those fees. Yeah, exactly. Yeah. There used to be a joke that if you ever wanted a new tool, you'd just go and rent it and you'd keep it forever. Yeah, yeah. And then, I mean, I was saying, you know, I need to verify a bunch of stories I tell. I have another story I tell about, like, your paint desk where you're improving the way that paint is done there. Yeah. I know, I don't know the whole story, but you know what's interesting is I don't think we ever had a thing where we saved, like, the formula for a color. Like, as crazy as that sounds, right? Yeah. Like, you go and you buy paint, and then six months later you want to paint another room the same color. It's like, you can't, that color isn't saved anywhere. It's like you have to recreate it from scratch with all the color matching and stuff. So now I think, you know, there's a lot of work being interesting and very valuable. Yeah, and, you know, the reason I, well, not the, one of the, my personal reasons for asking about apps is I think it's fascinating. You look at a company like Home Depot, and you list all the applications, you realize, like, how many different applications there are and the variety that they are, right? Like, it's, it's one thing to think, like, well, we have to handle payments. I mean, sure. Right. And then, and then it's even somewhat simpler to be like, well, we, we buy, we buy the flashlights

and the flashlights have to ship from here, and then we have to determine where they go. Yeah. And like, sure. But then you start thinking, like, well, there's also software for the tool rental, there's software for the paint mixer. Yep. There's probably even some software at the key making place, like, and like all these places have like, and it can't really be off the shelf software, or even probably just like ERP stuff that you customize a little bit. Like, you end up wanting it to be like full on custom software. And then at that point, at least my mind kind of in a delightful way kind of boggles at the amount of applications that are out there. And you realize, multiplied across every company out there in the world, there's just like endless software, right? Yeah, absolutely. And like I said, I, you know, with the self-service nature, it's sort of taken on a mind of its own. Like, we're, we're not, I'm personally, I'm not fully aware anymore of all the stuff that's on there. Right, right. I mean, it's, you know, we're, we're constantly learning about new things that people are doing. That's good. Because I mean, I mean, this idea that you're not deploying just one monolithic, like, store app twice a year, it just does everything that you need to do with a store, right? Which might be the old way of doing it, like, ERP style, just makes keys and does check out. As we know, this is how all pet shops in the 2000s ran, right? That's true. They had the one app that you just got out of the box. So, I mean, I think that when you showed the number, you know, doing 17,000 deploys, whatever, you know, your numbers, like, I liked, and I was facing you, so I didn't get to look at the crowd. But you could tell from some of the questions that some people were like, wait, wait a second. Oh, I saw, I saw a bunch of people like that, yeah, a lot of people kind of stood up and was like, what? So I think you were, you know, as you talk about your more social form of support and the number of deployments you're doing, and you're getting questions on how the heck do you test and what about change records? So, I mean, when you, what's the most common thing you hear from other people who go, that sounds crazy, but I'm also used to hearing weird startups tell me this, how is the Home Depot doing this? Yeah. How do you, what do you hear the most? A big one that comes up is compliance and change records and how do you get, you know, security and networking and everyone else on board to make all of that possible? And to be honest, like, I don't think there's an easy answer to that.

And I think that's the cultural issue. So, you know, my job rec says one thing, but I probably spend, you know, 70, 80% of my time just doing that, which is, you know, rallying people across our company, having the hard discussion, right? And then, you know, being empathetic. I mean, they, they, they want to do the right thing and then there's, you know, stakeholder reasons for that and compliance reasons for that and security reasons for that. It's valuable stuff. But how do you do it in such a way that, you know, is easy and frictionless? And I think that's the, that's the hard thing. I think your chip away metaphor is probably the right one because you explained how, hey, like you don't cut these teams out. But instead it's like, hey, here's an API to actually create a ticket or a change record. Like we're actually trying to give the, put interfaces on these relationships so that you still do good stuff. But as you say, make it easy to do the right thing. And they love it. The quality of stuff that's being audited and looked at is way better and more honest and more accurate than what it was before. Yeah. That's like, I think it was, it's like, uh, Mark at, uh, Liberty. I think it's Liberty Mutual instead of HCSC. I get him. I get these two talks mixed up, but he had a good point. He was like, when it comes to audit, like you can put whatever you want in a word doc. Yeah. Right. Like, like, so don't think that your current way of doing compliance and auditing is actually better. Right. Like, like it's, it's, it goes from checking a box to like providing something substantive as context in a history. Yeah. And, and, and, and you, you went over two tactics that I think are interesting. One of them was the way I remembered it, uh, or filed it in my mind is, so you work with whether it's auditor security people, we'll just call the, all these, these people, the auditors. And one of the things you said, and it was kind of a response to a question you were alluding to Richard is, um, so how do you get their permission to do all of this? And then your answer was like, well, we kind of sort of didn't do that. And then, but then I think the tactic that was interesting that, and I, and I wanted to go over it because I think it's one that can be reused by other people is once you have it in place, it's almost like it's some sort of psychological trick, but you're, you motivate

the auditors to figure out how to say yes, instead of going to their default no. Right. Right. And, and it's a little risky, like it's a little bit of a gambit that you're playing there. There is, absolutely. But that seems like kind of what the only thing to do. Well, I, I mean, I think that's what good leaders do, right? I think that's really the, um, you know, and it's sort of some of that we've learned, you know, from pivotal, like the mantra of the ask for forgiveness, not necessarily permission. Right. And, um, you know, it's the same thing. Like, you know, it's, there's a lot of mythos and, you know, legend around what happens if you don't follow certain processes or if a developer pushes something to production directly and, and, you know, nothing burns down and no one goes to jail and, you know, it just doesn't happen. Right. The lumber still ships. Yeah. I mean, as you're dealing with PCI, again, I think everyone's, it can't be irresponsible, right? Like we're not going to accidentally throw a data set online and for fun and like, I will ask for forgiveness later. So I'm sure there's this sort of line where you go, this feels like I could do this, but maybe I check first versus like, this is, we're in the spirit of compliance. We're in the spirit of support. Let's get this out and then let's modernize whatever our practices were. I mean, do you have that fine line or is it just a judgment call? You know, a lot of it's a judgment call and, you know, a lot of it's education on my part. You know, when we get into the compliance, I didn't know anything about compliance until three months ago or four months ago. Right. And it's like, you know, the best. Yeah. You know, I just think, you know, we, but we've talked to other companies that have sort of done it the other way. Right. It's like, Hey, we have a platform, we're going to get compliance and security. Right. And it, you know, and they stand it up and they have all those things in place. And then it just takes so long to get the adoption. And I think another thing that's lucky for us is that when you have 2000 stores, we have a culture of trying a thing. Right. And so it's very easy for us to pick a store or a team that we trust. Right. And just play with something. And so we have a lot of trust in that. And, and I've been blessed with good leaders who, who really trust my judgment and have backed me and kind of stuck their necks out. And yeah, that's interesting. You already have a structure and culture of canary testing, basically.

A little bit. Yeah. Yeah. And we learned that the hard way. There's a lot of operational scarring behind that. Yeah. Yeah. Yeah. So, yeah, I mean, there, there's, there's another topic, this whole, like a phrase you kept using is like trust, but verify, like, I think maybe my favorite Reagan doctrine. I'm sure there's a handful of them, uh, anyways, but, uh, like that's kind of related. And I wanted you to tell a story of, it's also related to audit. And I'm using that as the all encompassing thing of how you basically like automated security audits, right. And, and it involved, it even involves like service now, but like that, it seems like a good example of, it's not, it's, it's not so much like try something and ask for forgiveness later. It's more like try something and automate audit auditing. Yeah, absolutely. Like I said, there's value in what they do. And I think the trick is to do that frictionless, right. Right. And the easiest way possible. And I think people gravitate towards the path of least resistance. And that's why there is shadow IT and there's, you know, there's, uh, you know, rogue code repository somewhere on someone's system or in the cloud. I always used to misspell that as Roge. Roge. Roge. Roge. There you go. I don't know how to pronounce anything, but I mean, tell us the story of how the, the sort of security audits were automated or some of them. Yeah, we're working on that now. And, and that effort is being done by a bunch of volunteers in our company. Um, and you know, what they're, what they're essentially doing is that we've worked with our ops team who owns, um, service now, um, which is supposed to be our, our repository of all of our changes for audit. Um, but you know, if there was a way, but that's locked away by another team, right? So if I want to make changes there, I have to kind of go through someone else or only certain people have access and there's licensing and that's not frictionless, right? So, um, and so the quality of stuff that goes in there tends to be a big copy paste or, you know, it's a checkbox. So what we've done is, um, worked with that team to create APIs that allows teams to hook into that from their own pipelines. So, you know, our, our enterprise monitoring folks, um, we have someone there, um, who's

super talented, uh, Marcos Mendez. And he's done a lot of work working with operations to kind of create APIs for that so that teams can, you know, basically commit their changes and create change records and, and, you know, parse GitHub commits and stuff to put, you know, really good information in there. Um, and so then a part of that also is working with security who's interested in doing, you know, static, you know, security scans of things, right? And so we work with them to create, you know, APIs for doing that and, um, and then getting the return results and then attaching those as documents and so forth. So in doing these as APIs, I mean, did these become mandatory or do you feel like because it's easy, a dev's happy to do them now? I mean, just adding an API on service now, they might go, it's cool. I'm still not doing it. Or does it become a like, I know I'd like to use this. It actually makes my app better. It's way better than the alternative. Like I said, like most teams have like, there used to be a culture of like change captains, right? Like only coordinators can create things in service now. And it's like, I don't like, why would you, you know, I know why we did it, right? Right. Financial reasons or, you know, trust reasons or whatever that is. But, um, you know, now that it's, you know, everyone would do it the other way. Everyone who's done it this way can't imagine doing it another way. It's simple. Yeah. That's, that's, that's a, uh, a pattern I hear over and over again. Well, first of all, culture of change captains. That's a good phrase. It sounds like, it sounds, sounds like a book, but, uh, but the pattern I hear over and over again is the, uh, I think the first time I heard it was someone said that they wrote a chef script to open a service now ticket, right? That, that, you know, there's, there's a bit, if you do sort of like an end to end, I hesitate to call it a value stream map, but a pipeline. And there's certain moments where it's sort of like, got to have a ticket. And like, so, so people have discovered over the past few years that like, well, with an API, uh, I could just automate that. And, and that's a slightly disingenuous. It's kind of like open ticket and forget to use the fire and forget thing. But I think what I liked about what you guys are doing is it's more like, not only do we

open a ticket for this other party, but we actually make their life better by like arranging all the stuff and attaching it. And like, because it's driven by automation, it's a lot less error prone than a person doing it. And in theory, the auditor on the other end, they can open this ticket and like, everything's there. Everything's there with way more detail than they can probably even get into. Right. And it's just a lot more efficient than like we have the, uh, the, the twice month, like cab meeting scheduled where we've got to put together slides and like it, people talking to each other is, I guess Bezos would say is failure. With the change notes of fixed bug and yeah. Yeah, yeah, exactly. No. So, and, and so that gets to the thing I was alluding to earlier is it seems like, um, I don't, I mean, you talked about this. Is the main point, but I think one of the main things running to the way you guys are doing stuff at over there at home Depot is this trust, but verify thing where there is this, it almost starts. And this is where the, the, the, the rainbows and sandals culture stuff comes in, but it starts with this idea of like, we're paying these people a lot of money. We should trust them to do a good job. Yeah. But then we have audits in place to make sure they're like, Hey, we'll just make sure you go off the rails. It's, it's, it's more, it's more about like, like safety nets rather than like bureaucratic mazes that people have to run through. Yeah. It's a good point. I mean, it was something I wanted to include in the talk, but I didn't, but one of the things we had early conversations about was a sort of, how do you make guardrails? There are a couple of things you want to be absolute about, right? Yeah. And set some constraints and, but how loose do you make those, right? How do you make teams have just enough power and influence while still being bounded somewhat by these constraints and guardrails? And so one of those guardrails, for example, is GitHub. Like your code has to be in GitHub. Right. But if we made GitHub, you know, require an approval process and make it super difficult to use. And if it wasn't anything like the experience of GitHub out on the cloud, they're not going to use it. So you have, you sort of have to live up to that, that responsibility. Right. You've, I mean, I think when I first met you and you, one of the first things you were talking about was developer experience and opening those floodgates.

And I don't know. I mean, I'm sure that makes people want to be a little more compliant when they don't feel like you're just nagging them. Like if you're giving them the tools to do things and they can assemble those things and they feel like you're trusting them. Yeah. That's such a different story. And that's why you've seen such crazy adoption. I'm sure is that you said at the beginning, it was just, here you go, like go do good stuff here and hopefully it helps the company and you're responsible. And I think it's interesting, like when people start landing on a couple of those guardrails and we don't mandate Pivotal Tracker, but it's quickly been adopted. And, you know, I would argue most of our teams are on Pivotal Tracker now, but when you do have those guardrails, like you get to pull out, that's what makes it possible to have all that really rich metadata and monitoring and alerting and logs, right? Like you have so much data about what your community is doing, it makes it really interesting to put pictures together and see patterns. And, you know, we're starting to look at that on PCF as well, like much prior to the chagrin of you guys, but like, what does it cost to do Spring Boot versus Go, right? From an infrastructure and capacity, does Spring make sense for all teams, right? Sure. Or, you know, are there other alternatives? I just like that you've got this sort of meta feedback loop. Like there's the feedback loop of building good apps, but there's this feedback loop of how am I helping people build good apps? And you're talking about that, that, you know, hey, if Tracker doesn't work for you, you'll switch to something else or you'll learn about the guardrails. And if everyone keeps hitting this guardrail over and over again, then maybe we have to do something better. Yeah, exactly. Because that's really being obnoxious. I like to hear that. Yeah. The point is that you want those guardrails to be in place, but they shouldn't feel like they're in place. Right. You know, it's like there's limits, but you don't want the developers to ever feel like they're being limited. Like it should be presented as the easy choice for them. So if you don't mind a completely self-serving pivotal question. Yeah. How did you guys think through, like you guys started off with your own platform that you had built. Yep. And then you ended up using Pivotal Cloud Foundry. Yeah. Can you kind of tell the story of that and how you ended up deciding on Pivotal Cloud Foundry instead of your own platform? Yeah. I mean, the platform we had built from scratch and it was, you know, over the course of five years before I even got on the team.

And, you know, it worked pretty well, but it missed a lot of features that I think in retrospect, you know, we should have probably built in and that Cloud Foundry has. And so, for example, the concept of kind of organizing teams and delegating responsibilities and without that, like you have to have a bottleneck group that kind of acts on users' behalves, right? So whatever. But, you know, that's not easy to build, right? And it's expensive. So for us, really, like I said, we didn't prescribe Cloud Foundry. You know, we started off small on some hardware sort of laying around. We had a couple teams doing it. What we loved about some of the engagement with labs and stuff were the blog posts and sort of this diary that developers kept and pair programming. Yeah, yeah. I remember stumbling across that. That was like internal that you guys had. Yeah. Or they were password protected somewhere. Yeah. But I mean, but we would have, you know, those people come back and we have a, we had already had a cadence of like doing these monthly sort of get togethers and we started repurposing those to have these people tell their stories about what's it like to pair programming and what's it like to use Cloud Foundry and everyone's delighted. Like it's a great experience. And so it became a thing where by word of mouth and, you know, like, well, how do I start doing labs and, you know, what do I need to pair program and can I use Cloud Foundry? And so, you know, that's sort of where it grew is that it became something that our community wanted more of. And so we just kind of gave it to them. It just became a different way to work. Yeah. And you've explained how many hundreds of people have kind of gone through a training on, you know, building the good apps, but more importantly, TDD and pairing. It may not be perfect for everybody, but it seems like it's really changed how you think about small batches and how you think about shipping software. I don't know. I think, I mean, we, in sitting through your talk, this was not a, this product saved us from ourselves. It was, we needed to be better at software and this was a piece of it, but it was also, we need better methods. We needed to change cultural things. Absolutely. And I think that was, I mean, you alluded to it in your talk that that's not always overarching in some of these sort of conferences where it's just kind of high level platitudes

and like transformation. Right. But like transformation's hard and no one product will solve any of it. Yeah. I like the idea of a redemption product. Saves you from yourself. I guess maybe that's like those, uh, monitor your eating and weight apps on the phone. They're just like trying to save you. So, so, I mean, do you think, do you think, uh, closing out the self-serving topic, do you think like nowadays, if, if you or Home Depot is doing this, like you would want to build your own platform or does it just make more sense to get an off the shelf one or like, how would you evaluate that? Yeah. Again, I think. Cause five, cause five years ago, like who knows, right? Like, but yeah, like I said, so the team I adopted was the team that built the old platform and supported it and loved it. And, you know, we had some cultural issues with, you know, sort of cloud foundry being thrown in our lap and, you know, there was some very, um, natural sort of lash back to that and some other things. And, um, but, you know, if you talk to that team today, I mean, they would tell you the same thing. Like, it's like, this is awesome. You know, it's like I get to focus on things that, um, actually add value to our community as opposed to, you know, like something simple with air quotes, right? Like, you know, aggregated logging, right? Like we spent a lot of time and money building that and it was good, right? But it was one guy and it's like, and that's a hard problem. Yeah. I mean, did, did that make you money or did actually charging for late tools get you money? And I think the answer is always the latter and you don't want to be bad at the former, but do you have to be good at building the former? And I think it's a, and I think at any company, that's a constant question, right? It's like, what do you want to build yourself? Like, you know, what do you want to buy off the shelf? What do you want to take open source? I mean, there's, that's a tough question. And I think, um, you know, I just think there are some things, right? When you're looking at your guardrails, like they're super important, um, you know, and it's, it's good to have the, you know, the best, you know, I think, um, so one of the, I've heard, uh, the, one of the analogies that someone, I forget who, uh, they were talking to our legal and finance people. And they're like, if we're being sued, like, what kind of lawyers do you hire? Do you hire the best lawyers or do you just kind of get okay ones?

Right. And it's like, like, why are you willing to spend all the money on that? Right. And I'm telling you, this is the best platform, right? That's interesting. That's a good analogy to steal that. So like, I do so much of your material. So, so before we wrap up, I had one more question. You've already identified one of these. Uh, but like, if, if you were to look at like pivotal and the overall kind of cloud native, I don't know, cloud foundry community, like what, what's, what's like at least one thing you think we need to like improve on overall. And the one you identified, I hear this one a lot is like, it sure takes a lot of resources to run spring, which, which I think, you know, that that's something to fix, I guess, but I mean, it depends. I think, uh, I don't know enough about it, um, but where we are in our maturity level, it seems like that. I don't know if we've gotten to the interesting bits of spring. Sure. Sure. Well, I, I think, I think, I think at the moment, it's sort of like a volume thing that's like one, once you're doing everything, it's such a small amount that it doesn't matter. But at first it seems like you mean from a memory consumption, just from pure infrastructure resources, which again, the smaller your footprint is, the more you notice it and it grows. So that's, that's, that's, that's one thing, but like, what's another thing that you think, again, like just the overall kind of like cloud foundry and pivotal cloud foundry world, like what do you, what do you think is a good thing to tackle as a, I, I, you know, I think the, uh, the, it's hard to articulate sort of the value of this upfront, right? Like when you have a company that's focused, when I have company, I should say, uh, but there's like a culture and you know, the people with the money are so bottom line focused and budgets and stuff. Um, it's an investment, it's a, it's a deep investment. And, um, it, in luckily we, you know, we work with someone who's really talented in sales like Don Addington and he was very flexible and, um, you know, it's sort of, you know, there's probably some bending of rules somewhere to like, you know, get our feet. I think you called that leadership earlier. Exactly. Exactly. Um, but yeah, I think there needs to be a little bit of sort of this, um, uh, there needs to be a, I think an easier way to lean into it. Yeah. Yeah. Man, I, I'd agree to that a hundred percent doing the business case ROI stuff is up front.

It's hard and I think the reason why people ask for that, and I could be guessing is that it is so expensive that, you know, um, they want to know that up front and if there was some way, you know, to lean into it, I think that question starts falling off the radar more and more. Right. So last thing for you is, uh, I'm often a proponent of letting big companies, letting folks talk at conferences because, Hey, it gets you out there. Let's, I mean, again, with all sincerity, you ended your talk at my first thought is if I lived in Atlanta, I'd probably submit an application right now. Like, are you hiring, are you hiring engineers at Home Depot right now? Always. Yeah. So I think we're always looking for super talented, collaborative, you know, problem solvers. Absolutely. I think there's big problems being solved at a lot of enterprises that are different than the startup. And if you have the startup culture in the enterprise, maybe you're, you're actually tackling some really meaty stuff that you would have shied away from before. But again, hearing what you all are doing, I think it's hard to, hard to beat. So I guess if you're in the South and, uh, you're looking for a change of work, hopefully you're flying at Home Depot. Yeah, man. Thanks for the plug. Absolutely. Doing lots of good data science. I do pricing. There's lots of really cool computer science problems. To that end, where, where can people, uh, track you down? So to speak. The easiest place is LinkedIn, um, Anthony McCauley, M C C U L L E Y. And then, and then what's your Twitter handle? Epic nerd. That's pretty good. Yeah. All right. All right. Well, as always, thanks for listening. This has been Pivotal Conversations. You can find us, uh, at soundcloud.com slash Pivotal Conversations often. Uh, also if you go over to, uh, uh, pivotal.io slash podcast, or maybe it's blog.pivotal.io slash podcast. We're there somewhere. We put full show notes there. Um, and you know, if you liked this episode or if you didn't like it, you should do the following. You should go into iTunes and give us five stars and or leave a review that talks about how awesome it is. And if you listen to this in overcast, as so many people do, you should click on the little recommend thing. One day I'll figure out what that means. We'll see everyone next time. Bye-bye. Thanks.

Tanzu Talk · 🍕 Get more pizza.