[
  {
    "start": 0.0,
    "text": "Tobi: Hello friends. This is the alphalist podcast. I am your host Tobi. The goal of the alphalist podcast is to empower CTOs with the info and insight they need to make the best decisions for their company. We do this by hosting top thought leaders and picking their brains for insights into technical leadership and tech trends. If you believe in the power of accumulated knowledge to accelerate growth, make sure to subscribe to this podcast. Plus, if you're an experienced CTO, you will love the discussion happening in our Slack space where over 600 CTOs are sharing insights or visit one of our events. Just go to alphalist.com to apply.",
    "end": 36.0
  },
  {
    "start": 36.0,
    "text": "intro music]",
    "end": 51.0
  },
  {
    "start": 51.0,
    "text": "Tobi: Welcome to the alphalist podcast. I'm your host, Tobi and my guest today is a crazy guy who's retired, who used to also do many complex things, um, in his past life. I don't know if you agree, Kelsey. It's Kelsey Hightower. And, uh, Kelsey is actually retired these days, right? You at least pretend to be retired. You can you can tell us more later. And you're you're like a self-taught hustler. Uh, also happy to hear about that. Um, you, you're a Kubernetes rainmaker, so you wrote a book about Kubernetes. You like changed so many things in Kubernetes and influenced it so much. You worked at Google as, I think distinguished engineer, is that correct? Yes, yeah, you're, you're not not shaking that. Okay, okay. Um, and you're a minimalist to the bone. um, and a life demo legend. Like that's that's what what my research spit out. So you're also well known for doing doing doing talks without slides, etc. So, you're happy to happy to meet you. Like, was it all correct? Like did I did I forget something? What what's what what?\n02:03] Kelsey: Yeah, that's that's a decent summary. Look, I I I've been in this industry for 25 years. I had lots of roles, everything from tech support to leadership positions and I think a big part of my public work known work is around open source and that comes with contributing to industry standards and, you know, giving talks to nudge the community globally towards a set of ideas around those projects. So, you know, if you were doing that external search, I'm not surprised that's what comes up.\n[02:32] Tobi: So but maybe maybe we start with that self-taught part. Like why are you actually doing what you what you're doing? Like what what initially sparked your attention? Uh, why did you get attracted to computers, let's say? If you're if you're still attracted, uh, what why why are you doing what you're doing?\n[02:52] Kelsey: Yeah, I mean, I started kind of right out of high school, 1999. I turned 18, graduated high school and faced with the same decision most people are faced with. Do you go to college or, you know, do you just get a job that you can? And so most of my life up to that point, I've worked fast food jobs, right? So this is places like McDonald's or delivering pizzas, that kind of thing. And so you look around the landscape and I decided that college wasn't for me. Not that I found school pretty challenging, but it's just like, I just didn't want to go through more schooling after just graduating. But I wanted to do something. And when you looked at all the open roles, you know, if you want to be a doctor or a lawyer, you got to go to college. You know, those are credentialed fields. But in 1999, people were standing in line for operating systems, right? People wanted the next release of Microsoft Windows, computers were everywhere, it was all over the news. And you when you dug into it, that particular industry was more interested in people with skills. Not necessarily degrees or credentials. If you had skills, there was a pathway to get in. And so I decided that that was going to be the thing that I was going to attempt to do. And look, just like most people, you probably use a computer for something, school work or playing video games. So computers are already around us, but the idea of being able to work in that field, I didn't know anyone in that field, but it felt like it had the least resistance in terms of what was required to break in without all the gatekeeping that I saw in other professions. So that's where I got my start.\n[04:29] Tobi: What what was it exactly what you've been doing? Like, I mean, you're right, like back in the days it was more about skills. it's still somehow is today.\n[04:38] Kelsey: Look, when I started, I opened a computer store, right? I was 18. I said, hey, I want to service my community. So I looked at all the open job openings, you know, even though they wanted skill, they also wanted experience, right? So if you don't have 10 years of experience, when I was 18, I was too shy to apply for a job where I didn't have the amount of experience. And so I went to get IT certifications, right? A+ certifications, learning how to break, fix computers. And so the first thing I did was like, hey, I'll just open a small computer store and buy parts from the north side for a certain price and sell them for a small markup on the south side of town. And so that worked out well and it led to things like contract work, you know, DSL installations, contracts with small insurance companies, hooking up things like active directory, network printers. You kind of do whatever you can during that period. And I did that for a number of years until I had some experience. And I applied for my very first job maybe around the age of 24 uh for Google actually, right? So I've been at Google twice. And the first time being at Google, it was for a data center technician. And they had these huge data centers, even back in the early 2000s that had hundreds of thousands of servers in there. And the interview process was all about do you know system administration? So they ask you all the trivia, do you know what Unix commands? Do you know how to do this? Do you know how to do that? And luckily for me, my career to that point had prepared me for that style of interview. And so getting that job, you walk in and you've seen this humongous data center. Everything is perfect. Every wire is ran to perfection. Google at that time is starting to build their own servers, their own hard drive controllers, their own top of rack switches. So I'm learning how to maintain data centers in this capacity, right? When something goes wrong or you're troubleshooting at scale. So for me, I'm thinking this is how all data centers in the world look and not even close, right? What what Google was doing was extremely cutting edge at the time. And so my role after that, I hopped around in the early days as a contractor, you're going to go get any job you can that pays slightly more money. So if one job is paying, let's say 40 grand and the next one is paying 50, uh, then you make the swap. And eventually I get to financial services after doing tech support, web hosting, voice over IP, and then you get into like corporate America where there's much higher stakes, revenues on the line, outages impact customers or even make headline news if something goes wrong. And at that point, I'm really starting to mature. So that whole period, I would classify as like system administration with the ability to write code. And I think at that time before we started using the term DevOps, that was a time where if you were a system administration system administrator that understood networking, Unix, how servers work, how to deploy applications and you could write code, you were kind of at the cutting edge in terms of automation, you know, DevOps, puppet, chef configuration management. and a lot of companies that were moving from just a few servers to virtualization where you go from like 10 servers to hundreds of servers, automation became a must-have. And so for me when I got to that point, that's when I kind of made that transition to software engineering. right? building the tools that we would use to automate those infrastructures. And then from contributing in open source, I find my way at puppet labs, which is one of the small companies that was at the dawn of DevOps, building all of these automation tools that would change the way system administrators work, right? It would say, look, if you're still writing bash scripts or you're doing things manually, there's a new way of doing things. and configuration management was that way of doing things. and then I just got caught up in the wave of change, right? so we went from dev ops to containers, to distributed systems and it felt like everything was changing. So that last 10 years was a wild ride of going from being a system administrator and having an array of jobs to becoming someone who builds the tools for that very same group to move them to the future.\n[08:48] Tobi: how does the future of of infrastructure look like from your perspective? I mean, also given the fact that you were faced like quite a lot of complexity in your life. I I I assume, like also having having seen so many different like inceptions of how computers are being managed. Um, like how is it now? Like after you basically quit your job and you're retired? how do you see that world of of of yeah, infrastructure and complexity?\n[09:17] Kelsey: It looks the same. And it looks the same because I think most people have no desire to do the maintenance. Like people love building new things, next generation this, next version of that. But the maintenance part is where I think things get a little dicey. Right? Just like if you own a home and you don't maintain any of your subsystems, you just wait for them to break and then you call a technician. Mainly because most people don't even have the expertise or understanding of the value of maintenance. But if your AC goes out and you're too hot, you'll say, hey, now I have an emergency, let me call the repair man and I will pay any cost not to be hot anymore. And a lot of enterprises still work that way today. They don't like to give a lot of attention to things that don't need it. And so for them, they tend to wait till things blow up. and so all these systems accumulate. I think a lot of times we think that, oh there's a new technology, somehow it replaces the old technology. I'm pretty sure most of your listeners are aware, that's not how it works. You just end up collecting technology. So if you're a company that's been around for 50 years or 100 years, my guess is you still have some mainframe, you still have every other generation of technology that came every decade after that. And so what you end up with is this hodgepodge of things that need to be maintained. and you don't have enough people to maintain them. and so I still see the same firefghting that I saw in the 90s, where something blows up, the person who worked on that system no longer works here anymore, and so then you try to pull together a tiger team to put the fire out. Do you have the bandwidth to rewrite that system? No. Are you going to replace that system anytime soon? No. And so what you end up with is just more stuff. So now that AI is here, people are now adding this to their infrastructure, and there's still this fallacy that that stuff is going to replace all the old stuff. And I doubt it's going to happen that way, at least in the short timeline. So we're just going to have another layer of technology that needs to be maintained, that needs to be upgraded. So it looks very similar. But one thing I will say on the positive note though is, if you are paying attention, if you are willing to roll up your sleeves, there's never been a better time to take some of the advanced tooling and go address a lot of problems that you were doing manually or by brute force, right? Like all of these cloud products or the database auto tunes itself, auto resizes or auto scales. Now it's may cost you, but boy, is there now solutions to a lot of the problems that almost you needed an expert to do, where now you can almost outsource it to a managed service.\n[12:01] Tobi: Right, right. So you're positive on managed services. Um, in a way, this also leads to you forgetting about like important things that are maybe under the hood. What what are your thoughts on that? Like what you these days like I mean now you had reboot, right? You you're you're you're retired. If you ever would like to start something again, would you rather prefer Kubernetes or would you would you go for Firebase? Like what would be\n[12:28] Kelsey: Honestly, at this point, none of that really matters. Like seriously. Yeah. This idea where people over index on one tool versus another is has always been insane to me actually. Remember when I was working on Kubernetes, I was working on Kubernetes. And if you were interested in using it as a tool, I was happy to educate you about how it can help solve a problem, one of your problems. But when you zoom out, you have bigger problems than Kubernetes. Kubernetes is not going to solve all of your issues ever, nor is firebase. So there's just tools in the toolbox. So when I think about managed services, I'm thinking about the average company that cannot afford to pay the very best engineer. Right? Most people say, we want the very best people but they don't have the very best pay. So in that scenario, you probably will not be getting the very best people. At least the smart ones that know that they can make much more money somewhere else. So, okay, so you can't afford to hire the very best people. And then even if you did, do you have the ability for them to gain the experience they need to really manage a service well, meaning, hyperfocused. So if you hire someone to be a DBA, will you really let them learn and spend time researching the state of the art of managing the best database? And if they did all of those things, so you managed to hire the very best person. You managed to give that person the time and the space to not only do the maintenance but research the state of the art and participate in all the ongoing discussions. You saw that as a valuable investment. What would the byproduct of that look like if that person worked in house. It would look like a managed service. You wouldn't have to interact with that person, you would probably just have an API or some automation tool that would allow the rest of the organization to just use the byproduct of having that person work at the company, right? That would be the holy Grail. So since most people can't do that, don't know how to do that, or are not willing to invest in that, your very next best option is to use a service from a company that is. And so a lot of managed services are filled with experts that are hyperfocused on one or two products that try to alleviate you from having to do all the investments that I just talked about. So that's why I think managed services are pretty great because in most cases, that's what most people should be doing, especially a small company that doesn't have a large IT team. You're already leaning on big management services. So if I were to build a company today, yes, I would totally start with all managed services, right? The number one managed service, the internet. Most people are not going to run their own cables from their office or from their home to start a business. it makes sense. So you're going to use a managed service from some ISP, internet service provider, and you're going to go for there for your networking. And it just makes sense for your compute and your database. And then maybe there's an inflection point where margins start to be, you know, prohibited because of those managed services, then you have enough ammunition to ask yourself, should I get into this area of expertise as well if it affects my margins?\n[15:49] Tobi: And what what are what are what are your thoughts on like or do you think that many CTOs or many many people out there, many founders, do the wrong step first uh through not going to to managed services, but rather being in or not for the let's say cheap stuff. I mean, I would say like almost all SAS companies that I see and I I also see many SAS companies, they kind of try to go for Kubernetes first and uh try to go for like let's say little managed services or um not not pure simplicity. I mean, for many companies like a a simple server, like a a server in a rack or like a rented server plus uh some managed postgres would be enough, right? Um, is are we are we all doing that wrong or?\n[16:44] Kelsey: No, I think like if you're in a startup mode and you have no customers and you're just building, you're probably going to do what's comfortable. For some people, like let's say, a lot of these founders, a lot of CTOs, they're not like the first year on the job. Some of them have lots of experience. So if your experience is with Kubernetes, then that's the path of least resistance to you. You're like, hey, well I use Kubernetes at my last company, we spent years getting it to a point where it really works well. So now that I'm starting my own company, I'm going to start with the thing that I know best. I know where it breaks, I know where it fails. I can also get a managed version of Kubernetes and just use it as an infrastructure layer and then build my glue on top. So to me that makes a lot of sense. It's the same thing we see with programming languages, right? Like what programming language should you use? Should you use the new exciting language that just came out or should you use the one that you're comfortable with? And I think a lot of people end up just using the thing that they're comfortable with. Also, Kubernetes is just 10 years old. So it's been around for a while. So if it makes sense and that's what you're comfortable with, great. Most of the time you're going to be evolving anyway. So and if you start with a single server, you're probably going to have to evolve away from that single server, right? Because if you have a single server, maybe your focus on things like backup and recovery, but you haven't really thought about scaling horizontally, right? Because you got to delay that decision. Great. Some people are going to start with serverless and, you know, with very few customers, costs are going to be very low. But as customer spike, you may find out that the serverless billing model doesn't align with your billing model. And so then you're probably going to have to evacuate the service serverless tools you're using and then move into more, you know, virtual machines or something like Kubernetes. So, I don't think there's anything wrong. I think the only thing that is wrong is when you fail to evolve. I think that's the part where companies say things like, we will only use Kubernetes for everything. Right? You you write that down. Hey, this company will only use Kubernetes for everything, we won't even look at anything else. And then you get a new customer that needs a feature and you're like, oh, we're going to build it from scratch because Kubernetes, that's what we have to do versus just using a managed service to meet that customer expectation for now, and then having more of a road map to dictate when does it make sense to do something else. So I think that's probably the biggest mistake that I see people make when they make a tech decision. They try to make a permanent decision on day one.\n[19:15] Tobi: Oh. Uh in larger companies there's often this tech radar. Um, that that is missing and smaller, which often leads also to like if you're not if you don't have that presence, like which technology do I embrace and which technology do I rather want to get rid of. Um do you do you think that um, this is this is something that that um, like people should should do from the start, like having like pure visibility and also paying paying back tech debt or is that like how do you see that? What's your perspective on that?\n[19:53] Kelsey: you do what's necessary. If you got three people on your team, you just do what's necessary. Yeah, right? Like if you have a bunch of tech debt but it still works, you're probably going to delay that because you have something more important to work on. So I think that's just kind of normal. But I do think staying paying attention. So the things that I would do, let's just speak from maybe like real world experience. Real world experience, I think if you're on a particular set of technology, you don't want to use a piece of technology where the community is dying and you're going to find yourself on an island. So let's say you're still writing everything in C. Well, look, C is a fine language. I don't want anyone that loves C to bash me or anything, but that community isn't growing. Finding people that really want to write C code all day is going to be a challenge. And so maybe C was a great choice 10, 15, 20, 30 years ago, but it may not be the best choice now. So then if you start to see that you're on that wrong trajectory, you may start planning your pivot. Right? Maybe you still like Z, so you may look at Zig where you can interrupt with some new ways of doing things and keep the C code base you have and evolve very slowly. Or maybe you're like, hey, for the next project, we're going to optimize for a programming language that has the libraries we want to use. So maybe MCPs is so exciting and I don't see a lot of C implementations for MCP servers. So in that world, you may decide that your next language will be rust because there's a good SDK for adding MCPs to your infrastructure. So I think of it more of of that way that you got to do what's in front of you. But yeah, I think if you're going to be a technologist and and a practitioner, you should always pay attention. For some people, that's just watching hacker news and see what lands on the front page and clicking on a few links. Uh but I think just talking to your peers, hey, what are you all doing? Is there anything interesting you see? Also, I think you can get a lot of information from the vendors and the founders themselves, right? A lot of you are buying products and services from other companies. Just look at their roadmap. Right? You say, hey, what's on your roadmap? Why are you investing in these things, Google, Microsoft, Amazon, Oracle? Why does your roadmap look like this? Let me talk to the people who spent a bunch of time making this decision. So I don't think you have to do all of this from scratch. You can just literally talk and listen and probably get a whole cheat code from doing that.\n[22:13] Tobi: At Google, as far as I know, you warned engineers that they would ultimately fail if they couldn't link commits to revenue. Um and and you just you just mentioned like uh do the things that matter for your business or do the things that are the right things. Um do you think that this is um, let's say a trend or this is something that that like all engineers have to have to hop on? Because I I see like many engineers still failing with with with linking really uh output to outcome. Um, how how do you feel about that?\n[22:47] Kelsey: If you can't link your work to revenue, then you're in for a surprise. I think that's probably more accurate. So for example, let's say you're a great engineer and the team relies on you and you get things done. You're a solid engineer. No matter what team you're on, it's going to be a great outcome for you for the most part. But let's say you have a manager that is not paying attention to the overall organization. Right? Let's say they're not paying attention to trends, they're not paying attention to where customers are investing their dollars, they're not paying attention to the competition. They don't have any idea if they're contributing to the future of the business or not. So, you have no idea and you kind of trust that someone on the team, mean if it's not you, that your team lead or your manager understands if the work that they're accepting and their road map reflects what's important to the organization. And so I think making sure that you're on a team where there is somewhere in the chain, whether it's your VP, your director, or your team lead, that is working on the right thing. Now, from an engineer's perspective, so where does the surprise come from? You've done great work. You're the best engineer at the whole company. You just happened to be working on the wrong thing. And so they decide to lay off the entire team. And you look around and you're like, hey, hey, why am I being laid off? I'm one of the best engineers at this company. It's like, yeah, but we don't know that. All we know is that you're working on the wrong thing and we've decided that we're going to take this part of the org chart and get rid of it. And you're just a casualty of that decision. And so if you're an engineer, what do you do instead? You say, hey, hold on. Let me go look at the other OKRs. to see what other leaders deem as a high priority. Maybe I should listen to the earnings call of the company I work at and listen to what they're promising investors or what they're promising customers. I know a lot of engineers that don't watch their own conference, right? Their company has a conference, they're showing off the road map, they're talking about what customers are expecting from them and what's coming. And so if you're ignoring all of that signal, then you're going to be in a surprise. But if you do pay attention to the signal, what do you do as an engineer? You say, hey, hey, whoa, hold on. Maybe I should be switching teams. Hey, I I might be on the wrong team. I might go interview for another team and say, hey, I'm a really great engineer, I know this stack pretty well, I know this organization pretty well, but I see where things are going. So let me go ahead and make my own career pivot before someone decides to make it for me.\n[25:35] Tobi: Okay. Well that's uh that's a that's a wise uh wise tip uh for for engineers then. Um but do you also like for the CTOs listening, you have a a metric that kind of or that you like that kind of forces people more if you if you show it to folks that forces people more to to think about the the impact they're creating. I mean, revenue for sure, but\n[26:04] Kelsey: well at that level, I always like those quarterly business reviews. You know, when you really listen to the organization talk about the health of the business, right? So we're in this business together and our engineering efforts contribute massively to the products that we sell. And so one thing I like to hear is like I'll listen to the sales team, how's it selling our product? And they'll say, look, we have so many deal blockers that we can't generate any revenue. We're going to all miss our quotas this quarter. You know, our quota was set to this, but given our current product, we're really having a hard time selling against our competitors because they have these capabilities and we don't. So we're waiting patiently for your team to close the capability gap so we can actually have a seat at the table and compete for some of these deals. So when I hear those metrics of like, we can't close deals. Some people like churn, right? We're getting these customers and now they're leaving the platform. So if I was a CTL, it's like, wait, wait, wait, wait, wait. Why are they leaving? So maybe you have to talk to the support team. Hey, we have too many outages. It seems like every week there's an hour of downtime and we've lost trust in our customers. So as a CTO that tells you whoa, whoa, whoa, we may need to slow down new features and focus on reliability. And so, I've been a VP of engineering before and I remember I had to do something very similar where the feedback from support was, we have a very frustrated customer base. Something has to change. And so, one thing I did was say, all right, we're going to do something to make new releases predictable. We're only going to deploy stuff on Tuesdays and Thursdays. That's it. And people like, oh no, a great organization should be able to deploy any time of day, no problem. I like, yeah, but we're not that yet. So until then, we're just going to bring in some predictability into the system to regain trust. And we're going to do something very simple. Tuesday or Thursday. Number one, we're not going to have people getting burnt out trying to do deployments randomly and doing things on the weekends. I want you to enjoy your family and be fresh when you come to work. But two, what happened was, the support team knew that they only need to be really on high alert on Tuesdays and Thursdays because we were going to be shipping something so they can be proactive and tell customers, hey, we're planning to do shipping tomorrow. If you see anything, we're going to be on high alert, you're going to be on high alert. versus the randomness of, well we have no idea when a new release is going to go out, we're going to find out when it breaks. And so I think bringing that calm because I I I paid attention to the support metrics. And I remember having like a team kind of like offsite, but it was in the same building and we were downstairs and they're having like, you know, pizzas and soda. and I remember the lead for support said, I don't know what you all are doing up there, but it has gotten so much better for us down here. And so that predictability, our customers appreciated it, the support team appreciated it. but that's the type of feedback that I think a good CTO does is they calibrate based on listening to different parts of the business and then trying to educate the team like, hey, we have the opportunity to regain trust with our customer base, but we got to do some things different. And I think that's kind of the signals that I like to pay attention to.\n[29:19] Tobi: And in a few cool SAS startups that I've seen, um, also the founders, um, including the CTO were sometimes like doing support for a half a day a week or something. Like even in in more mature companies, I think you can actually learn a lot from that, right? Um and and and and also like getting to know your customers better is a is a very good idea as well.\n[29:46] Kelsey: Oh, 100%. Anytime I see that in an organization, I think it just makes the people doing support feel like they're seen and that their roles are respected. And it's also easier to listen to leaders that spend time in those roles even if it's just a half a day because we know they understand the frontline deeply. We know they have empathy, right? It's not just pie in the sky, everything is a north star, they understand the reality too. So yeah, that's that's probably one of the biggest tricks to being successful in all of technology I can think of.\n[30:14] Tobi: So the topic for today is like minimalist CTO and one one thing I actually love a lot is when I see like super simple, super lean SAS companies that are operated by two, three people, API businesses that are, I don't know, running on Firebase, auto scaling, etc. Now, um, you also mentioned AI earlier and that it just adds like another layer of or potentially adds another layer of complexity to the whole game. Um, what what do you think is the future in terms of like infrastructure and software? Like is it um, like will those do you think those those small tasty bites will survive? Uh how how do you think like a new the new uh layer and the new user user flow for the web will look like in a few years? And how do you think um, software software engineers will play a role there?\n[31:13] Kelsey: Yeah, I mean if you think about that example you gave of a three-person startup, every vendor, every technology makes a bunch of promises, right? So let's just put those to the side. I think your role is to see what promises are actually real right now and pay attention to the ones that are coming. So look, maybe they're saying, hey, if you use Cloud Code, you'll write code faster, or you'll get more feature work done faster. Then I think you owe it to yourself to prove it. If it's true, it's true, let's find out. And so I think when you say tools like Firebase where you can just let the infrastructure do the heavy work, you give up a little bit of control, right? Because if you're going to use tools like Firebase, you have to do things a certain way. You can't just do whatever you want. You have to use their SDKs, you have to use their libraries, and in return, you get a lot of reward from it, right? It's just like mobile apps. If you use Swift and Swift UI, those are SDKs from Apple to build apps for, you know, iPhones and iPads. If you use that SDK, then you get a lot of things for free if you stay on that train. And so I think a company in that kind of situation, that's their job. I'm willing to give up a little control as long as I'm getting much more in return. So I do think in the future, right now if when I look at the current generation of AI, it's almost trying to help us with the grunt work from the legacy systems and how they've evolved over time. So if you think about like configuration management like infrastructure, right? I need a database. And today you can get a database by clicking on your browser, logging into some console, clicking a bunch of things. You have no idea what the thousand options are, right? Because these managed services have evolved over decades, so they're not just three choices to make. You still have to make a dozen choices to get the database you want. Maybe you don't have to manage the database, but you still need to make some decisions. And so over time, the number of decisions you have to make grows even more complex and some of those decisions aren't even compatible with each other. And so we built tools to help us with this. Tools like Terraform where we can play around with the configuration until we get something we want and then we save it. Great. And so now I have a Terraform model that says, Terraform apply database, sweet. So now we have AI. So what is AI bringing to the table? Does it change the way databases work? Well, no, not right now. Yeah. Postgress is still postgress, right? So that database engine works the way it works. Does the API for creating a database change? Right now, the answer is no. It's the same API and the same set of decisions that need to be made. So that stays the same. Now, where does this stuff help? So if you take like a large language model, maybe it's been trained with all the configurations that have ever been posted on GitHub or on the internet. And so maybe it does have an advantage of figuring out what a good permutation looks like. But remember, I think the thing that's still key is, it doesn't matter who makes the decision, whether it's you or the LLM, a decision has to be made. And I'm simplifying this. I'm not talking about necessarily code. I'm just saying something a little bit more simple like configuration. And so if you let the LLM make the decision, it's still your responsibility. And I think that's the part that people are learning about these tools. So it's great that I now have a companion that can make this decision, but I don't think this is drastically different than what was before. I think it's way more convenient. Do not I don't want to sound like I'm underselling the power here. Because I think what we used to do to help us make these type of decisions, we would just search for it. Right? You know, what is the best practice for a database in production? You find stack overflow and someone will say, this is the configuration I always use. And you look at it and say, you know what? That looks better than what I was going to do. So you copy and you paste that and then that's your starting config. If something goes wrong in production, what do you do? You say, oh my God, how do I fix this performance issue? And someone will say, change these two lines in your config. So over the years, your config evolves from all this decision making. And so whether we copying and pasting from stack overflow copy and pasting. Oh yeah, a lot of people are copying and pasting. you know, don't even know what this stuff means, right? And then you get an LLM and you say, give me a production ready config. And ideally it's going to go through a similar process and give you a working config and then your job then is to put it in production and if something doesn't work, then you have to go back through this process. either give a new prompt to say, hey, we're experiencing this in production. and I would like you to address that and then it will make a decision. But I think what's going to happen for most people is we're going to realize that even the decision it makes, you're still probably going to want the expertise and the experience to decide if that decision is good or not. and then you print production. and so I think a lot of software development is decision making. What library should I use to connect to this third- party API? What part of the response should I keep? Should I use this library to authenticate a user or not? So all of these decisions we now have a new companion to do so, but we I don't think the underlying systems have changed very much. So maybe in a decade, we'll start building systems that don't assume all the other things that we currently do now. and I have no idea what those systems would look like.\n[36:49] Tobi: what do you mean? Like a system that writes its own database and doesn't need postgres anymore? something like that?\n[36:56] Kelsey: Why do we even need sequel? Yeah. Right. and if we don't need sequel, then do we need databases? Well, not even flat files. let's just say if I don't need files. yeah. Yeah, why are we using files? Why do we have B trees? Why are we doing structured data the way we do it? Like we we do that because we've evolved from files to indexes on those files, data structures to lead us to those files, files turns into different things like tables and other structures and then we got to back up this stuff. and so all of this has evolved from that Genesis. But what happens in a world where we don't have to start from there? Will we build a different storage engine? if we knew that we didn't have to query it through sequel? And I think you saw that in the no sequel movement, right? Some of those implementations look very different. We saw this in things like big data, right? Where the storage engine and the way it stores data is optimized like a column format for retrieval and not necessarily for things that a sequel database would be good at. And so I think that AI might have the potential to evolve those systems, but maybe it doesn't. Maybe it doesn't. and if it doesn't, then I don't know if we get the grand promise of super intelligence if the systems underneath don't evolve with them.\n[38:17] Tobi: Yeah, right, right. Like someone still needs to maintain and and develop and uh, like progress, um in in infrastructure, right? Uh, and and postgres needs to still evolve, uh, and that's not right now at least not not so much happening by AI itself, potentially developers that use AI, but not much more, right?\n[38:41] Kelsey: And I want to be clear for people thinking about this. So if you think about this deeply, if you take open source postgres and you put the best postgres database administrator in front of it, what would they do? They would watch all the logs, they would watch all the metrics, look for slow queries, you know, they'd pay attention to the operating system, the file system and something goes wrong, they will leap into action. And if you want that to be minimalized in terms of like the impact that you feel, then they may set up like multi master, multi region replication. So even if one region goes down, you can continue doing what you're doing and want another region while they fix this region, put everything back online, and it's like they're not even there. Like imagine having an army of people that could do that. In an evolutionary situation, what would it take for postgres to do it itself? So would it just be postgres or would it look something very different? Would it be more like postgres and your operating system became one thing? So instead of these things working with arbitrary APIs around each other, would you combine the whole stack? so that they're all aware of each other? It'd be more like an appliance. Right? Because if the Linux kernel does something that the database is unaware of, now the database is down of no fault of its own and the database is unaware of how to repair itself because it's not in charge of the file system. The kernel has done something. or maybe it gets context switched because some backup is now running and it doesn't have enough IOPS to respond to the query. But it's unaware of the environment in which it lives. So imagine a system that evolves where the database can deal with its own file system or whatever manager, right, the database management system expands its scope to deal with the network. Will you give it access to your switch? Will you give it access to your routers? Right? If there's a networking issue, will this overseer be able to deal with those layers? And some people think that's way some of these database systems will evolve where the control plane becomes a little bit smarter and it doesn't just deal with the database, it deals with the entire environment. And I think that might be the evolution of where this goes.\n[41:02] Tobi: Yeah, we'll see, yeah. It's uh, still like hard to imagine, but um, I mean, yeah, looking at how the world is is changing, uh it might happen. And what's your what's your perspective then on like Indie hackers and uh, like people building 3 million uh SAS companies in the basement. Like do do you think that this is something that will will still be alive in a few years?\n[41:30] Kelsey: Yes. Because it's like um, you could technically make your own clothes at home. Right? Most people like if you with enough effort, anyone can buy a sewing machine. There are lots of places to buy fabric. The patterns are out there. Most people could in theory make all their own clothes. But they don't. It's never been easier to make your own clothes at home than right now. But most people choose not to. Why? Because maybe you like their style. There are some styles that are exclusive to particular brands. and if you want that style, then you have to go buy from them because they won't sell you the pattern. Maybe you can copy it or study it and make it your own. We try to copy it, yeah. Yeah, but most people just rather do other stuff than manage and maintain the infrastructure to build their own clothes. And I think when it comes to software, I think it does evolve to the point where brand becomes more important than, brand and experience becomes more important than the capability. So I can remember starting in my career, some software was only good because it was the only thing in town. That's it. There was no other software that did that. Think about the day when there was only one tax software. Right? That that's it. If you want to do taxes on your computer, there's only one and that's the one you're going to use. There's some proprietary software. If you want to program this thermostat, you have to use this software. And so I think there'll still always be a world where there's going to be proprietary things where the hardware mandates the use of a particular software package. But let's just say it become very easy to create software. Then I can definitely click a button and say, chat GPT, build me this software. So why would I ever pay for software again? This doesn't make any sense, right? Like today you could say, uh, generate a song and only listen to the music you generate. But that's not what most people want to do. We're still humans. We still like to admire the art and production of other people. So I want to hear a song written by this other person because they're going to take their experience that goes beyond my experience or beyond my imagination and I just want to see what they put out and I want to enjoy it. I think the software is very similar. I want an experience. So I want to book a flight potentially a bit more complex, right? I mean that that uh plays into that as well. Um, I mean you like if you print your own shirt, uh it doesn't have any dependencies on other things than itself, uh while a software typically especially if you're like, I don't know, think of modern software where you have collaboration features etc, there's there's more involved, right?\n[44:16] Kelsey: Well, we're making an assumption. We're making an assumption now that all of that stuff will be available to everybody. Whether it's like a framework, like I've seen like like Ruby on Rails. If you download Ruby on Rails 10 years ago, it had caching built in, web front end, database ORM. It it was just built in the box. You didn't have to do very much to get all those things. So let's just make an assumption that all this stuff evolves. So collaboration features will be a library. Import collaboration. Why not? Right? Like payments have evolved that way. Remember payments used to be a very hard thing. Now you can import stripe and a set payment. That's it. Yeah. Right? So I would imagine a lot of these capabilities evolve. They may be backed by some SAS platform, but let's just say that stuff evolves. So then what are you buying? You're buying someone else's finished product. You just like the way it looks. You like their workflow. You like the way uh it feels when you do your taxes with their software, right? Maybe they have a great workflow and you'd rather just pay for that workflow. So I this is why I think those things become more important. Some people don't have the imagination necessary to put together a great workflow. But someone else may have that and so they may decide to use that instead. So, I I still think that's just kind of where it evolves. So yes, I think those three person indie shops will be more of a thing, just like we see small teams building great open source projects. Those indie shops will now have even more tools to build world class things, right? We saw this with the App store, like Apple gave you the ability to use the Apple SDKs with one person and distribute your software to 300 million people without ever negotiating placement in a box store. That was a game changer. So I don't I don't see why that would stop.\n[46:05] Tobi: I'm with you. I'm with you. I mean there's a lot of like rumors or not rumors but but a lot of like people um, pretending that this might change, also uh like if you look at the whole AI bubble that has a has a special view on software these days, but uh yeah, I I I think you're you're like you have a very wise and and simple view on it. So why should be different than what it was.\n[46:33] Kelsey: Hopefully, it happens right? So what does the world look like if no one has a job? Yeah, right, let's just say there are a few people in the world that have a theory that AI takes over everything. Right, they say there's just no more intellectual work to do because AI is going to take care of all of it except for the people that work on AI, right? Someone's going to maintain the AI systems for a while. So then what does the world look like at that point? Does that mean we get the Star Trek feature we've been promised for a long time where everyone just has a replicator at home, you can print anything you want, you get unlimited entertainment all for free. Right? Like is that is that the thing we're going to be looking at? No one has to work anymore and everyone's going to live a really wonderful life? So, if that's the promise, then yeah, I'm waiting for that. But if we're talking about a world where no one has a job and then no one can get the things that they need, then that's bad. And so I'm trying to figure out which one are people targeting. I'm hoping it's the one where there's an abundance for everyone and there's just better tools that people can use to self-serve. So hopefully we get to that future. Everything else is like, I don't know, man. I hopefully there's a counter balance in place.\n[47:48] Tobi: Yeah, I hope so too. Um, so um one one thing that I still would like to hear from you is like, why or tell us about the moment when you said like, okay, I I I want to live off interest. Like, what was that like pivotal moment in your career when you said like I quit my Google job, I I I stop doing what I'm doing and I I focus on simplicity.\n[48:12] Kelsey: You know, there's that question it's like um, or there's this goal like, I love my job. Right and you hear people say that it's like I love my job. I couldn't imagine doing anything else. And maybe 15 years ago I thought about that. I was like, you can't imagine doing anything else. What happened? If you ask a kid, they can imagine all kind of things. and if you ask most children, none of them will say, I can't imagine not having a 9 to five where I have to go to work every day. That's probably not the highest thing in their imagination. So something happens to you as a person that believes that that is your destiny. The whole universe was created so you can go to work at a nine to five and process email all day and go to meetings. I I don't think that's the goal. So I asked myself like, wow, what would be a better answer? And I didn't have a better answer. And I'm like, well, the reason why I think I don't have a better answer is because I've spent no time thinking about it. I've spent a lot of time on work, I've spent a lot of time getting new skills, staying in the know, staying relevant, making sure that I deliver all the things and it never stops. And I thought about it, if I continue on this path, then I can essentially do this forever. And if I were to do this and I was 65, 70, would I be happy when I looked backwards? I thought about it and the answer would be no. All the accomplishments, all the awards, all those things, I don't think I would be happy with that being my core set of memories. is all the work that I did. What I would rather try to figure out is what does life look like when work isn't the core objective? And and remember, I'm separating like natural work. Like natural work for me today is cleaning the house, pest control, cooking, um, building relationships with friends and family because that stuff should take effort as well. Learning about the things that are around me, maintaining the subsystems in my home, educating myself on how these things work, managing my health. These are natural things that everybody is responsible for. If you don't have a lot of time, then naturally you just pay someone else to do all of these things for you. But this is work that still needs to be done. So, taking out the unnatural work like clock in at 9:00 and build this application. Right? Like it's great for the business, it can definitely make money. I have no problems with capitalism, but it's very unnatural. Some people would deem some of this stuff unnecessary. We're going to build a login system for the trillionth time. Is that really necessary? So, I wanted to take a step back from that type of work. And so once I did that, I had to ask myself a question, well, how much does it cost to buy your time back? As I started making more money in my career, I was like, wow, why are people willing to pay me all this money? Right? You when your salary starts adding zeros to it, you start asking, what value do they see? And if you ask an employer, they're like, hey, the impact that you make here, they can enumerate to justify what they pay you. This is a really great feeling. But then I asked myself, would I buy my time back? Would I be willing to spend as much money as they were for my own time? And when you think about it from that perspective, it changed the way I started saving, it changed the economic moves that I was making. You know, I've been practicing debt freedom for a very long time, but I also came up with like, what is my freedom number? And so my freedom number was one that would allow me to take care of myself, my family for decades on interest alone. Not stock market growth, not some swan event, not some big bet paying off, but just interest. The type of interest you would get from a nation's uh Treasury bonds. And then my lifestyle is so minimal that, you know, I still enjoy myself. I still go on trips to places like Japan and Europe and all these things. So I'm not just sitting here eating cans of beans. So don't worry about that part. But I wanted something that would allow me to just free myself from the grind. And that was it. And so I worked towards that freedom number and when I got there, I decided to cash in and bought my time back. Now, I'm still too busy, right? I still do a lot of advisory stuff, I still do a lot of public speaking, but there's at least four or five days out of the week where I don't think about that stuff. I don't check the email every day. I don't have two email boxes to keep track of. and so now I'm learning how to live. So I spent 25 years learning how to work and I spent the last two and a half years just like learning how to live and it takes a while to make that pivot because everything has been optimized for being good at work and now I'm learning how to not do that.\n[53:30] Tobi: Cool, cool. And can you think of a a moment where you say, oh, I'm so attracted by like grinding again that I jump back into the hamster wheel or?\n[53:42] Kelsey: Oh, no. Never. I mean, I mean, look, there's so I like the idea that all this stuff has evolved and is evolving. I look at the ability to make an impact, but I'm so satisfied with the impact that I've made over the last 25 years. And I think there's some value in appreciating I did a great job. I had a wonderful career. And so I stay close to being able to recycle some of that by being an advisor. So there's lots of founders that are discovering a lot of this stuff for the first time. So being able to coach them, be a mentor to them, um, I help some venture capitalist make investment decisions by doing due diligence. So I'm able to take a lot of that knowledge and expertise and experience and leverage it, but the idea of me going back and grinding I'd rather put 25 years 25 more years into living than doing that. So yeah, let me get 25 years of living and I'll be 70 around then and then I'll have a better answer.\n[54:51] Tobi: Okay, cool. Yeah, we'll all observe that. Um I still have a little surprise for you, which is like the let's say flux capacitor moment. Um, imagine there's a a very hidden hidden Easter egg um in Kubernetes in the vertical pod auto scaler, um which is barely used by people. but um, and um imagine there's there's a a little like cheat where you can basically to the to the to the YAML file, you can you can add a line which allows you to travel back in time, uh, physically, uh to to to to to to to to now your life, um, a few years back when you worked for for the first time at Google. And imagine like we now travel back to that date uh, and we observe yourself for a while and you now have the chance to whisper something into young Kelsey's ears. What what would you whisper? Like having all that knowledge that you have now and give it give it to your younger self.\n[56:00] Kelsey: Well, the thing I would whisper to that person would be, you're on the right track. Don't change anything. And I and and the reason why that's important is that it's the confidence component that contributed to some of the best experiences that I had. You walk on a stage and there's 20, 30,000 people in the audience, that confidence is the thing that allows me to do my very best. or you're trying to solve some technical problem that you've never seen before, it's that confidence that says, trust me. You will eventually figure this out and don't be afraid to get help because the goal is to solve the problem. And so I would have told myself that hey, you're on the right trajectory because you'll be retired at 42. Just stay the course. So yeah, I would have I would have reinforced some things. In terms of like what I what I wish I would have known seven years ago that I know now, um but remember I put a lot of thought into even joining Google in the first place. I was already marching towards this kind of idea of being free from all these things. But the thing I would tell Kelsey back then would be is that all of this is going to change again. Kubernetes is hot right now, but it also is going to go away. And there will be something else that's going to replace it. and the thing is you don't have to chase the new thing either. You can stop. Right? I think that's the thing I would tell him is like, hey, you don't have to ride every hype cycle. Be really great at the one, finish what you start, it's okay to ride this one and then sit on the sidelines and let some other group have a turn. And I think that would have been the the wisest thing because I think you got to still stay focused because the truth is Kubernetes isn't done. There's still a lot of work that needs to be done. It's just not at the forefront of the hype cycle. but it doesn't and I think and the unfortunate thing is a lot of people will now leave the project, right? A lot of people are going to move on from cloud native to go chase the next hype wave. And look, that's fine. I think lots of people should be in command of their own career and make those pivots, but it doesn't mean these projects are finished. I think the worst thing that can happen is that we don't need these things to get abandoned. And if they get abandoned, then they'll never reach their full potential. And so I would just say, hey, these things are worth continuing to invest in. And I would tell myself, speed up the passing of the baton. Identify the next generation of people because I think when I joined Google, I really wasn't thinking about the transition. When people like me kind of fade away from the community, who exactly is taking our place? And so maybe I would have told that person, start identifying that group now and tell them that they can also uh take this place and get them ready to receive that baton when you pass it.\n[59:03] Tobi: Makes a lot. Very wise. I like how you're thinking Kelsey. Uh thanks a lot for for for for this recording. Um and hope to to meet in person. I mean, you're you're traveling to Hamburg, so we'll meet in person. 100%. Um and uh yeah, thanks for your time. Have a have a great time as like uh a retired person in the next 25 years. Uh we we're looking forward to to to observe that.\n[59:31] Kelsey: Awesome. Later.\n[59:32] Tobi: Thanks a lot. Bye.\n[59:34] [outro music]\n[60:22] [outro]",
    "end": 3630.36
  }
]