Putting People First, and Engineering Tools Second with Kelsey Hightower of Google

Transcript

Ledge: Kelsey, it’s great to have you on!

Kelsey: Awesome! I’m looking forward to being here.

Ledge: Can you give a two- to three-minute background story of yourself, your work, and how you got here?

Kelsey: I’m one of those people with no computer science degree who just kind of worked their way up ─ self-taught, worked in the data center, worked in the enterprise, worked in open source companies like Puppet Labs. Now, I’m at Google, the big cloud provider but has a mix of all of those elements over my career; and I’m still that person who’s out in the community just trying to build tools that I want to use and, hopefully, you want to use.

Ledge: We can get into all kinds of serverless, obviously. You talk endlessly about it. What I’ve been struck by, watching some of your keynotes and your work, is that it’s a more holistic approach to engineering. It’s not all command, line, and code.

You ended your keynote at CNCF with “You’re an engineer. Act like one.” I wonder if you could just expound on that. It was really a profound moment for me.

Kelsey: When I did those keynotes, there were no speaker notes. I’m looking at people and talking directly to them. A lot of what I’ve been seeing in the industry lately is that we’ve kind of turned our brains off or we’re trying to run through the groupthink.

I read this blogpost that’s telling me what I should be doing. Maybe I should just be doing this because it’s the fashion technology of the week.

The thing is, engineering is not about that. When you’re going to build a bridge, you’re building that bridge for the community that you’re in. You’re trying to connect two things that are hard to get to.

As an engineer, these are just tools. They don’t define us. Kubernetes doesn’t define who you are. The language you write in doesn’t define who you are. The problems you’re trying to solve and what you believe in define who you are. So these are just tools.

I want people to really take a step back, put themselves first, and put the people around them first; and then, as a group, start to consider the tools that help them get the mission done. And that’s what I meant. I want us to go back to being engineers first versus “I am a Linus administrator.”

No, you’re not. You’re you and you can leverage those tools to get the job done.

Ledge: I’ve seen you talk on Twitter about the customer empathy sessions that you’ve facilitated. Does that play in that ─ trying to reopen those connections to other areas?

When I was a software engineer, we were all in the basement and the lights are off. God forbid, you ever let an engineer talk to the customer! And it’s like the sea changed now.

Is that all the same conversation?

Kelsey: Yes. I’m that person who turns the light on and say, “Hey, what are you doing? Come up for a minute. Let’s see what you’ve been building.”

I think it’s very important for an engineer ─ some people can get down or feel sad. Maybe their product isn’t perfect because they know where all the bugs are. They know it isn’t perfect. And some people may not understand how a customer wants to use it so they constantly are fighting and building the wrong thing.

So what I’d like to do this with these empathy sessions is ─ you can imagine some of the ones that I’ve posted online where you take a group of people maybe working on Kubernetes and you say, “Listen, let’s all come up ─ maybe you’re working on the scheduler; maybe you’re working on something that’s so low level on Kubernetes that you may not have a chance to understand how people are like people who work on an assembly line but don’t have a driver’s license.

I want to get you in that car. I want you to understand what it feels like when you hit a bump so you know how to work on that suspension.”

For them, it’s more about being empathetic that maybe what you’re building is actually really good ─ have you used it? ─ and maybe showing them what the alternatives are.

In many ways, they’re learning that there’s a low-level pain point that we can solve if we just knew what the immediate needs are. So everyone wants to work on complex things that take years or months to do. But there are things that you can do in two weeks that would just save the whole world thousands of hours if they didn’t have to have those sharp edges get in the way.

Ledge: One thing that popped in my head watching some of the works that you’ve done ─ I call it “engineer dogma.” I’m sure you know what I’m talking about. It’s like these endless sort of vitriolic debates about vendors, frameworks, and language. Pick your poison, right?

I just wonder, when does a spirited debate stops being productive?

