Kelsey Hightower (@kelseyhightower on Twitter) is a technical leader in the open source community who contributes to projects like Kubernetes, Terraform, and more. In Episode 18, Kelsey shares secrets to driving technical changes in teams, and how to find feedback in unexpected places.
Transcript
JENNIFER: Welcome to Storytime with Managers, a podcast by Cohere.
I’m Jennifer Tu, and I’m here with Kelsey Hightower to talk about how to manage how tech stack changes will change your team culture. Kelsey, can you tell us a little about yourself?
KELSEY: I’m a self-proclaimed minimalist. I like to keep things super simple, simple basic. These days, I do a form of leadership that involves making impact without any direct reports. But throughout my tech career, I spent a lot of time in the open source community. I built libraries that people use in their own applications. I’ve helped contribute to popular projects such as Kubernetes and projects from HashiCorp such as TerraForm and Packer. And I spent a lot of time wearing like a manager engineering role where I’m managing other engineers, helping get things built. And that’s me in a nutshell.
JENNIFER: Awesome. Thanks for being here.
KELSEY: Oh, happy to be here. Really excited about the topic we got lined up for today.
JENNIFER: Yeah. Okay, let’s dive in. One thing that I want to hear more of your perspective on is a common experience that managers might have is when their team picks up a new tech stack, then the path to how that team will work with that stack can sometimes get kind of bumpy. And I’m wondering if you’ve seen this as well and what kind of problems you might have seen as teams try to adopt the new technology.
KELSEY: I’m really going to approach this topic from two perspectives. One, as a person who’s had boots on the ground attempting to roll new technologies into my own teams that I’m managing and a part of. And there’s another perspective as someone building these technologies, whether that’s a vendor or an open source project, and you’re trying to help people adopt them within their own teams as an outsider. So at a very high level, as an engineering manager, the one thing that’s really hard about introducing change, you’re almost in some ways saying that the current work being done or the work that has already been done can use improvement. And I think if you ask someone, they would believe that. But it’s really hard for them to say, “Well, that means that you may be attacking me if I am linking my identity to the particular thing we have now.” I think that’s one perspective that I’ve seen in my career.
And then on the other side, as a person who’s building technology, it’s always hard to go to a company and you don’t really know all of their details. And you say, “Hey, here’s this new thing that’s been working for a lot of people. And I think you should use it too,” kind of after hearing some of their high level goals and what they want to be, but not having insight into some of the political things and the human factors that go on within the team.
JENNIFER: Huh. I really like this idea that introducing new tech as a manager means that you’re almost giving feedback and that can make it kind of hard for someone to hear. And I’m wondering, how can a manager tell when their team is having a hard time hearing that feedback? And what could they do to change that?
KELSEY: Yes. I’ll give you maybe two scenarios. There is one scenario where I worked in like a financial kind of company in Atlanta. So I go there and I’m new there and I see so much room for improvement. It’s just very obvious that there’s room for improvement. And I came from a background where I had a lot of experience in the tools that I thought could really, really help people. And that’s when I kind of learned that one way to lead a team is by inspiring them. Some people take the approach of, in some ways, telling people what to do or introducing them to something that they say is better. What I did in that particular scenario, the tool at the time was Puppet. It’s a configuration management tool. And it competes with homegrown shell scripts. People automate things, they write shell scripts to do it. And in my world, configuration management was the new way of taking these ideas to the next level.
So what I did was I actually just started pouring some of those scripts into the new tool just to see for myself that it was actually going to be viable. And the way I introduced the technology to the team by showing them a pain point that I was solving. I was like, “Hey, I want you to check out this thing. You remember this problem we have?” And the team says, “Yeah, that’s a big problem.” “I think I have something that may solve that problem.” And you show it to them. And at that point, they’re inspired to learn a little bit more. And at that point, I can safely introduce the name of the new technology. So the way it’s introduced is very human, it’s approachable, and they have a chance to buy in on the idea of improving. And then the tool just become secondary. So now, people aren’t fighting the tool and they’re not going to fight me for introducing it.
JENNIFER: Yeah. So it’s almost like what you were saying through your actions is what do the team think of this approach to the problem?
KELSEY: Exactly. And having a little bit of skin in the game. It took me a while to mature to the point that you can’t just take a small demo that you’ve seen from a conference and then try to say that this will be good for us. You almost have to have a little bit of patience and actually put your hands on it first. Get your hands a little dirty and make sure that it’s going to actually solve the problem. And also take the time to think about day two and day three. What happens when it’s time to upgrade this? Think about teaching other people how to leverage the stack. How are you going to roll this out? Not just from a technical standpoint, but how are you going to educate all the people who will be required to support it going forward? And you do all of that homework and you present that whole plan kind of unified. They know that you’re thinking about the whole team and not just yourself.
JENNIFER: That makes a lot of sense. I’m wondering what happens when you do all of your homework. You do all of that prep work and you still encounter resistance to this idea. What do you do then?
KELSEY: You know what? At that financial institution, it took two years to roll out that thing that I did.
JENNIFER: Oh.
KELSEY: It solved the problem. People saw it and no one would give me the green light to put it in production. And for valid reasons, there’s risk involved. You’re changing a lot of things at a lot of time. There’s not enough expertise with the team. And until those problems have kind of clear solutions or momentum, you don’t get to go to production. So I was okay finally understanding that there was no need for me to stop educating myself and pushing these ideas, because a lot of times, you had to fight for this kind of change, especially if it’s widespread. So, I made incremental progress, meaning I use a lot of that technology to speed up the way we deliver development environments. So, there’s no production yet. But I was okay with saying maybe we can solve a much smaller problem by using these tools without as much impact to the way we do things today. And I got the green light maybe six months in to start using this tool for the lower environments. And once you got a little bit more success, then we could use it for the next level environments. And eventually, once you got enough people that bought into it, saw actual value, then we said, “Okay, green light.” And that took years.
JENNIFER: I’m definitely appreciating how much consistent work needs to go in in order to drive change like this. And one thing I’m wondering is who do you need to get that green light from? Are you looking for it from your team, from your own managers? And how do you get that green light? And how do you get more of it?
KELSEY: I’ll talk about my situation. I remember when – so putting this grand solution to the side for a second. Sometimes I had to build credibility by showing some results in other areas first. I can remember sitting at my desk and we were doing a big change over of the previous platform with the new platform. And we’re having some challenges. So, people who had a lot of experience were trying to roll in the new platform, but they were missing something. And I was super sure that I had, kind of on my own, researched a better approach. But I wasn’t sure yet because I needed to be able to put it into production to actually find out if it was going to work.
So maybe two or three change windows. The place where we go and implement some of these changes. I wasn’t given the green light to try this one solution for maybe two or three of these change windows. And I put a lot of my own career on the line here. I’m betting my reputation. I believe and almost guarantee that this is going to work. But here’s what I need in order to be able to fail and recover. When I was given that green light, then all eyes are on me at this point. “You put a big expectation out there. Now it’s time for you to deliver.” And luckily for me, the solution actually worked. Now, it didn’t work smoothly within that change window, took maybe three or four restartings of the web server and all these other things. But it actually worked and it stuck. And at that point, I gained the respect of not just my manager, but my manager’s manager because they were also in the room. I gave myself the ability to prove that I deserve the credibility for the bigger things that I wanted to do.
JENNIFER: All right. That makes sense. Start small and keep finding ways to scale back and prove yourself if you need to.
KELSEY: Execute in anywhere you can get it. If it’s documentation is where they want you to start, if it’s just something a little bit smaller of a problem set, knock it out of the park. Go all the way with it and then gain that trust. And sometimes you have to do three, four, or five of those things. But that’s that reputation that then you can use as a bargaining chip to take on something much bigger that’s going to need people to back you. And almost do the same. Put their reputation and careers on the line to give you that green light.
JENNIFER: Yeah. So, you start by helping someone else. So that way, they’re willing to help you.
KELSEY: The most successful parts of my career was the understanding that I am better off helping other people look like superstars, than I am doing that on my own.
JENNIFER: Good lesson. One thing I’m thinking about is going into the past and into the future of the past with your team that ended up adopting this new configuration tool to do deployments. What was it like to get this team of engineers who didn’t have experience with this tool to learn how to use it in a way that everyone on the team agreed with?
KELSEY: You know what, that was really the part where I understood that you’re going to find yourself in a situation where people will have to agree to disagree. And I can remember before becoming the manager of that team, the current immediate manager I had was not on board with this at all. And we got to a breaking point where the technology had demonstrated its value far beyond the risks that were involved in adopting the technology. And also the industry itself started to say that these things are now starting to become more common practice than just being an early adopter. So at that point, he found himself kind of on an island where the value was there and he became the gatekeeper to that value. And sometimes that’s the wrong side of the fence to be on. And eventually he was no longer with the company. And that’s not really a cause for celebration. But it was the thing that unlocked the momentum, because I think for a lot of organizations, it says a lot, not only by who you hire, but who you let go. And that was the signal to the rest of the team that we are now moving forward. And we’re not going to fire people for being skeptical. We’re not going to fire people for not having the skills. But we do have to say that we will not allow one person to not even try. And I think that was the thing that helped motivate other people to understand that this is the way forward and we are here to help. But if you’re going to be in the way, then there are ways that you have to kind of deal with that.
JENNIFER: Yes. That makes sense. I’m wondering, as your team found their way forward and saw they need to move forward with this new technology, how did that happen? Was it mostly based off of the work that you were already doing and then building on it? Or did you need to find champions within the team to carry the work forward? How do you move from one person saying, “This is the way that we’re going to go,” to the entire team saying, “This is the way we’ve always been doing it and it’s great.”
KELSEY: And that was probably early in my career, it was the biggest lesson I had to learn. It’s not about you being able to do it by yourself, it’s about more people can support this long term. So I think the biggest thing that I did, maybe within that one or two years, we started finding people who really wanted in on this. And one thing I had to learn was to let go. I don’t need to be the person creating all the code. I don’t need to be the person that ships the solution in this case. So when it comes to configuration management, there are tons of things that need to be configured. So what I learned to do was go to people who had domain expertise in the existing parts of the business and say, “Hey, I think this tool might be able to help you. I’m going to be here to give you any advice, maybe give you some examples of what I did in another part of the business. But I want it to be you that ships it. Meaning, I’ll review whatever you do. If it breaks, I’ll help you fix it. But I want you to be the person that they see complete the work.” And people get really motivated when they’re up there presenting to the rest of the team or their team that they were able to accomplish something. And guess what? You now have someone else who can push things forward and not be all on you. And looking back, I went back there after being away for six years, and that culture stuck around. There’s so many people at that company that are pushing the edges of what’s new, what’s exciting, bringing their own ideas to the table, that that’s why it’s scaled, not because of only one person that’s the clear leader of the tech stack.
JENNIFER: I really like that idea. It’s not about selling the technology, but it’s about selling a solution to a problem that people are experiencing, a pain point that people are experiencing. And so, that’s why it’s important to find these domain experts who have a problem and share with them, “This is a solution that could help you solve that problem and make you look good in the process.”
KELSEY: That is the secret. And I think a lot of people takes way too long to understand that these tools, just like a hammer and nail, mean nothing if there is no problem to solve. Just having a bunch of hammers and nails laying around does nothing for you. It’s only when you want to build a house that those tools become important. And I think the faster you learn and understand what the core problem is at your organization, you put the problem at the very top and you suggest various tools that can help solve that problem. And then you empower people to go do that. That’s leadership.
JENNIFER: Yeah. How did you find the right people? I mean, once you knew what domains to go to, you probably could find the experts for those domains. But how did you identify what domains around you needed that problem solved.
KELSEY: Luckily for me, I worked in operations at that time. In operations, you typically have your hands in all parts of the business, at least at the lower levels, where the machines meet the customer. And in that world, you can kind of see what things break all the time. You see all the alerts, you’re on call, so you know what you get called about. When things break, we typically have to scramble and fix it really quickly. So over time, you start to really understand where the paying lives within the organization. And this is why I think in operations, you have kind of this vantage point that maybe a lot of teams or other roles don’t have. So a lot of times, what I would do is even if it wasn’t in my immediate domain, I would also try to find a solution for that. For example, the DBA’s had a hard time getting test data bases in the lower environments. Even though I don’t work on the Oracle team or I wasn’t a DBA, I figured that the technology I was using could be applied to that particular problem. And then I would just pair with someone on that team. Maybe I worked with them during an outage before. Maybe I just saw them send an email out about how they’re updating our databases and say, “Hey, I have this tool we’re using for this, that, and the other. Maybe we could use it for the thing you’re doing. But here’s the thing. You are the domain expert. I only understand the tool.” And then we pair together. And then when they get to show off and say, “Hey, I was able to work with Kelsey. We now have a much better way of getting these dev environments spun up quickly. You can now push a button and get it done.” That takes pressure off of their team. And then we move on. And I just kept doing that slowly, meeting new people, figuring out what they do, and then helping them look like a rockstar.
JENNIFER: Yeah. And it sounds like you really focused on meeting people who were closer to the customer.
KELSEY: Oh, yeah. I think a lot of times, if you want adoption, if you want to see support come from the business, you have to make it very clear what the exact problem you’re trying to solve. So in the case of those databases in the lower environments, when we were not able to do that, that means you have your developers and all of these smart people you hired, in QA and across the whole organization just on pause, until they get a database that they can use to continue their effort. So you can almost write down those numbers and say, “Hey, we’re spending all of this money by having people do nothing until we can clone a database into the new environment.” So now you have a very clear problem. And I can actually put a dollar amount to the problem. And for some people that are a little bit more savvy, you understand this as an opportunity cost that’s lost that we could be doing something else with. When you bring all those things together and you put that at the front, that’s how you get people to buy in and say, “Hey, whatever you need from me, however I can help get that done because I really, really want that problem to go away.”
JENNIFER: Did you ever get resistance to that? For someone, I don’t know, a DBA was saying, “No, the way we spin up databases is just fine,” or something like that, where they kind of rebuffed your efforts to help them with what they were trying to do?
KELSEY: All the time. “You can’t do that with Oracle. Oracle explicitly says you can’t do that.” Or, “There’s a license that says you can’t do it that way.” Or, “Our scripts are XYZ.” When I was a little bit less mature, I would probably get upset and say, “Oh, my God, they’re just thinking about this old way,” blah, blah, blah. But when I got a little bit more mature, I just took that as a form of feedback, and said, “Oh, what exactly is wrong? Well, your thing doesn’t do this, our thing does. Your thing doesn’t do this, our thing does.” “Great. You’re giving me all of the requirements I need.” And then what I would do is say, “Look, this is valid or probably honest feedback,” even if they were trying to derail the effort. But what you do, though, as a professional, you take that feedback, you put it into the tool. You make sure that it actually works and then you represent it again. And sometimes, again, it may take you three or four months. But guess what? There’s going to be a time where there’s a group of developers sitting around waiting for a database. And I’d say, “You know what? I’ve added the two things you’re missing. I promise you that I can get that database in five minutes instead of five days. Are you up for it?” And eventually people come around.
JENNIFER: Wow. I really like this idea of resistance and unhappiness as a form of feedback that it’s your responsibility to understand better.
KELSEY: Exactly. That is a valid form of feedback when people don’t understand something, when people are frustrated, they’re not going to always be calm and give you feedback in the perfect mechanism that you have in your head. Sometimes when people are frustrated, you have an opportunity to say, “I have empathy for you. I know why you’re frustrated,” and just listen for a moment. And sometimes, you don’t even need to respond in that moment. You can just say, “Fair point, go back to the lab and ask yourself, can I actually solve the problems that they’re bringing up?” And the answer is no. Then I understand why they brought them up. But if the answer is yes, I can then actually put together – I’m a show-don’t-tell kind of person. So I like to put together these demos that say, “Hey, I heard you loud and clear and you had some really valid points. And it took me a while to address them. And I think I have. Here’s a little video or maybe I’ll show you at the next all-hands presentation. I think I solved it. And without your help, this tool would have never improved to the point where it is now. So, thank you.”
JENNIFER: That’s amazing. We are out of time, unfortunately. Do you have any final words of advice for our listeners?
KELSEY: I think patience is key to adoption. A lot of times when you’re looking at new technology, it is not about how fast you get it into production. Sometimes that journey of helping people understand what the technology is, challenging yourself and your own bias towards that technology, and then eventually showing true value with that technology. And in some cases, it won’t be a good fit. You’re going to have to be okay with abandoning that particular project. But everything you learn along the way is going to be super valuable, and it’s going to be the core skill set you’re going to need to get any technology adopted in any organization.
JENNIFER: Awesome. If people want to continue the conversation with you, Kelsey, what’s a good way for them to get in touch?
KELSEY: I spend most of my time on Twitter @kelseyhightower on Twitter. My DMs are open and I do a little bit of ad hoc mentoring for people who have basic questions like the ones we’re covering here today.
JENNIFER: Wow, thanks so much.
KELSEY: Awesome. I love being here. Thank you.
JENNIFER: Thanks for listening to Storytime with Managers by Cohere. I’m Jennifer Tu. Our theme music is by Kevin MacLeod, and we are edited by Mandy Moore and the DevReps crew.
If you like this episode, please think about leaving us a review on your favorite podcast listening platform. This can make a really big difference in helping other people find and start listening to Storytime with Managers. Thanks so much.
