Subscribe
Share
Share
Embed
Candid conversations with the builders shaping the future of engineering.
Braintrust dives into the operational realities of running high-performing engineering organizations, from production readiness and migrations to AI adoption and operational excellence.
Hosted by Ganesh Datta, CTO & Co-founder of Cortex
Kaspar von Grünberg:
You first have to prove this, right, with customer zero. Platform engineering is almost like building a startup. Really build something for a small team that's 10X better than what they have right now. And then that word of mouth, and I've seen that play out so often, that word of mouth and that game changing experience will mean that your user account will absolutely explode.
Ganesh Datta:
You're listening to Braintrust by Cortex, where we explore how engineering leaders blend AI, platforms, and culture to build high-performing software teams. I'm your host, Ganesh Datta, CTO and co-founder of Cortex, an internal developer portal designed to help engineering teams ship reliable software faster with AI. In each episode, we go deep with CTOs, VPs of engineering, and technical leaders who've been in the trenches, navigating the tension between speed and quality, building reliability at scale, and figuring out how to lead through major platform shifts. Whether you're running a team of 10 or 1,000, this is your space to learn from people who've made the hard calls and live to talk about it. Hey, welcome to the podcast. I'm Ganesh, one of the co-founders and CTO of Cortex.
Kaspar von Grünberg:
And I'm Kaspar, and I'm the CEO and co-founder of Humanitec.
Ganesh Datta:
Excited to have you. For our listeners who don't know Kaspar, he's one of the gurus of platform engineering. So, very excited to have him on, talk all things platforms, the scary stories of platforms gone wrong, the success stories. And obviously, we'll talk a little bit about how it's transformed in an AI first world. Very briefly, you want to give us a little bit of background on yourself and Humanitec. How did you end up becoming this platform guru in the first place?
Kaspar von Grünberg:
That's a big word. Well, I've been doing platform engineering for a scary long time, always been working and leading engineering teams. And at some point you have to notice that, let's call it the artisanal way of designing stuff where everything's all over the place and everybody has access to every Amazon account and you essentially YOLO work your way through your day. Doesn't scale to a certain extent, but if you want to take things to the next step, you work at scale. And my perspective has always been an enterprise perspective. You need to think about, how do you actually do that? How do you think about standardization? How do you think about abstraction? How do you think about abstraction without limiting creative freedom? If you want to put it like this, right, we're still knowledge workers.
And so over a long period of time I've just observed that problem with what I would call the artisanal setup, and always tried to find answers to that when I was on the side of managing the engineering team. At some point, this became so much of a passion for me that I said, okay, well, I'm going to dedicate my life to thinking about, how can you culturally approach this? How can you technically approach this? And that's what I'm doing today. I've been thinking a lot about the necessary cultural change and organizational innovation on the one hand, and on the other hand, the technical bits. And with Humanitec, for instance, we are thinking about the backend side of platforms, so to speak. We are building an orchestrator, which is a rules engine that allows platform engineers to codify paths and say...
I mean, just recorded a trial test set up where I use Cortex, and I'm a big fan of what you're building at Cortex. And I used your score carding functionality, for instance, to detect, hey, there's an AWS, oversized AWS RDS database. And then give the platform engineering team a single button that can call the backend and say, hey, remediate this for me. Automatically make sure all my AWS RDS instances are right sized and I can save a lot of money. So this is sort of this backend logic handling component that allows you to do that heavy lifting. And yeah, it's like I've never been able to get away from platform engineering again, and this is what I'm spending all my day on.
Ganesh Datta:
I love the description of the artisanal approach, I don't think I've heard that one before, but I think it really captures the kind of craziness of people doing their own thing. I want to touch on that a little bit more. You mentioned standardization and a couple other things, even the example you just gave was around right sizing Postgres databases. A misconception a lot of people have is that building out these kind of platforms is a developer experience problem. And I think that's part of it, but I think there's so much more value. In your experience, what is the reason that people should be investing in these platforms? I don't think it's just developer experience, or am I wrong about that?
Kaspar von Grünberg:
Well, funny parallel that I thought about a couple days ago, and maybe let's take that. If we would go back all the way to 1907 and we would zoom into Detroit, and we would see an artisanal workshop where some guys are building a car in a 100-hour fight between one man and his machines, then we would be seeing such an artisanal workshop. And we would probably be looking at a human that's super proud of what they're doing, super happy, and has been... That's the thing that makes them the legend they are in their communities. And that's good for them, fantastic. I don't want to question that. But this approach has a ton of downsides and external effects, not for that individual, because that's what they've been doing all their lives.
But for the consumer, because they are getting a car that's not super standardized and it will have a lot of maintenance and Cloudflare outages. And for the organization, there's a low degree of standardization, there is no structure, there's a lot of tribal knowledge in the hand of single individuals. My epithetic moment that drove me closer and closer to what's platform engineering is when a DevOps engineer came to me and said, "Hey, Kaspar, can you double my salary?" And I said, that's usually the point where I say, "I'm not sure we should continue working together." And then my CTO said, "Hey, we have to double the salary. We were completely dependent on this guy to deploy." Driving again the parallel to Detroit. What then actually happened in 1908 is that Ford went in and said, hmm, I don't think that this makes sense.
Let's think about standardization, let's think about abstraction, let's think about, and as probably the most important sentence, let's think about a way of thinking about the systemic process along the value chain, the process of building something as a product. We're not only thinking about the car as a product/the software, we are thinking about how can we make the process of crafting that product, the value stream, assisted by a product itself. And that product in Ford's world is the factory, that product in the software world is the platform. And this platform, yeah, it makes workflows easier for the users. But first and foremost, it solves the external effect problem of tribal knowledge, standardization, abstraction promises, highly structured things.
Now, this analogy and power falls apart a little bit because obviously we do not want to treat knowledge workers like factory workers, right, under no circumstances would we ever want to do that. And that makes platform engineering all the more complex because we can't just go in and say, my friend, you're doing exactly that. We want to contain that creative energy, we want to, especially in the age of AI, yield the full potential of the human creativity and brain power. And so we need to build platforms that assist humans alongside the value stream. They take the heavy lifting, they drive the synthesization, they remove the external effects on the organization, while still allowing developers to bring their full potential and build amazing and very creative things.
Ganesh Datta:
Yeah, that makes a lot of sense. I did an episode recently with Tyler Davis from Canva, and we're talking about internal tools and build versus buy. And one of the takeaways, and this is not a surprise to anybody, but you generally don't want to build things that are now your core competency. If Cortex is in the business of building developer portals, we're not in the business of building clouds or CRMs or whatnot. And so we focus on the things that we're good at. And you can kind of extend that analogy internally, which is most of your teams should not be experts in building out a platform or managing AWS accounts or setting up the right guardrails for themselves, their innovation is everything else, is the product delivery on the other side. And so you can kind of think about the same thing internally where you have your platform teams building out the platform, that's their core competency, and the rest of them are focused on, quote-unquote, product innovation.
So I think that makes a lot of sense. You mentioned, like you said, we obviously don't want to treat knowledge workers like factory workers in that sense. And so part of what a platform needs to provide is that room for innovation. How exactly does it do that? Why is building on a platform different than a team going off and doing their own thing? What actually leads to the innovation within the guardrails that you mentioned?
Kaspar von Grünberg:
I think about the approach of helping people get stuff fast that assists that creative process along the value stream as essentially paths that branch out from that value stream. So what could that value stream be? Well, let's say I am a developer and the value stream is I want to have a running application all the way from scaffolding to running and production. That will be a typical value stream. Why? Because it provides an outcome to the business. At the end of that value stream, the outcome is I have that application running, it can do things for internal or external customers. Now, alongside that value stream, my users will need stuff. And so this is sort of the first, most important thing here, we are thinking about in platform engineering the consumers of our platform as users. So we are treating that platform that we're now building and spanning alongside that value stream as a product, just like Ford treated his factory as a product.
And then we think about, what are all of those things that my users will need that go beyond the thing that they are specializing on? Well, they're specializing on building fantastic React code, they're probably less specialized on making sure I'm configuring my DB micro RDS instance in a way that's not oversized and redundant and secure, et cetera. So that is sort of a clear boundary where I can set an abstraction and say, my user expresses what they need, my platform delivers that to them. And that process and structure of delivering this, that this is delivered by the platform is what I call a path. Now, I differentiate three types of paths. I differentiate the rigid paths, where I have no say. I have flexible paths and I have what I call golden paths. And that describes the degree of flexibility the user has if it comes to that operation.
I always opt for golden paths. And golden paths for me mean the user could go off the beaten path, so to speak. Let's stick with our example of the RDS database. The user could potentially write the Terraform file themselves and then do whatever they want. But it is so convenient to just use the default provided by the platform that by default they're opting and to consume that golden path, just take that beautifully sized, correctly sized RDS that they're getting with a single command by Claude Code or by tapping a button in their Cortex portal. And that is exactly what makes golden paths powerful. So the user chooses this because it is the path of least resistance. And if I'm looking at a path also from its structure, pretty simple, a path serves a request, right? So my user requests something along the value stream, I need an RDS database.
It has an interface, right, and that interface can be a portal. This interface can be Claude Code, it can be whatever, can be UMCP server. It then has what I call capabilities. So I'm not talking about tools because tools change underneath all the time. Capabilities are sort of a turner. It's the capability of vending in the right RDS database that has abstractions, it has guardrails, and it has sort of tools in the background, part of the capability. And then we run this past a policy engine probably to make sure it's actually compliant with everything that we've done alongside our governance framework. So that's sort of how a path is structured. Again, it serves a request, it has an interface, and it has capabilities. And then whatever it outputs gets policy checked and then returned as output to the user, the user is then using this alongside that value stream to slowly create the value outcome for the organization. That is how I think about platforms.
Ganesh Datta:
I love that breakdown of the different types of paths because, like you said, if you think about platform as a product, then you're trying to create the best possible product so that consumers or customers will choose that product over other things. And so golden paths are really no different than that. It's not like if you build it, they will come. If it's really great, then they will come and they will use it. And I think that distinction is really important. One of the things I think about is, especially in a large organization, how do you make that even more enticing to folks? And I think that's where platform teams can work closely with SRE or security. Because if your SRE team, for example, has a SRE readiness program and you have to go through that before you can deploy something to production, if your golden paths are already baking in those practices, now your SRE team will be saying, hey, if you want to skip my readiness program, go use that thing that the platform team built, you're going to get all this stuff for free.
And so now you have multiple teams internally who are advocating for that golden path that has been defined, so it's not just the platform team advocating for it. The other thing you mentioned that I want to make sure to double click on, is you started with a concept of business outcomes and then the experience. Correct me if I'm wrong, but I think one of the biggest failure most for platforms, if people just ignore the business outcome and they build a cool experience and they're forgetting, why did we even start this in the first place? What business outcome are we trying to deliver? And then work backwards from there.
Because any product, if you think about it as product, a product manager's goal is to align products with some sort of business metric, whether it's revenue or time spent or whatever that might be. And so platforms are no different. At the end of the day, you can only get investment for a platform if it leads to something that the business cares about. What have you seen work well? Generally speaking, what are platforms tied to? How do the best platform teams that you've worked with describe the value to the business and get that investment that they need?
Kaspar von Grünberg:
Yeah, there's so much in there that we need to unpack. I'm 100% with you. I think if you look at everybody, you could potentially serve as a platform engineering team, you could serve yourself. You hate doing A, B, C, here's what I hate, I hate ticket ops, so I'm sure you can serve yourself. That's probably the worst thing you can do. You can serve your developers, that's already great, but in itself, it's not the thing that will pay your wage in two years from now. And then you serve the business. And so if you want to build a hierarchy, you serve the business, period. If you can't show me how this will lead to tangible outcomes for the business, it's not on me to tell you, history will tell you. It's very, very simple. This initiative will lose funding very fast. Managers, enterprises are not stupid, they're looking at something and they're looking at whether there is a return or not.
And then people say like, hey, it's different to compute return on investment. Yeah, nope, it's not really difficult. If I'm looking at the best platforms out there, and one of my favorite examples is the platform at the car sharing company SIXT. I was so surprised to see that because family owned business, billions of dollars of revenue, but family owned and super slick engineering team, but I would've not expected. Now, if you just take how they reacted to corona, right, you look at all the car rental services and you look at how fast were they able to say, okay, well, there is an existential problem coming our way. Can we react from a software perspective super quick, changing our offering to more long-term rentals? We're getting the fleet on the street, all of those things. These guys reacted in days, right, completely new application, everything shipped, et cetera.
That is something that cost all of their competitors an insane amount of profits, they made a lot of losses. SIXT, they were the only ones that were still making profit. Why was that possible? Because of the platform, period. Because everything was so streamlined, so aligned, so standardized that the engineers could go in without thinking and saying, ba, ba, ba, ba, ba, ba, ba, create this, ship this. And that is sort of the power and the value that a platform provides. Platform well done absolutely has the impact that Ford had on workshops in Detroit where, 1907, it takes you 100 hours to create a car, in 1913, it takes you 93 minutes. And that is, you can absolutely, I've seen this over and over and over, if you do it well, you can absolutely get that almost 10X effect out of the productivity. And that's a game changer because we are in a very competitive world, as we all know. And speed in feature delivery and how fast you can react to the digital economy is absolutely vital, whether you're selling on Amazon or you're renting out cars.
Ganesh Datta:
It's really, at the end of the day, it's a leverage point. We're in the business of finding leverage points for us as a business, and the right platform done right can be a leverage point. And one of the things you mentioned is, don't solve just for the developers, solve for the business. Just to expand on that a little bit, I think what people forget is that if you serve the business, you do serve the developers, because part of the friction that developers face in their day-to-day is from business requirements. If your business is saying, hey, we want to deliver a secure application because we're in financial services or whatever, security can be a business outcome. That business outcome is leading to multiple layers of friction for developers. So if you solve for that business outcome and say, hey, we want to move, we want to increase velocity, but maintain a high bar for security, and that's an outcome that we care about.
Naturally creates the right developer experience because you're solving a business outcome and that's the thing slowing down developers, now those things are aligned. Those two things are not separate problems, they're actually fully connected, and I think that's really important. Going forward with the business outcome piece, I love the example that you just shared about how the right platform investment led to such a great outcome during a time that was so existential for so many businesses. Let's maybe reverse engineer that a little bit. What do you think the business outcome was when they first started building that platform at SIXT? What led to that building of that right platform that led to the right leverage points when they needed it the most? What do you think they were focused on as the business outcome?
Kaspar von Grünberg:
Well, so in that example, they have very strong, very technical management. And if I'm talking about strong from a management perspective in an engineering sense, it's almost always, do the guys that are calling the shots actually know how to use a terminal? And do they have intricate knowledge of what it feels to write software? Have they really done it? I see that everywhere, and the reaction to AI is a good example. Are they sitting around and watching YouTube videos or are they going into a terminal, they're trying Claude Code and they're just feeling it for themselves? That is a big, big difference. And I encourage everybody to get their hands dirty and just test stuff. And I think that's something that Boyan, who's the CTO there, has always been great at. Now then very clearly realized what many businesses are realizing today, this idea that we had starting, I would say in the early wave 2008, where Vana Fogles went on stage very self-confidently and said, "You build it and you run it."
Everything should be pushed to the developer, no guardrails, do whatever you want. That idea sort of makes sense if you're Amazon and you want to sell a lot of metal, that's great. This is from a marketing perspective, absolutely spot on. If you run things at scale, it doesn't work this way. It leads to hundreds of teams and developers having access to cloud accounts, doing whatever they want, creating an incredible amount of cost. Configuring, I always take this example, 500 different ways of configuring Postgres databases and staging, where I can maybe come up with four or five, and that surface area will then become super hard to maintain. Now, Boyan and team saw that very early on and just came to the right conclusion, to say it is not true that standardization and abstraction equals limited creativity. That sentence is just inherently not true.
So I spent a lot of my youth actually, a little funky, composing Baroque music. And that's something that I got into, I wasted all my youth on. If you're into composing Baroque music, then you have that incredible set of rules you have to follow. It's almost like programming, you can't have that note follow this one, and there's a lot of harmony things that you need to follow. And I had this super strict Greek composer that would teach me twice a week. And the thing that this taught me is that creativity can absolutely come from restriction. Sometimes restriction and restrictive systems can spark way more creativity than if you have just sort of a blank piece of paper in front of you and you can do whatever you want. That fundamental approach that users have to be able to do whatever they want and only then are they able to build a fantastic application to rent out cars for a long time is just not true.
And so if you come to that conclusion and to that insight, then the next thing you derive is that, well, we need to think about standardization. We need to think about where to restrict without actually limiting stuff. We need to think about governance frameworks. We need to think about silos. We don't need to be afraid of silos, silos are fantastic because they allow for specialization within teams, as long as the interfaces between them are well-designed. So SIXT and Boyan, they came to that conclusion. Another thing that I always recommend, they didn't start with a big bang, they didn't do everything at once. They started with a small team, not even the team of sophisticated high performers, just sort of that average team that was on the lowest common tech denominator. And then they built an experience, and the first paths for just that team were superb, 10X better.
And you said that beautifully before. You don't want to push people to use the platform. The platform should create a pull because it's so much better than what you have right now. And so if you start small, that's great. Now, I think the trick is to invest a little too much money into a little bit of a too small team. Does that make sense? You shouldn't take a couple million and say, bam, initiative, make sure the platform is there in a year. You should say, hey, here's sort of 100K, couple 100K, let's allocate that on one team so that we'll all feel a little uncomfortable because it's such a small scale for the hundreds of developers we have. But you first have to prove this, right, with customer zero. Platform engineering is almost like building a startup. Really build something for a small team that's 10X better than what they have right now.
And then that word of mouth, and I've seen that play out so often, that word of mouth and that game changing experience will mean that your user account will absolutely explode. You will need to gain access to the platform and slow them down because so many people want to onboard. And you can master this, but you can only master this if you don't do too much at once.
Ganesh Datta:
It's so important. I wish I could scream that lesson from the rooftops and the mountaintops. The number of times you see people who think, oh, a platform has to be everything, everything to everyone all at once. It's going to be a six-year initiative and eventually we'll launch it. And obviously it's a failure when you launch it six years later, or you lose funding along the way. Starting with one very small slice and doing it really well is so important. And it's very obvious if you think about it. I gave a talk at Reinvent last year about exactly this, about the product management mindset around platform. I'll link it in the description. But it's basically this idea of incremental value. Product managers do this. We say, we're not going to ship the whole thing, it's minimum viable product, minimum valuable product. As founders, we know this.
We have constraints. We can't go and build products of our dreams immediately. We'll get there eventually, but you start with something very small, you show a lot of value, you can sell that. And then you get buy-in from people like, oh yeah, I see what you guys are doing, there's a lot of value, go build more of this stuff. So an internal platform is no different. You don't want to boil the oceans and build a thousand things and they're all very mediocre, do one thing really, really, really, really well. And then suddenly that creates momentum, it creates a flywheel internally. It's like, hey, this is awesome, we should do more of this. Why aren't we doing more of this? And you get that pull immediately. And it's such a classic failure mode that we see with people trying to do a lot of things.
It's the same thing with portals too, right, it's like this is probably true about every product ever. But you see that with portals where people are like, oh, a portal can do 500 things, we should do self-service and scorecards and catalog and this and this. It's like, no, no, no, no, no. What is the first thing you're going to do? Do that one thing and suddenly people believe, you create believers. And then the moment you have believers, all of a sudden that creates the momentum you want. And building a platform is no different, you create those believers and all of a sudden it creates that momentum. So I totally agree with that. And maybe this is a good segue to talking about failure modes. A, what is the worst platform you've ever seen and what made it that bad? And then maybe talk to us a little bit about the failure modes of a platform. What do people tend to do wrong? Because we talked a little bit about what great platforms look like, let's talk about the opposite.
Kaspar von Grünberg:
Sure. Well, I have a long list of terrible platforms. I mean-
Ganesh Datta:
I'm sure you see a lot of these in your day-to-day.
Kaspar von Grünberg:
The thing that scares me most, I mean, we have this sort of a couple markers that if somebody tells me a combination of sentences, I'm ready to walk. Number one is, we don't have a product manager for the platform, I think. Or the opposite, if you have a product manager, okay, I know you get that this is a product and you're going to treat it at such. If you don't, that's sort of a wild amount of red flags. Whom are you serving? If you are talking the entire meeting about how you want to get rid of A, B, C and you dislike doing this and you dislike doing that, good for you. There are all parts of our work that we don't like, that's not the job. Your job is to serve others, right, this is a serving function.
I'm serving users and you have to, I think, understand that. So if I hear a lot of self-referential stuff, then that's sort of a clear warning sign to me. Bloat, right, we want to do everything until January. It's like, you won't. You would need to break every single thing that I've seen over the last 10 years. I've never seen this even in extremely efficient setups. You can get to a good MVP in two, three months and then go into having the first application run on this in, if you're very good, month three and maybe month four. But I've not seen that a lot faster. Unlikely you'll break my pattern and be a big outlier. Especially then you're in a regulated industry and you have a lot of security and red tape, it's not going to happen.
Inflated expectations if it comes to timelines, inflated expectations if it comes to what is this platform then able to do. And frankly, another thing is just looking at the budgets. So I'm always looking at, is this a long-term recurring budget item? Are they thinking about this as an initiative? If they go like, okay, for 2026, we are going to invest 800,000 into the platform and that's non-recurring, that's not going to cut it. You will have to invest into that platform for the rest of the existence of your organization, and you will need to do so every single year. Good news, the return on investment will be very, very fast and you'll save a lot of other stuff, and you'll have less infrastructure cost and you'll have less overhead.
You'll be able to serve a lot more developers with a lot less staff. All of those things will kick in linearly with the amount of users that you onboard. You'll have to invest into the platform for the rest of your life. That's just the nature of building a product and then maintaining a product, and making sure the next runtime and the next funny infrastructure is code format that some guys in KubeCon are launching. The next acquisition can run on this platform as well. So there are these combinations of things that if I see them, I know, guys, you're in big trouble.
Ganesh Datta:
I love that. I think you touched on two of the filler modes that we see ourselves with Cortex, is like you don't have a product mindset and you're focused on what you think other people want. I think that's one of the things we see, is you assume what your end users want. It's like, we think that the portal should do X, Y, and Z. It's like, have you talked to them? Do you actually know what the problem is or are you just solving a contrived thing that you think is the right thing in your head? Because even with a platform, I'm guessing it's the same thing. If you're just going off and building the thing that you think is cool or what your users want, you're going to end up at the state where you build it and people don't come.
But if you actually think about what people want and what pain your developers have or what pain the business has and you solve for that, then naturally people will adopt the platform and you get to the golden paths and all the stuff that you care about. I know we're getting up on time here. I do want to touch on the topic that I'm sure everybody is thinking about, which is, does AI affect platform engineering? I'm guessing the answer is yes, to some degree. But how have you seen it change? Is there an effect on platform engineering? What advice do you have for people who are worried about this next iteration?
Kaspar von Grünberg:
Well, first of all, I think there's no reason to be worried about that at all. I mean, you want to be in platform engineering, you want to be Henry Ford, right, you don't want to be the guy in the artisanal workshop to an extent. Let's face it, there are going to be restructurings in the organization, there's going to be change. It will have political implications. I think that's just the nature of things. But the platform is going to remain the platform and I think it's going to grow much, much stronger in relevance. I'm thinking about AI from two perspectives. I think as platform engineers, we now have a new user group and that user group is called the agent. The agent or agents are not different to junior engineers, in that they need well documented interfaces and they need MCP protocols and they need strong guardrails in order not to do whatever they want.
So I really think that that's good news. The AI way forces us to improve developer experience actually, because we're now also going into agent experience and that's very, very similar just because the structural way of consuming this is very similar. Now, the second bit is you have so many new ways of bringing these AI things into your capabilities inside of the golden paths. Let's take your example of the RDS sizing thing that I did in the demo with Cortex. We're now able to, from our Cursa IDE, whatever we're using, to ask Claude Code like, hey, what's up with my databases? Are they outsized? What's up there? It's a fantastic way of consuming a lot of data and saying, yeah, well, I mean, we have problem A, B, C, and then we can start remediation.
So it's giving us a fantastic new interface that's so human and conversational. That's a big plus. It gives us analytics capabilities within the tools, in the chains and in the workflow. So it really allows us to build these amazing platforms, experiences like never before. So I'm genuinely excited about this. From a platform engineering perspective, I find it hard to see any downsides. I think it will have a very positive effect on the investment that's going to go into the platform side. It's really the place to be, so only positives here.
Ganesh Datta:
I love that. My assumption here is, going back to the car manufacturing analogy, the car manufacturer's building more types of cars or moving from ICE to EVs or anything didn't negate the need for standardized manufacturing flows and tooling and all that stuff. If anything, it made it even more important, because all of a sudden you're chipping six different types of vehicles on different platforms and you're manufacturing two-wheelers and SUVs and maybe EVs and ICE cars on the same plant. And if anything, it made those things more important. And I think with AI, we're seeing the same thing where it's an amplifier. An amplifier is the best things and the worst things in your organization. If you already have people YOLOing things around an organization, they're going to YOLO things even harder, even faster.
And so I think investing in the platform may actually lead to higher velocity on the other side. If you can just give your AI agents or your developers like, hey, here's a platform you can go build on, let your agents loose. It's probably actually a great thing for the organization, it's not actually a thing that's slowing down. If anything, it's more important than ever has been. Is that a safe assumption? Is that how you guys think about it as well?
Kaspar von Grünberg:
A thousand percent. Well, if you have a good platform, you can literally go to Claude Code and say, give me, let's stick with that example for this podcast, give me the RDS database. And the platform will say, okay, well, let me check your RBC. Well, I feel uncomfortable giving you that for production right away because I want to have a human confirm this, but I'll give it to you in dev and I'll give you a sort of small one because we want to save money. And then you have a situation where you have a secure RDS picked by an agent and you can't destroy anything, the agent isn't vibe coding the Terraform file. It's in a very structured way. And that's all possible because of the platform.
I mean, look, in the AI world, we can't influence the layer on the AI, as of that ship has sailed. The thing that we should focus on is what's getting in and what's getting out. The connections that are actually molding the real world, the data centers, the things that we spin up, the things that we spin down, plus how do we interact with it. But yeah, the potential is limitless. And the better your platform, the more you're actually able to have productivity gains from that technology. I mean, look, Henry Ford is a fantastic example. The combustion engine was invented in 1870 something, right, and it took another 50 years almost until we could put that into productive use. Why is that?
Because technological innovation alone, let's take the example of AI, is not sufficient to actually deliver gains in productivity. It always has to be accompanied by organizational innovation and change. And the thing that I really believe is going to be that innovation that boosts the productivity, both for CPU as an innovation, as for GPU and LLMs, I think that's the platform. And that's why I'm so bullish on platform engineering.
Ganesh Datta:
I love it. It's more important than ever before. And I think people spend more time thinking about their platforms, building on the right foundations is so critical, whether it's platform, whether it's code coverage practice, quality practice. It's like all the things we've been talking about for a decade as things you should be doing, if anything, are just more important than they've ever been, because we're trying to solve for the lowest common denominator. It's like, how do you make things dummy proof almost so that people don't make the right mistakes, starting from design patterns and software practices, to platforms, to code quality practices. It's all about like, okay, how do we make things so simple that anybody can do it and not, not necessarily mess it up, but deliver the right value. And if anything, with AI accelerating all that, it's like all the things we've been talking about, investing in the platform and giving people golden paths, it's more important than ever before.
We're at time here with the podcast. Last question for you. The listeners here are engineering leaders, VPs and CTOs who are thinking about investing in these types of areas. If you could give them one piece of advice as they think about their platform as a final takeaway, what would that be?
Kaspar von Grünberg:
So I think many at this point think that platform engineering is sort of this vague, early phased movement with little best practices. And I don't think that's true. I would encourage people to look at, what are the patterns that are working in other organizations? How can I avoid those pitfalls? I would go out and speak to specialized consultancies, training firms, whatever, about that. I mean, take a little time, there's a lot of bullshit out there, a lot of people that are just saying stuff on LinkedIn because it's the next trend. But there are those out there that have seen the study, the failure stories. And I think you made a very good point in asking that, look at what worked, what doesn't work. They're very clear patterns. With all of those dozens and hundreds of initiatives that I've seen over the last eight years, the patterns are always the same patterns.
Study them and try to not repeat them, because it's terrible to see these things fail. There's a wild amount of potential. And yeah, I mean, I want everybody to succeed. There is this tendency that you listen to things that are being said almost too often on LinkedIn and in these podcasts, and you always go like, yeah, maybe that's true, maybe not. Look, if you've seen them hundreds of times, there's probably some truth to it. And you can save yourself an incredible amount of time by just following advice if it's advice that's represented for the organization you run. I mean, the advice that I give is never representative for a small startup. You guys should be scrappy and should use Helm Charts and Terraform and everybody does everything. Absolutely right. But if you're a large enterprise, we've probably seen your case, and I would pay attention.
Ganesh Datta:
I love it. Well, Kaspar, thanks for coming on the podcast. Like I said, you're one of the top minds in platform engineering, so I'm sure our listeners are going to take a lot of interesting takeaways from this conversation. Thanks again for being on it.
Kaspar von Grünberg:
Thank you so much for having me.
Ganesh Datta:
Thanks so much for listening to this episode of Braintrust. If this resonated with you, do me a favor, share it with another engineering leader who's wrestling with these same challenges. And if you want to continue the conversation or learn more about how we're thinking about internal developer portals at Cortex, reach out to us at cortex.io. Thanks for listening, and we'll catch you on the next one.