What Most Engineers Get Wrong About AI and Career | Kelsey Hightower

because everyone thought that the endgame was open AI chat GPT and Nvidia. That's it. Everyone else will just fall in line. End of story. And then Deep Seek comes out and everyone's like, "Oh my god, whoa, whoa, whoa. " So the tragic mistake with Kubernetes number one was everything sucks. This is easy, right? Everything sucks. Your manager sucks. The project sucks. Pearl sucks. Ruby sucks. Go everything sucks. Okay, so this is the baseline. Everything sucks. But what doesn't suck is your ability to make what you want to exist happen. Like we get new iPhones every year. Do we get new versions of you every year? Right now, every engineer I talk to is asking the same question. Is AI going to take my job? And I get why people are worried. Companies are laying off engineers. We're watching AI tools write code in seconds. And the anxiety is real. So I sat down with Kelsey High Totower to talk about this among other topics. For those who don't know him, Kelsey helped build Kubernetes. He worked at Google as a distinguished engineer, which is one of the highest career levels as an individual contributor engineer. And Kelsey has been part of the infrastructure revolution over the past decade from containers to Kubernetes to cloud platforms. and he recently retired from Google and I wanted to get his perspective on what's actually happening with AI and engineering careers in general and what he told me was very different from the usual takes that you hear not more optimistic or more pessimistic just different I would say more grounded in what he has seen happen with technology shifts before so in this conversation we cover a lot we talk about the early days of Kubernetes and the mistakes people made with complexity of Kubernetes that are showing up again with AI today. We also discuss what happened with deepseek and what it reveals about how technology actually evolves. We got into his personal career journey and how he approached learning and growth and you will hear what skills and thinking actually matter especially in the age of AI for engineers specifically.

So this will be a shocker for you but I would like to start with topics about Kubernetes. — Okay. So um let me start by asking you to tell me a little bit of the initial phase and kind of the journey of or the fir the baby steps and the first steps of Kubernetes project and what is like the most um significant difference from how it was in the early phase and the the project Kubernetes and the today's industry standard Kubernetes. — Yeah, I think in the early days, so my perspective, I'm coming from a company called Puppet Labs. Configuration management, DevOps is all the rave. Then we get Docker. Docker changes the game completely. And about a year later, after Docker comes out, I join a company called Core OS. And they build tools like CD uh this container optimized operating system. So Linux optimized for running containers. And we started building our own orchestration called fleet which was a way to manage docker containers across multiple hosts. And then docker decides to build this thing called kubernetes that let lots of companies know red hat docker uset coros and when I first got access to that project maybe a day before it was announced and you kind of look around repository there was no volumes uh there was no concept of a deployment everything was based on orchestration of docker containers very simple but they did introduce this concept of a pod and that's the big game changer. So Docker was pretty successful. Docker had Docker Swarm. MSOS was very popular around this time. So there was no reason to believe that Kubernetes would ever be this popular 10 years later. But they did have some very interesting concepts. And I think the two big things that stood out to me was a declarative API. You know, this whole YAML file object-based thing and then this idea that you should have multiple containers run as a single unit. And so maybe 2014 this was kind of the core of what Kubernetes was and for me it was like perfect. zoom forward 10 years now you have deployments you have all of these other APIs you have CRDs where early on in the Kubernetes project we realized that look these are the core objects you know like a deploy um a pod a network a service an ingress controller — but there was no concept of like what do we do for extensions and so CRDs were born and so now you have things like ISTTO you have all these uh mission controllers doing permission management so I think today there's thousands of people who contribute the Kubernetes and the related ecosystem. So a lot has changed mainly because more people are involved. — So when we're talking about Kubernetes complexity, I mean of course because it became a standard and because so many people wanted to use it, you know, obviously volumes became an issue because then people were like we want to deploy stateful sets in Kubernetes and we want to you know migrate all our databases there and then the you know they hit the you know obstacle of you know what happens with the data right? Um so the storage became this big thing and then people were like we want to deploy our thirdparty stuff with Kubernetes native um interface kind of so you know that kind of created this uh people or groups of people and also open source community who were you know uh creating pro projects and things became standard but there was a lot of development going on Kubernetes. So when you think about this landscape, do you think that Kubernetes emerged uh and developed into a little bit of a controlled chaos or would you say that it actually uh the structure that it developed with is actually pretty consistent and scalable? — Kubernetes itself is simple. You have CD, a key value store. You have an API server that processes input and then that's actually it. That's all it is. Everything else is a controller built to interact with those objects. So the most basic Kubernetes cluster does nothing other than accept objects and stores them in STD. That's a Kubernetes cluster. You want to deploy containers, okay, you need more things. You need an agent. You need a scheduler. You need something to make sure that it's running. And so then you layer on interfaces to Docker. You layer on this concept of scheduling. But again, these are all just kind of in many ways optional components. And so if you want to manage storage, yeah, you can define a storage type and then you have a controller that tries to do the best thing to make that storage real. So in many ways, Kubernetes just layers on top of the existing world. If you think about it, it introduces no new concepts. Zero new concepts were introduced by Kubernetes. Low balancers already existed. We just gave them an API. Uh volumes I think the complexity is the fact that people just want to use a random collection of things, right? I want to use Oracle for this, Java for that, React for this, Cloudflare for that. Once you start trying to assemble all these incompatible things, there's going to be a lot of glue. And I think that glue which existed since shell scripts has always been there. And now it's just like now we're formally articulating that glue and we're just being honest about the complexity this

