Kelsey Hightower has worn every hat possible throughout his career in tech, and enjoys leadership roles focused on making things happen and shipping software. He is a developer advocate and a strong open source advocate focused on building simple tools that make people smile. Kelsey is an expert in Kubernetes and has written a book about it called "Kubernetes: Up and Running: Dive into the Future of Infrastructure" (link in show notes). When he is not slinging Go code, you can catch him giving technical workshops covering everything from programming to system administration. Learn how Kelsey went from tech support to dev advocate to keynote speaker!
For full episode shown notes click here
Kelsey Hightower has worn every hat possible throughout his career in tech, and enjoys leadership roles focused on making things happen and shipping software. He is a developer advocate and a strong open source advocate focused on building simple tools that make people smile. Kelsey is an expert in Kubernetes and has written a book about it called "Kubernetes: Up and Running: Dive into the Future of Infrastructure" (link in show notes). When he is not slinging Go code, you can catch him giving technical workshops covering everything from programming to system administration. Learn how Kelsey went from tech support to dev advocate to keynote speaker!
For full episode shown notes click here
[inaudible].
Speaker 2:This podcast is brought to you by slumber. Do you ever have trouble falling asleep? Maybe can't stop thinking about a bad day or all the things you need to do tomorrow, soon enough, it's 3:00 AM you're not alone. One in three Americans report not getting the sleep they need and you need great sleep in order to thrive in whatever you're doing better. Sleep helps improve performance. Whether you're trying to climb the corporate ladder or you're just trying to learn a new skill. That's why we're partnering with slumber. The number one app for sleep. With slumber, you get a library of over 100 calming stories and meditations designed to help you fall asleep fast. Slumbers stories and meditations are especially designed to help you drift off peacefully. I should know I've not only worked with the team over at slumber firsthand, but I've also been a user of slumber ever since I saw it in action. As someone who spends a hundred plus nights in a hotel for work, a good night's sleep is critical to my job function. Slumber helps me get that night of sleep. Don't just take my word for it though. Slumber has over 8,005 star reviews and was recently featured as Apple's app of the day. Join over 1 million people and try and slumber for a great night's sleep. Search the Apple app store for slumber download tonight and get a seven day free trial.
Speaker 3:Hello everyone and welcome back to the development or podcast. I'm your host grant Ingersoll and my goal in each and every episode is to highlight all the different roles that go into building a great tech company as well as the path people take to get to this point in their career. On the show today is a self-taught developer who's had a variety of both individual contributor and leadership roles focused on shipping product that customers actually want to use these days. He's a developer and open source advocate who in addition to still coding is a tech author, an in demand keynote speaker, primarily focused on two big emerging trends in technology, serverless applications and container management and orchestration via project name Kubernetes, which of course will link up in the show notes. Please welcome to the show Kelsey Hightower. Kelsey, great to have you here.
Speaker 4:Awesome. Glad to be here
Speaker 3:at Kelsey. You know, thanks for joining me. I mean in, in one of your bio's online it says you've, you've worn pretty much every possible hat throughout your career. So how about we start things off then by you just spending some time introducing all those different hats.
Speaker 4:Yeah, so I started out and you know more than that tech support role, you know, answered the phone, give people support and web hosting. So I used to at a company called server beach and owned by a company called one, and this is back in the day before cloud, right? When you're just getting like a$5 shared VPC or if you really had some cash, you can get your own server, like one no VPC, you get that server and then of course you don't know what you're doing. So you call whatever the one 800 number is and then someone would help you with your Linux problems, maybe patching. Back then people were running things like class cleaning, little web UI to help you set up email and domain. And so I kind of cut my teeth on that customer service part. So you have a lot of empathy for people who just want to use the technology and you've got to have those quick answers, right? So you need to learn a lot about a lot of things and just have those quick answers. And at that job I realized that[inaudible] that's probably one of the most valuable assets you can have is if you can get people back on track so they can focus on the things that they were doing before the problem came up. That's where the gold is, right? So whether you're a system administrator, which I was classified at as then, or you're a director of a whole engineering org. Yeah, that's kind of the goal is to work towards being able to do that. And there's really many avenues to do that. So when I look over my career, I've taken that theme across lots of roles, whether a system administrator, I've worked at companies like puppet labs that produce these configuration management tools where you kind of write infrastructure as code to deploy your stuff. And there was a big connection to the open source community where your engineering skills and the ability to solve people's problems and understand them all came to play and just variations of management, engineering system administrator across multiple verticals and industries but still working beyond the title regardless of what it is.
Speaker 3:Wow, that's great. And I think I've seen a few talks of yours on this notion around customer empathy and this is one of the things I try to do with my devs when I hire is like, Hey, you know, you need to come in and spend some time actually understanding customer problems in order to be more effective engineer. Maybe expand on on some of your thoughts there because I know you've put out some really good content around uh, you know, this notion of, of being customer focused within engineering.
Speaker 4:Yeah. So I, I think, you know, analogies help people best. And I think in these regards, if you think about if you are a painter and you paint houses for a living, that's what you do. You have the best tools, you do it the best. And then someone says, I would like you to paint my house and I'm going to go on vacation. And when I come back I want my house to be painted. And you don't ask any other questions. You just paint the house. What your favorite color, what you think is hot, what you think they want. So you just guessed the whole time. And the thing is that's not very customer driven. You're just doing something. Yeah, you got the house painted, you've been got it painted on time, maybe even under budget microarray, but then the customer comes back from vacation is like Whoa, w what? Why is it this color? And also why did you paint the brick? No, I didn't tell you to paint the brick. Like why did you, why would you, who would even do that? So the customer empathy part is about as a customer, how would they want this to go? So ideally a customer may want to know or may even pick their own paint choices. So when you start to think about a business, a painting might want to walk around with samples of colors so that the user can pick a color before they leave. You may ask them come and things like, should I paint the brick or not? Most customers don't get their Britt painted as a homeowner. I wouldn't want someone to paint my brick either. So those are the things that give you empathy so that way you don't just make up things as you go and it just makes you better at your job. And we translate that to software engineering where a lot of times engineers will get a task from maybe a product manager or maybe a bug report. And if you blindly go implement that thing that's very equivalent to painting the brick. What you want to know is like what pain is the customer experiencing? Can I reproduce it with my own hands? And you start to think and feels like, Hmm, I see the problem. I think I have a solution that will address that and maybe even delight the customer.
Speaker 3:Yeah, that makes a lot of sense. And, um, I imagine then that bringing that forward into your career now or into your role now perhaps can, can you spend some time talking about your role in Kubernetes and, and uh, you know, this position of developer advocate, if you will?
Speaker 4:Yeah. So you know, if you strip away the titles, the day to day is to be customer zero yourself. So you gotta use this stuff. You've gotta be building with this stuff, right? So I'm not necessarily building a company myself anymore on these, I've done that in the past, but I do try to deploy the things that real people would deploy. I try to tweak and tune them. I try to follow performance guys to get all the performance out of these deployed things. And then what you start to find out as you hit the friction first you say, wow, it's way too hard to configure my sequel on Coobernetti's should I even be doing this? And if I was to do this, what's missing from communities to make this happen? Now as a customer myself, customer zero, I only have a finite set of use cases, right? I can't explore everything. So one thing to keep myself grounded and to provide, you know, a great feedback loop. I love to go onsite. Well our customers, whether they're startups, large existing companies, you can think the fortune 200 and I like to just spend time on a whiteboard. What are you trying to do? Put it on the whiteboard and I bring my computer and I like to try to answer these questions with either quick prototypes, maybe show them exactly how I would go about it. And you just riff a little bit and then I come back and say, wow, our product is way too hard. After that road, after that road trip, a meeting with various customers, different verticals, it's way too hard to do such a task. Their product has to get better. Here's my prototype on what better looks like. We have design docs internally at Google. You can work with product teams to specify that thing, but you do it in such a way that when anyone reads it or touches the prototype, they really feel the customer experience. So then when we ship the product, the customer is like, wow, so when gets it that built this.
Speaker 3:Yeah. So I imagine that, I mean, you know, that's, that's a really interesting role in the fact that you know, you've gotta be really quick on your feet, right? B, you've got to be able to kind of code on the, on the spot there, right? Or at least be able to kind of wire together things and then see, you know, be uh, being a really good listener. What other kinds of skills go into those kinds of scenarios where you're, you know, just right there on the hot seat if you will. And, and this, this account may or may not, you know, kind of may hinge on, on your actions there.
Speaker 4:Yeah, that's a really good point where there's lots of deals where, you know, all sales organizations have what they call the wind wire, right? You see your name as someone who contributed to the win. And some of these deals are pretty large. And in those wind wires, they call out the impact that you've made to either move the needle or cause the needle to drop and the customer get on board. And so when you start to think about the skills here, you know, when you think about the skills in this, in this kind of role, someone introduced me to jazz, right? I always knew of the drama. They're like, what? Why are people so, you know, fascinated with jazz, right? I love my hip hop, I love RMB. And someone said, when you listen to jazz, a lot of it is improv, right? When you go see a live jazz band, that song that you know from them, they just go into play together and just try new things and they just go with the flow. And it's very organic. It's very natural and it's quick on their feet because they're really great musicians. So nothing really throws them off, right? You can go off and do something new on stage and they'll just roll with it. Actually. They're expecting it. So as a, as a customer myself, I'm always playing with our products and services and just understanding what the industry is doing. And that's like me learning how to play various instruments, how to tune my own guitar, how to make sure that no matter what the vibe is, when it's time to go, I can adjust on the fly, right? Because I know the instrument well. I'm not just trying to play the exact notes or the exact song as written, I'm okay, I can go left and I can go right and I can bring it back into the center and make it feel natural. So that's what I think the number one skill set is the flexibility and just knowing how things work and map that to just real world context. And that really makes you clever. So I would say the number one skill where I've developed that as, as a system administrator, right? You're, you're trying to manage software that you didn't write, you deploy it, right? It falls over. You get these cryptic messages in the long, all people want is that thing back up and running as quickly as possible. So you get real clever real fast.
Speaker 3:Yeah. The good old, uh, reboot. Always. Uh, try that one. Yeah, that's fantastic. And I think that, you know, I've seen that in my own career too. And, and you know, the beauty though a, of a role like yours, unlike the jazz is, it's okay sometimes to say, you know what? I don't know, but you can't just say, I don't know. You have to say, I don't know. But let me get back to you. I will find out. I know somebody who knows. And, and that perhaps leads then into my next question is like, you know, perhaps reflect on, and one of the consistent themes on this show so far has been about how you go about building relationships, right? And, and in your case, you're building relationships with the customers, but you also have to build relationships into the community, into your internal development teams so that there's this trust factor that Kelsey's a guy who's gonna, who's gonna tell us the truth. He's gonna tell us when he doesn't know about it. And you know, spend some time, you know, perhaps reflecting a little bit on, on some of those key relationships and how you've built them.
Speaker 4:Yeah, I would say the last 10 years I've been very careful not to go on social media and talk about things that I haven't put my own hands on. Right. I want to touch it and just say, what does this feel like to me? What I, what I use it in my current context, what I use it to solve past problems. Is this thing legit or not? And once you start to be, once you have that own hands on experience, it's easier to be authentic as long as you keep it real. Like you can't, you can't be a paid talking head. Right? You can't say, Hey Kelsey, I would like you to tweet this or I would like you to say this. Exactly. That's not very authentic. People want people who are authentic, even if you're wrong. Yeah. They will appreciate you putting an opinion as long as it's rooted in honesty. So over 10 years of working in these open source communities, you start to build a reputation. I have a lot of popular libraries on get hub where scratching my own itch, you open it up for others to use. So that whole notion of a person who is building things, sharing things really goes a long way in building community and trust because you know, some of these projects are, you know, three, four or five years old, you're sharing knowledge so you're really impacting the careers of other people and you start to do that long enough. So before going to Google, I kind of had a decent[inaudible] no community vibe going. I had a good social media presence where I kind of had a name for myself built around this integrity and this trust and also the skills or you can see a lot of my code on get hub. So you know that there's not a lot to assume or guess about my abilities. And then what you do is I spent a majority of my career making people better. Meaning I think someone just tweeted yesterday, I, you know, they pay me on a DM and said, Hey Kelsey, have a question about something. Just want to know if I can get your 2 cents and I recommend it. Did they choose their mode of communication that they're comfortable with? And we just do it live back and forth and all your only goal there is I want this person to be the best person they could be. And let me give all of my secrets to them and look forward to what they can go and accomplish with it and really boost their energy levels, boost their confidence levels to the point where they go shine and do more for others. And if you do that for six, seven years, you build a base of people who you've supported and will be there to support you.
Speaker 3:Wow. That's, yeah, that's fantastic advice. I mean, uh, uh, you know, I think so many of us in the, in the tech community, you just think even if you're a contributor to open source, it's just like, Hey, here's the code, here's the code. But, but, you know, thinking of it as a, as a way of building trust amongst, uh, you know, fellow humans, it's a really fantastic way of looking at it. You know, speaking to the code, I think in doing my research and in the opening, uh, I said, and correct me if I'm wrong, that you were self taught on coding. So you know, what's the backstory there? How'd you, you know, you're in tech support and, and you say, well, Hey, this coding thing doesn't look so hard. Is that, is that how it got going? Or you know, what's, what's the story there?
Speaker 4:Yeah. So I elected not to go to college. Right. So, you know, I grew up single mom, you know, working fast food job and you're like, you know, I didn't know anyone in my family that has ever had a tech job. So that really wasn't a career path early for me. It's one of these things where I don't plan on working and fast food all my life at a high school. So what else do you want to do? And I remember how assessable I thought learning tech was right. I remember going to like Barnes and noble. Yeah. You pick up some of those books and those books, like for$35 you get hundreds of pages of just knowledge and wisdom and how to do something. So I committed myself deeply to just starting to understand Linux, how the Colonel worked, bill my own distro, just just entrenched in it. And then I decided like this is what I want to do. And there's lots of details there. But if we fast forward to the part of, I now have a job in year, you know you're hopping between jobs because you don't know what you're doing, you want to go and spearmint with things. But then I started to notice that once you learn to program, then the thoughts in your head become reality in the tech world, right? It's like learning to read and write. Yeah. Once you can put your thoughts down on paper, then they outlive the short term memory. They outlive you and they can grow into bigger and better things. So when you're in tech support, you get really good at what you're doing, but then you start to understand like, why am I keep doing the same thing over and over again? There has to be a way to take what's in my mind and put it in a tool. And I think for us in tech and you know this well, like once you write that little utility that then gets shared around the team, you become a tool Smith and as a tool Smith, then you can capture that and then move on to something else. And that's when I fell in love with this idea of taking what's in my mind and turn it into a utility that I could use.
Speaker 3:Ah, that's great. I used to have a friend that said anytime you had to do the same thing more than a two times, you'd better automate it. Right. You know, and so you start throwing together these bash scripts or whatever your, your language choices for that stuff. So, yeah, that's, that's fantastic. Uh, and then you, you basically leveraged that into this, uh, you know, first the dev ops movement and the, and then these days with the Coobernetti's, uh, into, you know, really deep understanding of, of what users care about in these systems. You know. So speaking of Kubernetes, I want to shift gears a little bit and I know you coauthored a book, uh, titled, which we'll link up in the show notes, title Kubernetes up and running, dive into the future of infrastructure. I personally would love to really geek out with you on the book itself, but, but I won't instead want to talk about what it's like to be a tech author. Right. You know, cause this is about, this is about careers. So why write a tech book? What, what was the motivation? What was the process like for you?
Speaker 4:So that book, I started it by myself for about a year. And you just get to a roadblock where each can't finish it, you don't know how to finish it, right? So, you know, after about a hundred pages, you're just like, now I feel like I'm just filling in the blanks. And you know, like, I don't know how to bring this over. So I brought in two coauthors, Brendan burns and now at Microsoft, one of the original co founders of Kubernetes and Joe Beda, also one of the original co founders of Kubernetes. And they came in, they did a really good job of filling in the blanks. I didn't even know I had. So they bought an additional voice to the book. So those two came in probably a year later, maybe after six or seven chapters had been kind of put in play and they filled in the gaps. And I'm glad I did it because it gave more of a balanced view to this whole Kubernetes thing that I think really tuck off. And that book is still performing well, at least according to the bank account. And I just thought that book needed to exist because again, I had so much in my head that you can only get if you went to a conference or I talked to you directly. So I wanted something to scale those ideas. And that's how that book, that's how that book landed. Um, and also there's another piece of, uh, I guess documentation that I keep up to date. And that's, um, Kubernetes, the hard way and Kubernetes the hard way was written to give people a very deep dive into how to build Kubernetes from scratch. And what made me excited about that one is that's how I learned Linux, right? I learned Linux by following a book called next from scratch. And I was like, I want to give that to other people. And man, that thing has taken off and yeah, so that's just me giving back to the community.
Speaker 3:That's awesome. You know, and, and that feeling that there is out there, there's some, you know, a 10 year old or 15 year old, uh, Kelsey wannabe, who's, who's building Coobernetti's from scratch right now. That's, that's such a good feeling. I, I too, as a author of a book and relate to the, the pain comment though as well, this is not a, uh, a money making endeavor, at least directly, usually.
Speaker 4:Well, I got lucky that money, that book makes money. But I'll tell you the thing is I think most the most, one of my favorite tech books is the C book by a K and R in the seat book is like a hundred and something pages. Yup. And that's all you need, right. And I think a lot of times is you can't try to solve or teach everyone everything you need to decide what your book's going to be is going to be. An intro is going to be intermediate, it's going to be advanced. And I think a hundred pages can hit a real sweet spot if you cut the fluff just straight to the point and then maybe work on volume two or or an add on. So I think going forward, if I ever do this again, hundred pages are going to be my Mark and then at which point to ship it and tighten that thing up
Speaker 3:that that's a great goal. I know there has been some trend in publishing that way too because people kind of want these quick things they can consume. So sounds like you're onto something there, you know? So you seemingly live on the road these days. Uh, as I mentioned in, in the lead in here, I mean, I think you're traveling a lot, you're speaking a lot and you know, in that kind of role you have to pretty much beyond all the time. Right. And that's why I was kind of wondering how do you manage those in between moments so that you can stay fresh and relevant?
Speaker 4:Yeah, so I, I try to balance it out so I try to not go on the road more than two to three days max a week. If I'm on the West coast, I go on the morning and I'm home by dinner. Uh, so family first. I love being at home. I work from home, but there is no substitute for getting in front of the people you're working with from time to time and more importantly the customer. So I really do enjoy engineering at home, getting these prototypes, getting these solutions, taking everything I've learned from the previous set of customer visits and engineering, deep dives, and then showing up and then being able to do the next whiteboard session or the next executive briefing in front of real people. And that's what keeps me grounded to reality, that this is just tolls, helping to solve problems. And I got to stay sharp. Right? So it's like being a professional athlete, you need to stay sharp, you gotta write code. And in my case, like to write code every day, I wake up around 4:30 AM and I'll just hack on something to make sure that I still got it. And also I want to see some of my ideas and solutions come to life. And that's the way I get to do that.
Speaker 3:Yeah. Wow. Fantastic. Four 30 in the morning, that's a[inaudible]. That's no small feat. So, um, so then, you know, the reflecting a little bit and before I go into the next section where I like to talk about kind of what's, what's coming up, you know, if, if you were to reflect back, uh, you know, what might a younger Kelsey be be surprised to know on, on how things have turned out for you in your career.
Speaker 4:Oh man. I'll tell you the one thing I would tell younger Kelsey is that you're fine the way you are. And it took me a long time to realize that I spent the first part of my tech career the first five to 10 years, literally trying to figure out who should I be like, should I be like this person? Should I be like the Unix guys so I can Thompson and Dennis Richie, should I be like the professor that I'd never had? Should I learn to speak a certain way? Should I dress a certain way? What does it mean to be a tech professional? How do I get people to respect me? Right? And then you stress yourself out. And then some people call it impostor syndrome because you're trying to impersonate something you're not. So if you're trying to be an imposter, if you're trying to mimic something else, then you may always have imposter syndrome because that's kind of what you're doing. You're, you're walking around as an impostor. What I learned now is that, you know what? It's okay to say it's dope. It's okay to bring my real life into my work. It's okay to be who I am. And what I found is it's, it's refreshing to most people. You're different. You're, you, I remember Kelsey's talk, not necessarily the talk that you gave and that means a lot. So then you can now focus on you and how do you make yourself better versus comparing yourself to everyone else.
Speaker 3:Wow. That's, yeah, that's a, I think spot on. I think a, I think all of us always struggle with that and, and uh, uh, you know, I think no matter how good you even are, right? Like that, that's always something that, you know, you getting comfortable with yourself, uh, at the end of the day is all you've got. Right? So the, the, that's uh, that's really well said, very much appreciate that Kelsey. You know, so shifting gears, I like to, uh, spend a little bit of time kind of talking about the opportunities and challenges in a role like, like yours, which is this, you know, developer advocate and product manager and all of that. And, and so what do you, you know, as you look forward into the next few years, and maybe it's anchored in Kubernetes, maybe it's not, but what do you see as kind of the main, the main opportunities and challenges that, that are sitting in front of you or in front of this role in terms of advocating for a particular project or particular ideas?
Speaker 4:Yeah, so I think the number one thing is, you know, just anyone, I think this is general guidance. Like the role is how you get in, maybe get hired, maybe how you, you a map things initially, but then you quickly realize that most people that are very influential or impactful, half the share a set of shared traits, right? So the ability to find solutions to problems don't really care what they are. But if you're in a role that's surrounded by problems, your impact is going to weigh heavily on your ability to produce solutions to those problems, and there's many ways of doing that. Sometimes you're writing code, sometimes you're teaching someone something new, sometimes you're teaching yourself so that way you can understand the problem better before you go and attack it. All of those things, I think are the things that you should do in any role. Now, if you come in and you say, I'm a developer advocate, remember the imposter thing, and you start comparing yourself to what you think in a developer advocate is, Oh, maybe I'll go talk at some conferences. Maybe I'll write some code samples. Maybe I'll file some bug reports and friction logs about our product. That's what I'll do. I'll just do a lot of it and I'll be the best at doing that. And what you'll find is you're going to get burnout. You're going to get tired of it. It's going to be real boring because that's not the job, right? That's, that's just the HR description of the job. The real job is to use that arena to use that kind of flexibility in terms of the role and decide how do I make impact for the people who pay me? Right? Like if it's your job, then you work at a place and hopefully you work at a place where you believe in the technology and what's going on. So now when your goal is, if I'm going to get on stage to talk about what right, I want to talk about things that I've found that work for me, I found that work for others that I'm working on or excited about. So I'm here to share my knowledge. So you can also move forward and then you want to assist the people who are building and in some cases selling their product, right? So if you have a product that you believe in, it should be very easy for you to go out and tell a customer, here's why I believe in it and here's why I think it's the right solution for you. And here's why I think it's the wrong solution for you. Having that ability is what I think will make you super impactful regardless of the role. I just liked this developer relations role because of the flexibility. Right? I don't think the best use of my time these days would be 100% behind a keyboard fixing bugs and shipping new features. I think for me, I have a, you know, a broad range of things that I can cover from dev ops, some of the cultural aspects of delivering software and value for customers and businesses all the way down to implementations and work arounds for dealing with reality. So for me, I want to be in a role that affords me the flexibility to exercise all of my areas of expertise.
Speaker 3:Yeah, that's fantastic. Let's expand a little bit on that delivering product side of it. Cause I know you've given a number of talks on engineering culture and, and you know, as part of, uh, you know, what I'm trying to do here with this podcast is really show all the different things that go into all the different people and roles that go into building great tech companies. So, you know, perhaps, uh, reflect a little on, on your view, how do you build great engineering or technology companies?
Speaker 4:Yeah, let's just start with a simple example, right? So you know, some founder, maybe you're the founder and you start an insurance app, okay? Your app is going to change the world because they all do handy. You want to revolutionize the insurance industry, right? So you want to do car insurance is going to be your first market that you want to leverage technology. So solve this problem, right? So you go out and the first thing you ship is a proof of concept to get a few customers, right? Putting your information, I'll give you a quote and hopefully you don't crash more than I have money in the bank. So that can actually make a profitable endeavor out of this. Get more customers on board to distribute my risks, right? That's, that's the core business of it. Everyone is doing that or can do that. So that's not where you're going to do well in the marketplace. And now you want to leverage software and technology and all of these things. So think about that. So now you join this organization, helping them get from this base core thing to something that customers find very pleasing. So one trend we see in the insurance industry is charged by the mile, right? So instead of charging people this kind of every six month premium, you can say, look, if you don't drive very much, that's very low risk for us. We're going to pass that savings down to you and let's go from this. Try a new model and to sign up for this, you need to remove the friction. Because one thing, if I have insurance already, I typically am not looking to change that every week. This isn't Netflix, right? So it's like that quote needs to be fast. So here's an opportunity to use technology when it'd be nice if I can take a mobile phone, take a picture of their existing insurance card and extract all the information. That would have been three or four screens in a web form just to make the quoting process seamless and quick. So then you would say in that product meeting, let's start from the user experience. I as a user do not like filling out five screens to get a new a counter quote. That's why people aren't signing up with this. It's too friction. What about this experience? And then people see that experience and say, Oh that's magical. We like that. Then you go build the implementation. Maybe you use someone else's, you know, machine learning library or some service that can do OCR and extract the texts and yada yada, yada, yada. Those implementation details, but it's what you're implementing. So being a part of a product or if there's a product manager who wants to continuously improve the upside of a product by making it easier to onboard, enjoy the service while you have it. Innovate in the marketplace, set up profitable pricing on the engineering side, you want to make sure that the business understands all of the possibilities and technology available. Mobile is out, machine learning. Libraries are just one API call away these days. There is no reason for you not to take advantage of of these things that are available to them. Average consumer with your application to improve your standing in the marketplace.
Speaker 3:Yeah, it makes a lot of sense. And, and then, you know, at the end of the day, I think, you know, ship it right, like ship it and then go meet with customers and, and get that feedback. Right. I mean we're, we're, you're learning from what your users are doing with it. Right.
Speaker 4:And that's the magic of the feedback loop. So whether you're in a sales engineering role where you're helping the sales team, you know, try to close that initial deal, or you're in a dev REL role where you want to go out and you're talking to people, you know, what are you currently using? Why haven't you looked at us? What's, what are we missing the Mark on? Is the vision correct? Are we telling the right story? Is a product even any good? What are your concerns are? Why did you leave us? Yeah. And then what you want to do is take that feedback and say, yo, we can make this product better. We can win some of those customers back and be way more attractive to the customers we don't quite have yet.
Speaker 3:Yeah. Beautiful. So well said. And so important. You know, Kelsey, it's been awesome to have you on the show. Lots of really good nuggets in there for our listeners to on fat. Unpack a, to wrap things up though, I want to ask just one final question. I think maybe you hinted at this in various parts here already. Uh, but something I ask all my guests, which is, you know, just what's the advice you would give to someone who wants to follow in your footsteps?
Speaker 4:Uh, don't
Speaker 3:or you must career advice if you will.
Speaker 4:Yeah, I would just say look, look, you can definitely look at the path to other people's travel just to kind of get a view of the landscape. Maybe seed a few ideas in your mind about what's possible. A lot of times that is very helpful for people to take inspiration, you know, wants to man lands on the moon, then we know we all can go to the moon. So I think there's definitely a lot of value and understanding what boundaries others have hit and when thing you have to understand at that point though is that you know, now you know that those things are possible. Don't be afraid to be yourself and come up with things that you've never seen anyone else has done or just don't limit yourself. Right. And I think it's okay to be yourself. And one piece of advice I got that really made that resonate with me. I was at puppet labs and I had just started and I was very ambitious. I saw a big, big problem. And I remember I tackled that problem on my own. I didn't, you know, go through the full review process and there I just said, let me just get this thing done, build a prototype, check it in and I'm going to show it off on their Friday engineering demos to show people that, Hey, this is possible. I've done it. Of course it needs a little bit of Polish, but let's get the idea out there. And I put it out there and everyone was nitpicking like, Oh man, that's not going to be easy, or blah, blah, blah, or did you think about this? I was like, look, all that stuff is addressable. I just proved that it's possible if we really want to do it. And I don't know if I was getting a little out that people chose to nitpick instead of figure out how to get this thing over the ultimate finish line. And one of the, uh, he was the lead of UX. His name was Randall. I had a nice ball head and a long beard. Uh, I thought he was going to float away at any minute and I remember and he was like, yo, that was freaking amazing. And don't worry about what people are talking about because they've been talking about this for a long time and things. You did it. So don't be afraid of your own power. And that stuck with me forever because I started to understand is that you all have something to contribute as long as you're not afraid of it.
Speaker 3:Yeah. Nothing I can even add to that, Kelsey. Uh, that's amazing advice and, and I hope our listeners will take that to heart. Kelsey, I want to thank you so much again for joining me on the development or podcast.
Speaker 4:Awesome. No, it's been amazing and I love this format and thank you for having me. Yeah, thanks again.
Speaker 1:[inaudible].