Teaching the Cloud Forever with Jez Humble

About Jez Humble
Jez Humble is co-author of several books on software including Shingo Publication Award winner Accelerate, The DevOps Handbook, Lean Enterprise, and Jolt Award winner Continuous Delivery. He has spent his 20 year career in software tinkering with code, infrastructure, and product development in companies of varying sizes across three continents, including working for the US Federal Government’s 18F team as part of the Obama Tech Surge, and co-founding startup DevOps Research and Assessment LLC, which was acquired by Google in December 2018. He works for Google Cloud as a technology advocate, and teaches classes on agile software engineering and product management at UC Berkeley’s School of Information.


Links Referenced

Transcript
Announcer: Hello, and welcome to Screaming in the Cloud with your host, Cloud Economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.

Corey: This episode is sponsored in part by Catchpoint. Look, 80 percent of performance and availability issues don’t occur within your application code in your data center itself. It occurs well outside those boundaries, so it’s difficult to understand what’s actually happening. What Catchpoint does is makes it easier for enterprises to detect, identify, and of course, validate how reachable their application is, and of course, how happy their users are. It helps you get visibility into reachability, availability, performance, reliability, and of course, absorbency, because we’ll throw that one in, too. And it’s used by a bunch of interesting companies you may have heard of, like, you know, Google, Verizon, Oracle—but don’t hold that against them—and many more. To learn more, visit www.catchpoint.com, and tell them Corey sent you; wait for the wince.

Corey: nOps will help you reduce AWS costs 15 to 50 percent if you do what tells you. But some people do. For example, watch their webcast, how Uber reduced AWS costs 15 percent in 30 days; that is six figures in 30 days. Rather than a thing you might do, this is something that they actually did. Take a look at it. It's designed for DevOps teams. nOps helps quickly discover the root causes of cost and correlate that with infrastructure changes. Try it free for 30 days, go to nops.io/snark. That's N-O-P-S dot I-O, slash snark.

Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Jez Humble who's currently a developer advocate at Google, but is already very well known in the continuous delivery DevOps spaces. And, I guess—well, what would you say you're most known for? Co-founding DORA's got to be up there.

Jez: Thanks very much for having me. Pleasure to be on the show. Yeah, co-founding DORA, the State of DevOps Research Program, which [00:01:57 unintelligible] Nicole Forsgren and I worked on for many years. Yeah, I've written some books. That's probably the biggest stuff.

Corey: Yes. And then you've got Googled, by which I mean, acquired—not the common use case these days of being turned off.

Jez: [laughs].

Corey: In fact, at the time of this recording you’re in the process of coming out with more research. Which was a question. Whenever a large company buys a smaller one—I don't mean to pick on Google unnecessarily on this—it's, “Oh, great. Are we not going to see any of the things that we'd loved out of those folks now, ever again?” And it turns out that oh, in fact, we are.

Jez: Yeah, that's right. So, one of the things that I've been working on recently, and by the time you—the audience—hear this, this will be fully available, is making all the things we learned in DORA publicly available, to the greatest extent possible. So, there's going to be a bunch of more write-ups of the capabilities that we discovered as a part of the DORA research program. We have, for example, write-ups on code maintainability, which was new in 2019; database change management, monitoring, and observability; cloud infrastructure, like what it means to actually, really, use the Cloud in a, kind of, modern, appropriate way, and some other bits and pieces; and a quick check, which lets you see how you're doing. 

So, everyone who knows our research knows that we have four key metrics that we found to be valid, and reliable, and predictive of organizational performance. You can find out how you're doing in those, and it will recommend to you some capabilities that we think you might find helpful to work on. And you can take another quiz and find out which of those we think should be a priority for you, some suggestions, and also, crucially, that exposes the questions that we ask. So, taking the quiz will give you a good idea of what we found that actually works in terms of implementing these capabilities as well, which I think is valuable information to have. 

So, that's all out there, on page of our research program where you can explore the research and all the articles that we've written about how to implement these capabilities, and what the common obstacles are, and what it means to be good at them. So, we could not have done this without Google's resources. You know, it was a three-person company; we were strong enough focused on serving our customers, there's a ton of stuff that we learned, and my job for the last year and a half has basically been putting it out there in a way that is easy to consume and because it's on the Google Cloud website, it's Creative Commons. So, I'm really pleased that we were able to do that.