time. — Um, so I've heard this from a lot of people, a lot of engineers, a lot of projects that say exactly as you said, right? you know you have this Kubernetes out of the box which is not production ready so we need to do some magic there and prepare and configure it so that we can actually make it live um we could already start deploying our applications and workloads into Kubernetes even if it's not you know quote unquote production ready but you know before we switch on you know turn on the lights on Kubernetes cluster and go live then we have to do all this stuff again what is your perspective on like and you know and there are like a lot industry practices, you know, security p best practices and so on that people kind of layer on top of that with different tools and you know they are like you know let's do because we need the security within the Kubernetes cluster let's do obviously the monitoring and observability into the cluster what what is your experience from using Kubernetes cluster in actual like production projects and I would say what are the most bizarre things that you see uh that have been introduced as best practices in the industry. So most of these are not best practices. They're just like how to do things and someone wrote it down. So that's the best we got. That's pretty much what it is. — So the tragic mistake with Kubernetes number one was you could have easily 10 years ago taken a Kubernetes cluster and just run compute workloads in it and been fine. This idea that you have to put metrics in there, put Prometheus in there, put a volume management in the cluster. This is insane. Think about it. For 20 years prior, if you want volumes, you use something like NetApp or you use a cloud provider and you call those APIs and you mount and dismount storage. We've been doing that for 20 years. Kubernetes comes out, people like, "Oh, no, no. Let's not do that. Let's bring storage management in the cluster. Let's bring the metric stack in the cluster. This is insane. You're trying to recreate the last 20 years inside of Kubernetes. This is actually unnecessary. Some people do it because they want a whole cloud provider in a box. — This is exactly what I see happening with AI right now. And I need you to pay attention to this because this pattern will help you avoid mistakes that are costing other engineers their jobs. The mistake that Kelsey mentioned with Kubernetes, putting everything inside the cluster. This is happening again with AI. Companies are trying to AI all the things. They're trying to put AI in every part of their workflow without asking if it actually makes sense or not. And here's a lesson for your career. When you're evaluating any technology, AI or otherwise, ask these three questions. First of all, what problem am I actually trying to solve? Not what's cool or trendy, but what specific problem? Second, is this the simplest solution to that problem? Answer is no. And you should look for something simpler first. And third, what am I giving up by adding this complexity? Because there's always a trade-off. The engineers who become more valuable, who get promoted, who get interesting projects and who build the things that actually work, they are the ones who can resist the hype and focus on solving real problems simply. That skill is more valuable now than ever, especially because AI makes it easier to add complexity without thinking. Now, speaking of solving problems simply, I want to take a moment to thank Control Plane for making this video possible. If you're dealing with Kubernetes complexity or managing infrastructure across different environments, control plane provides what they call a global virtual cloud. Basically, a platform that lets you avoid all of this overhead that we just talked about. You can run your applications across AWS, GCP, Azure, or even your on premises infrastructure all from a single intuitive platform. So you're not switching between different consoles and cloud providers anymore. But here is what I really like about their approach. Your workloads run serverless and they leverage AI autoscaling. So you only pay for what you need and companies are seeing a huge cloud cost reduction because of this somewhere between 60 to 80%. And on top of that, automatic geo routing sends traffic to the healthiest region closest to each user for high availability and low latency worldwide. So definitely check them out at controlplane. com. They have a 30-day free trial. The link is going to be in the description. So now, let me show you what actually works when you keep things

simple. So this is what leads to a lot of the war stories you hear about. What could have easily happened is what we did with VMware, bare metal, what we did with cloud. VMs or compute is one part of the stack. You can have a whole another control plane for your networking part of the stack. And then you can easily configure a thousand clusters from outside the cluster. We've been doing that forever. And so I think a lot of people trip themselves up by trying to put all the pieces all the various control planes. Remember logging is a control plane, storage is a control plane and they put them all in Kubernetes. So to me that's just people playing cloud provider in the box. I understand why they tried it but a lot of that complexity was unnecessary. So in production some of the best use cases I've seen is where people keeps the cluster simple. So most cloud providers what they tend to do is take Kubernetes open source and do all the necessary integration work security networking you name it and then they leave all the other stuff out metrics lives outside database management lives outside right and so then those clusters are pretty stable there are people who run hundreds if not thousands of those and then you have the other extreme where they say hey we don't want to use anything the cloud provider provides everything we're going to do is going to be based on open source we're going to put everything in the cluster now they're competing for resources. Everything is being starved. You started seeing pods get evicted and moving around. They're autoscaling the cluster. I'm like, what — are you doing? — You're trying to recreate the cloud inside of the cloud itself. And that's where I think it leads to so many problems. So people have a hammer. All they see is nails.

