My name is Bob Cunningham. As you mentioned I work for TD Ameritrade. We are an online brokerage company and so financial services we obviously do a lot of different things for retail customers but we have a large institutional line of business as well with advisors so we have a couple different ways we go and those have you know different requirements from a technology stack. It's interesting what the advisors need from technology versus what the retail customer needs is sometimes in common but a lot of times different. So I have come from a financial services background. I actually worked at Scottrade before TDA we were purchased and so I've been doing this now. This February will be my 19th or 20th year. I always have to look 19th year. Started as an intern and worked my way up so I now I lead the application architecture enterprise application architecture team at TDA and then nine months ago took over and then we formed we decided to go all in with PCF and we started a program and I formed the cloud arm and I generically called the cloud you could have went PCF or whatever but I decided to go generically cloud because you know we have ambitions of taking PCF and hosting it in in public clouds at some point but we are kind of starting with on-prem you know get our feet wet. Tell us the backstory. So you mentioned you know starting with PCF I think it's about nine months ago, six, nine months ago. What led to that decision? What were some of the factors driving your need or your decision to modernize the way the way you build applications or the way you operate applications? What led to that decision first off? Yeah, so I'll give a little bit of a back story before I join because I know it, the company, but you know we had been working with Pivotal through Pivotal Labs and so there was a, I'm going to call it a PCF presence but it was pretty small and minimal.
2:05It was pretty small but it was just enough to support our labs engagements and for those that don't know that's where you actually go. You sit at a Pivotal location, you're totally immersed and you build some new product, whatever that thing is you're there for. So there was a couple starts and stops of doing that with Pivotal Labs and then I think you know everybody realizes that whether it's public cloud, whether it's agile, whether it's PCF, you all need to find ways whether it's technology but it's hopefully more than just technology to accelerate your path to production. Ultimately, you know, shrink your cycle time and get features and products out quicker. Hopefully also better products quicker. So I think our leadership realized that PCF was a good potential for that. We also had a competing product at the time so they asked us to do an evaluation so we did a bake-off. And based upon the requirements and the things that we were looking at, PCF was a better fit. So the main thing that drove, there was a lot of different things but the, I'd say one of the largest things is we had a real focus on developer experience. Right. And so, since that was weighted so heavily in our evaluation criteria, it just made PCF a better choice. And of course, developer experience is, you know, in furtherance of the end of, I assume, releasing software faster. And giving your customers more functionality, responding to their needs more quickly, was that kind of part of the goal? Yeah, for sure. And, you know, developer experience, you know, if you think about the way classic IT works, less service tickets, less wait time, less, you know, ultimately, everybody has their own motivation on what drives them to do good work. But generally, developers just want to get product out, right? And that's what gives them the satisfaction. So for their, to have their satisfaction scores be high and to have a great experience, they have to be able to do that in a pretty frictionless manner.
4:05And that's where PCF automation, some of the, let's call it DevOps experiences, really enable that. Got it. So let's talk about application transformation. So, you know, we, I think a lot of the attention sometimes gets put on, you know, net new cloud native applications, which are great and can drive a lot of new business and new, new interest from customers and those kinds of things. But in any existing enterprise, you're going to have a lot of legacy applications. A lot of those are going to be monolithic applications beyond, you know, legacy tech stacks. And part of the challenge is, well, how do we modernize those applications? Because those are oftentimes the ones that are really bringing in the bulk of the revenue. Talk a little bit about your, your approach to application transformation. I thought I was on here for you to give me that answer. If I had it, I would share it with you. Although I have heard from a few different, a few different customers, and perhaps I can share some insights. But I'd love to hear from you what you were thinking as you kind of started that process. Yeah. Looking at that last portfolio of applications and thinking, how are we going to modernize these? It is a daunting task, right? Like you have thousands of applications that have been written. Some might go back 10 years or longer, depending on where they are. So I think, I think for us, we had one advantage that I like to lean on. So generally speaking, we were already in the process of modernizing and moving forward towards spring, spring boot. So even the newest version. So we have a large presence there. So it's a natural thing for us to say, well, that's kind of the sweet spot for PAS. It's not exclusive by any means, but it's just like they're born for each other, clearly with Pivotal being a number one contributor. So I think we decided to start with some of those low hanging fruits. And we worked with some teams and we targeted some that we thought we could be successful with our first engagement with Pivotal. So we, we did do a 10 week, well, a four week engagement for a roadmap and then a 10 week engagement with them to work side by side.
6:05And I had my team, a couple of my members on my team went and they actually took the role of the developer, not the pivot. Okay. So I was like, well, they have to experience working. And it was a kind of a win win because of the team we went and worked for, you know, pulling together resources with this new thing. So I said, I'll give you one of my resources. They'll essentially act like one of your, your developers and we'll get to learn. And so it was interesting. And then slowly as the engagement went on, they kind of switched roles and they started trying to help more as a pivot. So, um, from an application stack, we just kind of, we did a, a funnel process where we kind of set criteria of what we thought were, um, good business reasons why you would want to target that app. Um, it's important. Like, uh, so it really doesn't make a ton of sense to invest into something that is running good. Well, um, doesn't change ever. And, you know, so we wanted to have some criteria like frequency of change. We wanted to have some criteria around, you know, um, you know, risk profiles and everything. And then, um, then we went to the technical criteria and honestly, it was mainly driven from pivotal, right? The, it was new to us. So they taught us a lot about whether the things that make things good candidates and bad candidates. Um, and then it's you, we kind of just targeted those apps. And then what we did in our engagement that I, I, and we did it again when I'll, I'll get into our own private engagement. Um, is we tried to pick things across a, a, a broad range of, I'm going to say scoring, right? So we picked ones that were really good fits to get our feet wet, to kind of just get into the platform and learn. We picked some harder use cases. We tried to fit enough type of things in order to maximize our learning experience more than maybe maximize, um, how much we got onto the platform. That's an interesting concept. So it's an early, early engagement. You recognize that you have a lot to learn.
8:05So let's pick a few different types of applications that have different risk profiles and different, uh, architectural concerns. And let's kind of vary that up so that we're learning and you're somewhat could be potentially sacrificing the total number of applications. You're going to move to the platform in the short term, but long term, you're going to learn. It's going to ultimately accelerate. Yeah. It's sort of like, um, TDD or, um, any form of automated testing. There's probably a little bit more initial upfront costs, but the, the hope is, is if you do it right, that you end up, um, accelerating and getting, you know, an order of magnitude back, um, once you reach that, that tipping point. Um, so we just, you know, we had the pivots there and they've done this at a lot of companies. So we just tried to pick some interesting use cases out of this pool. We were working with a single team, but we tried to pick some interesting use cases, um, and make sure we could learn as much as we possibly could. A big part of what you do in applications is, you know, you come up with your recipes and this is the thing that shows other people how to do it, right? Um, they don't have to, you leave it up to them for their choice, but if, if it's easy and it enables them, they're going to want to follow it. Um, and so we just tried to, you know, get as much as we could during that 10 week engagement. Um, and then, so I think we, we definitely wanted to get apps on the platform. We definitely wanted to learn. Um, so it was really a mix of learning experience and, uh, making some progress. Um, and that was 10 weeks and then, um, Pivotal moves on and, uh, we are, we've successfully just completed our own, um, first one. It was just me, uh, the team as part of our program. We worked with, uh, app devs, um, and did one without Pivotal, um, followed a lot of the playbook, right? A big part of the playbook that we haven't mentioned is like OKRs. So it's hard to know where you're going to get if you don't set your objectives up front, um, and your key results to get there. So we definitely do that process.
10:05We like it a lot. Um, it's actually started to grow is in the company. Um, so all of technology at the, the, the CIO level and his directs now have OKRs. Um, and I don't know if it was a coincidental, it probably was, or maybe they were thinking about doing it. They saw it and also decided it was time. Um, but it's definitely a practice we do now. Um, and we're going to mature that. So we did that. We've met with the team and then our engagement was five weeks. Um, we did five weeks and in five weeks we moved, uh, we, we platformed, um, 12 applications, which doesn't sound that, that great. Um, but, uh, we also did a bunch of different modernizations. Um, our first time doing it, we probably, our mistake was we probably focused a little too much on modernizations that first week when you're still trying to form as a team. And so lesson learned. Um, but we got two apps to production, um, all the way to through the pipeline. Um, right. Cause this is still new. So we have a lot of processes that we still have to optimize and automate, but we're, we're constantly trying to pick pain points and improve them. Um, and I'm sure you've heard this with, from everybody, it's a journey, not a destination. Yep. So it takes some time. Well, talk about the, the team. Um, what, what, what kind of characteristics do you look for in people, um, who are best suited for this kind of, kind of work? I was talking to, uh, another customer of West Corp earlier today and they were talking about, um, you know, there's different, uh, there's different types of people. Some people are really, you know, into this change and want to learn and others are kind of resistant. And, you know, that just based on the nature of people, you know, people that react different ways to, to, to these kinds of things. I can, what do you look for? Yeah, I can tell you two things. So I'll say what I look for in my team. Who's ultimately out there working with people. And then what we, when we're talking to a leader, trying to get a team to work with what I suggest or say to them. So for my team, I mean, obviously experience is important. Um, but the, I, the number one criteria is a willingness to be open to change.
12:10So I, my team's architects, um, and at that senior architects, they've been doing it for a while, but they, they each have their own personalities and their own styles. Um, so they're not the same, even though they're the same. Um, and so each of their styles are different. So you just gotta, you know, understand that and a willingness to teach a willingness to pick up stuff new. Um, so an open mind and a, and the ability to learn is probably number one thing. And then the technical stuff, right? The writing the code to doing those things, it just comes naturally then for most of them. Um, so some are better at always being open and communicating. Some are better at bringing a new thing to the table that everybody gets super excited about. Everybody has their sweet spot. Um, so for the teams I go to work with, you know, we've only done one, but when we were building the material saying, Hey, this is what we want to do. I said, it has to be your, your, your rock stars. And by that, I didn't mean like your best developers. I just meant the people that if you say, Oh, he's good at everything I asked him to do. Um, he, if you ask him to go teach somebody, he does that. If you ask him to go code something by himself, he would do that. Like they're just open to whatever they're tasked with and they put their, their, their everything they can behind it. And the reason I asked for that, um, to start with is because it's new and you want to be successful. Um, but the other part is you really want to, and I owe kudos to pivotal as they, as you're learning this from them, you almost don't believe it until you go do it yourself. And you're like, ah, it makes sense. Right? So it's because you want them to be the people that you leave behind that kind of do that again. So you want them to get out and build a community amongst while you're also helping build a community. So those guys can now go work with a team, be open to teaching them, go sit with them for a while, say, Hey, do a learn. So we had everybody on, uh, one of our OKRs was how comfortable they were, um, with being able to do this without us. And, and that included teaching other people to do it. So we just, we ask them a question.
14:10They give us a, yeah, we're really comfortable. And that'll mean that, you know, binary, we met the OKR. So they might give a learning session or a brown bag, um, lunch session to a team. Um, they've, with the apps that we've moved, they've already went and worked with teams to explain what they did. Um, they've already committed, uh, and created their own recipes and put them into our overall cookbook that the whole enterprise can look at and use. So it's not to say that they have to be rock stars, like, but you want to try to cherry pick, especially in the beginning. Like the people that you think you're going to be successful with, because like, you've probably heard a million times today. It's a culture change too. It's a, it's a, we're going to do things different. And, uh, my boss told me this a long time ago and I used it with everybody so far. It was, um, you have to be comfortable with being uncomfortable, especially in the beginning because everybody comes in. They think they literally asked the team, they asked me, well, how do you do this? They want to answer in the beginning. There aren't answers. There's a lot of ways to do things and we haven't done enough or, um, learned enough to know that this way is necessarily better than that way. So I just kind of told them to be comfortable with, um, being uncomfortable, be willing to experiment. And so after the first week they were like, it took a little bit, but they were super excited about that. And we just tried things. And so we have things that could go on to prod that we probably won't because we're like, it was good, but there's probably a better way to do that. But you had to try something to know that. Right, right. And so finding those people that have that mentality that can, can, can live in that space where it's a little bit uncomfortable. Not going to know if this is going to work or not. Uh, those kinds of people who you're looking for, because then it sounds like your strategy to scale this throughout the enterprise is those, those people are going to go and try to teach others. And hopefully that's a self perpetuating. Yeah. So we have, we have multiple lines of business. Um, and so our technology has multiple technology lines that line up with those lines of business. Um, and so through the first app TX with pivotal, we, we worked with two different lines of business.
16:12Um, and then this time we did one, we went to another line of business. And so the, the hope is, is that you've built enough momentum and inertia with those people that you work with, that those lines of business can make lots of decisions. They could form an enablement team of their own, sort of like what we're doing at the enterprise level and just have them do that kind of process. They could have it be more informal and those people are just available. And maybe they go work with the team for a couple of weeks and maybe they work with a different team or maybe they're answering questions, um, on our, on PCF Slack channel. So we have, we're trying to build a Slack community. Um, you've, uh, Otto from, uh, Greg Otto from, uh, Comcast talks a lot about the Slack community. Uh, it's, it's a big deal. It's a great way to learn stuff from each other. So yeah, the goal, but we don't want to be overly prescriptive either. Right. Um, you can't go in and say, you got to do something this way, right? That's like the antithesis of what you're trying to do from a technology point of view. So why would you do it from a process point of view? So you just kind of say, here's things that I think will work and just partnerships. Um, you really just got to partner with them and start talking and have a great dialogue, be open and figure it out. I mean, ultimately all I want for my team to do is, um, enable people, whatever that means. Um, so if that's creating reference implementations, great. If it's creating recipes, great. If it's partnering and actually implementing a new modernization technique or a new technology, then great. Um, as long as it's helping everybody, um, I feel like that's the new style of architecture. Um, kind of get rid of that old ivory tower standard based out, shout, do X, um, and focus a little bit more on, um, getting out there and enabling teams. Cause there's lots of smart people out there. If you, if you help them and point them in the right direction, they'll, they'll, they'll be successful. Right. And you want to take, take advantage of that, those, those smart people. For sure. Got it. Um, so we were talking earlier, you mentioned, since you've got two groups, you've got more of your, I guess, traditional architecture group. And then you started a cloud group. Tell us a little bit about the structure of the, of the organization, how that, how that works and what you were thinking.
18:16Um, it doesn't work great. Um, no, I mean, uh, it was, uh, it was kind of born out of, um, need. Um, so, you know, you have a classic application architecture team and, um, I buy into a way we're already trying to transform that kind of team into doing a little bit more hands on a little bit more enablement. Um, definitely more community based, right? We've set up some communities and we're kind of trying to push that. And then the, the PCF, um, pivotal engagement came around and, you know, they live and breathe that kind of mentality. So I shifted. And the reason I created two teams is because I, I really felt it was important if I was going to do this and, and be really change the way we're thinking. And I wanted to actually create new roles. So a lot of the, the, um, a lot of the characteristics that you're looking for are in my new role. I mean, I call out, um, hands on time pairing with developers in my new role. So I call out a lot of the cloud things, um, reference implementation. So, uh, I felt like if you're going to ask people to do it, then ask people to do it. Um, and then it also helps with hiring, right? Like, you know, sometimes people will say, Oh, I'm hiring this and then you're doing something else. And that's not great. So that's kind of why it happened. Um, I would wager over time that line between them gets blurrier and blurrier and blurrier. And so there's not really a line between them. And, um, but right now it's just like focus areas. So we have other initiatives going on, um, that, that require some resources. So I kind of just keep them a little bit separate, but we, we still have team meetings together. We still do things that are together and talk across. So it's not like it's a pure boundary. So it sounds like it's a, it's a pragmatic approach for today. I mean, I, I assume the, the, the, not the end point, cause there's never an end, but the goal is to get to a point where this is cloud native. It's just the way we do things.
20:16Yes. There's not these two separate groups. Yeah. No, I, I think so. Um, right. Once you've evolved enough and you don't have some of maybe these legacy constraints or, or some of these other things that you're doing in a non cloud native way, I think that becomes a more natural thing to just say. But in the meantime, it's like, you know, I wanted to both give the recognition in the roles that are different, right? Because right now they are different. And then if they morph together, maybe the roles become the same again at some point. Um, but right now you have tons of legacy. You have tons of classic things. Um, you have things that fit in the cloud native space, but also fit in the old monolithic space. Um, so something I'll have to figure out, but luckily not right now. Well, you know, speaking of the future, so, so what, what, you know, what do you hope to accomplish, let's say in the next six months to a year? Uh, what was kind of on your agenda and how do you see this progressing? So, um, you know, we did our own FTX and we did some, some good work last quarter. Um, this quarter we're, we're taking a small step back from what I would call like a larger FTX, which five weeks cause it's very consuming and it's most of my team. Um, so I don't have a lot of capabilities to do, to do more than that when you're there. I mean, it's nonstop eight hours a day. You're with them. You're doing those things. Um, so this quarter we're going to do some, what I call mini engagements and we're still going to, it's something I invented. I don't know if pivotal does something like this or prescribes it, but basically we're going to focus most of the quarter on enablement. And by that, I mean, um, you know, we have some new backing services that are coming available. Um, Redis via the marketplace. Um, we're working on spring cloud services, uh, via the marketplace. So get those reference implementations, um, get some recipes around them set up so that we can, cause I want to enable as many people as possible. So if we go work with one team, we'll get a lot done with that one team, but it's still one team. But if I do this, um, hopefully the goal is we can, we can, we can communicate through the community channels and that might uptick more than one team.
22:16Right. And it'll be a proof in concept. We're only doing it this quarter. We'll see. And if we don't, then we'll, we'll try something else. Um, but the small mini engagements will be, we'll just have a much more focused effort of going to work with that team to implement whatever that capability is that's now available. So we'll target a team that needs a distributed cache or recession caching so that we can, uh, you know, improve their application and actually use Redis via the marketplace. Um, you know, spring cloud services, we have a couple of teams that were really wanting to use Eureka, explore that. Um, so we would target a team specifically to get that implemented and work with them on it. Um, still doing an aptX style, like we'll get together, we'll make sure we're on the same page of what we're trying to accomplish. But, and we'll be hands on during the time, but not this five weeks where we have a, probably a bigger pool of applications and you're kind of, you know, whatever you get done during that five weeks based on your OKRs, what you get done. This will be a little bit more focused. Um, but that's really just because like I said, there's capabilities that we're trying to deliver from the platform and everybody, um, this quarter that I think made that, uh, an option. Um, and turning a little bit to the infrastructure. So you're running, uh, on-premises now, uh, is, is public cloud in your future? I mean, how do you think about, uh, hybrid cloud, multi-cloud, whatever you want to call it? Uh, how do you see that playing out at TD Ameritrade? So we haven't, um, uh, we haven't had a very many conversations about it other than to say that it's something we are going to do at some point. Um, so I, like, yes, we'll be in public cloud at some point, um, hybrid cloud, um, foundations across different clouds, right? That's kind of one of the reasons why you want to use PCF is you don't want to be stuck in a, in a single provider. Um, but we haven't really looked into it from a point of view of actually doing it. Um, so we'll be, um, at, at, at the end of fiscal year 19, that'll be, you know, essentially a year's worth of time we've been doing this.
24:17And every, a lot of people say, well, you needed like the 18 month windows, that special sweet spot of whenever you're, uh, the term you guys, a lot of people use is the hockey stick starts to go up. Um, so maybe then you have enough momentum that you can refocus a little bit of your resources towards, okay, what does it mean now to get a foundation running in public cloud? What is, what has to change from our applications being further apart? Um, those types of things. Um, so I definitely think it's part of the conversation just as something in an order of magnitude this big. It's like you have so many things you can prioritize and focus on at once. But it gives, but PCF gives you that flexibility when you get to that point. For sure. It'll be a lot easier than if you were potentially using it. Well, and I'm, uh, I was talking to people that are further along the journey here. Um, uh, Comcast guys, um, couple other companies. And so they obviously have foundations running in public cloud. And the thing that excites me most is this, that, that how close it gets you to those public cloud services. Right. And so that's the thing about public cloud. Yes, it's nice. I get it. Uh, multiple availability zones and, um, you know, being able to run on a public infrastructure, public cloud infrastructure, and so on and so forth. But I think the, from the developer in me would be, it's just, it gets you closer to more and more services available. And that if we've done the transformation, right. If we have these product teams and we've enabled them and they've, you know, they've upskilled and they're doing great things. And well, it might make sense for a team to go do some, a service that nobody else is doing. Right. Because for their problem, it fits. Right. Um, and some other teams might do something completely different because for their problem, it fits. And, but you know, it just, the world kind of opens up once you've got there. Um, you know, internally, there's a lot of conversations like how do you provide those services that only a single team needs? Or, um, how much is that going to cost to bring in X, Y, Z for them? Or are they going to have to support it on their own? Those types of conversations. So I, I just feel like public cloud, um, kind of opens up your world a little bit more too.
26:17Cool. Um, so just a couple more questions. Yeah. Very open ended. So, you know, if, if you could give, let's say one or two pieces of advice, like the most important lessons you've learned over the last year or so, uh, to our listeners who maybe are where you are, where you were a year ago, they are now. Uh, what would that be? Trust pivotal. All right. I like that one. I, I say that jokingly because, uh, we, uh, question them constantly. Like, why don't you just tell us what the OKR should be? You've done this 50 times. Why don't you this? And, um, like after doing it, I get it now, but you have to, so just let it kind of ride out. Don't, don't set unrealistic expectations. Um, start small. Uh, I don't know. Like, I don't know that we have or haven't done this well, but I can just tell you, I, it's something pivotal preached and it's something I hear the people that are the most successful, they've done. They did that well is just start with a team or two that are good and build those capabilities. The platform is great. Pivotal, uh, PCF is awesome, but it still doesn't come done. Right. There's still work to do. Absolutely. So like, uh, you have to do things that are specific to your environment, your specific problems. The platform engineers, um, they have to upskill their themselves and the things that are doing differently. Um, the app dev teams have new ways to think of things. Um, so there's just a lot of things going on. So if you start small, start with a couple of teams, um, really start upticking, showing some value, right? Once you start showing value, getting everybody else to want to take advantage of that value is probably the easy part. So I, I would definitely suggest, um, starting small. Um, and then I think, uh, this is probably hard for everybody. Um, and I definitely preach it, but struggle with it is being, you know, open to that. Um, being comfortable with being uncomfortable. Um, like as an architect and, you know, let's call it classic architect, like you want to have the answers. You want to, you want to make sure the thing you're doing, you're doing right.
28:18And then it's going to work for everybody. But I, you just can't think of it that way. If you're really trying to achieve the agility that transformation promises, then you have to let go of some of that because not every answer fits everybody. Um, and it really is about shifting left and, and empowering teams to be able to do more and control more of their own destiny. So to do that takes a lot of trust and a willingness to try something. And if it doesn't work, be like, okay, we failed and try something different. Um, so that's, that's probably the one that I say it a lot, but I'm still the most uncomfortable with sometimes, but you know, everybody has to grow too. Absolutely. Uh, and last question. So we're here at CF summit. Um, talk about the community and how that is important to what you guys are doing and, and perhaps learning from, from your, uh, you know, your colleagues at different companies. Uh, you know, how important is that open source community to, to the, to the development of, of your platform and your transformation? Yeah. I mean, there's two aspects of it. There's the open source aspect of it. And, um, you, we've heard, you know, multiple police speak that once they've accepted it and they, they ultimately bought into it, it really accelerated them. It opened up their world. Um, that's one side. And I guess you could argue that it's part of the two sides of the same coin that to me, just community without open source, like just community. All right. Um, we're very focused on just community. Um, not that we don't use open source products we do, but we're early in our journey. We're definitely not, um, highly contributing to anything or creating our own yet. Right. Um, so we're more focused on just community. And like, to me, that's just like bringing the, the human factor back in. Like it became sort of factory for a while in it. And like, you know, there's a bunch of boundaries and this team does this and this team does that. And like, you forgot that we're all humans. And so it's like getting everybody to help each other. And, um, so people can ask questions on the community channel and yes, my team can answer more often than not, or go do some research and find the answer. But it's awesome. Whenever someone else answers that question, cause like that gives them some satisfaction. They, they knew something that they've already experienced it and they helped someone else
30:20out. So bringing that human factor back, um, is a big part of the community. Um, I don't know, I don't know if it's coincidental, but we had that, um, keynote where they were talking about empathy. Maybe that's part of it too, is the human factor empathy in my mind. Um, so I think that that's a big part of it, um, as well. Um, what else? So the other thing about community is a numbers game in my sense, in a sense, like I think I think of that, maybe I'm the only one, but I hope people agree with me is the open source community. And even the, what I was calling the regular community, it's a numbers game. Um, so if you have a team of four developers or five developers and they're trying to solve a problem, they might solve it. Perfect. They might come up with the most elegant solution, but if you open that up to a 5,000 people, well, what are your odds that you're going to get something that fits right? And yes, you'll have a lot of strong opinions, but ultimately you're just absorbing information. You don't have to do anything. Um, the open source community, I think about a lot like that in a numbers game. So yeah, we could build a framework that does X with our architecture team and there's six of us or eight of us and we're doing a great job and we're helping, um, we're helping the rest of the developers. But if like a couple of people mentioned that we intersource that, well, now we can have a developer contribute something that we didn't even think about. And now that maybe unlocks a bunch of other things. So it's like, that's the kind of aspect of like just bringing different perspectives, making it a safe space to talk or experiment and just see what great things come out of it. Absolutely. I think that's a great, great place to end on. Awesome. Bob, thanks so much. This has been great. I'm sure our listeners will really enjoy it. All right. Appreciate it. Thank you very much. Thank you.