Corey: As someone who's in a small company, myself—we’re 10 people at the moment. At least at time of this recording. One never knows. Hiring is a thing—one of the hardest things for me to wrap my head around, having come from small companies most of my career, is the resources available at a big company. I never quite understood it until I was talking to someone once, probably later in my career than I really should have figured this out. 

It's, “Yeah, what's the point of big companies? There's process and procedures, and you always have to ask permission, and do the other stuff.” And the person I was talking to sat there and looked at me, and she said, “Think about this for a second, Corey. What's the thing that annoys you the most?” And I mentioned some business function or another. And the answer is, “Yeah. Here we have 200 people that do different aspects of just that function.” “Oh, okay.” 

And it turns out that when you can sit there and straight-faced, theoretically, write a check with three commas in it for something—which again, most companies don't do particularly frequently, but the fact that you can do that means that the limit of what is possible is radically different. Here, if I want that kind of outcome, I'm pretty much limited to either doing something monstrous to raise money from SoftBank or else holding people's kids hostage. There's really not a good third way to get there.

Jez: [laughs]. Yes, that's definitely a thing. And there's advantages to both. My career has been kind of a whipsaw between huge organizations and tiny ones. I started my career in startups, and then I was a contractor, and then I joined ThoughtWorks which was a medium-sized company, and then I went to work for another startup, and then I went to work for the US federal government, the world's largest bureaucracy, and then a two-person startup, and now Google. So, I feel like I've [laughs] really experienced the whole gamut. And, you know, there's definitely advantages to both. The great thing about being in a small company is that you can do whatever you want. And that's fabulous.

Corey: The weird combination there was your time with 18F, your time in the federal government. As you say, the world's largest bureaucracy. The 18F program, to my understanding, is a two-year term renewable for up to another two, but then you have to leave, which to, I guess, most lifelong government workers, that sounds terrifying, but for tech folks—at least in my case, until I started this company, I've never stayed anywhere past the two-year mark, it's oh, “That sounds wonderful. There's no illusions going into this.” What was that like?

Jez: It was amazing. It was certainly one of the highlights of my professional career. I got to work with some really incredible people who were very mission-focused and very good at what they did. And we got stuff done. It was an amazing experience. 

Helping to build cloud.gov was just wonderful. We built a Platform as a Service that allowed other federal agencies to deploy stuff to the Clouds in a seamless, straightforward, easy way. And we demonstrated that you can do continuous delivery with cloud platforms in, possibly, the world's most heavily regulated organization. I still have my NIST binder, where I have a significant number of NIST documents printed off, double-sided, two pages to a piece of paper, and it's still enormous. And, you know, we—

Corey: That sounds like a lot of companies’ DR plans. Hasn't been touched in years, enormous, sits on a shelf somewhere in a binder.

Jez: Yeah, I mean, although it is a living document, extraordinarily, Special Publication 853, which for the NIST junkies out there will know is the list of information security controls you have to implement when you're deploying a government information system. That's on revision four. When I left, revision five was in process. I don't think it's been officially released yet, but it's there. And then not a lot of people also know that there's also a Special Publication 853a, which is how you test those information security controls.

Corey: NIST has a lot of great stuff, but I keep looking for the 800-page NIST document on why brevity is important.

Jez: [laughs]. I mean, interestingly, they do have a very short document which defines what is a clouds, and that's one of the things: that was a document that we used to build our capability, or test our capability of cloud infrastructure. And that's really good. I actually have a huge amount of respect for the NIST stuff. And that one is very good because it defines these five characteristics of what it means to have a cloud. 

And I think well under 50 percent of people who say they have a cloud meet those five characteristics, but the ones who do are 24 times more likely to be elite performers, which is a very large number. Even if it's only a correlation, it's still a big number and demonstrates a big impact. So, for all NIST’s issues, that is a particularly fine and striking example of something concise and powerful.

Corey: So, one of the most surprising acquisitions in the last decade was the DevOps Research and Assessment—or DORA—which you co-founded, by Google because historically, Google was always very in SRE, and for better or worse, the Industry seems to view there being a schism, real or imagined, between SRE and DevOps. And the cynical among us—ahem, ahem—assumed, “Oh, okay, Google really doesn't understand DevOps, so they think they're buying it out, then they can kill it.” It turns out, nope, that was not the strategy and not the plan. But why was DORA something that it made sense for Google to acquire?