Okay. Um let's switch to another category which is extremely trendy right now which is career. So uh we have a lot of people in the community a lot of engineers uh you know there of course there are few engineers who are exceptional like yourself. uh but there are also massive amount of engineers who are thinking what are my next steps uh next career steps so that I can feel secure in my job keep my skills are still relevant 5 10 years from now. I wanna I want to start with a more personal question which is what was your career like a natural transition of career like and how did you feel for you to make that next step like okay I'm going to um go in like did you think this is the project that I'm interested in so that's what I'm going to work on or did you think uh in terms of IT roles instead in terms of professions in terms of this is what I want to uh be doing as part of my like job responsibilities How what is your approach to or what was your approach to developing your career and kind of making that progression? — Well, first step is hard to imagine something you've never seen before. Just it's just almost impossible to ask someone to conceive of something they've never seen before. And so for me, the only jobs I had seen early, right, this is 18 years old. All the jobs I had for the four years prior were like fast food restaurants. That's it. It's all I knew. You can walk there, you can apply, low requirements. I have a job. And then when I graduated high school, it's time to go. And it's like, what type of things could I imagine? And so I remember seeing like an ad for A+ certification. — Mhm. — So I went to the bookstore and I bought the book for $35 and I read it cover to cover, page to page. There was no social media 1999, not the one that I was paying attention to. And so it was kind of me just being laser focused. I didn't know anyone that worked in tech or open source. And so I just read this book as like the authorative way of getting into tech. And so I don't I think I read that book 50 times. I did all the practice exams. Yeah. I mean because it's like I don't have a lot of money. I bought this book. I'm going to get a lot of value. And so I'm learning about memory, motherboards, how everything works. — And then I remember there's a little CD in the back and you put it in your computer and you could take the practice exams. And I just kept taking those exams until I really understood it 100% every time. And I remember when I went to go take the exam for CompTIA's A+ certification. I remember going to the facility and they give you like an hour and maybe even two hours to take the test. I think I was done in 15 minutes — because if you know it, you know it. There's no tricks. There's no things there. So, I was like, "Okay, I think I understand it now. " And as I'm walking out of the facility, there was a job fair. They were hiring people that had A+ and network plus certifications to go around the city and install DSL. So, you would go to businesses or homes and you would hook up highspeed internet access, right? you have to install network drivers, reboot the machine, hook up the DSL, call the ISP, make sure everything looked good, and then you leave. — And so I just got a job and again, it was in front of me, right? So I took one action and another possibility opened up. And as I was doing these network installs, I learned how to run Cat 5 cable. You got to make them by hand. I learned how to test and troubleshoot dlams, the things out in the street. I have all this equipment. And then I noticed one thing is when I was doing this work, a lot of the businesses were like, "Hey, we want to have DSL across eight different computers. " Well, I can't do that as part of this job. So, I started a business where I would come back and do routers and network switches and then eventually become their IT department, opened a computer store. And so, for that first four or five years of tech, I was just following what was in front of me. And every time I acquired new skills, my business was able to offer a new service. So I like oh so as an entrepreneur I saw the benefits of what I put in come back out 5 years later I get married — it's a lot of work running IT business and selling parts and all of these things I say no I'm going to go get a real job and like many people at this point I'm probably 23 24 and I'm looking at the job openings and I'm seeing you need 500 years of mainframe AIX Solaris you need to know Java 2 and I'm like I don't know any of these things and I didn't go to college — and so I was like you know I'm just going to try to just see where my skills are. And I remember interviewing for Google at a Google data center. And those interviews were very rigid around Linux system administration. You better know every command, every switch, and you need to know it quickly and fast. And I remember doing really well in that interview. And I got hired as a system administrator inside of a large Google data center. Right? So this is around 2005. And I was only at that job for maybe five or six months. Why? Because the salary I was getting was okay. But I would look up with these new skills that I just learned at Google, I can make 25% more money. So I went to the next job, to the next job. And I did this for maybe three or four years, just accumulating all these skills. Remember, I'm still in an entrepreneurial mindset. Don't care what everyone else is doing. I don't care what the average is. I just have this illusion of if I put in the work, I'm going to learn these skills, make an impact, and learn to market myself. Fast forward, I get to more stable settings where I'm looking around. And I know a lot of people don't have that mindset. I come in, I do my job, I go home, not doing any extra. And to be honest, look, nothing's personally wrong with that. That's what you want to do. Good luck. I want to push the boundaries. And I started contributing to open source. I started going to meetups. And what I didn't know was when I was going to these meetups, it's like interviewing. When you're on that stage presenting stuff, people are like, "Wow, I think this person is smart. you're painting this perception of who you are because no one will ever see the stuff that you do at your cubicle at one company between nine and five. — And so I was able to kind of branch out and start connecting with people around the world and I was contributing to Python and Dish util and virtual imp then puppet learning Ruby and eventually I end up at Puppet Labs. So now I'm at a tech company and again the pattern continues. Golang comes out. I was contributing to Terraform in the early days of Hashi Corp. that turns into contributing to Etscd and building my own open source project comping on the radar of Core OS and now I'm at Core OS and then I'm you notice the pattern here? — Yeah. — I'm dictating my career path and just putting in the work to get what I wanted. — Okay. Can I can I'm going to dig in there because this is really interesting. Um so you have this curiosity. You have this desire to learn new things. So you're not satisfied. I got this job. I'm cozy here. You know, everything is nice. I'm just going to do this for the next three to five years, which is the standard, right? What is it that motivates you to do that extra work to learn new skills to is it that is it the thought of I'm going to learn this new stuff become more valuable switch to a new position get higher salary repeat or is it also like for example when you started at the beginning that did you feel that excitement of like this is what I should be doing like this is super interesting for me this is exciting and if I make money at you know at the same time awesome like what was what do you think was the driver for you that made you make that next steps so quickly, you know, instead of just sitting there in your cozy job for 3 years and then switching to the next one. — I think there's a combination of being competitive and having this entrepreneurial mindset out of the necessity for survival. So in high school, middle school, I played sports. I ran track. I played football. I played basketball. And in those settings, everyone doesn't make the team. There's only so many slots. And so you're competing. You're even competing with your teammates during try out. Then they eventually become your teammates and then you're competing against the other team. And so doing that for like 10 years, right, as a kid getting to that stage, it's on you to put in the work. And if you're not good enough, then you have to decide if you want to continue practicing after practice and you show up in the game. Everyone's watching. There's accountability. If you're not good, you don't make the team. That's just how it works. And when you're running track, you're alone. It's you against the clock and the other competitors. And then you learn how to lose. win. And you learn that there's always another race. It's not all in one shot. And getting that kind of level of personal responsibility. I learned to be competitive. I learned to enjoy just being able to play. And then you want to be the best and not let down yourself nor your teammates. — So then get into the entrepreneurial mindset knowing that you have to pay people. them first. So if you only make so much money, they get paid first. And then you got to hope everything doesn't fall apart. And so you kind of learn to be tough, mentally tough. You have to learn how to be optimistic even when it looks like there is no hope left. And you have to learn how to create scenarios for good outcomes. Meaning you may go door to door and hand out flyers. — Hey, these services I provide them. Here's our phone number. Give us a call. — So you're trying to manufacture something to happen. So when I get into normal corporate America, none of this goes away. I'm looking at the big picture. I don't need to be at this job for 50 years. I'm trying to learn what is the best. I remember asking someone. I think I was making like $70,000 a year at some point. And I was like, how much can people make? He's like, there are engineers who make millions per year doing roughly the same work you're doing. I'm like, no, no. How is this possible? Like, no, it's true. And then I met some of the people. And when you think about what are they doing that's unique is they have this number one, they're good at what they do. That's step one. Yeah. Step two, other people believe that. And so then you get into a different mode of operation. So you go from applying from a job with this resume and trying to convince the people that you're good to another world where they know you're good and they calling you. They're saying hey we want you here. It's like well if you want me here these are the terms and it changes everything. So for me I wanted to understand what was possible. So for me I never stopped that I just want a good job. That wasn't enough for me mentally. I wanted to know what was possible — and then I kept trying to go to what's possible and then when I got there I didn't stop asking the question what's possible right and then you start to become this person that is like um you're pushing the boundaries and I did it in public and that does a couple of things it shows other people what's possible — right so they may move their boundary and it also shows other people how to see you can't see me as a software engineer you can't just developer advocate you have to see the hold me and then that comes with a bigger price tag than you're used to.