I mean, we all know that great improvements come from productive disagreements. But, then, I just see these endless things where it’s not productive disagreement and it’s just like “I’m going to line up and fight about the thing that I have used all these years.”

How do you see and experience that being in the advocate space?

Kelsey: As an engineer, maybe six or seven years ago, I was working at this financial institution and they had the tools that they had. You may not like them. It was like, “Hey, here’s our CRCS tool” and I look at it like,

I’m not familiar with that thing. Jenkins is better than that or this other tool is better than that.

What I’ve discovered is like,

you know what, who cares? All of these things are the same. They’re going to run Bash scripts in a specific order. I need to know how this one runs its Bash scripts. You know what, I’m going to not care but in a good way. If this is what we have, I want to take that thing to its endgame. What can it actually do?

And what you end up understanding is that you’ve got to give in order to receive. So you say, “I’ll use the system that you have. I’ll use the system that you want because the only thing I care about is the fact of using CICD. I don’t really care if it’s Jenkins. I don’t really care if it’s Bamboo or Travis CI. That doesn’t matter.

Now, when we hit the wall, you’re going to see that I put my all into making what we currently have work, making your tool of choice work ─ that when we hit that wall, it’s got to be real clear that this is not going to meet the high-level mission of what we’re trying to do. And you’ve seen the amount of effort that I put into helping you try to succeed with your choice, I need you to meet me halfway where I say, ‘Look, this thing is not going to get us where we need to be.’”

I think that’s where you start to say, “People argue about CICD for years and still don’t have CICD. You’re just better off flipping the coin picking anyone that’s out there, go all in; and then, if you end up in three months where it isn’t perfect, then you have the right amount of data to make the next choice.”

Ledge: In the tooling environment, there’s just this explosion ─ exponential numbers more tools, DevOps, the infrastructure orchestration.

How do see the industry dealing with that?

In the market dynamics, there may be a consolidation wave in the next five years. You can’t even evaluate all the tools.

As a vendor, I would be a little scared that we’re now so saturated that we’re talking about coin flipping to pick the tool.

From an industry vibe, where is it going?

Kelsey: Honestly, I think the plethora of tools that are available are just like the plethora of ingredients and food available. If you go to a grocery store, there are ten versions of this particular ketchup; there are ten brands of soda.

Are you going to get the one that tastes good to you, every one slightly different, everyone is coming from a different place?

It’s also situational. If I’m with Vendor X and they provide 90% of my other tools and I need the other tool that they have in the portfolio but it’s only as 80% as good as the other ones ─ you’re likely going to go where you have an existing relationship, right?

We shop at the grocery store closest to our house, not necessarily the best grocery store.

I think a lot of people, when it comes to evaluating these products, a lot of it is going to be situational.

Can you get support? Can you hire people for this thing? Is it good enough for you?

To me, that’s number one. Maybe it doesn’t do everything but maybe you don’t have every problem. So, I think, for a lot of people, it’s just really “Pick one. Start there and use that as kind of the baseline for making the next decision. And be fair. You may not have to.”

Ledge: I think a sales kitten just died somewhere at a vendor. But let that go for now.

Here’s the next thing I was thinking about and I’d love to get your opinion on this. Obviously, you’re very huge in serverless and Kubernetes and you look at all these things and I think the operative word is “abstraction” and it just continues to be. We abstract and abstract and abstract.

I can still remember back when bare metal was the thing. And it’s just simply so far above that now.

In the next couple of years, in five years, what’s the next level of abstraction and what’s the next level after that?

Kelsey: I think the next level of abstraction is work flow abstractions. I think we’ve kind of reached the limit on what we’re going to do in terms of programming abstractions.

The kernel gives you system calls. Your programming language abstract those system calls away with functions and classes and libraries. Then, we have frameworks that abstract that away a little bit more. Now, we have platforms like Kubernetes that abstracts the deployment of the artifact into containers. And then, higher level, we start to have things like Lamda that turns a lot of our abstractions into events and just focus on the business logic, transform this request into something else, and take action on this particular event.