Jez: So, I can give you my perspective. My perspective is that Nicole and I had this research program, which was the most academically rigorous program into what it means to be good at software delivery. And I should mention though, it's not just Nicole and me. Obviously, Gene Kim played a big part in it. We work with Puppet Labs, originally, on four years of this before it was acquired by Google. 

So, there's a whole bunch of people who worked on this, I want to make sure credit where it's due. But it's the most academically rigorous program investigating what it means to be a high performer in software delivery, and people trust it because it's independent, and it's academically rigorous, and we have an extremely large n, which is a big deal in its own right, literally. And so I think that's why it's valuable is because we have good research that tells people how you should actually do this stuff.

Corey: It definitely aligns because as I look at tenets of DevOps—and again, we could have an entire thesis arguing what DevOps is or is not if we wanted to do—but the interesting piece I take away is the more agile, the easier it is to iterate forward, it almost seems like the ‘cloudier’ an environment becomes. It seems like there are a lot of points of alignment between what it takes to succeed in business today, what it takes to develop and deliver software safely, securely, and fastly, and being able to leverage a hyperscale cloud provider. Is that something I'm imagining? Is that something you're seeing too? Is it something much more nuanced than that? Almost certainly.

Jez: So, my two cents on this is, I mean, we find that if you're doing Cloud, right: if you meet those five characteristics that NIST defines, which I'm going to [laughs] fail to remember off the top of my head.

Corey: I've mentioned them in one of my talks. I put them on a slide, and the reason I put them on slides is so I don't have to remember them in conversation. We go to, “Cut to the slide deck, Ted,” and then, problem solved.

Jez: Yeah, exactly. I do actually have them here, just because we have, in fact, released the article on it. So: on-demand self-service, the ability to provision computing resources as needed, and this one, I mean, in terms of pushing my buttons, this is a big one. When organizations buy a clouds, but then developers still have to raise a ticket or send an email and wait weeks for their environment to be provisioned, or to raise a ticket to get some networking setting changed so they can actually have a route to the thing that they want, it's not a cloud. 

So, [laughs] a lot of people fail in step one. It's like, “Well, we spent all this money on the Cloud, but outcomes for the people who use that cloud—developers, and people trying to get their software built—are completely unchanged, so what was the point in that?” And then, broad network access, resource pooling, rapid elasticity, measured service. You can go to cloud.google.com/DevOps and go to the research and go to the article, or read NIST Special Publication—see, I can't remember this number. I'm not that good—800-145 for yourself. 

But that has an impact on software delivery performance. And what I will say is, I think a lot of the things that let you take advantage of that are things we talked about in the research program: things like being able to version control the configuration of your system, being able to do test automation, being able to build security. And you have all these different capabilities, that's going to definitely give you the ability to take advantage of the things that Cloud offers, which is the ability to stand up an environment based on a configuration you specified, and do testing in that environment, and be able to rapidly deploy software. If you can do all these things that we talked about in the program, that's going to give you an incredible ability to actually use cloud infrastructure in a way that's a force multiplier. So, that's kind of how I feel about that.

Corey: One of the biggest challenges for organizations of almost any size but particularly large ones is, we can read books like Gene Kim's The Phoenix Project, and then The Unicorn Project from other perspectives several years later, and it's easy to see, oh, we should be doing this, we should be doing that, we should align better with this vision of the future. And the problem, of course, is that it's easy to say that, how do you get there? What is the journey look like to go from where you are to where you're going? And, of course, how do you avoid the trap that we all fall into at every company, which is, “Just after this next sprint finishes, we're going to stop making poor decisions and make good ones instead and all the technical debt gets paid off.” Everyone says it, but it's the biggest lie this industry tells ourselves constantly. And we tell it to ourselves in every company, in every environment I've ever seen.

Jez: Yeah. I mean, in the future, things will be better. And there's never been a worse time to think that. And I think the important thing to realize first is that all these books, certainly all the books I've written, they're composites of a bunch of different experiences. 

So, there's no one project on which all the things in the Continuous Delivery book were true, or The DevOps Handbook], or Accelerate. None of these books—and I can only speak on my own behalf, but I would suspect the same is true of other books—they’re composites of a whole bunch of different experience, plus some extrapolations, plus some hindsight bias, plus some narrative fallacy. And so what you’ve got to realize is all of us, when we're writing these things, we've been inspired by things that have happened that, we've experienced, and things that have happened that other people have experienced, and you synthesize and you extrapolate, and you're like, “Oh, there's a thing here.” There's a set of principles; we can test those; we can validate them. 