— Okay, this is interesting uh because first of all it is also being exposed to the possibility right knowing that this possibility even exists. So that kind of gave you that motivation to like oh this is possible within the thing that I'm actually already doing with some additional like additional next steps. Did you then use that as a target to kind of re and kind of reverse engineer from that to ah okay this is where I want to go so let me see like which steps I should take based on the people that I know ready to actually reach that level and once you got there do the same. So considering because I try to do that with a lot of our community which is I don't want them just to learn to be safe at their job. I want to kind of excite people to be curious to enjoy the learning you know not necessarily I'm not trying to convince them to be entrepreneurs because you know it comes with a lot of uh additional stuff so that's a whole new topic but even if you want to uh grow your career as an engineer like as an employee to teach them how to enjoy the process versus try to kind of be in defense mode and try to defend like what they know and just stay within the comfort zone. What do you think from and I tried to do it in different ways. What do you think is the best or what do you think would work best on people? Is it showing the possibility? Is it you know fearing them or scaring them to know okay you know if you don't do this then something bad is going to happen. Um is it the positive motivation the negative motivation? Is it um just to direct them towards the things that they actually start enjoying instead of dreading the the job or role that you're that they're doing or maybe even switching the project because they may not enjoy being software developer in this project because you know the project itself sucks and not their job title. Like what do you think would be some of the most influential things for people to kind of get closer to that mindset? So, I'm a inspirational type person. I want people to feel like there is more. I was just at a meetup last night and uh a person walked up to me. She introduced herself. My name is Z. I was like, Z like Zeta. I was like, yeah, Z. She said, five years ago, you respsparked my passion for this work. That's all I wanted to say. Thank you. And I'm thinking like how? I' I've never really met this person. And the people that I do get to spend time with, I always say like everything sucks. This is easy, right? Everything sucks. Your manager sucks. The project sucks. Pearl sucks. Ruby sucks. Go suck. Everything sucks. Okay, so this is the baseline. Everything sucks. But what doesn't suck is your ability to make what you want to exist happen. And then you start figuring out who they are and you try to find that thing that sparks them. So I usually try to share my stories and say, "Listen, I chose to be happy with my situations. " And that means making people smile. Like you know how you're building something. And I'm like, you get that feeling like, okay, I know we're supposed to build these CD pipelines. We're supposed to do this demo on Friday. And I can just have a bad attitude about it. Or I can be like, I can't wait till Friday. I cannot wait to show the team. I got to get my unit test right. I got to do documentation. Let me look at the demo. Okay, it's not spicy enough. Let me add some music to it. jokes in there. Because when I go on stage, I'm trying to present like, how do I want them to feel? And so when I see a software developer that's like, look, I've been doing this for 10 years. I don't know if I want to do this anymore. And I ask them like, what are you doing? Oh, I just write code. I was like, but why are you simplifying everything? Like you have the ability to make things that are in our minds come to life? Is there anything you want to see come to life? And they may start talking about things that they're passionate about. It's like, all right, great. We have something. So now we got to figure out how to go do that. Here's the good news. Your job doesn't have to be the place that satisfies that. You can always just start an open source project, join one, even if it's not successful by industry standards, you still can go just build the thing that you want to see exist in the world and you could take joy for that. So then it removes a little pressure from the company there. So use the company as a funding source to give you the time to build the things that you want to build. And if you do it in the public, you might actually find out that people want you to do that full-time and you get to switch, right? So that's one thing. And I would say this, — when it comes to entrepreneurial thinking, it's not that everyone should quit their jobs and go start a business. Like you said, — that is a whole can of worms. And it doesn't equal success immediately. I want to be my own boss. You may not like your boss after a while. — Yeah. So I think the key about entrepreneurial things is like you need to understand that what is the value you're delivering even if you're an employee when you're just working on something you say am I giving my employer my customer the best value how would you do that am I growing am I better than I was last year like we get new iPhones every year do we get new versions of you every year how have you grown what has improved you learn a new language did you get better at these things some people forget to improve Right? And I used to have this saying, some people have 20 years of one year experience — and they just get stuck. So I just tell people constantly improve or maybe you need a break. But I do think the name of the game is you have to think entrepreneurial. Meaning you have to go search for opportunities. Even at your company, even though you're being assigned boring work, go find the interesting work. Make proposals. Write it down. Say, "Hey, I think we should be doing things in a better way. Something that excites you. " Look, they may still tell you no. But as an entrepreneur, your job is to try and then you have to try to sell it. You got to try to plead your case. — So, I don't know. I just tell people like, hey, there's always more you can do and maybe the company you're at isn't the end all beall whether you get to do it or not.