Then, you start to get real close to workflow. This thing is only being called when a file is being uploaded. This thing is only doing X because X happened.

Now, you start to look at what workflows we can do to improve. If I give you a piece of code, you can almost scan that code and tell me what the security aspects of that code should be. It’s only writing to the database, not reading.

Okay. Maybe I generate permission to automatically, for you, attach it to it and make it where there’s only one step to do deployment versus “Go set up IEM. Go set up the database. Go set up the schema.”

You can almost parse my code and say, “Oh, the schema needs to look like this. I’ll just generate all that for you,” and that’s going to be an amazing time where you can just articulate what you want to do and then a new abstraction is just like workflow abstractions. That’s going to be crazy.

Ledge: I’ve heard that described as “move from orchestration to choreography.” Is that correct? Does that resonate with you?

Kelsey: Yes. I think you see that a little bit now. To me, Kubernetes is more choreography for a lot of people. You say, “Here’s my service.” And then, underneath it, there’s a lot of orchestration happening, the thing that makes sure that it stays there.

Buy in Kubernetes, you can’t just tell it the way you want the world to relate to each other like “Here are the steps. You go do them.”

I think that is a central piece to move us forward.

Ledge: Let me shift gears totally here. I’ve watched your talks. I’m not a command line sort of dev guy anymore. I basically understand what you’re talking about. But I enjoy them.

You are a good tech speaker. You’re funny. Your comedic timing is just like spot on and I just find myself enjoying it. It’s like a reality show. I just wonder, how do you pull that off?

I think people want to do that. What’s your process on performance?

Kelsey: In my early speaking engagements, I used to just do the most technical thing possible: “Here’s how Python Iterators work compared to Haskell; here’s how Kubernetes schedule their works.”

You know what, there’s a time and place for those talks as well. Those are the technical deep dives to educate people, kind of like what a college professor would do.

But on the keynote stage, I think it’s different. On the keynote stage, you have a range of skillsets, disciplines, and backgrounds. People also probably want to break from all of those tech dives and deep sessions.

So, to me, it’s like part entertainment, part performance, and it’s a story.

“Hey, I’m a developer looking to move toward serverless and I want to see what that looks like in your world or what it will look like in my world.”

So I just come up with a story first like you mentioned the path to severless. So I come from the Kubernetes world and there’s a way I think about what Kubernetes brings to the table. And then, when I look at the serverless world, it looks a certain way to me.

So the goal is “Look, there are some good parts about it. This looks like some CGI script. I don’t know if this ready for prime time.” And then, you start to see similarities; you start to see differences. So when you get on stage, you just tell that story.

Typically, I start with like an end-to-end process. I want to go from Kubernetes to Lamda. What do you have to do? And then, once I figure all of that out, I smooth it out into something that I can actually show live on stage.

And to make it a little bit more engaging, I was like, “Well, if I just copy a Docker container and get the binary and put it on Lamda. That’s cool. But you know what, I’m going to write a tool called ‘Diana’ and it’s going to play music to really up-level the audience and say, ‘Yes, you took something that could have been super boring and then you made it super engaging and you break up the content in a way that it’s like a roller coaster. I’m learning a lot. I’m having fun. I’m learning a lot. I’m having fun.”

Ledge: You talked about your background in music in Atlanta. How does that play into it? I mean, are you bringing that along to the engineering space?

Kelsey: Honesty, I think I just found the courage to just be myself. I used to think I have to pronounce all the words right; I have to look a certain way; I have to mimic maybe a college professor.

I said, “I’m not doing that anymore. You know what, I’m listening to Diana Ross this week. We’re going to put that in the keynote.”

When I’m in a circle with friends, I like to tell jokes. I like to have a little fun. So I decided that that will also be my onstage persona. It would be the same persona if you’re just hanging out with Kelsey in high school or at the party or at the conference.