But in real life, I mean, the dirty secret, which we wrote at the end of the DevOps Handbook, is that a lot of those case studies where, la, the amazing thing happens, well some senior manager left and then someone new came in, and then it went back to [BLEEP] again. And so I think, firstly, you've got to lower your expectations and realize that even the people who you look up to who are doing great things, they’re living in the real world, too. Google is often pointed to as some kind of amazing, perfect unicorn. Google is a massive bureaucracy like any other massive bureaucracy, and we can't change the laws of physics. And I think it's important to be humble about that. 

And the important thing is, it's really boring. It's just like anything else, you just got to do a little bit every day. It's like trying to diet, or trying to get better at anything, or trying to write—the advice from Ernest Hemingway about writing, about making sure you do a little bit every day, which is probably the most boring thing that Hemingway said, but also one of the most important things. It's just that. It's just that discipline of trying to get a little bit better every day. And that's how you do it. And really good organizations give you the time and capacity and resources to do that. But it's hard, and it takes a long time, and it's relentless, and it can be a bit tedious.

Corey: In what you might be forgiven for mistaking for a blast from the past, today I want to talk about New Relic. They seem to be a relatively legacy monitoring company, and I would have agreed with that assessment up until relatively recently. But they did something a little out there: they reworked everything. They went open source, they made it so you can monitor your whole stack in one place and, most notably from my perspective, they simplified their pricing into something that is much more affordable for almost everyone. There's even a free tier with one user and 100 gigs per month, totally free. Check it out at newrelic.com.

Corey: That's the hard part, is people also look at this through a lens of, “Well, okay, I read the book, and I saw all the things we have to do, and I look at what we're doing across the board, and we're doing approximately none of those things. So, okay, what do we do? Well, we have to fire everyone and burn everything down to the ground.” And it's not really—there's a reason that we call this a journey, not a destination. And not everything has to be, I guess, the top of the scale in every category. It just doesn't work that way. 

I mean, we take a look at the same idea of how to go multi-region, and being able to handle extreme high availability at global scale but, I mean, take the ridiculous system that builds my newsletter, it's single region in a single AWS region. There's no redundancy there, and there doesn't need to be because if you think about it through a lens of a business context, for example: cool. The entire AWS region is hard down. I'm going to be sending a very different newsletter out that week if that happens, and I think the world will be quite okay with that. It doesn't have a business need for that, so why invest in the additional expense, not just of infrastructure, but of engineering time and effort of getting that monstrosity to work in a more durable way when there's no business requirement for it? Just get better than it is today, and focus on the thing that's material to your business, not the thing that—with all love and respect—some book say is important for you to focus on instead. Because yeah, there's commonality there, but a book that is written for the masses is never going to have particular context into your situation. That's what judgment is for. And it's why robots don't do our jobs… yet.

Jez: [laughs]. Yes, hopefully. That is a worry, but I've consistently been relieved by the fact that it appears that I have a job for life because I'm still talking about things that we were talking about in the 1960s, and still haven't been able to effectively implement. And those are all human things. I mean, I've got McGregor's Human Side of Enterprise on my bookshelf from 1960 where he talks about theory X and theory Y, and that's still a real problem that we face. We just published an article on transformational leadership which is closely related to those concepts, and effective leadership is still really hard. 

All the big obstacles to improvement are people-based, human-based, and those are hard problems to solve because a lot of it depends on building an organization where you can effectively delegate to the people doing the work to make decisions. And the larger the organization gets, the harder that is to do because people don't have visibility into what's going on and how to get better, and they are unable to make good prioritization decisions, and they need to work together with other people who may have different priorities, and trying to get people aligned, and trying to give them the resources and the ability to make change and accept that when they do that, they're going to mess it up a whole bunch of times. And that's okay because that's how you learn. Those are all incredibly difficult things to achieve, and no machine is going to ever solve that problem. And we'll be lucky if any human solves that problem, frankly.

Corey: One of the things that I'm a big fan of is the Dunning–Kruger effect. And I think that that is entirely malign when we look at how it is commonly applied. Because people generally understand it: it's this idea of, “Oh, people who are ignorant of an area don't even know how much they don't know, so they think it's easy.” What I think people miss is that this applies to everyone in various fields of endeavor. Just because you know this thing exists does not mean that you're not susceptible to it. 