How do you learn? So tech is obviously like a lot of the technologies are complex especially when you have this approach of let me take this one concept and see not as this one tiny thing but let me see it in the entire ecosystem which is what you do right you like to you know learn the history and put it in the context of the entire thing instead of just learning the syntax of a technology or language. So how do you learn like give me as much details as possible. So I think the order of operations for me is the what, the why, then the how. What is it? Uh why does it exist? So like what is a bike? It's this thing that has two wheels. Why is there a bike? And then people say, "Well, before we were walking, uh we had horses. Uh we had unicycle. We put wheels on wagons. Wagons are big. They can get in narrow spaces. They're expensive. " and someone decided how or to make one. That's the why. So then I might study the history, who invented it, like what was the challenges, what was the earlier designs. I'm so interested in the thing. And then if I'm still interested that I want to know how do you make a bike from scratch and so you look at all the individual elements because once I have the first two, then I have the motivation necessary to finish the how. — So a lot of times people say, I want to learn how to write apps. Like when we teach people how to program, we're going to write code and we didn't give them the other parts. They're just not motiv. It's like this is boring. We're typing text into an IDE. We're going to compile it. This is not why am I doing this? So then they lose motivation quick. — But if I told them that you can go to the moon and when you get there, you're going to find gold and you'll be rich forever. It's like really? Yeah. But — in order to get there, you got to write some code, man. they're going to be they're going to do whatever it takes to write that code because they have the motivation. So that's kind of my formula always. I apply that formula. But the other part is — I pay attention to how I feel. So when people think about like you said boring construction stuff, they forget how they feel when they walk into a clean house, when they feel safe at night, when they go to sleep and wake up and feel energized to go do things the next day. This learning approach that Kelsey just described is exactly why some engineers are irreplaceable and others are worried about their jobs. And I need you to understand this difference. Notice what he said. He learns the what, the why, and then the how. Most engineers will skip straight to the how. They want to know how to use the tool, how to write the code, how to configure the system. They don't understand what problems it solves or why it exists in the first place. And this is exactly why AI is so threatening to some engineers because if all you know is the how, then yes, AI can replace you. AI is really good at the how. You give it a problem and it can figure out how to implement a solution, especially for common repeatable patterns. So here's my practical advice, and I'm always advocating for this. When you're learning anything new, especially AI tools, any technologies, spend more time on the what and why than on the how. Ask yourself what problem does this solve? Why does this approach even exist? What were people doing before this solution? And what was wrong with that approach? If you can answer those questions before learning any technology, then the how becomes way easier. And more importantly, you become the kind of engineer that companies value the most, not the kind that AI can easily replace. because understanding problems is usually harder than implementing solutions to those problems. And that's where your value comes in. Now, here is where things pivot a little bit because Kelsey and I got into a really interesting discussion of mindset and life philosophy and he mentioned something very profound for me. So, let me share it with you.

