OwlTail

Cover image of Jez Humble

Jez Humble Podcasts

Read more

9 of The Best Podcast Episodes for Jez Humble. A collection of podcasts episodes with or about Jez Humble, often where they are interviewed.

Read more

9 of The Best Podcast Episodes for Jez Humble. A collection of podcasts episodes with or about Jez Humble, often where they are interviewed.

Updated daily with the latest episodes

Episode artwork

Teaching the Cloud Forever with Jez Humble

Play
Read more
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 ReferencedTranscript
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.
Oct 29 2020 · 30mins
Episode artwork

DevOps with Nathen Harvey and Jez Humble

Play
Read more

Happy Thanksgiving! This week, Aja and Brian are talking DevOps with Nathen Harvey and Jez Humble. Our guests thoroughly explain what DevOps is and why it’s important. DevOps purposely has no official definition but can be thought of as a community of practice that aims to make large-scale systems reliable and secure. It’s also a way to get developers and operations to work together to focus on the needs of the customer.

Nathen later tells us all about DevOpsDays, a series of locally organized conferences occurring in cities around the world. The main goal is to bring a cross-functional group of people together to talk about how they can improve IT, DevOps, business strategy, and consider cultural changes the organization might benefit from. DevOpsDays supports this by only planning content for half the conference, then turning over the other half to attendees via Open Spaces. At this time, conference-goers are welcome to propose a topic and start a conversation.

Jez then describes the Accelerate State of DevOps Report, how it came to be, and why it’s so useful. It includes items like building security into the software, testing continuously, ideal management practices, product development practices, and more. With the help of the DevOps Quick Check, you can discover the places your company could use some help and then refer back to the report for suggestions of improvements in those areas.

Nathen Harvey

Nathen Harvey helps the community understand and apply DevOps and SRE practices in the cloud. He is part of the global organizing committee for the DevOpsDays conferences and was a technical reviewer for the 2019 Accelerate State of DevOps Report.

Jez Humble

Jez Humble is co-author of several books on software including Shingo Publication Award winner “Accelerate” and Jolt Award winner “Continuous Delivery”. He has spent his career tinkering with code, infrastructure, and product development in companies of varying sizes across three continents. He works for Google Cloud as a technology advocate and teaches at UC Berkeley.

Cool things of the week
  • It’s a wrap: Key announcements from Next ‘19 UK blog
  • Explainable AI site
  • Hand-drawn Graphviz diagrams blog
    • Add one line to plot in XKCD comic sketchy style site
Interview
  • DevOps insights from Google site
  • DevOps Quick Check site
  • DevOpsDays site
  • Agile Alliance site
  • Velocity Conference site
  • DevOps Enterprise Summit site
Question of the week

Why do you need the Cloud SQL Proxy?

Where can you find us next?

DevOpsDays has events coming up across the globe, including Galway, Warsaw, Berlin, and Tel Aviv. Nathen and Jez will be at Delivery Conf.

Aja will be home drinking tea!

Brian will also be home drinking tea!

Nov 27 2019 · 34mins

Similar People

Gene Kim

Nicole Forsgren

Mark Miller

Kelsey Hightower

Christine Spang

Randy Shoup

Jeffrey Snover

Joel Spolsky

Laura Frank

Esther Derby

Andrea Goulet

Phil Haack

Dave Thomas

John Allspaw

Jeremy Miller

Episode artwork

Ep. #9, High Performance DevOps with Jez Humble

Play
Read more

In episode 9 of o11ycast, Charity and Rachel sit down with Jez Humble, Co-Founder and CTO of DevOps Research and Assessments (acquired by Google since this session was recorded), to discuss DevOps security and how a team’s culture relates to their success.

The post Ep. #9, High Performance DevOps with Jez Humble appeared first on Heavybit.

Mar 12 2019 · 39mins
Episode artwork

DevOps by the Data (Guests: Nicole Forsgren & Jez Humble)

Play
Read more
This episode we talk with two of the co-founders of DevOps Research and Assessment, LLC (DORA) - Nicole Forsgren, CEO and Chief Scientist, and Jez Humble, CTO. Nicole and Jez are two of the key thought leaders in the DevOps movement and have done more than most to evangelize and legitimize DevOps best practices. Through their extensive research, surveys, and in-depth analysis at DORA they, along with their co-founder Gene Kim, have built a strong, data-backed foundation for DevOps. We will discuss their new book, Accelerate, where they brought this research together and present some fascinating conclusions about what DevOps, when implemented well, can do for an organization.
Jun 11 2018 · 49mins

Most Popular

Elon Musk

Barack Obama

Bill Gates

LeBron James

Mark Cuban

Michelle Obama

Melinda Gates