I mean, I was as guilty as anyone, but when I first started my company aimed at fixing AWS bills, I was worried that AWS was going to fix all the problems with the bill in the next six months, and then I wouldn't have a business anymore. Now that I know what I know, my big concern is that they're never going to be able to fix this because it is such a complex and deep problem that I might not ever get to go focus on other problems I find more interesting as I walk through the world. There is such hidden depths of complexity behind almost every area that you have to constantly remind yourself—at least I do in my case—is whenever I look at something I don't understand well and think, “That doesn't seem hard,” that is almost certainly the whispers of Dunning–Kruger in my ear and it's, you're basically hand-waving over entire fields of expertise that is not being accomplished right now by people who are bad at things. Maybe dig deeper.

Jez: [laughs]. Yes. And I think Silicon Valley is one of the worst when it comes to the Dunning–Kruger effect. You'll never find people more willing to wade in on topics that they're supremely unqualified to pronounce on then a bunch of Silicon Valley tech bros who have solved one problem and think they thus have the ability to solve every problem. And that's something I constantly work on myself because, you know, I'm as susceptible to that as everyone else. 

So, fortunately, I have people in my life who tell me to shut the [BLEEP] up, and that's a very valuable service. And I think you're in a very lucky position with The Duckbill Group. I love this quote from Upton Sinclair. “It's difficult to get someone to understand something when their salary depends on them not understanding it.” That's where you are with The Duckbill Group. I don't think Amazon will ever solve that problem, and you're in a great position to solve it. And it's the same with getting people to improve the way they develop and deliver software.

Corey: It's gone through weird iterations because at first, again, naively I thought, “Oh, I'll come in and I'll fix the billing problem they have and save a bunch of money, and there we go, I'm done. And it's a shame I'll never have a second engagement to sell those people.” Yeah. Turns out it doesn't work that way. A) find me a single cloud environment that is static from month to month, where the entire team hasn't disbanded and someone forgot to cancel a credit card. It just doesn't happen.

Jez: No.

Corey: Environments continue to evolve. And it's also not just about lowering the bill—people believe it is—it's about understanding and predicting it. It's about moving up a maturity model of going from—on one end you have finance getting a giant bill from Amazon, and their first question is, “Wow, how many books is engineering buying?” And there needs to be an education there. 

And on the other end of the spectrum, it's, “Cool. As we wind up defining our bill every month by a function of users that we have, how do we wind up accurately predicting that over an 18- to 36-month span?” And again, this is not specific to Amazon, these problems. It's just where I focus because, surprise, specificity in marketing really the right answer. If I'm all things, all clouds, to all people, great. Swing a dead cat, you look like a generalist. And that's not an expensive problem that people bring consultants in for. Be specific, solve a problem.

Jez: This reminds me of my funniest experience working at 18F was when I was sat next to a contracting officer talking about an AWS buy that we were trying to get through. And I was basically explaining the problem with the Cloud, there's two axes of variability. There's the resources you decide to buy, which is somewhat under your control, and then there's how much end users decide to use those resources, which is really not under your control as much as you would like. And the contracting officer was, kind of, looking at me as I was having this discussion, and he said, “Let me explain how contracting works in the US government. We put an order in for 100 sandbags, and then we get 100 sandbags.” And he just sat there in, kind of, silence, paused for a little while. And I was like, “Okay. We're going to have to go back to the basics here.” 

And, you know, we had a discussion about mobile phones and how mobile phone bills are variable. And he was like, “Yes. This is why we have fixed-price contracts for mobile phones, which is all you can eat.” And you just fundamentally can't do that with the Cloud because of that second-order effect. So, I ended up putting together this crazy spreadsheet, where I basically listed all the things we had consumed and then did some kind of moderately complex statistics with two orders of standard deviation to try and put a buffer in.

But, I knew it was all crap because consumption of resources doesn't follow a normal distribution, and so it was all just padding, and you can't make predictions based on power law, which is Nicholas Taleb’s entire career in a nutshell. And also because what that forces you to do is just spend a large fixed amount of money on something which is probably going to be ending up much cheaper, but that won't end up much cheaper because you've got to buffer it because you want to fixed price. And that's fundamentally what you're dealing with, and it's incredibly problematic.

Corey: It turns out that one of the hardest parts in all of business and all of computing is not—contrary to popular opinion. For example, “Money is always a limiting constraint.” Not really. Look at companies like SoftBank walking the world. You can always find money from someone who has no clue what's going on. 