Awesome. Really, really interesting. Um, all right. So, a couple of wrap-up questions that I have for you. First of all, what is I would ask it this way. What occupies currently 80% of your mental headsp space? — Uh, so I spent 25 years learning to get really good at working and now I'm spending all of my time learning how to live. So, when it's time to go somewhere, I'm going. Birthday party, I'm going. When we went to Germany and I had that keynote, uh, one of our friends that we haven't seen in 14 years lives in, um, right outside of, uh, Vienna. And so we decided to modify the trip and just go because I'm really optimizing these once in a-lifetime things like seeing people on the other side of the world or going on a hike. So it's like almost learning how to live, right? So became a distinguished engineer, but you don't want to be a junior human. And so 80% of my time is really valuing what it takes for society to do its thing because I'm retired now. And when you think about why anyone in the world can retire while everyone else works is because everyone else is working, keeping things working. All right? So now I'm trying to find a new appreciation for all the work that people do. And that means learning these new trade skills and all these other things. So a lot of my time is occupied from like, man, freedom and peace is so valuable. Like I don't we don't get a lot of time to experience it. You know, you get off work, the weekend is never long enough. But imagine having a little bit more time on your hands where you can kind of pick and choose what you do and what you get involved in. And for me, I'm trying to slow down. There's this phrase called uh slow is pro. When you can slow down and do it right, that's like professionals get to do that. I know what to do and I'm going to slow it down to do it correctly. We're not going to skip any steps. I can afford to go slow now. And so I'm trying to make sure that I get the best of it. — Is it difficult to do for you? Like was the trans transition especially at the beginning difficult? Like did you wake up on some days and were you like what am I supposed to do today or you know what how do I fill my calendar you know this habit of you know being in this work mode and this ambitious mode and then suddenly like that is a big switch so was it difficult for you is it still difficult — so I think I learned with this because when I was like 20 something years old became a minimalist so I don't really care too much about like jewelry and all these things I buy what's necessary doesn't mean I buy the cheapest thing I by the right thing. And so I learned to be very intentional about the things I acquire and the things that I do. So that's been 20 years in the making. So intentionality was always there. But the thing that I never accounted for, all of this ambition, all this success, all of these failures, they build up a really big ego. — And I was very careful not to let my ego treat people bad or become a primadana or do anything like that. I tried my very best to be a very respectable person and all of those things. But there is something when you walk into KubeCon and everyone knows who you are. There's something to the nice comments and those nice emails, right? And when you look at them, it feels really, really good. And then when you decide to kind of retire, there is this question, what happens when all of that goes away? Like when I left Twitter to just use blue sky only, I left hundreds of thousands of followers there. And one day I asked myself like, why am I so afraid to leave th those numbers over there? And I realized it was my ego. So the hardest part was the ego part. I'm no longer a distinguished engineer at Google. I'm no longer necessarily going to have people ask me questions about certain things. So that was the biggest one. I think it took about two or three months to be like, I literally don't care. And it turns out that I've been as busy as ever. I'm still giving keynotes, but you know what? This time most people don't care about Kubernetes or what Google is doing. Kelsey, how do you think about these things? What is your philosophy on these things? we would love your opinion about these things because I think they feel that all of my experience ends up being something that is inspirational to other people. And so the hardest part was getting rid of the ego. And now that I think I've kind of understood where my ego plays into all of this, it doesn't really matter what the title is anymore. It's just kind of nice being who I am. Look, all the other stuff is still there. It doesn't go away as fast as you think it does. And I just choose to continue to being helpful. And the scale doesn't matter. That's another thing that I had to learn to let go. I don't really care about the scale, the number of views, the number of this, that, and the other. People will p me on LinkedIn, don't know who this person is. I will give them a link and we will just talk one-on-one to ideally hopefully I can inspire them to feel a little bit better about their current situation. So, again, I can afford to go slow now. — Interesting. Yeah. Um, it's for me specifically, it's interesting because I'm very much in a hustle mode. for pizza completely different and you should do that all there's a season for it that's your season you do it you knock it out of the park — but just know when the time comes that you want to stop you've earned it — yeah because I've always said actually um because a lot like all my friends have known that you know this is my character and I've always said with a conviction that I would be 80 years old or maybe you know 90 year years old and still be doing this and thinking about like the next project or the next business idea. But yeah, as you said, you know, you never know how your life philosophy changes, you know, what events going to affect you. But it's really interesting to hear it from you.