Arnold Schwarzenegger

Kevin Hart

Terry Crews

Mike Tyson

Episode artwork

Jez Humble on Making Continuous Delivery Work and Responding to Discrimination in Tech

Play
Read more
In this podcast Shane Hastie, Lead Editor for Culture & Methods, spoke to Jez Humble about his Agile 2017 Keynote talk in which he refuted many of the common excuses why “continuous delivery won’t work here”. He also gave a scathing response to the “Manifestbro” controversy which recently unfolded at Google.

Why listen to this podcast:

Key takeaways about DevOps:

- There are many reasons cited for not adopting DevOps – the real reasons are cultural and architectural issues
- It takes commitment and effort at every level to rearchitect not just the products but the organisation to support the new ways of working
- Even if you are not deploying every day, the practices of DevOps deliver huge dividends around reducing development costs, improving quality and maintainability and driving shorter lead
- It’s not about repeating what someone else has done, it’s the ability to make mistakes and learn from them which makes teams and organisations successful

Key takeaways on the gender diversity challenge:

- In 2017 we should have come beyond the need to address these issues but the state of the industry means we must
- There is extensive research that shows the differences are tiny between the genders, and this cannot explain the vast disparity in representation in the industry by women and people of colour
- The harm done by perpetuating the myths around gender differences
- We all have a duty to create an inclusive environment
- Examine your organisation’s systems, policies and practices for the visible elements of discrimination and fix them – check salaries and career advancement by role and if there is a gender or race difference in the rates of pay or advancement then fix them
- Introducing Inclusive Collaboration and calling for participation and having the conversations about the many aspects of diversity in the workplace today

More on this: Quick scan our curated show notes on InfoQ http://bit.ly/2hYYH6G

You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq

Subscribe: www.youtube.com/infoq
Like InfoQ on Facebook: bit.ly/2jmlyG8
Follow on Twitter: twitter.com/InfoQ
Follow on LinkedIn: www.linkedin.com/company/infoq
Want to see extented shownotes? Check the landing page on InfoQ: http://bit.ly/2hYYH6G
Aug 14 2017 · 28mins
Episode artwork

Jez Humble Interview Lean Enterprise Trunk Based Development

Play
Read more
Episode 7 of the Modern Agile Show features an interview with Jez Humble, co-author of Continuous Delivery, Lean Enterprise and The DevOps Handbook. Jez reads a passage from Lean Enterprise, we discuss the Modern Agile principles, Continuous Delivery and Trunk-based development.
Dec 19 2016 · 24mins
Episode artwork

Lean Enterprise by Jez Humble | Episode 160

Play
Read more

In this episode Jez Humble takes a deep dive into his book, Lean Enterprise where he uncovers how high performing organizations are able to innovate at scale.In his book Humble sifts through case studies, principles, and patterns of very successful well-known companies providing you with an action guide to help you rethink how to run your business. The goal of the book is to teach you what it takes to implement the methodologies he presents, manage large-scale projects, create a non-traditional management style, and accelerate innovation.This book is perfect for entrepreneurs who run a well-established organization that is having trouble adapting to changing market conditions and need a fast, innovative approach to scaling up.About Jez Humble:“I am a Vice President at Chef, a lecturer at UC Berkeley, and before Lean Enterprise I wrote Continuous Delivery. My background is in software engineering and I’ve worked in multiple industries, in multiple companies, helping organizations get better at delivering high quality valuable software products.Lean Enterprise is about how you create organizations that are able to work in short development cycles, build products rapidly, and get feedback. And that requires us to change the way we think about portfolio management, financial management, culture, and pretty much everything else. All these things need to be a bit different in order to compete in this world where we have these very short product cycles.” – Jez HumbleFor a detailed summary of Lean Enterprise according to Jez Humble CLICK HERERelated Books:Scaling Up by Verne HarnishExponential Organization by Salim IsmailFail Fast or Win Big by Bernhard SchroederFor more advice, tips, and stories on entrepreneurship, join our community on Facebook and Twitter.

Feb 19 2015 · 21mins
Episode artwork

Continuous Delivery with Jez Humble and Martin Fowler

Play
Read more

Scott sits down with Jez Humble and Martin Fowler at the GOTO Conference in Aarhus, Denmark to talk about Continuous Delivery. How do your software systems have to change if you deploy weekly? Daily? How about 10 times a day?

Oct 02 2012 · 34mins
Episode artwork

DevOps Cafe Ep. 33 - Guest: Jez Humble

Play
Read more

Jez Humble joins John and Damon for a chat about DevOps, the history of Continuous Delivery, leadership, and changing culture.  

Show notes are at http://devopscafe.org

Sep 26 2012 · 1hr