Platforms are for humans

Kaspar (00:05): Okay, what do you want? Do you want to be a service catalog and focus on the enterprise asset management element? Or do you want to cater the developers, those are two very, very different personas with very different needs. Marc (00:21): This season, Andy and Marc are back with a fantastic group of guests. Andy (00:26): I bet the depths remain classified, and Marc keeps his head in the clouds. With our combined experience in the industry, we can go from the bare metal to the boardroom. Marc (00:35): In DevOps Sauna Season Three, we'll explore platform engineering, and the people and cultures that make it happen. Andy (00:42): Enjoy your time in the DevOps Sauna. Marc (00:53): Okay, we are back in the Sauna. I have my usual cohort, Andy Allred. Andy (00:58): Hello, happy to be here, as always. Marc (01:01): And I'm super excited to talk for the second time with Kaspar Von Grünberg, founder and CEO of Humanitec. How are you today, Kaspar? Kaspar (01:13): I'm very well, thank you for having me. Marc (01:14): It's great to have you back. And we spent just a little bit of time together in Copenhagen last autumn, and you captured me with a lot of the thoughts on humanity and platform engineering, and I really wanted to get you on the podcasts. I'm so glad you could come. Tell me what's on your mind today? What are you looking at? Kaspar (01:36): I had a conversation earlier this week with a platform engineer, actually. And he quoted Alan Kay, a computer scientist who worked on Perl, and the quote said, "We should design platforms that make simple things simple and hard things possible.” And that very much resonated with me because it's summarizing, I believe the key thing in platform engineering, that is how can you actually design paths, and pathways that are respectful towards every single individual contributor, and everybody who's actually working with these platforms. There are a lot of different users, but how can you accommodate their individual preference? And so that's really top of mind for me at the moment. Marc (02:24): This idea of, can we actually please everybody, and we're talking about computer scientists. <laughs> I think it's a lovely idea. And it's something that, of course, we're trying to do in all of our work when we're doing platform engineering, how do you go about that? There's so many different needs for so many different people and kinds of teams. And there's always that guy who argues about everything that's not exactly what he has. And he'll argue about that if there's nothing else. Kaspar (02:56): I think platform engineering shares a lot of the same principles with good management practice. If you are running an organization, or you're managing a team, the team has different needs. And there are individuals, some people are very vocal, some people are reserved, good management practice means you hear all voices, you take all the different factors into consideration. And then you make a decision. And you explain to everybody why you're making that decision. People get the context. I think we're very social animals if you want, and people are okay to take one for the group. But you need to explain that and you need to be transparent. And that's the same for platform engineering, you need to hear the different voices, and then you need to prioritize, and you need to explain why you're making decisions, and then you'll be fine. Marc (03:49): I like this. Something that we talk about a lot is what does it mean to listen. And one of my favorite definitions of listening is trying to listen to understand, not listen to respond or listen for other reasons, but listen to really understand where people are coming from. Kaspar (04:07): Yeah, that is so vital. And not many people are doing it. Andy (04:12): When you're talking about hearing all voices, and then decided just reminds me back in my Navy days. Before any mission, we always had the pre-mission brief, and we talked through everything. And during this pre-brief, everybody's expected to speak up about anything. And it doesn't matter if you're the colonel or the corporal or anybody in between. If you have an opinion about something you are required to bring it up. And it doesn't mean that whatever you say will influence the decision. Meaning if I say we should do this way, it doesn't mean it's going to go that way. But everybody then left with the feeling and the comfort of knowing that their point of view has been taken into consideration. Maybe because of XYZ doing something else was the better choice overall. But at least my point of view was considered and weighed against all the other options. And just knowing that makes so much difference. Kaspar (05:11): So much difference. I'm a big believer, for instance, in written decision management. If we make a read daunting decision, we write in like a working paper, a memo or an operation. And we take a little too much time structuring our thoughts around this. And then we actually do the same thing. Like we gather everyone and say, "Okay, you now have a mandate to criticize this, tear this apart, try to find the loopholes." And as you say, then everybody's in the loop. And maybe you say, I disagree, but then you say, I disagree and commit, and then we say, okay, for the next, whatever the execution period is, we'll not look left, we'll not look right, we'll not do things 80%, we'll do things 100% because we're all aligned on that goal. And that's exactly the challenge, the complexity with platform engineering, it has a lot of cultural elements to it. Marc (06:00): Are there some examples of what type of things can be very difficult, especially at a cultural level to make these kinds of decisions? Like, one thing that I could put out is, I've seen companies that want to execute cultural change in an organization by doing a tool chain change consciously. Kaspar (06:19): And that almost never works, right? Assuming you can bring in a tool, other vendors will tell you that, and we'll try to sell that. But you can't compensate a problem by just throwing another tool at it. That's impossible. My favorite example is one of the questions in platform engineering. Where do you cut, right? How do you abstract? Do you abstract at all? Abstraction is like in itself a dangerous word because it's implying, you're taking away context. How do you balance that that thing? How do you make sure that you hear the Linux kernel hacker and you hear the junior front end engineer and the product manager? And how do you make sure that management is not over shouting at all and say that we should start with fancy dashboards? That's a very, very delicate thing. And so, the easy answer is usually, that isn't necessarily the right one. And that's especially the case if you have like a multi attribute problem, like platform engineering, or complex tool chains. It's so absurd people say, oh, there's so many tools. Well, if you look at every factory that's building a car, think about how many tools there are in these factory halls. And, of course, there are many tools, like a car is a complex thing. Everybody knows a car because they can feel it. Not many people know distributed microservice architectures, and how complex these things are if you run them at scale, and how much pressure there is on these teams to get that right. And so, we always think that these digital assemblance should be so simple, but they're not simple. It's a really, really complex thing. Marc (07:57): You had me for a moment because you said, the easy answer is, and I was waiting for the easy answer. But it's like almost never. <laughs> Andy (08:06): I was talking about this abstraction, and where do you find the abstractions with a customer couple of weeks ago, and they were basically saying the platform engineering is going to be too complicated and it's never going to work because these abstractions are never good. You can't have abstractions and do things properly. And I said, "Well, how do developers decide how the electricity is made which goes into the server? How did the developers influence the design of the silicon inside the chip? How many of your developers are committing to the kernel?" Let's just accept that there are abstractions. And instead of saying no abstractions, let's make a conscious and informed decision at what level we think the abstractions is the right place to put for our environment in our way of working with our organization, then it shifts the thinking, and then we're talking about, okay, where do we bring value? And where can we make changes that will help us instead of this just well, abstractions, or bad kind of discussion, which happens way too easily. Kaspar (09:13): And what they're forgetting is that if you're not thinking about these things consciously, the abstractions build themselves. If you have an incredibly nasty CICD setup that nobody really cares about. That is a huge abstraction, right? Because nobody gets it. And it's an instruction that you didn't you didn't willingly decide to build it that way. Or you didn't consult anybody. It's just a horrible abstraction, and you're left with have having your people do deal with these things, and nobody really went. It's assuming that if you're not taking action, things will be fine. That's just wrong. Andy (09:53): Horrible and complicated CICD pipelines. I've never seen that except every company I've ever worked with. <laughs> Marc (10:02): You connected so many dots for me, Kaspar, just now, which is like if you don't take head-on the essential complexity, then it simply results in accidental complexity. Kaspar (10:12): Yeah, that's really the problem. And so if people say, I'm not sure we want to build an internal developer platform, I always respond with, hey, you know, you've built it already. The problem is you're not treating it right. And so it's really nasty. Well, what is an internal developer platform? It's the sum of all of the tech and tools that you have, right? There is not this golden bullet out of the box thing. I mean, there is it's called Heroku, right? And everybody who can use Heroku, I always tell like, please use Heroku if you can. Please use ever every single platform as a service product on the market before you actually do these things yourself. But if you have to do these things yourself, and that the uncomfortable truth is that's 90% of the market, especially with enterprises. Well, then you either focus on building your platform the right way, or it builds itself. Marc (11:07): Cool. What are some trends that are going on right now in platform engineering? Kaspar (11:13): Well, I think that everybody smells that there is something to do, especially in the last 12 months, Gartner predictions, and people are using the usual buzzwords 'golden path' and ADP and portal and platform engineering. And part of the problem is that there is a lot of confusion. And frankly, there are a lot of people shouting stuff. And one of the biggest confusion is probably that you can get something out of the box and your life will be good. That's not going to happen because there is not that tool, it's localized to the situation your organization team is in there are patterns, right? There are blueprints, but there is not the one. That's number one. I think the biggest fallacy that I'm seeing is that people believe that they confuse a portal or a service catalog with a platform, I think is number one, like everybody thinks out, okay, well, let's build a nice user interface where people can now actually, I'm not even sure what they can do now in their portal, like, they can see stuff. And then they say, okay, by seeing stuff, by visualizing stuff, it will get better. And a friend of mine, Lee wrote a great article saying, if you put a pane of glass on a pile of shit, you still see a pile of shit. It doesn't change, right? You can't build the front door first, but there is no house, you need to build the house and then you can build the front door. Putting like a UI on top of something make sense in specific situations, but just to try to calm down your management, because now they can see stuff, it doesn't really change the workflow. And I'm always feeling so sorry for these teams that put so much heart and energy into building shiny green portals and they looks stunning. And then you look at the user traits and develop this. I mean, it's a break in their workflow, right? They stay in in code. It's another interface that they're supposed to use. In reality, they don't use it. And then I saw this portal of a very, very large European ecommerce player the other day, and we looked at these assets. And so, developers were using it twice a year, they logged in twice a year, when they were building new services, but not actually to use the templating flow because they circumvented using GitHub templates, because what the UI did is actually called the GitHub template API. Now, they looked at this to actually use the search function to see whether there had been services built before that they can reuse, like the classical inner source case. And you can enable the inner source case with probably 5% of the investment that this team had done into that portal. I think that's the biggest problem at the moment that people are looking for easy fixes. They're avoiding building the fundamentals and getting the fundamentals right. And that leads to really nice-looking portals that nobody's using. Andy (14:15): We've had a lot of conversations with our Eficode customers recently about backstage, which is picking up a lot of steam in the industry and getting a lot of publicity and making a lot of noise. Just making sure for anybody listening backstage is a developer portal, coming out of Spotify, and it's really interesting and keen, but it's only a portal. And we've been having customer discussions where they're like, Okay, we need backstage. Okay, that's fantastic. We can we can help you put it backstage. It's a portal to help visualize these 57 other things that your developer platform needs, who's taking care of these other things? I don't know, but we want backstage. As you said, companies too easily are focusing on what's the technical solution we come in? What's the one tool we put in, that solves everything? It's sometimes really hard to get a discussion about what's the overall thing we're trying to solve? Then I've seen even some people who put in a conference talk with a title like DevOps is dead just to generate conversation. Then you'll come up and like, okay, no, it's not dead. Okay, you're right. Now, let's talk about it. Marc (15:32): This pane of glass in front of the shit, I'm not sure if I'd rather have that, or a flaming bag of it on my doorstep, which also came out of this conversation. But this minimum level of useful visibility thing is, I think, a really interesting topic because every big enterprise customer that I talked to, the fragmentation is it's unbelievable that they can get anything done. Is there something to pull this together? Kaspar (16:01): Well, don't get me wrong. Yeah, we need to be very precise here. I'm not saying that enterprise service catalog is a bad idea. But I'm actually advocating for like, what do you actually need it for? Should you have an asset management for all your stuff? Yeah, you should. No question. If you have a sufficient size, that's absolutely the case. I think that the problem is that we are conflating the needs of the product management and management layer, because they actually need Asset Management surfacing what's going on, right? Very important, like, where are we in the transformation? They're to like lean AIX, or like these large asset management systems. But I think what happened is that we tried to actually mix the asset management approach, which is geared towards informing product management functions. And we're trying to actually shove this down the developers’ throat, and the developers are focused on one element, right? They don't have the pain point that somebody who's overseeing 200 services. That's a very, very important differentiation. And now we're saying, okay, like, every developer is supposed to use this new UI, because we're calling it a developer portal. And you can see that like, all of these disrupt themselves as a developer partner slash service catalog, okay, what do you want? Do you want to be a service catalog and focus on the enterprise asset management element? Or do you want to cater the developers, those are two very, very different personas with very different needs. You can make the case for both. And if you're creating 200, 300 services every year, should you have a specific way of template testing? I mean, sure. I'm just saying that how will you prioritize to actually spend your money in different budget items should have a return-on-investment calculation attached. And that means, well, what's the element that we could do now that has the biggest impact and the biggest return on investment? And the answer is, whatever. That's the answer of the of the organization. What I think I'm criticizing is that the organization's don't even do that. They just look at what feels most obvious. And then my interpretation is they say, where do we start? We could look at the application lifecycle. What's first in the application lifecycle where the creation of a service. Hundreds of enterprises are now looking at standardizing the creation of a service. If you really zoom in, they already knew that they have GitHub templates. Now they hide this behind the fancy JS layer. I just don't think that that's the ROI. Marc (18:36): What do you think is the ROI? Kaspar (18:40): I've been really trying to dissect that and looked at a good amount of setups right now. And I thought about like this, if the developer just updates a specific element of their code, right? Git push update, everything is running, CI is there, flows out there, I have my individual service, I'm working on that service. And I'm updating that service and the change needs to end up in the, in the cluster wherever, yeah, then I actually don't need a platform for that because that is pretty static, there is no particular change in that situation. Now, you need a platform if you do anything that goes beyond the simple update of an image, if you think about it like this, a workload unit wherever you run it. And that could be things like you add a new service and you tie this into the architecture, you update resource definitions across a large number of different services. You add a new resource that you configure something, you move something from one environment to the other, you may be creating a new environment, you are creating a new service indeed, you do specific rollback actions you need to understand in an immutable way, what happened between deployments. These things are things that go beyond the update of an image and the developer in these cases is actually confronted with a break and experience because they can do it themselves, which is usually ending up with a high cognitive load on the individual user because they need to dissect well, how does that networking work now, and we've been throwing all this, 'you build it you run it' at them, now they need to do everything. The second option is, well, you just throw that over the fence to operations. And I like to call that ticket ops. And I see that in a lot of organizations, they are JIRA tickets, ServiceNow tickets. Can you debug this? Can you do this? Can you do this, the operation teams keep growing and growing and growing to deal with all of these demands of overwhelmed developers, and developers awaiting. These are actually the situations that you need to dissect and go to every single developer and say, "How often do you go beyond the simple update of an image?" Let's just normalize this against 100 deployments, how often do you do this? How much time does that eat from you? Now you go to operations, how much time if their developer comes with that request, how much time do you need for this? Well, then you can actually build a very, very clear prioritization and you hear a number of voices, you hear the junior, you hear the senior, and then you say, okay, that's our research based on this, this is the decision we're making. And that ties back to the conversation we had earlier. Make it very clear why you're making decisions, and then pull through and execute them well. Marc (21:19): Beautifully said. Very, very well iterated. Marc (21:27): Hi, it's Marc again, if you'd like to hear more on developer experience, please check out Emily Freeman's keynote from The DEVOPS Conference 2023. It's called what is DX, creating great developer experience. I'll leave a link for you in the show notes. Now, back to the show. Marc (21:50): Let's shift gears for a moment. Would you like to ask about the Kubernetes benchmarking study, Andy? Andy (21:57): Yeah. There was a recent study coming out from Humanitec. And it was about the Kubernetes benchmarking where we are, what the top performers do versus the bottom performers, what not. And then there were four key takeaways at the end. And just reading through that a lot of what they were saying just resonated so much with what I see. And I thought it'd be interesting to not walk through the whole study, but at least talk about the four key takeaways, and what kind of things you saw that led into these takeaways. Kaspar (22:32): Yeah, sure. We are doing a lot of these studies. Frankly, we're doing them to a large degree also because I had the feeling that my decision making also on the product side was just skewed, the data is not very accurate that is out there. And so we started to do this large scale studies where there are like in the thousands. This year, I think is 1000 something attendees, but we have larger studies with up to 3000, 4000. And I'm always fascinated by that difference between high and low performers, and how clearly certain things surface. I always feel like I had a certain gut feeling about them, but they were very blurry to me. I always found that very, very helpful. The first one is that if you're not running Kubernetes, yet, you should focus on getting that set up. Many people start with the other stuff too early. You need to have a certain period where you just get the fundamentals right. And that is security and set up and structure and making sure you are trying to use as many. That's my personal opinion. But hosting Kubernetes yourself, you can do that. But like maybe not, you should make sure to think about how can you automate these things as much as possible to have as little operational burden as possible. I do think in these situations where people start looking at this, you should already take into consideration how much you can shield the complexity of Kubernetes today, many people are now branching and looking into things like ECS, large banks, where I'm not a huge fan because you're really locking yourself in and then you'll have the next big transformation five years. And so while you're getting the fundamentals right, already get a sneak peek of what's technically possible already to even out the experience for the developers but fundament has to be rock solid, then second, and you can see that clearly high performing organizations have a high degree of self service, and that is because of the stuff that I talked about earlier. If it's too complex, and if there is no self-service, developers are waiting. I think a big time of this industry's developers just sit there waiting. And that's incredibly frustrating experience for them, then what many, many people get wrong, I think, in my opinion, so many vendors, like, I would wish for more vendors that think about things more holistically because you cannot only talk about Kubernetes. Kubernetes is an orchestration layer itself, it's only as good as its combination with its periphery, if you want. You can't think about Kubernetes without thinking about the database, or the DNS, or the file storage, or whatever it's the sum of all things, self service capabilities, need to really look at the holistic thing and make sure you don't build even more islands. And then the fourth thing is that approach of layered abstractions, if you want to build an internal developer platform on top, never... one of my mantras is 'golden paths over golden cages', humans react very allergic to things that work well, even 90% of the time, but fail you 10% of the time. And you can actually feel that for yourself, if you're using Amazon Alexa or Siri early days, and it worked in nine out of 10 cases, you still didn't really trust the system, right? And that's the same thing with platforms. In a daily workflow, these things work in nine out of 10 cases, that's not enough. And in this in this 10% bucket, the individual user needs to be able to go beyond the leaf the path if you want, and go down to the to the level below to actually configure stuff themselves. And again, that also holds true to accommodate the different personas, you have that type of person that wants to stay high level, they're okay with the defaults, they're actually happy with just focusing on React JS. But you have the Linux kernel hacker and you can't put them in golden cages, they will snap and they will torpedo and they have a very loud voice, right? A lot of the mistakes that we did with platforms in the early tense, if you want where they were too rigid, too abstracted. Andy (27:10): You're talking about Kubernetes, and then building up some self-service, I guess, some API's around it, and then an IDP that will include the holistic environments and whatnot. And then you brought it back to what the individual people need. I guess part of this may be the easy part of is the technical transformation, which tools do you use? How do you set up the technical workflows? And the hard part is how do you change the culture, so all these individual users are willing to get on board and support it and use the platform you're building? Kaspar (27:45): I talk a lot in these mantras, but it helps me solve my thoughts. I think about pull versus push. My observation is that push based methods don't work. If you build something, and it's built in isolation, and then you turn up at the doorstep and say, Hey, there's this great platform. This is the login, let's go. Here is a training material. Why don't you try it out? I can't say I've been very successful with that method myself, although I really tried. And so, my answer is a pull-based method to say, well, I'm trying to build that step-by-step guide to platforming always saying, okay, settle on lowest common denominator tech stick, don't try to build everything. And today, probably containers and Kubernetes, find a team of people that want something new, there's always this team of innovators. Once you have that, built something that's 10x better than what they have right now and focus too much time and energy on that small thing, and make them fans, because these fans will create your internal pull factor, everybody else will want to be on that train wagon. And that, for me, has been the most powerful thing. And second, I think the time horizon at which companies really operate today is too short to believe that you can fundamentally change people. I think you need to meet them where they are. And if they're today, writing TerraForm, and they're really happy with it and proud of that achievement, don't take that away from them, make sure they can still do that if they want, make sure people self-select what's best for them, and try to build the systems around that. That means probably you don't get the degree of standardization you want. It probably means that you have three CI providers and everybody's wondering, like what the hell, why do we have three CI providers, but I think pick your fights and try to keep people with what they're used to and try to consolidate wherever possible. Marc (29:48): Kaspar, I talk a lot about motivation and my daily work and I introspect and meditate on it and mantras and good days and bad days but, it comes down to a small set of motivations for me that at my age have kept me going. And then you there's all these dark places that we go to and some call it even the black dog and things like that. But could you tell me a little bit about your personal motivations and I felt like I empathize with you the day that I met you like, Okay, I know some of the paths have been in some of the rooms that you've been in, tell me a little bit about what motivates you on a daily basis, and how you keep going and how you face the dark times. Kaspar (30:31): I've been really struggling with that, it's hard for me to find an argumentation why there should be free will if you want and pre-determinism has always been something that has been a burden on me. I've been saying, okay, there's so much randomness, and there's the butterfly effect. And religion and everything, this thing that actually you and I probably looked at too much research on neuroscience, and they're all over the place, they actually have no idea, but they all have a right, lots of different statements. <laughs> For me, I thought, well, that's all good and fine, if you think about it in a theoretical way. But in the end, there is always a human that wakes up in the morning, and something happens, and then that human is happy, or the human is sad, or the human is stressed, or there is a human there because they're stressed, they're not fair on their children, or whatever it is. Now, because that's the fact, if you can do things that change the overall system to the better if you want, then that's always worth fighting for. And that's always worth striving towards. Because in all of its abstraction, and seeming pre-determinism, we still feel something, and the system overall gets better. If more people feel joy, if you want, and it's worth fighting for that. For me, there has different facets in my in my private life, and how I'm trying to actually be socially active or help others, it's really important for me, and I keep telling that to also my colleagues, it's really important to give without expecting anything in return. If everybody does that, we can change the world, actually. And we can make a better place. And we can we can ease the burden on every single one. From a professional point of view, for me that materializes in, I want to build things that make people's life better. In that case, now with software. I've been building stuff before that didn't make people's life better. I couldn't work with the intensity; I can't work on this. I then did a software for Non-Governmental Organizations optimizing their approach, which worked well. I do think it helped a good amount of organizations, but it's still around, actually. This was a great experience. And then the next thing is this year, because I've always been working with engineering teams. And I always thought this mantra 'you build it you run it' is a little bit abusive, if you want, because the subjects that are supposed to run it, weren't really asked whether they want it. If you think about it like that, they were trained on being React developers, and now you want them to do everything. And that constant idea of shifting left, shifting left, shifting left is from the medieval ages to now, in every single industry, we've had separation of concerns, and we allowed people to focus on stuff. And we're the only industry that for some reason think it's cool to let everybody do everything. And that's like, why? Because we're going to forget says that in 2006. And why is he saying that? Is that maybe really good for AWS, I don't know, margins. And I think the sentence is resonating really well with all of us. Because as engineers, we want to be capable of everything. And we want to go into the weeds. And so, it's meeting a psychological profile that never says no to technical complexity, but only because you never say no doesn't mean it's good for you. And that's the thing that drives me. Platform engineering is about making the life of others better and less stressful. That's really the core of what platform engineering is about. It's about psychological safety, and being respectful towards every single user. Marc (34:29): I just have to tell you that not only your mission and your way of describing it, but the fact that you have this goal, you have these values. And you also come out with the thought leadership and the capability to be able to share them with others. So that while we're on our personal journeys, we're able to also think about these things. You've made a fan out of me Kaspar. I've gotten to say that a few times lately. I feel very, very fortunate to be able to participate in something like this. I have two more questions that we've been asking all of our guests that come on. And the first one is Kaspar, can you think back to when you were a child? What is the first thing you remember you wanted to be when you grow up? Kaspar (35:15): Yeah, I wanted to be a composer. That was my dream for a very long time until I was 17. Marc (35:25): I applaud you. Do you play instruments? Kaspar (35:27): I play instruments. I play the piano. And I sing and I play clarinet now and a little bit of bassoon. I do a lot of music. And it's funny, it's very similar to software engineering, actually, you have a very clear set of rules. But you can be incredibly creative inside of that system of harmonies. Marc (35:51): You bring Beethoven's sketches to mind. If you listeners don't know Beethoven would make lots and lots and lots of tiny little sketches. And it reminds me of when we're building up test harnesses, or doing experiments in DevOps kind of thing, so fascinated. Kaspar (36:07): Writing complex scoring is nothing else, there are very clear rules, hey, you need to make sure that you don't have the dominant before the sub-dominant. And that's because the human, the Western human ear, to be very precise, is very used to this and it feels abusive to end. You want to make sure that you're following the rules in order to actually then please the listener. But still, you want to be creative. And so yeah, that this is a fascinating parallel. Marc (36:37): Excellent. Okay, I'm still at ii-IV-I. If I can get the one in there as well, or the six, and maybe I'm doing well. Okay, second question, Kaspar: Was there a point in your life where you either crystallized that you're on the right path, or you realize you're on the wrong path and you had to make a change? Kaspar (36:54): Yeah, several, I think the one that was most apparent, I have a large appetite for risk. At that point, I took a lot of risk. And lots of people, depending on the decision and lots of families, and we rescued that suggestion in the end. But in that situation, I did something that was so stupid, or that it makes so little sense to make that decision that way. And I had a conversation with my father. And he looked at me and says, like, what kind of advisors do you have around you? And that was a turning point, actually, because I realized, you don't have the right advisors around you, or if you had the right advisors, but I wasn't listening the right way. And I wasn't listening the right way because I was too young or too immature or not humble enough, I was probably just not humble enough. And so that's where I started, okay, well, you need to hear that triumph now. And you will need to be more humble and listen to the experience of other people. Because otherwise, you need to make that experience. If you have to make all of the experience yourself, life isn't long enough for that. You need to help them the affections of others if we want to stay in. Marc (38:03): Excellent. Very well put. I'd like to thank you again, Kaspar Von Grunberg, for joining us today and sharing so much of yourself and your values and your mission with us. Kaspar (38:15): Thank you, Marc. Thank you, Andy. Andy (38:16): I think Kaspar has been great. And I think this is the first time we talked about from medieval times till today of this tech podcast. Kaspar (38:24): Thank you very much for having me. Marc (38:28): Thank you. Before we go, let's give our guests an opportunity to introduce themselves and tell you a little bit about who we are. Kaspar (38:40): I'm Kaspar. I'm the CEO and founder of Humanitec. I've been building software and software teams for the last decade or so. And I've been always fascinated by platform engineering. I'm fascinated by platform engineering because it can play such a large role in the sanity of an of a team and organization. And it can ease the burden on the individual contributors. Platform engineering and building internal developer platforms is something that I'm fascinated about. And I'm spending really all my day on. I talk a lot about platform engineering, just for the sake of it, and about how to build platforms and the practices. And we do a lot of the community stuff. And we do this to help others be successful with that. And then I'm also building tools to help teams build scalable, dynamic internal developer platforms, couple of them open source, others closed source and I'm always interested to exchange on that topic. Feel free to get in touch with me. I'm always encouraging everybody, not many people do it, but my mail is kaspar@humanitec.com, so if you have any idea, please shoot me an email. Marc (39:48): My name is Marc Dillon. I'm a lead consultant in the transformation business at Eficode. Andy (39:54): My name is Andy Allred and I'm doing platform engineering at Eficode.