Um, so the last question I have for you is what is something that you are looking forward to the most right now? — What am I looking forward to the most? I mean, there's a collection of things. One is I'm always looking forward to one day people realizing that they don't have to be so mean to each other. Like just I just hope one day people just really wake up collectively like nine billion people at the same time and say we don't have to be mean to each other. Seriously, just like that would be so amazing because there's so many other problems that are hard to solve that would still take a big collective effort to solve. But like maybe we don't need the additional challenge of being mean to each other. Like so that one that's like number one like when it comes to like technology I'm really looking forward to 10 years from now so we can analyze this AI hype wave right like what parts of it were true how does society choose to leverage this technology because that's still a choice no matter how powerful this stuff gets it's still a choice whether we use it or not right all technologies present that situation and so I think there's something around humanity and giving people purpose giving them work to do meaningful work to do them being able to earn their living if that that's what they want to do. Do we still preserve that or do we allow AI to dictate society or will it be the other way around? So, I'm hoping that in 10 years that story becomes way clearer that we decide that we are in control of society and we will regulate this technology to where we would like it to live versus the other way around. Because right now I think there are some parts of the conversation that are like AI will dictate your life. AI will dictate what job you can have, what art you will create, how you were created. And I just don't like that scenario. I prefer the other scenario where humans dictate how these things get used to our benefit and not the other way around. — Which scenario do you think is more likely? Would you say 50/50 or do you tend to one of them? One thing I love about open source is the fact that it has a way of correcting, right? balancing the scales a little bit. And there's various projects, but I remember when Deep Seek came out. Oh, it was so great to see this because everyone thought that the endgame was Open AI, Chat GBT, and Nvidia. That's it. Everyone else would just fall in line. End of story. And then Deep Seek comes out and everyone's like, "Oh my god, whoa, whoa, whoa. " And these guys like, "Yeah, look, maybe they copied some parts, but who cares? " — Yeah. — This is the power of open source. We take the best ideas and we democratize them. And so when they did that, it reset the thinking a little bit, right? Whoa, whoa. Looks like open source is going to be competitive here. Nvidia isn't the only game in town. And going around the world, I'm seeing other countries getting inspired that, yo, wait a minute. We can build things, too. We can create compete, too. We have good ideas. And so, the way I'm thinking is that humans will do what they normally do. They will show up and leverage all of our tools. There's nine billion people in the world. I don't think we're going to rely on just like a few million of them to decide what happens to everybody else. That's insane. And so, as great as this AI train is moving, let's not forget the momentum that we've been building behind open source for the last 30 years. And I think if I had to bet, I think the inertia from open source, the appetite for community to continue to share and care about each other. We see this with recipes, right? People come up with an amazing dish. They cook it for other people. They figure out the recipe and they share with each other. And I don't think that stops when it comes to things like technology because we've seen it with operating systems. protocols. I don't know why we won't see with AI, especially once we democratize like the hardware and the rest of the stack. So my bet is most people are good. Most people want to do good things and if we give them the tools to do that, they will. Let me make this really concrete for you because