But in fact, that is the actual constraint. It's a lack of understanding. And we all suffer from it in different arenas in different areas, and the thing I never really appreciated until I started working with large enterprises is in a small company, the people I talk to as I go through a consulting engagement are effectively the same person at a small enough company, the person who signs the check, the person who champions bringing me in, the person who benefits from what I wind up doing, great. At an enterprise, the organizational distance between those various people is sufficiently great that no one person anymore can hold the entire problem space in their head, and that's where running and managing teams is incredibly important. Good departmental communication becomes critical. 

And my old-school startup approach is very cynical around that. It's, oh, just hire smarter people who can hold it all in their head. Yes, how scalable. Brilliant. Big companies are their own scale, and I never appreciated that. Like, when I started making fun of Amazon in the newsletter, I thought I was going to upset Amazon as if there's someone over there named Steve Amazon that is going to get upset by the things that I say that informs an entire company's opinion of me. Yeah, turns out companies don't have single people who make opinions for the entire environment. It's different groups, different people. Some people love me, some people hate me, but most of them—far and away—do not know who I am.

Jez: Yeah. That's definitely humbling. And the good news about that is that's why it's okay to give the same talk multiple times in different places. So, there is a benefit from that.

Corey: Oh, absolutely. I mix it up a little bit. I try and change the titles so people may not necessarily realize it's a version of the same talk, but also when you suck at preparation—hi—everything that you do, in turn, becomes an exercise in improv. So, yeah, I have the same bullet points, but I'll give the same slide deck twice with radically different results, radically different storytelling approaches, just because, well, I didn't write it down the first time. I guess I'll be coming up with this from whole cloth again. It's fun. Not that I recommend this as a great speaking technique for most people. It's sort of me working around my own shortcomings.

Jez: Well, I think that's an excellent point. And that probably is the major driver of my career as well is working for my own shortcomings, and finding good strategies to deal with my personality defects.

Corey: Well, thank you so much for taking the time to speak with me today. If people want to hear more about what you have to say what you're up to, find you in order to cast various slings and arrows in your direction, where can they track you down?

Jez: So, I tweet at @jezhumble. I am Jez Humble pretty much everywhere on the internet, so have at it. Definitely don't use LinkedIn because nothing is more annoying than unsolicited LinkedIn messages.

Corey: Oh my stars, yes. Like, it's always weird to me—I do want to ask you that one: that's a fun sidebar for there. My approach to LinkedIn has always been that if I've met with someone, and I've had a conversation with them, and I could pick them out of a police lineup—but hopefully won't have to—I will connect to them on LinkedIn. But, “Hey, you gave a talk to a room of 300 people, I'd like to add you on LinkedIn now.” For me, at least, and maybe I'm conceptualizing this in the wrong way, but if I am connected to someone on LinkedIn, I would need to feel comfortable sending them a message asking them for an introduction to someone they know. And if, “Hi, I gave a talk eight years ago, and you were in the room when I gave that talk. Can you introduce me to your boss?” Some people are comfortable asking stuff like that. I’m really not. So, for me, at least, I tend to curate my LinkedIn connections relatively carefully. It seems that most people don't take that approach. So, I have to suspect I'm the one who's wrong.

Jez: I mean, the only thing keeping me from deleting my LinkedIn account right now is my own ego, which unfortunately is a substantial obstacle.

Corey: [laughs]. Okay, I find it reassuring that people who I respect in this space are not going to look at my approach and think it's completely out to lunch.

Jez: Well, honestly, here as in many other ways, Kelsey Hightower has led the way by, in fact, deleting his LinkedIn account. So, just one of the many ways in which we can aspire to be more like Kelsey.

Corey: Oh, that sounds like the promised land where I get to wander the desert for forty years, but I am not allowed to go in.

Jez: [laughs].

Corey: Thanks so much for taking the time to speak with me today. I really do appreciate it.

Jez: It's an absolute pleasure. Thank you so much for having me on.

Corey: Jez Humble, developer advocate at Google. I am Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on Apple Podcasts, whereas if you've hated this podcast, please leave a five-star review on Apple Podcasts and a comment including the entirety of at least one NIST standard.

Announcer: This has been this week’s episode of Screaming in the Cloud. You can also find more Corey at ScreamingintheCloud.com, or wherever fine snark is sold.

This has been a HumblePod production. Stay humble.