Subscribe
Share
Share
Embed
The development world is cluttered with buzzwords and distractions. Speed, focus, and freedom? Gone.
I’m Nicky Pike. And it’s time for a reset.
[Dev]olution is here to help you get back to what matters: creating, solving, and making an impact. No trend chasing, just asking better questions.
What do devs really want?
How can platform teams drive flow, not friction?
How does AI actually help?
Join me every two weeks for straight talk with the people shaping the future of dev.
This is the [Dev]olution.
Caleb Washburn (00:00:00):
I think organizations that understand and enable their people to take advantage of these technologies so they're more productive doing the things that they were doing today means yeah, they'll be able to accomplish more than they maybe were able to do historically. Will it lend itself to less people? I don't know. Will it lend itself to people doing different work? Absolutely.
Nicky Pike (00:00:24):
This is [Dev]olution, bringing development back to speed, back to focus. Okay, so everyone's talking about Kubernetes and cloud data platforms, but here's what nobody's saying out loud. 70% of enterprises are blowing their cloud budgets. 32% of that spend is literally burning on idle resources and companies are adopting Kubernetes not because they need it, but because that's what everyone else is doing. Meanwhile, AI is generating 41% of all code that few understand and 66% of developers say is almost right, but not quite. We're building infrastructure we can't afford for processes it wasn't designed for. What could possibly go wrong? Joining me today is Caleb Washburn, CTO and founder of Momentum AI. Caleb has spent 17 years as a lead IT architect at State Farm before jumping into the platform engineering space at Pivotal VMware and Broadcom. He's helped teams move off mainframes, adopt cloud platforms, and build developer experiences that actually work instead of creating bottlenecks.
(00:01:26):
Now at Momentum AI, he's pushing enterprises to stop chasing shining tools and start saving real problems. Before Caleb and I get into that, here's the challenge on the table. 80% of enterprises are running Kubernetes in production, but 75% site skill shortage is their biggest obstacle. 84% of developers are using or planning to use AI tools, but only 33% trust the output and 46% actively distrusted. Caleb's seeing something else firsthand. Companies are racing to the cloud, they're getting sticker shock, and they're quietly moving back to their data centers. So how the hell do we navigate the platform decisions in cloud cost and AI integration without burning out our developers or building systems that we can't maintain or scale? Caleb, welcome to The [Dev]olution. Thanks for having me, Diggy. Before we jump into this, is there anything you want to say you want to start out with?
Caleb Washburn (00:02:14):
No, other than it's an interesting time right now. There's a lot of innovation happening, a lot of new tools, a lot of hype. Figuring out how to navigate through all this is a challenge, but why not? Let's all figure it out together.
Nicky Pike (00:02:26):
I agree. And before we kick off, anybody that knows me knows this. Caleb, you probably know this is coming, but I have this huge man crush on Caleb Washburn. He was pivotal, no pun intended in getting me started in my career. Some of the tools that you've written for helping people with platforms, amazing tools that are still in use today, and man, it's an honor to have you on here. Yeah,
Caleb Washburn (00:02:46):
It's great to be here.
Nicky Pike (00:02:48):
Thanks, Nicky. All right, so let's start with what's broken, because I think there's quite a bit out there. You told me something in our prep that I really can't get out of my head. And that's when companies come to you and they say, "Hey, we're going to use Kubernetes." The first question you ask is about why. And they usually don't have a good answer. With 80% of enterprises running Kubernetes in production, but how many of them are actually needing it? What's driving this fear of missing out and what happens when companies adopt technology that they don't understand?
Caleb Washburn (00:03:15):
Let's set it straight. It's not that Kubernetes is a bad technology. Kubernetes is great, but the question is, what problem are you trying to solve? What outcomes are you trying to drive for your organization? And is this the right tool right now for you to handle this? Because it's a very, very powerful tool chain. It's a very flexible tool chain. But the question is, do you have the skills? Are you ready for this journey? Are you ready to take your organization where you're at today? And is it the right first step? Is it the right end step for you right now? So yeah, that's a lot of the things that we work through with those companies. Looking at what are they trying to accomplish and let's find the right tools for you today to help you achieve those outcomes for your organization. Because at the end of the day, technology is great, but most companies are in the business of selling something that is not a technology platform.
(00:04:06):
They're in the business of selling insurance. They're in the business of selling retail products. They're in the business of handling healthcare data, whatever it is. What do you need in your organization to effectively move the needle for business capabilities that you're trying to deliver into a production environment that is secure, safe, and productive way for your developers in your organization?
Nicky Pike (00:04:27):
Yep. I mean, I agree with you. It's a great tool when it's used in the great circumstance, but you don't use a circular saw to put a nail in place. Do you think that a lot of companies out there are just looking at this and saying, "Well, this is what Google, this is what Meta's doing, maybe we should do the same thing?"
Caleb Washburn (00:04:41):
Yeah, it is the popular thing right now. You go to Cubcon, you go to these various different events, there's thousands of people, thousands of developers, there's tons of booths, there's tons of technology that's built upon it, but yet everybody's still trying to figure out how to create this elegant experience for their developers, build an internal developer platform leveraging Kubernetes as the substrate, figuring out how to layer the appropriate technologies, solutions from the CNCF on top of this. They're still chasing the ability to say, "Run my code in the cloud. I don't care how." And even in Kubernetes right now, there's companies that are being successful with this. Let's be clear, they are, but it's not without effort. It's not without a lot of blood, sweat, and tears trying to figure out how to make all these things work together because you're stitching together a bunch of open standard components and figuring out how to make that the right solution for you versus a more of a out of the box solution that was very prescriptive in the Cloud Foundry ecosystem comparison.
Nicky Pike (00:05:38):
Yep. Well, and I mean, you bring up a good point. We talk about that skills gap. We talked about KubeCon. I think it was Kelsey Hightower that said Kubernetes is a great platform for building platforms, but I don't think a lot of companies understand that. And we've seen, look at KubeCon, look at how big it's gotten. There's this whole niche industry that has been built up around Kubernetes just to help companies make sense of it. But still, there's this idea within companies of, well, we've got to use it. That's the way of the future. But I don't think that's necessarily true for all companies. And what's momentum stake on that?
Caleb Washburn (00:06:08):
Use the right tool to solve the right problem. And that might be Kubernetes. That might be Cloud Foundry. It might be deploying things to VMs right now because that's where you're at. It might be leveraging one of these solutions that makes more application, a deployment, lifecycling easier, like a cloud run, a Fly.io, whatever those technologies are. It's about finding the right tool to solve the problem for your organization and being aware that if you believe that is Kubernetes, you believe that is the right tool chain. Going into it eyes wide open, understanding the flexibility, but also the challenges you're about to undertake and figuring out how to do that. What we believe is doing that is not just saying, "We provide our developers a Kubernetes cluster or a Kubernetes name space and say, we've achieved our job as a platform team." That is the table stakes of getting started.
(00:07:03):
It is not what you would strive to achieve of providing that. We believe that providing your platform should be treating it like a product. It's a pretty interesting set of taglines in the industry, platform as a product. We believe and we strive to do that with our clients that we work with. Figuring out how, as the provider of that platform, you're thinking about taking the burden of responsibility off of your dev teams, not pushing a new set of tools to them and saying, "I've just provided you tools. Let me provide you capabilities in a self-service, a frictionless way or a low friction way so that you can focus on the, again, back to the objective of why do we work here?" It is not to build a platform. It is to deliver a new insurance capability. It's to deliver a new application into the app store.
(00:07:52):
It's deliver some business objective that is revenue generating, or if you're not in a revenue generating world, some business of outcome, it is not about the technology. The technology is an end to the means.
Nicky Pike (00:08:04):
Well, and I think you brought up a great point there that a lot of the platform teams that we're seeing, they do. They hand developers this namespace and they kind of basically say, "Good luck." And you call this standing up the dial tone for Kubernetes. And this feels like the wrong way. I mean, what's the actual impact on developers when they're trying to build platforms this way? What does it cost the business when they do it?
Caleb Washburn (00:08:24):
Yeah, it's the cognitive load that we're inverting and giving and pushing out to the development teams that now instead of just becoming an expert in how do I write a microservice and deliver that, understanding the business context, now I need to understand this technology context of I've got a bag at Terraform that I've got to figure out how to use. I've got to figure out how to do things with Kubernetes manifests. I have to think about how do I do ingress? How do I do TLS termination? How do I manage my observability? How do I manage my logging? How do I do all these things when, in fact, I'm just really just trying to deliver an amazing business outcome for my consumer. And now all these things have been sort of handed and given to me on my plate under the premise of this is self-service and this is what you've asked for.
(00:09:11):
Instead of, maybe I haven't really asked for this, but I got tired of filling out forms to get things done. So I wanted to be able to have more autonomy to deliver capabilities in a quicker way. And it sort of inverted itself to now I have to become an expert in wrangling infrastructure just to focus on getting my application out to production. So I'm doing CICD activities, I'm doing everything. And then at the end of the day, maybe I got an hour or two to write some Java code to deploy my application because I've been having to focus so much on the other aspect of things. Now once I've got it figured out, yeah, I can be fairly productive. And now I know a lot more about a lot of this infrastructure stuff, but was that really the objective of what I was trying to accomplish in the first place?
(00:09:53):
Probably not.
Nicky Pike (00:09:54):
Well, I mean, you've got competing priorities there because like you said, with Kubernetes and providing this self-service platform, we are asking developers to do a lot more, take on a lot more burden and no infrastructure, which is something that they didn't necessarily have to do in the past. But we're also seeing this kind of, there was this rush to the cloud and a lot of people found out that there's a sticker shock there, that cloud is expensive. And I think Kubernetes is one of those technologies that they thought would kind of help save them costs. And they're finding out that that may not necessarily be true, especially if they're not architecting, right? You're seeing this yourself. They're kind of quietly moving back to their data centers. I mean, are you seeing cloud repatriation trend being real? Is this a failure of the cloud or just a failure of the strategy for using it?
(00:10:37):
I don't
Caleb Washburn (00:10:37):
Think it's a failure of the cloud. I think the cloud has allowed people to innovate. It has allowed people and developers to show the art of the possible, but this has to be a holistic plan. You have to think about what am I doing as far as moving my data, moving what is on-premises? What are my dependencies? It is really about thinking about that bounded context of what does my application need to be successful? It's not just about moving the application bits, but now I have all of my data, all of the other scenarios are still sitting in a mainframe somewhere. You've got to really think about this problem holistically and figure out how you're going to migrate those workloads. A lot of times I've seen this be very successful where you're migrating to a local data center containerization solution. And then once you've got that figured out, it's a lot easier to move that entire portfolio to the cloud.
(00:11:28):
It's this piecemeal of where I'm moving the application bits because it's easier because I've got a Kubernetes environment that's managed in the cloud, but yet I'm still interacting with legacy data stores. It works, but doesn't work well. And that's what a lot of companies are finding challenges on is, well, it's the performance impacts of the latency between the environments. It's the cost impacts because now I'm pushing and pulling data between different disparate things. It's those hidden costs that I think as you're walking into this, understanding that you might have a journey to move, get yourself out of your data center and move into more of a cloud managed world. I think a lot of companies are struggling to complete that mission. They get started and they get started really fast and see a lot of quick wins, which is great, but the final mile is really hard.
(00:12:14):
And finding out that that final mile is maybe a lot more than a mile. Might be more like a marathon that you have still left to figure out how to move those final workloads and actually evict yourself out of your own data centers. And that's where they're finding challenges and saying, "Is this really what we had hoped to do? " And then the cost factor comes in because you're managing both.
(00:12:35):
Now it's not just you've moved everything to the cloud and it's more expensive. It's now we've got the worst of both worlds. I have still a data center I have to manage and I've got cloud spend that's rising day over day and that's where companies are finding challenges in that space.
Nicky Pike (00:12:49):
That's a great, I don't want to say middle ground, but it feels like a stick point because you mentioned legacy. There's mainframes are still out there, especially in like the financial services and the insurance agencies, they're still running mission critical workloads. And you mentioned that there's businesses out there that are still 80% on mainframe, but you've got execs that want to go all in on public cloud and you talk about this final mile. I think that leads to a place where companies, because of the skills gap, because of the new technologies, they get stuck halfway through this migration. And like you said, now they're paying for things that are both in data center and public cloud, nothing's really working good. I mean, what is your take on how can you get companies out of that trap and kind of help them move forward and really modernize their applications and infrastructure?
Caleb Washburn (00:13:33):
I think it comes back to what we started with. It's let's find the right tool for the right job, the right set of solutions, the right hosting platform for the right workloads. It's not about public cloud versus private data center. It's about what's the hybrid approach that's the right approach for you. And it might be that you've got workloads that are a good fit for cloud. You've got maybe a set of workloads that are still a good fit for the data center. There's this ideal state that it's all one or all the other. I just don't know that I see a lot of that panning out for organizations that are large and have a large legacy footprint because that's a really hard journey to move everything from pivot to everything that used to be in my data center to now everything is in a public cloud.
(00:14:18):
This may be a different answer for companies that don't have that large footprint than in a legacy world. So it's really, again, just about what's the right solution for you and don't necessarily have to have it be where everybody is following the exact same patterns. You got to do what's right for your organization.
Nicky Pike (00:14:36):
When you're talking about that, especially between the hybrid solutions, there's also this data sovereignty. You got GDPR, you've got people that are worried about their data getting out. So it seems like a lot of the hybrid would be data within our data center, the stuff that we, is proprietary that we want to own, but we put all the customer facing, the interfaces out in the public cloud where it's closer to the customer. Is that something you agree with or is that just kind of peanut butter spreading a solution without really looking at the real problem?
Caleb Washburn (00:15:03):
I definitely think there's use cases where that makes a lot of sense. I hate to say it depends. The typical consultant speak depends. Again, it's about understanding your situation, understanding what is the right balance of risk versus reward, what's the right balance of cost versus managing it and having control. It's all about a series of trade-offs and everyone wants to have a single solution that is the enterprise standard for all and that really are a set of patterns that you need to understand and figure out what's the right solution for you. As we talk about repatriation and other things, we're seeing that now as well, not just with public cloud, but public cloud was the easy way to get started with modern capabilities of, "Hey, I needed to be able to quickly spin up a database, RDS and those types of solutions are great. I need to be able to quickly spin up virtual machines." That's where cloud started.
(00:15:57):
And then Kubernetes, we're seeing the same things happening now with AI because initially the first things to get started were, let me just use these SaaS services that are out there from OpenAI and Anthropic and Gemini and all these capabilities that are hosted. Now you're seeing these things start to move away from these monolithic SaaS or these SaaS solutions into more private AI solutions, whether it's being able to run the Anthropic and other OpenAI models in Bedrock in your AWS environment or within Copilot, within your subscription, we're going to see that continue to repatriate itself back into the private data center. Those models will be there so that, again, finding the right set of solutions where the innovation happens easier in a SaaS or a public cloud environment, but then there's always this drag and pull to pull these same capabilities back to organizations that want to be able to do this in a self-managed, self-run world because they have other concerns.
(00:16:57):
They maybe don't want to leverage a SaaS environment because of risk and compliance. Maybe they don't want to fully leverage public cloud for other scenarios. That's where we're seeing a lot of them trying to recreate those capabilities, but inside of something that they own and manage. But the innovation generally always happens on the other side of it and then figuring out how to repeat and rinse that back into your data center.
Nicky Pike (00:17:19):
Well, and what do you think's driving that? I agree with you. We are seeing a real need, a real desire for people to bring AI back into, I want to say private, and it could be in the public cloud, but within private models or it could be within their data center. Do you think that is being driven by, is it going to be data concerns? Is it going to be the power of AI, to be honest with you? I mean, the ability and access that it has, what do you think's mostly driving that?
Caleb Washburn (00:17:45):
Yeah, I think there's a data locality aspect of it. You've got the data that you want to train these models, you want to give RAG or embeddings or other things that you're doing with those models and data. Then there's just the overall risk and concern about, if I'm giving all of this information out to third parties that are managing this for me, how does that put my core business at risk, especially if these core things are competitive advantage for my organization? If they're commodity capabilities, maybe it's not as big of a risk, but when these are the secret sauce of what your company is about and what differentiates you from others, you're still just in that back of these organizations' mind, the risk of doing that in a way that is, well, the promise may be that I can run everything cheaper, faster, better. Is it really the risk worth the reward of putting the future of my company in that scenario?
(00:18:37):
And that's always going to be the case. I mean, I think that as much as everyone's going to do the right thing, there is still this feeling of, if I can manage it myself, I should manage it myself for large organizations.
Nicky Pike (00:18:48):
Well, and we're seeing AI come out. It's talking about the risk, the risk and fear of the AI companies taking IP, getting their data, but we're also seeing the reverse of that where developers are coming in and saying, "Hey, this is something that's helping making me more productive, especially when we're talking on the junior levels." This is something that's speeding up and helping me produce outcomes, and that's leading to shadow AI. But it's also leading to this idea of we've now got code that's being written by AI, and when it's going and getting pushed out to production, well, now if there's a bug, when we wrote the code previously, we would know where to go look, but now with AI writing it, we have no idea. How is that having an impact on how you design and look at platforms for companies? Is that a consideration?
Caleb Washburn (00:19:33):
Yeah, it's definitely a consideration. And AI and gen AI is really something that if you're embracing it, whether it's at a junior level or a senior level person embracing it, there is productivity gains, but then there is also the rapid code generation, the rapid production of new code that you know a lot less about than when you handcrafted it and you kind of knew, oh, if this error happens, I understand it's happening in this part, this subsystem. Now it's like, I may not have really reviewed every one of those lines of code. So it's bringing it into place. While it was always important, I'm seeing a lot more importance in this, making sure that your applications have a platform that is instrumented well to help you understand when things go wrong, how do you provide a very rich stream of events so that you can then also use that to feed to the AI to say, "Help me figure out how to solve these problems because now I've got another source of data that is about here's the events that have occurred in my app, here's what's happening, look at the source code for my app, look at the events for my app." So this observability capability is paramount in this world to help give more a rich data stream because having that as an extra contextual source for your AI agents and the various different things that you're using to build your applications helps you triage these applications as well faster than maybe you were able to do so before.
(00:21:03):
But without knowing what every line of code does because humans weren't handcrafting it, that feedback loop of figuring out how to solve these problems, if you don't have that rich stream is really, really painful to see, see companies figuring out how to solve problems with these capabilities they're building in days that may have taken weeks or months before. Now the troubleshooting is not minutes, it's maybe days trying to figure out what is all this stuff that we pushed to production that we didn't really understand in the first place doing, and how do we fix it now?
Nicky Pike (00:21:32):
Well, and we've got this competing priorities here because you're absolutely right. One, every company, they're wanting to improve time to market, they're wanting to improve their output, so they're putting more pressure on developers to be more productive and they're using AI to do that. And on the reverse side, we're saying, "Okay, you can do that, but you still got to know what you're writing. You still got to be cognizant of what's in there." And I don't think those two things necessarily work together. And what you described, I completely agree. You got to have observability that's built in to find the way that you're asking people to do things, but it's almost like this self-described prophecy of we use AI, right code, we don't know what the code is. Now we got to build observability and probably use AI to help us debug when things go wrong.
Caleb Washburn (00:22:15):
I think it's a scenario in which if you're using it responsibly, you're understanding what advantage it's giving you and the capabilities that you have to help you make sense of all this, that's where I'm seeing appropriate usage. It's the scenarios where you're not being responsible at all about it's generating stuff. I'm not even looking at what it's generating, by the way. I'm just like, oh, the UI that it generated, cool, looks good. I definitely think there's different approaches, and I've seen a lot of this where they're using AI to help them do the code reviews. They're using AI to help them submit security fixes and PRs and various different things. Those are great usages of this. It's the scenarios where you've got no humans that understand how these things are being used at the end of the day. That's where this is going to get interesting.
(00:23:04):
It's not that it's a problem, it's creating an opportunity that I think it's not going to replace the humans. We're going to have a major surge of we're going to write more software over the next two years than we've probably written over the previous 10 years.
(00:23:20):
And that is by more people, by different skilled people, it's opening up the opportunity for people to create and innovate on things, but it's also then creating a different set of problems that we have to think about of it's not just in a solved problem, it's creating new opportunities that we need to figure out within this industry, how do we manage this? How do we make sense of this so that we're doing things in a ... Again, we want to have things that we can deliver quickly to production, but safely and securely to production as well. So I think that's the opportunities that are ahead of us here, of how do we make sense of all this, as well as how do organizations do that in a way that they feel comfortable using the models either in a public SaaS forum that they're using today or keeping those in private environments so that they don't feel that these are being used to trade models for their competitors.
Nicky Pike (00:24:10):
Yep. Well, and I think, again, that's a self-fulfilling ... We see it all the time. Technology comes up, it solves problems. The cloud solved problems for us, but it created a whole new set of solutions that we had to go figure out. AI is solving problems for us, but it's going to create a whole new solution. And we're kind of painting a picture here of we've got these FOMO driven decisions, we've got cost traps and code nobody understands, but Momentum AI is here to actually fix this stuff. So I want to talk solutions. You're a strong advocate. You mentioned it before, platform as a product, and this is something that I'm a huge fan of as well. I feel this changes the game. So instead of just handing developers in namespace or some infrastructure, you want to help companies build something that really simplify their lives.
(00:24:50):
So walk me through what that actually means to you and how does this change the conversation that you're having with platform teams and companies when we talk platform as a product?
Caleb Washburn (00:24:59):
Yeah. So really the first tenant of platform as a product is understanding if I'm an organization that's going to build and create an internal platform for my developers, for my data scientists, for my database administrators, whatever the role is that you're providing this platform is, the first tenant is actually understand what problem they're trying to solve. Let's talk to each other. Let's have a conversation. Let's figure out how I can be a solution provider as the platform team for you, understanding the capabilities you need and then figuring out ways for me to provide those back to you in a self-service frictionless or a low friction way so that it's not just about hearing what I think you need. It's more like collaborating with you, figuring out what actually could I do that would help you deliver more business value to our organization. That's the first thing that I see for organizations that are successful with this.
(00:25:54):
It's really about trying to remove that cognitive load from my dev teams or whatever other role that I'm providing this for and pulling that into a centralized capability that then can really move the needle for my organization. The challenge with that is it means you're doing more and you're providing more value for your organization, not just service turnup of a Kubernetes cluster, for instance. That's something that cloud providers do today for you. And if that's really all you're doing as part of your cloud platform, you're really missing the mark on what it means to provide capabilities to your organization.
Nicky Pike (00:26:25):
See, I'm smiling here because you're getting back to let's start talking about outcome-driven decisions again and not vendor-specific, not technology-specific decisions. And I think this is something that's gotten lost as we're watching the AI bubble kind of grow and we're seeing all of this just in rush of products and new technologies or reused technologies come in. People are forgetting about the outcomes. They're just looking for the next product that's going to help them, but they're not thinking about what they want to do. I love that approach.
Caleb Washburn (00:26:54):
Yeah. And as you start having these conversations, it should really be focused on, let me understand what it takes for you as a developer or you as whatever role you're interacting with. The minute you commit code, what is all of the steps today that you have to go through to get that to your end user within a production environment? Let's understand, let's map that out. Let's do that value stream mapping. Let's understand your golden path to production, and then let's figure out ways that we can start to say, what if I took that away from you? If I provided it in this way, would that make your life easier? And that's not, I've created a bunch of forms that you can fill out and then I've given you a script that automates creating those forms out. It's how do I do this in a way that is a delightful experience for you as my consumer treating my developers as an internal consumer of the product that I'm passionate about that I want to provide a great experience for like I'm running this as a business.
(00:27:53):
That's really what we're talking about is if you were doing this and trying to sell this to somebody, would you do this in a way that makes it super difficult for them to use or would you do this in a way that makes it delightful? If you were launching a business and you made it super hard to order things off the menu, would you actually have customers? The reality is a lot of these organizations have customers only because there's no one else that they can use. They're beholden to, you have to use these capabilities because it's our organizational policy. If you thought about this and flipped it on its ear a little bit to say, if my developers could use any capability they wanted to, would they pick me or some other solution? And that's where public cloud has really created this interesting with shadow public cloud initially because a lot of organizations were saying, "My developers aren't asking me to do anything anymore.
(00:28:42):
They must be happy." No, they actually are just doing everything in public cloud. You just didn't know it yet. And now they're trying to figure out how to get that, wrangle that back under control. And what will happen with any innovation, you'll see this happen and then once the machine starts to get ahold of it, it will then make public cloud hard to use. Same thing we're going to see with AI. AI is, "Whoa, it's really easy to use." Oh, until you realize that I'm sending a lot of information out, now we're going to put controls in place. It's going to make that hard to use again. But instead of making it hard to use, what we should be doing for these organizations is let's make the thing we want you to do easy. Let's make other things possible, but difficult. Let's make the right thing easy to do.
(00:29:25):
I tend to have a statement of developers are like water. They flow to the path of least resistance. If you make things easy to flow to the path of least resistant, the right thing, it's amazing the velocity you will start to see within your organization where developers or whatever role, again, and we talk about developers a lot, if they're your biggest champion, then it is easy to get people to adopt the thing. When they are your biggest detractor, then it is very difficult to get adoption within an organization and get that momentum flowing in a way that It's positive.
Nicky Pike (00:30:01):
I agree with that, but also I come from a platform engineering background and it sounds kind of like what you're talking about here is a good division of responsibilities when you talk about building a platform. And you use this phrase below the waterline. So when we're talking developers, there's stuff developers shouldn't have to see. They shouldn't have to see TLS, termination, load balancing, service mesh. I think the same thing applies for platform teams. They should be able to deal with the infrastructure. They should have to worry about what the application is, what stack it's running, any of that nature. They build a platform that the developers can use and it should be easy for both sides because even if the developers love it, if it's a nightmare for platform engineers, it's going to be hard to adopt as well. So are you advocating for that kind of split responsibility and what do you think each experience should be, both the platform engineer and the developer's experience when you deploy an application into a platform that's well designed?
Caleb Washburn (00:30:52):
Yeah, I definitely think it's a collaboration. It is understanding what each side of this arrangement need and what they're doing to be successful so that you can focus on your area of expertise and provide the best possible solution for your organization. So yeah, it's not just as a platform team, I just do whatever the dev teams want because I'm beholden to them and I'm just trying to make their lives easier. It is also making sure we're having conversations to say, let me better understand how you're building those applications so that as I'm designing these capabilities for you, I have a better idea of what would make my life easier to help you maintain that and what would make your life easier as a consumer of these environments as well. It all comes back down to sitting down, having conversations and understanding the needs and having empathy for each other.
(00:31:45):
I do find that within organizations that anytime you have an opportunity to have people that are in a platform team, go sit on the other side and be a consumer of the platform they've built, as well as have developers take some time and rotate into the platform team. Building a shared set of empathy for each other is amazing how much you start to better understand what the challenges of each side of that coin have to deal with because you can sit in meetings and talk about it, but at the end of the day, I find organizations that allow for that moving in and out of each side of that side of that arrangement, build stronger platforms, stronger relationships, and have really a better set of solutions that they deliver for their organization. So
Nicky Pike (00:32:29):
That old adage that engineers should have to go work on the cars they build or the machines that they create, right?
Caleb Washburn (00:32:34):
Yep.
Nicky Pike (00:32:35):
I 100% agree with that. Well, we've been through this before. Both of us, big history of cloud foundry, Kubernetes, now we're seeing AI. Every time we see a new shiny technology, there becomes this question of, do we buy or do we build? And you mentioned the spectrum, right? When we were talking at prep, you talked about on one end, you've got things like Cloud Run, which is deploy and forget. And then you've got entire custom platforms that are built on Kubernetes or on Cloud Foundry. What do you think? What are the questions that you asked to help determine where a company should land and how do you help them make that decision?
Caleb Washburn (00:33:11):
It's really trying to better understand the organization. What are the skills of the individuals? Where do they want to be in the future? Do they want to diversify themselves out of maintaining and running a proprietary solution? Do they want to have adopt a more vendor provided solution? What are the trade-offs of that set of conversations? That means potentially you've got a lock-in scenario that you need to better understand versus the other side of it is, "Hey, if we build this thing, we have no lock-in except for the people. " That's a really hard lock-in problem when you've got, you're dependent on three or four key individuals that have built this really great experience that's different than being locked into a particular cloud or a particular vendor product. So it really is about trying to do an overall assessment and an understanding of what are the outcomes you're trying to drive?
(00:34:01):
Where are you at today? Where do you want to be in the next year? Where do you want to be in the future? And then charting a course to do that. Again, there's not a one size fits all solution for this. It's all about figuring out what is the right tool, the right solution for you to get from where you are today to a better place tomorrow, and then positioning you for the right thing in the future. And then being nimble enough to understand that you can chart a course. We've created a five-year roadmap to get here. If you created a five-year roadmap two years ago, I guarantee that five-year roadmap doesn't apply anymore. Things change way quicker than what you believe that they are going to. So being able to adapt to the wins change, the tides change, things change in the industry that we're in faster than they ever have before.
(00:34:49):
So being able to be okay with the fact that you don't know what's going to happen tomorrow, let's make sure we're adapting and being best informed based on the results we're getting today and figuring out, is this course the right course still for us today?
Nicky Pike (00:35:02):
You're absolutely right. I always get cracked up when people say, "Well, here's our five-year plan," because that's not going to survive the next technology that comes out. And especially in the AI age, things are changing on a weekly basis, definitely on a monthly. So how do you keep up? And again, there's a little bit of sage to this, but how do you build an infrastructure that can accommodate those changes and allow you to pivot? And it's got to be something that is modular that's pluggable because new technologies come out, you're going to want to adopt them. And how does Momentum look at that? How do you build something that can accommodate the unknown?
Caleb Washburn (00:35:37):
Again, back to these first principles of we want to make sure that we're building flexible solutions. We want to do as many things as we can with technologies and approaches like infrastructure as code where, again, it's something that's sustainable. But the biggest thing that we advocate for is we've got to invest in the people. With any organizational charter, if you don't have the people to execute it, it's going to fall down. Investing in the people and being nimble enough to be able to understand where the wins are going, understand how to make the changes in that. We're big in enabling people. So as a consulting group, we bring forward a lot of this pivotal heritage with us that is we're pairing, we're all about trying to do knowledge transfer. We're trying to build and take the experiences we've have and build that knowledge into your organization as we work with you.
(00:36:28):
Because with that, you have the ability, you have a fighting chance, I would say, of being able to pivot when the technology changes and just assume that is going to be something that is going to happen. The only constant is change right now. Change is happening. And if you don't have the people that can adapt and react and help you navigate through these constantly changing world that we're in, you can have the greatest plan in the world, but it likely is going to be out of date the minute you write it down if you don't have the people to help you change that plan as appropriate.
Nicky Pike (00:37:02):
So let me challenge you on that a little bit because I'm not saying I disagree. In fact, I totally agree, but the people aspect seems to go in direct contradiction with what we're hearing a lot of big companies say, which is we're going to be able to fire everybody because of AI. Now, I personally believe that's more PR than reality, but what's your answer back? You got a lot of developers. You got even infrastructure people now that are starting to get worried about AI being able to take over some of their skillset and you are advocating that it has to be the people first. What's your take on some of this stuff that we're seeing out in the news today?
Caleb Washburn (00:37:33):
I think organizations that understand and enable their people to take advantage of these technologies so they're more productive doing the things that they were doing today means yeah, they'll be able to accomplish more than they maybe were able to do historically. Will it lend itself to less people? I don't know. Will it lend itself to people doing different work? Absolutely. I absolutely think that it's going to change what it means today for your job and what it means tomorrow for your job and having people that are able to adapt and react to using these technologies to be more productive is going to drastically improve or drastically increase the amount of things that we're trying to push through from a velocity of change, velocity of new applications. And if you have those first principles of we're able to do change quickly because we've built the platform, we have platforms that can help us do that, then you're going to feel really good.
(00:38:31):
When you don't have your hands around all these things you're pushing out into an environment today, that's where you're going to have a lot of chaos inside these environments, which then you're going to see it become constrained and you're going to see things are going to slow down the rate of change, which then the interesting thing that typically happens with that is you have dissatisfied people because they want to do more. People want to deliver good value for their organization they work for. Let's make it easy for them to do that for you. And when they do that, they achieve a lot more satisfaction out of their day-to-day job and they're a lot more willing to adapt and react to being asked to do a different role in the organization because they feel like it's the right thing for them. It's the right thing for the organization they work for.
(00:39:15):
So I definitely think that there's going to be a lot less of humans sitting down, typing keystrokes into IDEs to solve computing problems. Now it's more, how am I working with an assistant that is a computer to help me write code? So it's a different pairing model that I see as a successful model going forward and it's a skill. Prompt engineering, how you prompt something, how you redirect the assistant is no different than how you worked with a junior or an intern as a senior person, directing them to write really elegant, efficient code, and then correcting them when they're doing things that are not in the pattern set that you would expect to for your organization. And you still want to create maintainable things. I don't think you just want to have it generate a bunch of stuff that is ... At that point in time, I'm like, why aren't we just writing in an assembler?
(00:40:05):
If we're never going to look at the code, we ideally are going to have to look at it and debug it because we're not to that point where we really are fully trusting that is just going to do the right thing for me all the time, every time. So it's definitely a different paradigm that you're going to see people working through this over the next 18 plus months. It's started already for organizations that are adopting these technologies.
Nicky Pike (00:40:28):
Well, and you bring up, and we're going to kind of back it up a little bit here because we've been talking a lot about change. And I think this brings to mind two questions that we've got. We talk a lot about keeping up with change the ability to pivot, but you've got to be careful not to do change for change spake. And this is something that you actually talked about. I heard you talk about this one time when it comes to data. There's this assumption that modernization means that we've got to move everything to relational databases, but you said that's absolutely wrong. If your data's lived in VSAM or flat files for decades, maybe it should go to NoSQL or something to that, not Postgres. So there seems to be this duality here. We've got to be able to incorporate and adopt change, but you've got to be able to know when not to do change and keep things the way they are and kind of stay with the status quo.
(00:41:15):
How should companies be thinking about this, especially with like data modernization and AI around what they're doing with their applications and their infrastructure? Yeah.
Caleb Washburn (00:41:25):
It comes back to that same principle of the right solution for the right job. I may want to make it a simpler than it needs to be, but again, we want to make it easy to do the things we want you to do. Let's look at that and say, if this data was able to live in a world where it was key value-based access, why do we need to make it relational right? It might mean that we should have done it a long time ago. So let's not just say it should never happen, but if it was good enough for this for the past N number of years, maybe it's good enough now to keep it in a key value-based access model because that's the easiest way to get it migrated today. And then eventually maybe we look at it later after we do that initial step of modernization to move it to a different technology to help us access that data.
(00:42:13):
Over time, maybe it's harder because we can't use it in a way that is reasonable for us to access the data, it's becoming a problem there, but likely the answer's going to be, it was good enough then, it's probably going to be good enough tomorrow to have it. So organizations that are like, we've adopted Postgres and everything is going to be in a relational database. You can do it. I'm not going to say that that's not something you can't do. The question is, why are you being so stringent about this is the only way to solve this problem when in fact it's about having a number of solutions, but finding that right balance of not having so many that you're unguided. The decision tree has 900 if statements that you're walking through to figure out the right thing. It's probably more than one, but it's probably less than 10 that you need to think through as you're thinking through this.
(00:43:07):
And same thing with languages, same things with ... I see organizations and it's like, the only thing we write code in is this language. Maybe that's good, maybe it's not good. Maybe we should have a ... If you're doing this type of workload, this is the right technology or the right language to write this in. If you're having this data and it has these characteristics, maybe it's the right solution to have that and where it's a simplified detree that you're working through. But again, it's about finding the right tool for the right job.
Nicky Pike (00:43:31):
Well, and I think there may also be this perception that we're changing things to fit with the new technologies. AI is a great one. Vector databases, we've got to put everything in vector so that AI can use it. And we are 100% seen that people are wanting to do this, to bringing AI in. And you talked about that you've got customers that are wanting to come in and build their own models because they're worried about IP theft or they're worried about data loss. And we're seeing Google and Meta, they're offering these huge seven and eight figure bonuses to people that can do this work. But you mentioned the alternatives. There's Bedrock, there's Fertex, there's using Ragged Embeddings. In your opinion, and I have a feeling, because I'm starting to notice a theme here, Caleb, that it depends, but what do you think the right AI strategy from a data perspective is for companies that don't have the pocketbook at Google?
Caleb Washburn (00:44:18):
Yeah, I mean, I think there's the 1%s, the form doesn't fit them. They've got the budgets, they're going to figure out how to manage this. It's competitive for them to have data scientists to have the folks that are building these models and that experience. And then there's the rest of us that are figuring out what's the right solution for me to leverage these capabilities with the minimal amount of the maximum amount of reuse of that investment of building these purpose-based models that are either open source models that I can run. They're models that are provided by these vendors that are heavily investing in these purpose-based models and figuring out what the right solution for that. You can definitely accomplish a lot of this with RAG and embedding data and having that context shared with these models versus building these models yourself. It's amazing how good the models have gotten because of the amount of adoption that they've seen and the ability to use that to help them train and build these very purpose-based models.
(00:45:20):
There's a lot of stuff around even just models that you can run locally, just how much they've improved over being able to do voice to text detection for local models that was before it was like, yeah, it kind of got what I was saying, but it wasn't ... They're really very good now for the ability to do that. And so that innovation is being distributed down into something that you can just leverage things that already exist. You don't have to create your own.
Nicky Pike (00:45:46):
Yep. Use the right tool, the right model, use the right thing for what you're trying to do.
Caleb Washburn (00:45:50):
Yep. Again, don't mean to keep it as simple as that, but a lot of times it's just as simple as that. Let's understand what's available to us. We're at the height right now of we have choice, we have options, we have solutions that we can bring in and understand how to do that. Let's figure out what the right solution is for the problem we're trying to solve. And everything doesn't have to be what everybody else is doing. I can get people with these skills. I can entice people to stay because these are the skills that they want to enhance and want to work with, but there's times where if you're the only one doing something in a certain way, maybe you should question what you're doing. For the 1% that doesn't apply because they're the ones that are going to drive a lot of innovation in this space.
(00:46:32):
But for most organizations, you want to figure out what the right solution is and to try and understand what other companies are doing. But at the same time, not just say, "Well, everyone's doing Kubernetes, so I should be doing 3%." Well, you should probably be doing something with a container platform. That's a fair assessment. What is the right container platform for what you're trying to do today? I think that's where you need to really evaluate that and evaluate where you're at as an organization.
Nicky Pike (00:46:58):
Yep, I agree. And we've talked frameworks, we've talked platforms, we talked AI, all this stuff looks good on a whiteboard, right? But our listeners, they're platform engineers, they're developers, there's leaders who are just trying to make this work when they come into the office. So I want to get a little bit practical. And you talked about containerization there. And I want to dig into that because I want to look at the skills gap that we talked about earlier. 75% of organizations site skill shortage as their main obstacle to Kubernetes. Now, you favor this crawl, walk, run approach. You start with VMs, progress to containers, and then Kubernetes when you're ready. How do you help companies build that progression? What do you do to have them not skip steps and especially get prepared for things that they're not ready for today?
Caleb Washburn (00:47:39):
It is really about evaluating what their portfolio is today. How do they have their apps deployed? While it is more cumbersome to do, you can do the idea of immutable VMs. Instead of every time I deploy a new version of my app, I get to new VM, I'm laying down that infrastructure, I'm doing that thing as I'm not really ready to adopt containers. This is probably more a technique of five-ish years ago. Now containers are fairly prolific. Container runtimes are fairly prolific within the industry. Whether you're a VMware shop, there's a built-in container run time now, there's also various different container orchestrators that you can still run on premise and public clouds all have them. But then you have to not understand, all right, so building a container, fairly wide skillset there that is available. People are understanding more how I use Docker, how I build these containers, that has progressed significantly.
(00:48:31):
Now, where do I want to run that container? What's the capabilities that I need? And that's where I see a lot of organizations, if they don't really need a lot of additional capabilities and they just want to say, "I need this container to be scheduled and ran and provide me an HTBS URL to my application," then maybe the right solution is one of these more opinionated container orchestration solutions, whether it's Google Run, whether it's AWS or Azure equivalents or even some of these other solutions out there in the industry, whether it's a cloud foundry based thing that runs containers as well, or you've got even some SaaS services like Fly.io and other things that are ... We'll take your container and schedule it and run your application just fine. Now, when you need to do more advanced things or you want to have more control over what that orchestration, then you're investing in likely using a Kubernetes-based substrate and figuring out how you want to manage all that, how you want to do that.
(00:49:26):
But then that's where as a platform team, you want to bring that responsibility and understanding so that your developers can have that cloud run-like capability
(00:49:36):
Without having to understand all the things that are underneath the covers.
Nicky Pike (00:49:39):
Well, and there's a cost consideration to this as well. I mean, when you start looking at things like individual development environments, those things may be better served by being on VMs. It doesn't mean they can't be ephemeral. It doesn't mean you can't turn them off and on, but maybe an EC2 instance or something like that works better in that instance. But if you've got something that's spinning up quickly and dying quickly, maybe it's a Kubernetes. Again, I'm going to pair it Caleb here and say, you got to use the right tool for the job. You got to look at the entire infrastructure and what you're trying to accomplish, not just trying to do that. And I imagine that when you go in and talk with customers, that cost is a huge component of what you're doing and how you're going to structure this. I think you told a story about how you went in with a customer and they just did turning off VMs at night and it was like one third or two thirds of their cost went down.
(00:50:25):
So how much does cost come into this? Should it be a first priority or is this a second or third priority?
Caleb Washburn (00:50:32):
It's interesting on what level of priority it is. There are ways that even without containers, you can still manage the cost profile of things within the environments that you have. Containers are a way to have a lot more dense workloads running on fewer physical hosts, fewer virtual hosts. And again, it's the next level of compacting things, but then there's obviously workloads that just aren't a great, as good a fit for containers. It comes back to the conversation that we had about Coder. You can run coder workspaces on a VM and you can run them on a Kubernetes pod. Finding that for organizations that are doing a lot of things where that they're trying to replace the dev laptop with an experience, the virtual machine gives them quite a rich experience with Coder. Whereas the Kubernetes, now I'm having to deal with maybe my pods are being rescheduled during the day because things are happening and I'm not running multiple Kubernetes pods that represent my workspace.
(00:51:28):
So maybe that's not as great of a fit because now I have the trade-off of instability for cost because the cost is cheaper because it's denser, but now I have a little bit of a trade-off because this is a type of pod that I can only run a single instance of because of just the nature of that workload where the fit for running things in Kubernetes is being able to have at least two instances of things and have things like leveraging the load balancing capability, the pod disruption budgets, all those things. If you got workloads that are not really set up to be able to run as non-singleton workloads, then you're probably still better off running those on a VM because that's the right way to solve that problem. But it doesn't mean the cost has to be dramatically different because you can still look at that workload.
(00:52:12):
You can still understand, is that workload a 24 by seven steady state workload or is that a spiky workload that's used for a couple hours and then it turns off? Putting those policies in place to help you manage the cost and turn those services down, but then quickly be able to resurrect those services as you need them is still ways that other workloads work that way, i.e. Serverless in the cloud, they're still running on servers, but it's treated like serverless because you don't know what server it's running on at any given point. So yeah, it's finding the right solution for the right cost profile for the workload that you have, but also not trying to chase the money because I've seen organizations have things that are, they are pretty steady state workloads and then they want to put them into technologies where they scale to zero when there's never really a scale to zero problem.
(00:52:59):
And so then you're having the complexity of the ability to scale to zero when this is really ever, never going to scale zero.
Nicky Pike (00:53:06):
Yep. And we go back to that observability story as well, especially when we start talking with AI. So we've got to be able to go in and anticipate and look for things that may not have been written by humans where humans may not know where it is. What are you thinking the teams should be investing in right now to prepare for that? Because AI's coming to companies, there's no stopping it. What are the investments that they should be looking at to prepare?
Caleb Washburn (00:53:28):
It really is about ensuring things that are running in your data center, things that are running in your cloud environment have an observability street. Leveraging the power of AI, AI is really good at making its way through lots of data quickly and finding anomalies, finding patterns, finding other things. But if you don't have that rich stream of data, you're missing out on the opportunity to leverage and feed that to something that can give you insights that maybe you didn't really realize because in a large data center, lots of workloads, lots of applications, there's lots of events that are probably being put into logs that if you aren't really able to take that and look across and look for common patterns and anomalies, you're missing out an opportunity to make cost enhancements, security enhancements, bug enhancements, whatever those things are that are happening without that rich stream of data, especially if it's applications that you aren't really 100% sure they're written in a secure performant way, this is going to be way more important going forward.
Nicky Pike (00:54:34):
Absolutely agree. All right, so I'm going to ask you one more question before we get into the predictions. Now this one I'm going to ask you to be specific on because like I said, I've noticed a theme here of it really depends and I know that's true, but I'm going to ask you to try to be specific. We've talked about the FOMO, we've talked about cost traps and skills gaps. What's the momentum AI checklist? Before a company makes a platform decision, be it Kubernetes, Cloud Run, Cloud Foundry, whatever that may be, what criteria should they meet? What are the questions that they should be able to answer yes to that they need to change and look for a new platform?
Caleb Washburn (00:55:05):
When looking for a new platform, the first thing that we talk to companies about is, do you have the skills to run it yourself? Are you willing to invest in the skills to run it yourself if you don't have those skills? If not, let's figure out the least path for you to do that, which is let's buy that capability, let's leverage an existing solution to solve that problem for you, and then let's make sure that you're pivoting your platform team from providing it to advocating on how developers can use this new platform that they've procured, whether it's Cloud Runner or other things. So it's really about the people, it's really about understanding the capabilities. And are you committed to investing in either retaining those people or stealing those people up if you're going to invest in building your platform yourself?
Nicky Pike (00:55:47):
Gotcha. All right. Well, here's the prediction time. So we do this, we end everything with the predictions, so it's time to put your reputation on the line here, buddy. So there's this assumption that AI is going to replace developers, but you see it differently. And you had mentioned earlier that you think we're going to see more software generated the next nine months than we've probably seen in the last three to five, 10 years. And it's not going to be engineers doing it. We've got business people, we've got domain experts, people that have never written code, all building with AI as their partner. Walk me through that future that you see. What does it look like and should we be excited or should we be hesitant?
Caleb Washburn (00:56:20):
I think we should be excited. And I think it will be that engineers will still be writing software. They will be writing software differently and now there's more people that are going to be able to help them write that software, help them contribute to that software, whether that's the non-technical roles using vibe coding techniques and other techniques within the organization. So we're going to see a huge uprise in the amount of software created. The quality of software, I think is going to get better as well. I mean, we'll get modern. We have a huge problem in this industry that we have a lot of software that is out of date, running mission critical, and it's out of date on modern software stacks. You look at Spring Boot and all the organizations built tons of spring applications over the last 10 years. I would gather that a lot of them are running on applications that have security vulnerabilities, have a lot of things that they need to fix and address.
(00:57:10):
So I think it's a great opportunity for us to understand how to embrace the technology, understand how to use it safely, securely, and responsibly. I don't think it's going to replace us. I think it's going to make us more productive, make our jobs more enjoyable, and we should be about understanding how to do that in a way that gets us great outcomes for the companies we work for.
Nicky Pike (00:57:29):
It's shocking when you look, especially when you start talking about like Spring and Java, how many companies out there are still running Java eight applications and not getting updated because those applications seem to be working fine, but they're not looking at all the security risks and things that come with that. So on that last question, here's your hot seat question. So you mentioned vibe coding. I think vibe coding and citizen development has got a lot of negative reputation right now, but you're seeing something different in enterprise. We're seeing where enterprises are actually looking to enable some of their non-technical people to be able to write tools for themselves. So give me your most controversial take on AI and development, something that might get you boomed off stage at the DevOps conference.
Caleb Washburn (00:58:08):
Oh, most interesting take on vibe coding. The take is it's not going to replace the engineer. It's not going to replace the seasoned person. It is going to change the way we work. I definitely think that like everything, it is something that if you embrace it, there's opportunity there. The thing that get booed off of stage. Oh boy. Probably the fact that these models are just going to get better and they're not going to get worse. The amount of improvement I've seen over the last six months is drastic to drastic improvements there. I don't know that there's a real hot take on this because I'm embracing it and I understand that we need to embrace it. I don't know. That's a good question, Nicky.
Nicky Pike (00:58:50):
I don't know. I think that is a hot take, the fact that you're embracing it and that you think we would, because there's a lot of discussion. You looked on LinkedIn, the professional development environments are saying, "Well, this is horrible, right? Nobody should be doing this. " It's DIY and home repair all over again. I
Caleb Washburn (00:59:06):
Think- Yeah, I definitely was super skeptical before I started rolling up my sleeves, looking at it, seeing what it's doing, the initial set of models. It's like, "Oh, this is kind of cool. I guess it's interesting." And then the more you understand how to interact with it, the more you embrace it as a first class kind of way you work, it is very powerful in the way that it works. And it really has changed, I think, the way I think about information gathering. I think about how I can prompt something to go fetch me a bunch of information and not tell me the answer, but give me research and insights into, how should I think about solving this problem? So it's definitely the new Google for me. Googling the appropriate way to solve a problem was a skill. I think prompting the way to have these engines, these models go I'll collect a bunch of information quickly, present it in a way that I can think through and still use that area between my ears and think about how to solve problems with it, I think is a very, very powerful skill that if you're not thinking about how to do that in your day-to-day and you're putting your head in the sand, it's going to pass you by.
Nicky Pike (01:00:15):
Yep. I liken it to the fact that it's Google and YouTube all rolled into one. Now I can get the answers I need and have it show me a way to do it. Doesn't mean it's right, doesn't mean it's the perfect way, but it's a way. Yep.
Caleb Washburn (01:00:28):
But validate it.
Nicky Pike (01:00:29):
It is a way.
Caleb Washburn (01:00:31):
You can fall into a trap really quickly where you're using it and you're accepting it as the source of truth and it will continue to double down at times and say, "No, no, no, this is the way it works." And you're like, "No, no, no. Here's another source of information. Please reconcile this with your recommendations." It's like, "Oh, you're all right, sir. Thank you for correcting me. " I think you have to, again, that's the using it responsibly, understanding it and trusting your gut that maybe if there's answers it's giving you that don't feel right, continue to question it, continue to derive through figuring out how you can better have it refined the things that you're looking for. And at times it means starting a new conversation and saying, "Am I getting the same answers that I was getting before?" Because a lot of times you'll get a different answer that depends on how you prompt it the way you through.
Nicky Pike (01:01:16):
Yep. And I don't see any difference. I mean, everybody knows I've got a man crush on Caleb Washburn, but when Caleb tells me something, I trust what he tells me, but I still validate it. Why is it any different with AI than it would be a person? Yep. All right, buddy. Well, this is where we're going to end it. Real quick, where can people find Momentum AI? You
Caleb Washburn (01:01:34):
Can find us on We Are MomentumAI. Momentum.ai is our website. Long website name. Find us on LinkedIn, connect with me. We're out there. We're gathering a team. We're getting the band back together. We're building our organization out and then really just looking to make sure that we can work with like- minded folks and either on our team or folks that want to bring us into your organization and have us help you kind of move things forward.
Nicky Pike (01:01:57):
Perfect. Well, we'll make sure we get the links in there or people can reach out to you. It's okay if we put your LinkedIn link out there if people don't reach out that way. Absolutely. So we'll make sure that's in the show notes below. And last question is, Caleb, can we consider you a full-fledged member of the [Dev]olution now?
Caleb Washburn (01:02:12):
Absolutely. Absolutely. Thanks for having me and it's been fun.
Nicky Pike (01:02:15):
All right. Well, we'll talk to you again soon. Thanks everybody.
Caleb Washburn (01:02:18):
All right. See you now. Cheers.
Nicky Pike (01:02:21):
Thank you for listening to [Dev]olution. If you've got something to show off, let me know. You can message me, Nicky Pike on LinkedIn or join our Discord community and drop it there. And seriously, don't forget to subscribe. You do not want to miss what's next.