what Kelsey just said about choice is the most important thing you need to understand right now. A lot of engineers are treating AI like it's this external force that's happening to them. Like they're victims of this technology wave. But that's a completely wrong perspective. You have agency here. You have control. You get to decide how to use AI in your work and in your career in general. Think about what happened with cloud computing. When AWS first came out, there were system administrators who were terrified their jobs would disappear. And you know what? Some jobs did change. Some of those jobs did disappear. But the engineers who survived and even became more valuable later on were the ones who said, "Okay, this is the new reality. This is the change that is inevitable. So, let me learn how cloud works. Let me understand where it makes sense. this is going. How I can improve my skills to match them to the current or near future reality. And the same thing is happening with AI right now. Maybe at a faster speed, maybe at a more powerful scale, but it's still the same pattern. Companies are going to use AI. That's already decided. So the question is are you going to be the engineer who understands how to use it properly or how to learn skills that are going to become much more relevant in the industry with the AI development or are you going to be the one who gets replaced by AI or by human who invests in their skills. So here is what you need to focus on. First of all, learn and understand on a basic level how AI models actually work. Not at a PhD level with complete deep down, but just understand what they're good at and what they are terrible at by knowing how it works, how the mechanism works in the background. Second, start experimenting with AI tools in your current work for your current use cases and see where they save you time, where they create more problems because you will find use cases for both of them. And third and this is the most important one probably focus on the skills that AI cannot do which is understanding business problems communicating with the non-technical people making judgment and decision calls about architecture system design and so on and the deepseek moment that Kelsey mentioned is actually very important so I want to highlight that and make sure you understand why this matters for your career when deepseek came out it broke the entire narrative that only big tech companies with unlimited budgets could build competitive AI. So everyone assumed you needed OpenAI's resources or Google's infrastructure. And then this relatively small team showed up and proved all of that wrong. So what does it mean for you as an engineer? It means the same thing that happened with cloud infrastructure, with Kubernetes, with every major technology shift, which is that the tools get democratized. They become accessible and suddenly the competitive advantage is not about who has the fanciest AI tools. It's about who understands the problems that they are trying to solve. I see so many engineers right now panicking in full anxiety thinking that they need to become AI experts overnight and they need to learn these AI platforms and tools and skip all the basics and fundamentals because that's where the trend is going. But that's not what the industry needs. That's not what companies are looking for. Look at job descriptions of DevOps engineers, cloud engineers. Not single one of them mention knowledge of AI tools and platforms. Isn't that interesting? Because what companies actually need are engineers who understand the fundamentals, who understand the systems, who can integrate AI and who can then use AI tools and integrate them where it makes sense, not everywhere, but where it actually makes sense and who can tell the companies when the AI is not the solution for a specific task. And that skill of understanding the fundamentals, the basics, the systems to be able to make those decisions is a skill that does not get replaced by AI. It actually gets more valuable because now you have to make more decisions because of AI development. And the most important perspective shift that I want you to get is that you have control over this. You get to decide how you use AI, what skills you build, and where you focus your energy. So that's really what this

conversation comes down to. Whether it's AI, Kubernetes, or the next technology that comes along. The question is not whether the tool will replace you. The question is whether you are making the choices that keep you valuable. Kelsey just said something really important. Do we get new versions of you every year? Are you improving? Are you searching for opportunities? Or are you stuck doing the same thing you did 5 years ago, just waiting for the next wave to decide your fate? AI is a tool, a powerful tool, yes, but still a tool. And like any tool, it amplifies what you bring to it. If you only know how to write code, then AI makes you less valuable because it can write code, too. But if you understand problems, if you can communicate with people, if you can make good decisions about architecture and tradeoffs, then AI makes you more powerful and more valuable because it handles the repetitive parts while you focus on the hard problems. So the engineers who are going to thrive and really become outstanding in the next 10 years are the ones who understand this. They're not trying to compete with AI on writing code or configuration scripts. They're using AI to write code faster so they can spend more time on the things that actually matter like understanding the business value, talking to users, designing systems and architecture that solve real problems, finding bottlenecks, making decisions that require context and experience. And most importantly, they are not standing still. They're constantly learning and improving. They're searching for opportunities. They are curious instead of anxious and afraid and they are building things that they want to see exist in the world. Now, if you take one thing away from this conversation, let it be this. Stop worrying about AI replacing you and start thinking about how you can use AI to become better at the parts of engineering that are most valuable for projects and companies and focus on skills that will allow you to keep it systems simple instead of adding complexity for the sake of trendiness. And most importantly, remember that you have agency. You have control. You get to decide how AI fits into your career instead of the other way around. And that's how you build a career that lasts for decades, regardless of what technology comes next. Now, I really hope you found this valuable. Let me know in the comments what specific part resonated with you the most and why. So, share it with me and everyone in the community. And if you want to learn more about building DevOps skills that stay relevant regardless of the new technologies and AI, then make sure to check out the links in the video description. And as always, thanks for watching till the end and I'll see you in the next video.