That’s where that kind of comes from. A lot of people have these personalities as well that we feel we’ve got to hide that personality in the business setting because we think it may put us in the wrong light.

But I’m just being me on stage.

Ledge: It makes me think that the keyword there is “authenticity” in all factions of life that takes a level of, if not maturity, experience to be okay with oneself in a professional environment.

Let’s say, I’m listening to this and I’m at home and I’m kind of introverted but I want to get there. I want to be you.

What’s the path to authenticity for an engineering thinker who really is kind of fun and can really interact personally but doesn’t know how to do it at work?

Kelsey: You’ve got to have some situation awareness. What you believe is acceptable isn’t acceptable to the world. Some of these jokes are terrible. You’ve got to make sure you, at least, have situation awareness on how the world works. And some people don’t because they’ve interacted with people before but not in a meaningful way for them to understand that everyone has gates and boundaries and you should respect them.

So that’s Step 1. You just can’t go and say, “I’m an asshole. I’m going to be an asshole to everyone because that’s just me.” That’s unacceptable. There’s nothing you can do about that.

But once you do get in the right place where you understand a little bit of how the world works and you have a little bit of empathy for other people’s perspectives, then you’ll also be able to respect your own so you’ll know how much of that you can broadcast and in what way you can broadcast it.

The goal is not to be offensive. That’s not cool even though people get a chuckle out of it.

It’s to be your authentic self. So make sure you know who your authentic self is first.

Once you have that, if you’re a little awkward and you really like

Star Trek and you find some

Star Trek jokes funny, great! You can incorporate that into what you do. And there’s nothing wrong with that because people like to see that mix-up. They like to say, “Oh, you’re just like me. I have those same interests. It’s kind of cool that you’ve made something a little bit more relatable to me than just a mathematical equation.

Tell me a story about something that happened on the ship and how that relates to software in the real world that can hold my attention.”

I think that’s kind of the goal.

And know that people are going to hit you. You’ve got to know that the more successful you get, the more people will be on your radar or you’ll be on their radar and they are going to say, “I don’t like it.”

People don’t like Michael Jordan. People don’t like Tom Brady. People tend to hate the winners. So when you’re doing really well, that’s when more people will publicly hit you because that’s just how it works.

So you’ve got to know that and you can’t let those critics drown out all the people who appreciate what you do.

Ledge: I appreciate those insights. That’s absolutely right. I feel that you probably have some hard-won experiences that got you to that point of self-actualization, and that’s super cool. I wish for that for the 20,000 engineers that were talking to you today.

Any last words? Anything we missed or something you want to make sure people are paying awareness to in their work and what you’ve got going on in 2019?

Kelsey: Broaden what you’re exposed to. For me, at Google, every quarter or so, I’ll switch between different technologies. I spent some time in a database world really understanding how they work. I spent time working on serverless stuff. You kind of saw that a little bit last year, kind of back in the Kubernetes space ─ and then, the people that I surround myself around.

I just go into communities in that mobile space, maybe different ethnic groups. I’ve got people in different parts of the country saying, “Well, we adopt technology in different ways here” and some people in Nairobi telling me, “This is where technology benefits us the most.”

You talk to the people in Germany who say, “This is how technology benefits us the most.”

The more that you do that, you start to really understand what you’re actually doing and what your potential is. People have a very narrow scope. For some people, their potential is writing the best PHP on earth. And that’s unfortunate because that can get very boring. It’s not very exciting. It’s not going to be the reason why you wake up in the morning.

So if you expand your boundaries just a little bit, then you start to understand what your potential will be. And I think that is the key tech way that we don’t often cover in our talks or in some of the engagements that we do with each other.

Ledge: Now, you just covered it, man, and we’re breaking the ground here. Thanks so much for your time. It’s really cool to have you on. Have an awesome year advocating across the globe.

Kelsey: Awesome! Thank you.