Podcasts about devops research

Connect to John Gilroy on LinkedIn   https://www.linkedin.com/in/john-gilroy/ Want to listen to other episodes? www.Federaltechpodcast.com We all know the quote from Peter Drucker, "If you can measure it, you can manage it."   It's pretty easy to apply when throwing a javelin but difficult when measuring success in complex software development projects. Today, we sat down with Jeff Gallimore, Chief Technology and Innovation Officer and founder of Excella. He brings with him decades of experience collaborating with teams on successful federal projects. We start by noting the fallacy of using one metric to measure success. While completing the initiative on time might make an agency administrator happy, that will change rapidly if compliance is not achieved, and scaling will break the system into pieces. Jeff has seen breakthroughs using a framework called DORA, DevOps Research and Assessment). The key metrics are deployment frequency, lead time for changes, change failure rate, and failed deployment recovery time.  These metrics, now part of Google, are research-based and predictive of IT and organizational outcomes. They emphasize the importance of a holistic approach, avoiding single-metric focus, and the role of leadership and culture in fostering high-performing teams

Derek Ferguson from The Fitch Group returns to share how his team of 600+ developers leverages generative AI tools like Amazon's CodeWhisperer and implements DORA metrics to boost productivity and team health. In this second part of the conversation, he delves into the transformative impact of these tools and the innovative strategies driving adoption and success at scale. Listen to Derek's experiences in introducing cutting-edge tools to a large organization, his lessons in fostering experimentation, and the surprising parallels between today's AI adoption and the internet boom. From the role of community practices versus centers of excellence to pragmatic advice on technology adoption, this episode is packed with actionable insights for leaders and developers alike. Stick around for Derek's perspective on the evolving role of technologists in an AI-driven world and how music creation intersects with his tech expertise. Inside the episode… • Exploring generative AI for software development and its transformative potential. • Implementing DORA metrics to boost productivity and enhance team alignment. • Lessons learned from scaling technology practices across large organizations. • The balance between prescriptive guidance and fostering creativity in teams. • Insights into creating impactful developer communities of practice. Mentioned in this episode • Generative AI tools (e.g., Amazon's CodeWhisperer) • DORA metrics (DevOps Research and Assessment) • Tools for music and tech crossover (e.g., RipX, Replicate) Unlock the full potential of your product team with Integral's player coaches, experts in lean, human-centered design. Visit integral.io/convergence for a free Product Success Lab workshop to gain clarity and confidence in tackling any product design or engineering challenge. Subscribe to the Convergence podcast wherever you get podcasts including video episodes to get updated on the other crucial conversations that we'll post on YouTube at youtube.com/@convergencefmpodcast Learn something? Give us a 5 star review and like the podcast on YouTube. It's how we grow.   Follow the Pod Linkedin: https://www.linkedin.com/company/convergence-podcast/ X: https://twitter.com/podconvergence Instagram: @podconvergence  

Nathen Harvey is Developer Advocate and the lead for DORA at Google Cloud, their DevOps Research and Assessment unit. For ten years Nathen has spearheaded tech communities and authored several reports that now form the industry standard for measuring DevOps performance. He was once a CRM system administrator too — he knows his stuff and the challenges we all face too!Nathen joins Jack on the DevOps Diaries podcast to discuss all things metrics. In an enticing and insightful conversation, Nathen shares with us how the DORA metrics came to be, what they are, and why measuring performance is important for all teams to drive their businesses in the right direction.Nathen also shares with us some of the common pitfalls of metrics, including Goodhart's Law, and what we can do to avoid them. If you're unsure of where to start when it comes to measuring performance, or how to improve, this is the episode for you.Nathen and Jack also discuss the wider market trends and how engineering teams can up their game using the SPACE framework.Learn more:DORA 2023 reportThe State of Salesforce DevOps 2024 reportThe common pitfalls when measuring performanceHow to align metrics with business performanceConnect with NathenLinkedInX/TwitterConnect with Jack X/TwitterLinkedInPodcast produced and sponsored by Gearset, the complete Salesforce DevOps platform. Try Gearset free for 30 days. 

Devops Redux (click here to comment) 16. April 2024, In dieser Episode begrüßen wir Sujeevan

Richard Seroter, Director of Outbound Product Management at Google, joins Corey on Screaming in the Cloud to discuss what's new at Google. Corey and Richard discuss how AI can move from a novelty to truly providing value, as well as the importance of people maintaining their skills and abilities rather than using AI as a black box solution. Richard also discusses how he views the DevRel function, and why he feels it's so critical to communicate expectations for product launches with customers. About RichardRichard Seroter is Director of Outbound Product Management at Google Cloud. He's also an instructor at Pluralsight, a frequent public speaker, and the author of multiple books on software design and development. Richard maintains a regularly updated blog (seroter.com) on topics of architecture and solution design and can be found on Twitter as @rseroter. Links Referenced: Google Cloud: https://cloud.google.com Personal website: https://seroter.com Twitter: https://twitter.com/rseroter LinkedIn: https://www.linkedin.com/in/seroter/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, 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: Human-scale teams use Tailscale to build trusted networks. Tailscale Funnel is a great way to share a local service with your team for collaboration, testing, and experimentation.  Funnel securely exposes your dev environment at a stable URL, complete with auto-provisioned TLS certificates. Use it from the command line or the new VS Code extensions. In a few keystrokes, you can securely expose a local port to the internet, right from the IDE.I did this in a talk I gave at Tailscale Up, their first inaugural developer conference. I used it to present my slides and only revealed that that's what I was doing at the end of it. It's awesome, it works! Check it out!Their free plan now includes 3 users & 100 devices. Try it at snark.cloud/tailscalescream Corey: Welcome to Screaming in the Cloud, I'm Corey Quinn. We have returning guest Richard Seroter here who has apparently been collecting words to add to his job title over the years that we've been talking to him. Richard, you are now the Director of Product Management and Developer Relations at Google Cloud. Do I have all those words in the correct order and I haven't forgotten any along the way?Richard: I think that's all right. I think my first job was at Anderson Consulting as an analyst, so my goal is to really just add more words to whatever these titles—Corey: It's an adjective collection, really. That's what a career turns into. It's really the length of a career and success is measured not by accomplishments but by word count on your resume.Richard: If your business card requires a comma, success.Corey: So, it's been about a year or so since we last chatted here. What have you been up to?Richard: Yeah, plenty of things here, still, at Google Cloud as we took on developer relations. And, but you know, Google Cloud proper, I think AI has—I don't know if you've noticed, AI has kind of taken off with some folks who's spending a lot the last year… juicing up services and getting things ready there. And you know, myself and the team kind of remaking DevRel for a 2023 sort of worldview. So, yeah we spent the last year just scaling and growing and in covering some new areas like AI, which has been fun.Corey: You became profitable, which is awesome. I imagined at some point, someone wound up, like, basically realizing that you need to, like, patch the hole in the pipe and suddenly the water bill is no longer $8 billion a quarter. And hey, that works super well. Like, wow, that explains our utility bill and a few other things as well. I imagine the actual cause is slightly more complex than that, but I am a simple creature.Richard: Yeah. I think we made more than YouTube last quarter, which was a good milestone when you think of—I don't think anybody who says Google Cloud is a fun side project of Google is talking seriously anymore.Corey: I misunderstood you at first. I thought you said that you're pretty sure you made more than I did last year. It's like, well, yes, if a multi-billion dollar company's hyperscale cloud doesn't make more than I personally do, then I have many questions. And if I make more than that, I have a bunch of different questions, all of which could be terrifying to someone.Richard: You're killing it. Yeah.Corey: I'm working on it. So, over the last year, another trend that's emerged has been a pivot away—thankfully—from all of the Web3 nonsense and instead embracing the sprinkle some AI on it. And I'm not—people are about to listen to this and think, wait a minute, is he subtweeting my company? No, I'm subtweeting everyone's company because it seems to be a universal phenomenon. What's your take on it?Richard: I mean, it's countercultural now to not start every conversation with let me tell you about our AI story. And hopefully, we're going to get past this cycle. I think the AI stuff is here to stay. This does not feel like a hype trend to me overall. Like, this is legit tech with real user interest. I think that's awesome.I don't think a year from now, we're going to be competing over who has the biggest model anymore. Nobody cares. I don't know if we're going to hopefully lead with AI the same way as much as, what is it doing for me? What is my experience? Is it better? Can I do this job better? Did you eliminate this complex piece of toil from my day two stuff? That's what we should be talking about. But right now it's new and it's interesting. So, we all have to rub some AI on it.Corey: I think that there is also a bit of a passing of the buck going on when it comes to AI where I've talked to companies that are super excited about how they have this new AI story that's going to be great. And, “Well, what does it do?” “It lets you query our interface to get an answer.” Okay, is this just cover for being bad UX?Richard: [laugh]. That can be true in some cases. In other cases, this will fix UXes that will always be hard. Like, do we need to keep changing… I don't know, I'm sure if you and I go to our favorite cloud providers and go through their documentation, it's hard to have docs for 200 services and millions of pages. Maybe AI will fix some of that and make it easier to discover stuff.So in some cases, UIs are just hard at scale. But yes, I think in some cases, this papers over other things not happening by just rubbing some AI on it. Hopefully, for most everybody else, it's actually interesting, new value. But yeah, that's a… every week it's a new press release from somebody saying they're about to launch some AI stuff. I don't know how any normal human is keeping up with it.Corey: I certainly don't know. I'm curious to see what happens but it's kind of wild, too, because there you're right. There is something real there where you ask it to draw you a picture of a pony or something and it does, or give me a bunch of random analysis of this. I asked one recently to go ahead and rank the US presidents by absorbency and with a straight face, it did it, which is kind of amazing. I feel like there's a lack of imagination in the way that people talk about these things and a certain lack of awareness that you can make this a lot of fun, and in some ways, make that a better showcase of the business value than trying to do the straight-laced thing of having it explain Microsoft Excel to you.Richard: I think that's fair. I don't know how much sometimes whimsy and enterprise mix. Sometimes that can be a tricky part of the value prop. But I'm with you this some of this is hopefully returns to some more creativity of things. I mean, I personally use things like Bard or what have you that, “Hey, I'm trying to think of this idea. Can you give me some suggestions?” Or—I just did a couple weeks ago—“I need sample data for my app.”I could spend the next ten minutes coming up with Seinfeld and Bob's Burgers characters, or just give me the list in two seconds in JSON. Like that's great. So, I'm hoping we get to use this for more fun stuff. I'll be fascinated to see if when I write the keynote for—I'm working on the keynote for Next, if I can really inject something completely off the wall. I guess you're challenging me and I respect that.Corey: Oh, I absolutely am. And one of the things that I believe firmly is that we lose sight of the fact that people are inherently multifaceted. Just because you are a C-level executive at an enterprise does not mean that you're not also a human being with a sense of creativity and a bit of whimsy as well. Everyone is going to compete to wind up boring you to death with PowerPoint. Find something that sparks the imagination and sparks joy.Because yes, you're going to find the boring business case on your own without too much in the way of prodding for that, but isn't it great to imagine what if? What if we could have fun with some of these things? At least to me, that's always been the goal is to get people's attention. Humor has been my path, but there are others.Richard: I'm with you. I think there's a lot to that. And the question will be… yeah, I mean, again, to me, you and I talked about this before we started recording, this is the first trend for me in a while that feels purely organic where our customers, now—and I'll tell our internal folks—our customers have much better ideas than we do. And it's because they're doing all kinds of wild things. They're trying new scenarios, they're building apps purely based on prompts, and they're trying to, you know, do this.And it's better than what we just come up with, which is awesome. That's how it should be, versus just some vendor-led hype initiative where it is just boring corporate stuff. So, I like the fact that this isn't just us talking; it's the whole industry talking. It's people talking to my non-technical family members, giving me ideas for what they're using this stuff for. I think that's awesome. So yeah, but I'm with you, I think companies can also look for more creative angles than just what's another way to left-align something in a cell.Corey: I mean, some of the expressions on this are wild to me. The Photoshop beta with its generative AI play has just been phenomenal. Because it's weird stuff, like, things that, yeah, I'm never going to be a great artist, let's be clear, but being able to say remove this person from the background, and it does it, as best I can tell, seamlessly is stuff where yeah, that would have taken me ages to find someone who knows what the hell they're doing on the internet somewhere and then pay them to do it. Or basically stumble my way through it for two hours and it somehow looks worse afterwards than before I started. It's the baseline stuff of, I'm never going to be able to have it—to my understanding—go ahead just build me a whole banner ad that does this and hit these tones and the rest, but it is going to help me refine something in that direction, until I can then, you know, hand it to a professional who can take it from my chicken scratching into something real.Richard: If it will. I think that's my only concern personally with some of this is I don't want this to erase expertise or us to think we can just get lazy. I think that I get nervous, like, can I just tell it to do stuff and I don't even check the output, or I don't do whatever. So, I think that's when you go back to, again, enterprise use cases. If this is generating code or instructions or documentation or what have you, I need to trust that output in some way.Or more importantly, I still need to retain the skills necessary to check it. So, I'm hoping people like you and me and all our —every—all the users out there of this stuff, don't just offload responsibility to the machine. Like, just always treat it like a kind of slightly drunk friend sitting next to you with good advice and always check it out.Corey: It's critical. I think that there's a lot of concern—and I'm not saying that people are wrong on this—but that people are now going to let it take over their jobs, it's going to wind up destroying industries. No, I think it's going to continue to automate things that previously required human intervention. But this has been true since the Industrial Revolution, where opportunities arise and old jobs that used to be critical are no longer centered in quite the same way. The one aspect that does concern me is not that kids are going to be used to cheat on essays like, okay, great, whatever. That seems to be floated mostly by academics who are concerned about the appropriate structure of academia.For me, the problem is, is there's a reason that we have people go through 12 years of English class in the United States and that is, it's not to dissect of the work of long-dead authors. It's to understand how to write and how to tell us a story and how to frame ideas cohesively. And, “The computer will do that for me,” I feel like that potentially might not serve people particularly well. But as a counterpoint, I was told when I was going to school my entire life that you're never going to have a calculator in your pocket all the time that you need one. No, but I can also speak now to the open air, ask it any math problem I can imagine, and get a correct answer spoken back to me. That also wasn't really in the bingo card that I had back then either, so I am a hesitant to try and predict the future.Richard: Yeah, that's fair. I think it's still important for a kid that I know how to make change or do certain things. I don't want to just offload to calculators or—I want to be able to understand, as you say, literature or things, not just ever print me out a book report. But that happens with us professionals, too, right? Like, I don't want to just atrophy all of my programming skills because all I'm doing is accepting suggestions from the machine, or that it's writing my emails for me. Like, that still weirds me out a little bit. I like to write an email or send a tweet or do a summary. To me, I enjoy those things still. I don't want to—that's not toil to me. So, I'm hoping that we just use this to make ourselves better and we don't just use it to make ourselves lazier.Corey: You mentioned a few minutes ago that you are currently working on writing your keynote for Next, so I'm going to pretend, through a vicious character attack here, that this is—you know, it's 11 o'clock at night, the day before the Next keynote and you found new and exciting ways to procrastinate, like recording a podcast episode with me. My question for you is, how is this Next going to be different than previous Nexts?Richard: Hmm. Yeah, I mean, for the first time in a while it's in person, which is wonderful. So, we'll have a bunch of folks at Moscone in San Francisco, which is tremendous. And I [unintelligible 00:11:56] it, too, I definitely have online events fatigue. So—because absolutely no one has ever just watched the screen entirely for a 15 or 30 or 60-minute keynote. We're all tabbing over to something else and multitasking. And at least when I'm in the room, I can at least pretend I'll be paying attention the whole time. The medium is different. So, first off, I'm just excited—Corey: Right. It feels a lot ruder to get up and walk out of the front row in the middle of someone's talk. Now, don't get me wrong, I'll still do it because I'm a jerk, but I'll feel bad about it as I do. I kid, I kid. But yeah, a tab away is always a thing. And we seem to have taken the same structure that works in those events and tried to force it into more or less a non-interactive Zoom call, and I feel like that is just very hard to distinguish.I will say that Google did a phenomenal job of online events, given the constraints it was operating under. Production value is great, the fact that you took advantage of being in different facilities was awesome. But yeah, it'll be good to be back in person again. I will be there with bells on in Moscone myself, mostly yelling at people, but you know, that's what I do.Richard: It's what you do. But we missed that hallway track. You missed this sort of bump into people. Do hands-on labs, purposely have nothing to do where you just walk around the show floor. Like we have been missing, I think, society-wise, a little bit of just that intentional boredom. And so, sometimes you need at conference events, too, where you're like, “I'm going to skip that next talk and just see what's going on around here.” That's awesome. You should do that more often.So, we're going to have a lot of spaces for just, like, go—like, 6000 square feet of even just going and looking at demos or doing hands-on stuff or talking with other people. Like that's just the fun, awesome part. And yeah, you're going to hear a lot about AI, but plenty about other stuff, too. Tons of announcements. But the key is that to me, community stuff, learn from each other stuff, that energy in person, you can't replicate that online.Corey: So, an area that you have expanded into has been DevRel, where you've always been involved with it, let's be clear, but it's becoming a bit more pronounced. And as an outsider, I look at Google Cloud's DevRel presence and I don't see as much of it as your staffing levels would indicate, to the naive approach. And let's be clear, that means from my perspective, all public-facing humorous, probably performative content in different ways, where you have zany music videos that, you know, maybe, I don't know, parody popular songs do celebrate some exec's birthday they didn't know was coming—[fake coughing]. Or creative nonsense on social media. And the the lack of seeing a lot of that could in part be explained by the fact that social media is wildly fracturing into a bunch of different islands which, on balance, is probably a good thing for the internet, but I also suspect it comes down to a common misunderstanding of what DevRel actually is.It turns out that, contrary to what many people wanted to believe in the before times, it is not getting paid as much as an engineer, spending three times that amount of money on travel expenses every year to travel to exotic places, get on stage, party with your friends, and then give a 45-minute talk that spends two minutes mentioning where you work and 45 minutes talking about, I don't know, how to pick the right standing desk. That has, in many cases, been the perception of DevRel and I don't think that's particularly defensible in our current macroeconomic climate. So, what are all those DevRel people doing?Richard: [laugh]. That's such a good loaded question.Corey: It's always good to be given a question where the answers are very clear there are right answers and wrong answers, and oh, wow. It's a fun minefield. Have fun. Go catch.Richard: Yeah. No, that's terrific. Yeah, and your first part, we do have a pretty well-distributed team globally, who does a lot of things. Our YouTube channel has, you know, we just crossed a million subscribers who are getting this stuff regularly. It's more than Amazon and Azure combined on YouTube. So, in terms of like that, audience—Corey: Counterpoint, you definitionally are YouTube. But that's neither here nor there, either. I don't believe you're juicing the stats, but it's also somehow… not as awesome if, say, I were to do it, which I'm working on it, but I have a face for radio and it shows.Richard: [laugh]. Yeah, but a lot of this has been… the quality and quantity. Like, you look at the quantity of video, it overwhelms everyone else because we spend a lot of time, we have a specific media team within my DevRel team that does the studio work, that does the production, that does all that stuff. And it's a concerted effort. That team's amazing. They do really awesome work.But, you know, a lot of DevRel as you say, [sigh] I don't know about you, I don't think I've ever truly believed in the sort of halo effect of if super smart person works at X company, even if they don't even talk about that company, that somehow presents good vibes and business benefits to that company. I don't think we've ever proven that's really true. Maybe you've seen counterpoints, where [crosstalk 00:16:34]—Corey: I can think of anecdata examples of it. Often though, on some level, for me at least, it's been okay someone I tremendously respect to the industry has gone to work at a company that I've never heard of. I will be paying attention to what that company does as a direct result. Conversely, when someone who is super well known, and has been working at a company for a while leaves and then either trashes the company on the way out or doesn't talk about it, it's a question of, what's going on? Did something horrible happen there? Should we no longer like that company? Are we not friends anymore? It's—and I don't know if that's necessarily constructive, either, but it also, on some level, feels like it can shorthand to oh, to be working DevRel, you have to be an influencer, which frankly, I find terrifying.Richard: Yeah. Yeah. I just—the modern DevRel, hopefully, is doing a little more of product-led growth style work. They're focusing specifically on how are we helping developers discover, engage, scale, become advocates themselves in the platform, increasing that flywheel through usage, but that has very discreet metrics, it has very specific ownership. Again, personally, I don't even think DevRel should do as much with sales teams because sales teams have hundreds and sometimes thousands of sales engineers and sales reps. It's amazing. They have exactly what they need.I don't think DevRel is a drop in the bucket to that team. I'd rather talk directly to developers, focus on people who are self-service signups, people who are developers in those big accounts. So, I think the modern DevRel team is doing more in that respect. But when I look at—I just look, Corey, this morning at what my team did last week—so the average DevRel team, I look at what advocacy does, teams writing code labs, they're building tutorials. Yes, they're doing some in person events. They wrote some blog posts, published some videos, shipped a couple open-source projects that they contribute to in, like gaming sector, we ship—we have a couple projects there.They're actually usually customer zero in the product. They use the product before it ships, provides bugs and feedback to the team, we run DORA workshops—because again, we're the DevOps Research and Assessment gang—we actually run the tutorial and Docs platform for Google Cloud. We have people who write code samples and reference apps. So, sometimes you see things publicly, but you don't see the 20,000 code samples in the docs, many written by our team. So, a lot of the times, DevRel is doing work to just enable on some of these different properties, whether that's blogs or docs, whether that's guest articles or event series, but all of this should be in service of having that credible relationship to help devs use the platform easier. And I love watching this team do that.But I think there's more to it now than years ago, where maybe it was just, let's do some amazing work and try to have some second, third-order effect. I think DevRel teams that can have very discrete metrics around leading indicators of long-term cloud consumption. And if you can't measure that successfully, you've probably got to rethink the team.[midroll 00:19:20]Corey: That's probably fair. I think that there's a tremendous series of… I want to call it thankless work. Like having done some of those ridiculous parody videos myself, people look at it and they chuckle and they wind up, that was clever and funny, and they move on to the next one. And they don't see the fact that, you know, behind the scenes for that three-minute video, there was a five-figure budget to pull all that together with a lot of people doing a bunch of disparate work. Done right, a lot of this stuff looks like it was easy or that there was no work at all.I mean, at some level, I'm as guilty of that as anyone. We're recording a podcast now that is going to be handed over to the folks at HumblePod. They are going to produce this into something that sounds coherent, they're going to fix audio issues, all kinds of other stuff across the board, a full transcript, and the rest. And all of that is invisible to me. It's like AI; it's the magic box I drop a file into and get podcast out the other side.And that does a disservice to those people who are actively working in that space to make things better. Because the good stuff that they do never gets attention, but then the company makes an interesting blunder in some way or another and suddenly, everyone's out there screaming and wondering why these people aren't responding on Twitter in 20 seconds when they're finding out about this stuff for the first time.Richard: Mm-hm. Yeah, that's fair. You know, different internal, external expectations of even DevRel. We've recently launched—I don't know if you caught it—something called Jump Start Solutions, which were executable reference architectures. You can come into the Google Cloud Console or hit one of our pages and go, “Hey, I want to do a multi-tier web app.” “Hey, I want to do a data processing pipeline.” Like, use cases.One click, we blow out the entire thing in the platform, use it, mess around with it, turn it off with one click. Most of those are built by DevRel. Like, my engineers have gone and built that. Tons of work behind the scenes. Really, like, production-grade quality type architectures, really, really great work. There's going to be—there's a dozen of these. We'll GA them at Next—but really, really cool work. That's DevRel. Now, that's behind-the-scenes work, but as engineering work.That can be some of the thankless work of setting up projects, deployment architectures, Terraform, all of them also dropped into GitHub, ton of work documenting those. But yeah, that looks like behind-the-scenes work. But that's what—I mean, most of DevRel is engineers. These are folks often just building the things that then devs can use to learn the platforms. Is it the flashy work? No. Is it the most important work? Probably.Corey: I do have a question I'd be remiss not to ask. Since the last time we spoke, relatively recently from this recording, Google—well, I'd say ‘Google announced,' but they kind of didn't—Squarespace announced that they'd be taking over Google domains. And there was a lot of silence, which I interpret, to be clear, as people at Google being caught by surprise, by large companies, communication is challenging. And that's fine, but I don't think it was anything necessarily nefarious.And then it came out further in time with an FAQ that Google published on their site, that Google Cloud domains was a part of this as well. And that took a lot of people aback, in the sense—not that it's hard to migrate a domain from one provider to another, but it brought up the old question of, if you're building something in cloud, how do you pick what to trust? And I want to be clear before you answer that, I know you work there. I know that there are constraints on what you can or cannot say.And for people who are wondering why I'm not hitting you harder on this, I want to be very explicit, I can ask you a whole bunch of questions that I already know the answer to, and that answer is that you can't comment. That's not constructive or creative. So, I don't want people to think that I'm not intentionally asking the hard questions, but I also know that I'm not going to get an answer and all I'll do is make you uncomfortable. But I think it's fair to ask, how do you evaluate what services or providers or other resources you're using when you're building in cloud that are going to be around, that you can trust building on top of?Richard: It's a fair question. Not everyone's on… let's update our software on a weekly basis and I can just swap things in left. You know, there's a reason that even Red Hat is so popular with Linux because as a government employee, I can use that Linux and know it's backwards compatible for 15 years. And they sell that. Like, that's the value, that this thing works forever.And Microsoft does the same with a lot of their server products. Like, you know, for better or for worse, [laugh] they will always kind of work with a component you wrote 15 years ago in SharePoint and somehow it runs today. I don't even know how that's possible. Love it. That's impressive.Now, there's a cost to that. There's a giant tax in the vendor space to make that work. But yeah, there's certain times where even with us, look, we are trying to get better and better at things like comms. And last year we announced—I checked them recently—you know, we have 185 Cloud products in our enterprise APIs. Meaning they have a very, very tight way we would deprecate with very, very long notice, they've got certain expectations on guarantees of how long you can use them, quality of service, all the SLAs.And so, for me, like, I would bank on, first off, for every cloud provider, whether they're anchor services. Build on those right? You know, S3 is not going anywhere from Amazon. Rock solid service. BigQuery Goodness gracious, it's the center of Google Cloud.And you look at a lot of services: what can you bet on that are the anchors? And then you can take bets on things that sit around it. There's times to be edgy and say, “Hey, I'll use Service Weaver,” which we open-sourced earlier this year. It's kind of a cool framework for building apps and we'll deconstruct it into microservices at deploy time. That's cool.Would I literally build my whole business on it? No, I don't think so. It's early stuff. Now, would I maybe use it also with some really boring VMs and boring API Gateway and boring storage? Totally. Those are going to be around forever.I think for me, personally, I try to think of how do I isolate things that have some variability to them. Now, to your point, sometimes you don't know there's variability. You would have just thought that service might be around forever. So, how are you supposed to know that that thing could go away at some point? And that's totally fair. I get that.Which is why we have to keep being better at comms, making sure more things are in our enterprise APIs, which is almost everything. So, you have some assurances, when I build this thing, I've got a multi-year runway if anything ever changes. Nothing's going to stay the same forever, but nothing should change tomorrow on a dime. We need more trust than that.Corey: Absolutely. And I agree. And the problem, too, is hidden dependencies. Let's say what is something very simple. I want to log in to [unintelligible 00:25:34] brand new AWS account and spin of a single EC2 instance. The end. Well, I can trust that EC2 is going to be there. Great. That's not one service you need to go through that critical path. It is a bare minimum six, possibly as many as twelve, depending upon what it is exactly you're doing.And it's the, you find out after the fact that oh, there was that hidden dependency in there that I wasn't fully aware of. That is a tricky and delicate balance to strike. And, again, no one is going to ever congratulate you—at all—on the decision to maintain a service that is internally painful and engineering-ly expensive to keep going, but as soon as you kill something, even it's for this thing doesn't have any customers, the narrative becomes, “They're screwing over their customers.” It's—they just said that it didn't have any. What's the concern here?It's a messaging problem; it is a reputation problem. Conversely, everyone knows that Amazon does not kill AWS services. Full stop. Yeah, that turns out everyone's wrong. By my count, they've killed ten, full-on AWS services and counting at the moment. But that is not the reputation that they have.Conversely, I think that the reputation that Google is going to kill everything that it touches is probably not accurate, though I don't know that I'd want to have them over to babysit either. So, I don't know. But it is something that it feels like you're swimming uphill on in many respects, just due to not even deprecation decisions, historically, so much as poor communication around them.Richard: Mm-hm. I mean, communication can always get better, you know. And that's, it's not our customers' problem to make sure that they can track every weird thing we feel like doing. It's not their challenge. If our business model changes or our strategy changes, that's not technically the customer's problem. So, it's always our job to make this as easy as possible. Anytime we don't, we have made a mistake.So, you know, even DevRel, hey, look, it puts teams in a tough spot. We want our customers to trust us. We have to earn that; you will never just give it to us. At the same time, as you say, “Hey, we're profitable. It's great. We're growing like weeds,” it's amazing to see how many people are using this platform. I mean, even services, you don't talk about having—I mean, doing really, really well. But I got to earn that. And you got to earn, more importantly, the scale. I don't want you to just kick the tires on Google Cloud; I want you to bet on it. But we're only going to earn that with really good support, really good price, stability, really good feeling like these services are rock solid. Have we totally earned that? We're getting there, but not as mature as we'd like to get yet, but I like where we're going.Corey: I agree. And reputations are tricky. I mean, recently InfluxDB deprecated two regions and wound up turning them off and deleting data. And they wound up getting massive blowback for this, which, to their credit, their co-founder and CTO, Paul Dix—who has been on the show before—wound up talking about and saying, “Yeah, that was us. We're taking ownership of this.”But the public announcement said that they had—that data in AWS was not recoverable and they're reaching out to see if the data in GCP was still available. At which point, I took the wrong impression from this. Like, whoa, whoa, whoa. Hang on. Hold the phone here. Does that mean that data that I delete from a Google Cloud account isn't really deleted?Because I have a whole bunch of regulators that would like a word if so. And Paul jumped onto that with, “No, no, no, no, no. I want to be clear, we have a backup system internally that we were using that has that set up. And we deleted the backups on the AWS side; we don't believe we did on the Google Cloud side. It's purely us, not a cloud provider problem.” It's like, “Okay, first, sorry for causing a fire drill.” Secondly, “Okay, that's great.” But the reason I jumped in that direction was just because it becomes so easy when a narrative gets out there to believe the worst about companies that you don't even realize you're doing it.Richard: No, I understand. It's reflexive. And I get it. And look, B2B is not B2C, you know? In B2B, it's not, “Build it and they will come.” I think we have the best cloud infrastructure, the best security posture, and the most sophisticated managed services. I believe that I use all the clouds. I think that's true. But it doesn't matter unless you also do the things around it, around support, security, you know, usability, trust, you have to go sell these things and bring them to people. You can't just sit back and say, “It's amazing. Everyone's going to use it.” You've got to earn that. And so, that's something that we're still on the journey of, but our foundation is terrific. We just got to do a better job on some of these intangibles around it.Corey: I agree with you, when you s—I think there's a spirited debate you could have on any of those things you said that you believe that Google Cloud is the best at, with the exception of security, where I think that is unquestionably. I think that is a lot less variable than the others. The others are more or less, “Who has the best cloud infrastructure?” Well, depends on who had what for breakfast today. But the simplicity and the approach you take to security is head and shoulders above the competition.And I want to make sure I give credit where due: it is because of that simplicity and default posturing that customers wind up better for it as a result. Otherwise, you wind up in this hell of, “You must have at least this much security training to responsibly secure your environment.” And that is never going to happen. People read far less than we wish they would. I want to make very clear that Google deserves the credit for that security posture.Richard: Yeah, and the other thing, look, I'll say that, from my observation, where we do something that feels a little special and different is we do think in platforms, we think in both how we build and how we operate and how the console is built by a platform team, you—singularly. How—[is 00:30:51] we're doing Duet AI that we've pre-announced at I/O and are shipping. That is a full platform experience covering a dozen services. That is really hard to do if you have a lot of isolation. So, we've done a really cool job thinking in platforms and giving that simplicity at that platform level. Hard to do, but again, we have to bring people to it. You're not going to discover it by accident.Corey: Richard, I will let you get back to your tear-filled late-night writing of tomorrow's Next keynote, but if people want to learn more—once the dust settles—where's the best place for them to find you?Richard: Yeah, hopefully, they continue to hang out at cloud.google.com and using all the free stuff, which is great. You can always find me at seroter.com. I read a bunch every day and then I've read a blog post every day about what I read, so if you ever want to tune in on that, just see what wacky things I'm checking out in tech, that is good. And I still hang out on different social networks, Twitter at @rseroter and LinkedIn and things like that. But yeah, join in and yell at me about anything I said.Corey: I did not realize you had a daily reading list of what you put up there. That is news to me and I will definitely track in, and then of course, yell at you from the cheap seats when I disagree with anything that you've chosen to include. Thank you so much for taking the time to speak with me and suffer the uncomfortable questions.Richard: Hey, I love it. If people aren't talking about us, then we don't matter, so I would much rather we'd be yelling about us than the opposite there.Corey: [laugh]. As always, it's been a pleasure. Richard Seroter, Director of Product Management and Developer Relations at Google Cloud. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry comment that you had an AI system write for you because you never learned how to structure a sentence.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

Google Cloud's DevOps Research and Assessment (DORA) team operationalize the Accelerate State of DevOps Report, surveying over 32,000 professionals worldwide in the DevOps industry.  Dave Mangot joins the show today to share how he leverages these metrics to improve companies within their technology organizations.   In this episode… DORA metrics Speed and quality  Monoliths vs. microservices Uptime and failure rates Mean time to recover  Deployment frequencies Production monitoring Sponsors Top End Devs Coaching | Top End Devs Links Mangoteque - Get good at delivering software℠ The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations DevOps Solutions | Google Cloud Picks Dave- An incomplete list of skills senior engineers need, beyond coding Jillian- Twitter: @PayGapApp Jonathan - Toothpowder is better than toothpaste

Google Cloud's DevOps Research and Assessment (DORA) team operationalize the Accelerate State of DevOps Report, surveying over 32,000 professionals worldwide in the DevOps industry.  Dave Mangot joins the show today to share how he leverages these metrics to improve companies within their technology organizations.   In this episode… DORA metrics Speed and quality  Monoliths vs. microservices Uptime and failure rates Mean time to recover  Deployment frequencies Production monitoring Sponsors Top End Devs Coaching | Top End Devs Links Mangoteque - Get good at delivering software℠ The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations DevOps Solutions | Google Cloud Picks Dave- An incomplete list of skills senior engineers need, beyond coding Jillian- Twitter: @PayGapApp Jonathan - Toothpowder is better than toothpaste

Rick Stewart, Chief Software Technologist at DLT Solutions joins Tech Transforms to give insight on Open Source, Platform One, and DORA initiatives. Listen in as Carolyn and Mark learn about the importance of focusing on the right metrics when managing security bottlenecks. Episode Table of Contents[00:48] Old Ways of Doing Things [11:55] Security Metrics That Need Improvement [22:54] Deploying Security Metrics Using Scheduling Techniques [33:19] Continuous Authority to Operate Security Metrics Episode Links and Resourceshttps://www.linkedin.com/in/rick-stewart-09618015/ (Rick Stewart ) https://www.dlt.com/ (DLT Solutions) https://www.amazon.com/Beyond-Order-More-Rules-Life/dp/0593084640/ref=asc_df_0593084640/?tag=hyprod-20&linkCode=df0&hvadid=509494905560&hvpos=&hvnetw=g&hvrand=15582897620124099519&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9030451&hvtargid=pla-1065603015754&psc=1 (Beyond Order) Old Ways of Doing ThingsCarolyn: Today, we get to talk to https://www.linkedin.com/in/rick-stewart-09618015/ (Rick Stewart), a good friend. Rick Stewart is a Chief Software Technologist at DLT for more than 34 years. Do you really want me to tell people that Rick? That makes you sound super old? Rick: No, it has some relation to the old way of doing things, traditional ways. Carolyn: He knows the old stuff and the new stuff with 34 years of diverse experience in the IT industry. He's progressing through technical and leadership roles in telecommunications, mobile entertainment, the federal government, and the manufacturing industries. Today, Rick is joining us to talk about DevOps research and assessments, or DORA, a term that is new to me. He'll also talk about the four key metrics for increasing efficiency and delivering service. He will discuss how Platform One has advanced the cultural transformation to DevOps. Mark: Welcome Rick. By the way, Rick started this when he was six. Carolyn: That's right. I'm going, to be honest. I've been in the industry for a while, and I have never heard the term DORA. DevOps Research and Assessments make sense. I just haven't heard the acronym. They have four key metrics for increasing efficiency in delivering service. Those metrics are deployment frequency, lead time for changes, change failure rate, and time to restore to service. Will you unpack those for us? Rick: It's interesting that you say that because I attend several different events and conferences where we have, especially in the public sector, astute people that have lots of experience. Security Metrics As a First-Class CitizenRick: They're on this journey of DevOps or in the public sector. It's more DevSecOps, bringing security up as a first-class citizen. They were talking about the things that they capture, the journey that they're on, and their improvements. On one of these occasions, DORA was brought up. I think it may be a Q&A panel. It was surprising that a lot of them didn't know what this organization does, especially being so well versed in the cultural transformation, not knowing some of the things to focus on. I thought it was really important to shine a light on. Carolyn: Is it a federal organization? Rick: No, it's more of a community-based organization, an industry-based organization. We've got people like Jez Humble and Gene Kim and others that are involved with this. What they do is, they go out and they do surveys of not just the public sector, but the private sector, all organizations globally. They basically give them surveys and they talk about their experience, where they're at in the spectrum of their journey, and what they have discovered through this analysis. It's a really deep, long analysis. There's a book called Accelerate that was done by Nicole Ferguson. She has a PhD and took lots of painstaking analysis of these organizations and these teams and asked them a series of questions. What it boiled down to is

In part two of this two-part episode on The DevOpsHandbook, Second Edition, Gene Kim speaks with coauthors Dr. Nicole Forsgren and Jez Humble about the past and current state of DevOps. Forsgren and Humble share with Kim their DevOps aha moments and what has been the most interesting thing they've learned since the book was released in 2016. Jez discusses the architectural properties of the programming language PHP and what it has in common with ASP.NET. He also talks about the anguish he felt when Mike Nygard's book, Release It!, was published while he was working on his book, Continuous Delivery. Forsgren talks about how it feels to see the findings from the State of DevOps research so widely used and cited within the technology community. She explains the importance of finding the link between technology performance and organizational performance as well as what she's learned about the importance of culture and how it can make or break an organization. Humble, Forsgren, and Kim each share their favorite case studies in The DevOps Handbook.   ABOUT THE GUEST(S) Dr. Nicole Forsgren and Jez Humble are two of five coauthors of The DevOps Handbook along with Gene Kim, Patrick Debois and John Willis. Forsgren, PhD, is a Partner at Microsoft Research. She is coauthor of the Shingo Publication Award-winning book Accelerate: The Science of Lean Software and The DevOps Handbook, 2nd Ed., and is best known as lead investigator on the largest DevOps studies to date. She has been a successful entrepreneur (with an exit to Google), professor, performance engineer, and sysadmin. Her work has been published in several peer-reviewed journals. Humble is co-author of Lean Enterprise, the Jolt Award-winning Continuous Delivery, and The DevOps Handbook. He has spent his career tinkering with code, infrastructure, and product development in companies of varying sizes across three continents, most recently working for the US Federal Government at 18F. As well as serving as DORA's CTO, Jez teaches at UC Berkeley.   YOU'LL LEARN ABOUT Projects Jez and Gene worked on together before The DevOps Handbook came out. What life is like for Jez as a site reliability engineer at Google and what he's learned. The story behind his DevOps aha moment in 2004, working on a large software project involving 70 developers. The architectural properties of his favorite programming language PHP, what it has in common with ASP.NET, and the importance of being able to get fast feedback while building something. The anguish that Jez felt when Mike Nygard's book, Release It!, came out, wondering if there was still a need for the book he was working on, which was Continuous Delivery. “Testing on the Toilet” and other structures for creating distributed learning across an organization and why this is important to create a genuine learning dynamic. What Dr. Forsgren is working on now as Partner of Microsoft Research. Some of Dr. Forsgren's goals as we work together on the State of DevOps research and how it feel to have those findings so widely used and cited within the technology community. The importance of finding the link between technology performance and organizational performance and why it probably was so elusive for at least 40 years in the research community. What Dr. Forsgren has learned about the importance of culture, how it can make or break an organization, and the importance of great leadership.   RESOURCES Personal DevOps Aha Moments, the Rise of Infrastructure, and the DevOps Enterprise Scenius: Interviews with The DevOps Handbook Coauthors (Part 1 of 2: Patrick Debois and John Willis) The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations, Second Edition, by Gene Kim, Patrick Debois, John Willis, Jez Humble, and Dr. Nicole Forsgren Nudge: Improving Decisions About Health, Wealth, and Happiness by Richard H. Thaler and Cass R. Sunstein Nudge vs Shove: A Conversation With Richard Thaler The Visible Ops Handbook: Implementing ITIL in 4 Practical and Auditable Steps by Kevin Behr, Gene Kim and George Spafford FlowCon Elisabeth Hendrickson on the Idealcast: Part 1, Part 2 Cloud Run Beyond Goldilocks Reliability by Narayan Desai, Google Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by Jez Humble and David Farley Release It!: Design and Deploy Production-Ready Software (Pragmatic Programmers) by Michael T. Nygard DevOps Days On the Care and Feeding of Feedback Cycles by Elisabeth Hendrickson at FlowCon San Francisco 2013 Bret Victor Inventing on Principle by Bret Victor Media for Thinking the Unthinkable Douglas Engelbart and The Mother of All Demos 18F Pain Is Over, If You Want It at DevOps Enterprise Summit - San Francisco 2015 Goto Fail, Heartbleed, and Unit Testing Culture by Mike Bland Do Developers Discover New Tools On The Toilet? by Emerson Murphy-Hill, Edward Smith, Caitlin Sadowski, Ciera Jaspan, Collin Winter, Matthew Jorde, Andrea Knight, Andrew Trenk and Steve Gross PDF Study: DevOps Can Create Competitive Advantage DevOps Means Business by Nicole Forsgren Velasquez, Jez Humble, Nigel Kersten and Gene Kim Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by Nicole Forsgren, PhD, Jez Humble, and Gene Kim DevOps Research and Assessment (DORA) on Google Cloud GitLab Inc. takes The DevOps Platform public Paul Strassmann The Idealcast with Dr. Ron Westrum: Part 1, Part 2 Building the Circle of Faith: How Corporate Culture Builds Trust at Trajectory Conference 2021 The Truth About Burnout: How Organizations Cause Personal Stress and What to Do About It by Christina Maslach and Michael P. Leiter Maslach Burnout Inventory Understanding Job Burnout at DevOps Enterprise Summit - Las Vegas 2018 Understanding Job Burnout at DevOps Enterprise Summit - London 2019 Workplace Engagement Panel at DevOps Enterprise Summit - Las Vegas 2019 Expert Panel - Workplace Engagement & Countering Employee Burnout at DevOps Enterprise Summit - London 2019 The Idealcast with Trent Green Kelly Shortridge's tweets about Gitlab S-1   TIMESTAMPS [05:22] Intro [05:34] Meet Jez Humble [10:19] What Jez is working on these days [15:56] What inform his book, “Continuous Delivery” [24:02] Assembling the team for the project [26:30] At what point was PHP an important property [31:56] The most surprising thing since the DevOps Handbook came out [35:07] His favorite pattern that went into the DevOps Handbook [43:40] What DevOps worked on in 2021 [44:46] Meet Dr. Nicole Forsgren [50:32] What Dr. Forsgren is working on these days [52:18] What it's like working at Microsoft Research [55:58] The response to the state of DevOps findings [59:18] The most surprising finding since the findings release [1:05:59] Her favorite pattern that influence performance [1:08:49] How Dr. Forsgren met Dr. Ron Westrum [1:11:06] The most important thing she's learned in this journey [1:14:46] Her favorite case study in the DevOps Handbook [1:19:12] Dr. Christina Maslach and work burnout [1:20:46] More context about the case studies [1:25:32] The Navy case study [1:29:04] Outro

Speakers: Dina Graves Portman and Henrik Rexed Through six years of research, the DevOps Research and Assessment (DORA) team has identified four key metrics that indicate the performance of a software development team: Deployment Frequency—How often an organization successfully releases to productionLead Time for Changes—The amount of time it takes a commit to get into productionChange Failure Rate—The percentage of deployments causing a failure in productionTime to Restore Service—How long it takes an organization to recover from a failure in productionSupport the show (https://cd.foundation/podcast/podcast-submission-form/)

On The Cloud Pod this week, the whole team definitely isn't completely exhausted. Meanwhile, Amazon releases MSK Connect, Google offers the Google Cloud Digital Leader certification, and DORA's 2021 State of DevOps report has arrived.  A big thanks to this week's sponsors: Foghorn Consulting, which provides full-stack cloud solutions with a focus on strategy, planning and execution for enterprises seeking to take advantage of the transformative capabilities of AWS, Google Cloud and Azure. JumpCloud, which offers a complete platform for identity, access, and device management — no matter where your users and devices are located.  This week's highlights

Who is Jez Humble? Jez works in Site Reliability Engineering at Google and teaches at UC Berkeley. He previously co-founded the amazingly influential DevOps Research and Assessment, DORA. And co-conducted the annual State of DevOps Report. Before that was stints at 18F, the legendary Obama-era federal agency that modernized several digital services and thought works. Get ready to meet Jez!

About NathenNathen Harvey, Cloud Developer Advocate at Google, helps the community understand and apply DevOps and SRE practices in the cloud.  Nathen formerly led the Chef community, co-hosted the Food Fight Show, and managed operations and infrastructure for a diverse range of web applications. Links: cloud.google.com/devops: https://cloud.google.com/devops 97 Things every Cloud Engineer Should Know: https://shop.aer.io/oreilly/p/97-things-every/9781492076735-9149 Twitter: https://twitter.com/nathenharvey TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, 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 Thinkst. This is going to take a minute to explain, so bear with me. I linked against an early version of their tool, canarytokens.org in the very early days of my newsletter, and what it does is relatively simple and straightforward. It winds up embedding credentials, files, that sort of thing in various parts of your environment, wherever you want to; it gives you fake AWS API credentials, for example. And the only thing that these things do is alert you whenever someone attempts to use those things. It’s an awesome approach. I’ve used something similar for years. Check them out. But wait, there’s more. They also have an enterprise option that you should be very much aware of canary.tools. You can take a look at this, but what it does is it provides an enterprise approach to drive these things throughout your entire environment. You can get a physical device that hangs out on your network and impersonates whatever you want to. When it gets Nmap scanned, or someone attempts to log into it, or access files on it, you get instant alerts. It’s awesome. If you don’t do something like this, you’re likely to find out that you’ve gotten breached, the hard way. Take a look at this. It’s one of those few things that I look at and say, “Wow, that is an amazing idea. I love it.” That’s canarytokens.org and canary.tools. The first one is free. The second one is enterprise-y. Take a look. I’m a big fan of this. More from them in the coming weeks.Corey: This episode is sponsored in part by our friends at Lumigo. If you've built anything from serverless, you know that if there's one thing that can be said universally about these applications, it's that it turns every outage into a murder mystery. Lumigo helps make sense of all of the various functions that wind up tying together to build applications.It offers one-click distributed tracing so you can effortlessly find and fix issues in your serverless and microservices environment. You've created more problems for yourself. Make one of them go away. To learn more, visit lumigo.io.Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. I’m joined this week by Nathen Harvey, a cloud developer advocate at a small startup called Google. Nathen, thank you for joining me.Nathen: Hey, Corey. It’s really great to be here.Corey: We’ll get to the Google bits in a little, but first, I want to start back in the beginning with your origin story. It turns out, for example, that you were at a lot of places, and the first thing going through your history that I really recognized was way back at the end of 2009, where you were the web operations manager at Custom Ink. They’re a t-shirt company—and other apparel—that I’ve been using for three years now for the charity t-shirt drive here, as well as other sundry things. Longtime listeners of the show might remember we had Ken Collins on to talk about Ruby in Lambda and other horrifying things, before it was cool.Nathen: Yes, indeed, I was at Custom Ink. And, you know, you talk about them being a t-shirt company, and I don’t know… maybe I’m still a shill for Custom Ink, but I really look at them as an experience company. And you’ve recognized that yourself. They produce and help people, really encourage that group and experiences, and really drive what does it mean to connect with other humans, and how can you do that through custom apparel? To me, that’s what Custom Ink has always been about. They’re not selling t-shirts; they are selling an experience.Corey: In my case, I view them as a t-shirt company because, let’s be fair here, I wind up doing charity t-shirt drives, and they’ve always been extremely supportive of—well, there’s really no other way to put this—my ridiculous nonsense. The year I had linked campaigns of the ‘AMI has three syllables’ shirt that was on sale, and then for the Amazonians, ‘ah-mi’ is how it’s pronounced instead and that one was $10 more because there’s a price to being wrong. And all proceeds, of course, went to benefit the charity of the year. And that was a fun thing. And I talked to a number of other folks on this, and they look at me very strangely, and Custom Ink didn’t even blink.Nathen: Right, right. Absolutely. Absolutely.Corey: And yes, they said lots of other apparel, but for whatever reason, it seems that sending out complicated multiple options of things that need each hit minimum order quantities to print during a fundraiser, and the fact that I don’t have to deal with the money because they just wind up sending it over directly. It’s just easier. It’s one of those things where back when I was a single person who was doing this stuff, I didn’t have to worry about it. Now that I’ve grown and my needs have multiplied, I still like doing business with them. Great folks.Nathen: Absolutely. And that’s exactly what I mean by—like, they’ve sold you on that experience. That’s why you continue to do business with them. It’s not just because of the t-shirts. It’s the whole package that goes along with it.Corey: And then in 2012, the world didn’t end. But yours kind of did because you stopped working at Custom Ink and went to another company called Chef. You were there for a little over six years. You started off as a community director and then became the VP of Community Development. And I think you did an amazing job, but first tell me about that, then I will give my hot take.Nathen: All right, great. I’m always up for the hot takes. So listen, Chef was an amazing community of people. Oh, it was also a company. And so I really fell in love with—while I was at Custom Ink, actually, we were using Chef, and I fell in love with the community.And I was doing a lot of community support, running my own podcast, or participating with some co-hosts on a podcast called the Food Fight Show back in the day—it was all about Chef—running meetups and so forth. And at one point I decided, you know, what I should do maybe is stop being on call and start supporting this community full time. And that’s exactly what I did. I went to Chef and yes, as you mentioned, spent just over six years there, or just about six years there, and it was really, really an incredible time. Lots of hugs to be given, and just a great community in the DevOps space.Corey: I took a somewhat, I guess, agreeing or disagreeing position. I was on the Puppet side of the configuration management debate, and it was challenging. And then, ah, I was one of the very early developers behind SaltStack because clearly, the problem with all of these things was that no one had written it correctly, and we were going to fix that. And it turns out no, no, the problem was customers the whole time. But that’s a separate debate.So, I was never in the Chef ecosystem. That was the one system I never really touched in anger. And it’s easy to turn this into a, “Oh, you folks were the competition,” despite the fact I’ve never actually worked directly for either of those companies. But it was never like that because our real enemies were people configuring things by hand, for one because that’s unnecessary toil; don’t do it, and it was also just such an uplifting sense of community. Some of the best people I knew were in the Chef ecosystem, in the Chef orbit.For a while, they’re, on some level—and this is something I’d love to get your thoughts on—it seems that a failure mode that Chef exhibited was hiring directly from its community, where if someone was a big fan of Chef, start a stopwatch, they’re going to be working there before the month is out.Nathen: I think that Chef, the company definitely pulled a lot of community members into the organization. And frankly, when the company started, that was really, really great because it was an early startup. And as the company grew, it was still wonderful, of course, to pull in people from the community to really help drive the future direction, how our customers are using it. But like you said, there is a little bit of a challenge or concern when you start pulling too many of your most vocal supporters out of the community and putting them into the company, sometimes in places or roles where they didn’t have the opportunity to be as vocal, as big a champions for the product, for the services.Corey: I think at some level, it was—again, it helps to have people who are passionate about the product working there, but on the other, it felt like over time, it wound up weakening the community in some respects, just because everyone who worked there eventually found themselves in a scenario of well, I work here, it’s what we do, and now I have to say nice things. It winds up weakening the grassroot story.Nathen: Mmm. There’s definitely some truth to that, but I think there’s also some truths to just the evolution of community as you went from a community in the early days where there were a lot of contributors to over time—gratefully so—the community that—or sort of the proportion of the community that were consumers of Chef versus contributors to Chef, that balance changed. And so you had a lot more customers using the product. So, I don’t disagree with you, but I do think that it’s part of the natural evolution of community as well.Corey: And all things must end. And of course, Chef got acquired, I believe, after you left. So, I mean, at that point, you left, they were rudderless and what else were they to do? And you went to Google. And that is always an interesting story because Google’s community interaction before the time you wound up there, and after—I don’t know that you were necessarily the proximate cause, but I’m going to hang that around your neck because it’s all been a positive change since then—look radically different.Nathen: Yeah. Well, thank you. It is definitely not something that I should wear or carry alone, but going to Google was an interesting choice for me and I recognize that. And, you know, honestly, Corey, one of the things that drove me to Google was a good friend of mine, Seth Vargo. And just to kind of tie the complete throughline here, Seth and I worked together at Custom Ink, we’ve worked together at Chef, he left Chef and went to Hashi, and then went to Google. And the day after I knew that he was going to Google, I called him up and I said, “Seth, come on. Google’s so big. Why? Why? And how? I don’t understand. I don’t understand the move.”Corey: I asked him many of the same questions back in episode three of this show. He was a very early guest when I was scared speechless having conversations. It’s improved since then, a couple hundred in. But yeah, very friendly; very open; very warm.Nathen: Yeah. And, you know—Corey: “Why are you at Google?” was sort of the next follow-on question there in that era.Nathen: [laugh]. Yes, indeed. And I do think that Google, and specifically Google Cloud, has really taken to heart this idea that there’s a lot that we can learn from each other. And I don’t mean from each other within Google. Although, of course, we can learn a lot from each other.But we can also learn a lot from our community, from our customer base. How are they using Google Cloud? How are they using technology to drive their business forward? These are all things that we can learn. It turns out, not every company has Google, and that’s a good thing.Not every company should be Google or Google-sized, and certainly don’t have Google customers. And I think that it’s really important that we recognize that when we work with a customer, they’re the experts in their customers, and in their systems, and so forth.Corey: A lot has changed with Google’s approach to, well, basically everything. It turns out that when you’re a company that is, what, 26 years old now—27, something like that—starting with humble beginnings and then becoming a trillion-dollar entity, things change. Culture change, your community changes, what you do changes, and that becomes something that I think is not necessarily fully appreciated or fully understood in some corners. But then 2018 hit. You went to Google; what did you do then?Because it is such a large company that it is very difficult to know what any individual is up to there, and the primary means that I engage in the DevRel community space—specifically via aggressively shitposting on Twitter—isn’t really your means of interacting with the community. So, from that particular point of view, it’s, “Oh, yeah, he went to Google, and no one ever heard from him again.” What is it you say it is you do there?Nathen: Yeah. So, for sure. What I do here as a cloud advocate, is I really focus in on kind of two areas, I would say: DevOps—and I recognize that is a terrible, terrible word because when I say it, we all think of different things, but I definitely focus on the DevOps—and then SRE practices as well, or Site Reliability Engineering. And specifically what I work on is how do we bring the principles and practices of DevOps, of SRE, into our customer base and into the community at large? How do we drive what is the state of the art?How do we approach these particular topics? And so that’s really what I’ve been focused on since joining Google. Well, frankly, I was focused on that while at Chef, as well, maybe without the SRE bend so much, but certainly at Google SRE comes in, but it’s always—for the past decade for me—been about DevOps and how do we use technology to align the humans and work towards the business outcomes that we’re driving for?Corey: And business outcomes become an interesting story in the world of cloud because it distills down, for a cloud service provider is, we would like people to use our cloud, more of it, in perpetuity. It is not a complicated business model—if I can be direct—because business models inherently are not. “Whatever it is your company does, we would like you to do it here.” And that turns into a bunch of differentiated services across the spectrum, in some cases hilariously so, when it turns into basically pick an English word, and there’s a 50/50 shot that’s part of a service name somewhere. But a lot of it distills down to baseline distinct primitives.You’re talking about the DevOps aspect of it, which is—we talk about, is it culture? Is it tools? No, it’s a means to sell conferences, and books, and things like that. But what is it in the context of a cloud service provider? Specifically, Google because let’s be clear here, DevOps apparently for other providers is Azure DevOps. That’s right. It’s a service name, and DevOps Guru on the AWS side because everything is terrible.Nathen: Absolutely. Look, I think that I used to snark that the only DevOps tool was the manager of DevOps. But the truth is that DevOps is… it is tooling, and it is culture, and to separate the two is really a fool’s errand. I think that your tooling amplifies your culture, your culture amplifies your tooling. Together, this is how we make progress.Now, when it comes to Google, what do we mean when we say DevOps? Well, one of the good things is, shortly after I joined Google Cloud, Google Cloud acquired DORA, the DevOps Research and Assessment Organization.Corey: Jez Humble, and Dr. Nicole Forsgren. And then, for all intents and purposes, they googled it. Relatively shortly thereafter, by which I mean, we never really heard from DORA again. In 2020, the “State of DevOps Report” didn’t exist, which was what they were famous for doing. And it was, “Oh, yep. That’s a Google acquisition all right.” Is that what happened? Did I miss some nuance there?Nathen: Yeah. Let’s talk about that. So first, you’re right, it was Dr. Nicole Forsgren, who founded DORA. So, when the acquisition happened, she came along to Google Cloud, Jez Humble came along through that acquisition as well. And frankly, what happened in 2020? Well, Corey, I don’t know if you noticed, but there was a lot happening in 2020, much of it not very good. I think when we look at the global scale, like, 2020 was not a great year for us—Corey: It was a rebuilding year.Nathen: Oh, all right, fair enough. Fair enough. [laugh]. A rebuilding year. But so here’s what happened with DORA, quite frankly. We—Google Cloud—continue to invest in that research program. And really, in a sense, 2020 was a rebuilding year, in that our focus was really about how do we help our customers and our community apply the lessons of DORA?And so one of the things that we’ve done is we’ve released much of the research under cloud.google.com/devops, including right there, a DevOps quick check where, as a team you can go in and, using the metrics and the research program from DORA, you can assess, are you a low, medium, high, or elite performer?And then beyond that assessment, actually use the research to help you identify which capabilities should my team invest in improving. So, those capabilities might be technical capabilities, things like continuous integration; it might be process or measurement capabilities, or in fact, cultural capabilities. So, all of these capabilities come together to help you improve your overall software delivery and operations performance. And so in 2020, the big thing that we did was release and continue to update this Quick Check, release the research, make it fully available. We’ve also spent some time internally on the program that, you know, is not super interesting to talk about on the podcast.But the other thing that we did in 2020 with the DORA research program was update the ROI research, the return on investment research. This is something that maybe your listeners don’t care about, but their managers might care about, their CIOs, CTOs, CFOs might care about. How do we get money back on this transformation thing? And the research paper really digs into exactly that. How do we measure that? What returns can we expect? And so forth. So, that was released in 2020.Corey: I have a whole bunch of angry thoughts about a lot of takes in that space, but this is neither the time nor the place for me to begin ranting incoherently for an hour and a half. But yeah, I get that it was a year that was off, and now you’re doing it again, apparently, in 2021. And the one thing I never really saw historically because I don’t know if I’m playing in the wrong environments, or I’m certainly not the target [laugh] audience now, if I ever really was, but most years, I missed the release of the survey of where people can go to fill in these questions. I would be interested to know where that is now. And then I would be interested to know, how have you been socializing in that in the past? In other words, where are you finding these people?Nathen: Yeah, for sure. So, the place you go to find the survey right now is cloud.google.com/devops, you’ll find a button on the page that says something like, “Take the survey,” or, “Take the 2021 survey.”And what we’ve done in the past, and really what DORA has done in the past is use a number of different ways to get out information about the survey, when the survey is open, and so forth. Primarily Twitter, but also we have partners, and DORA historically has used partners as well to help share that the survey itself is open. So, I would absolutely recommend that you go and check out the survey because I’ll tell you what, one of the things that’s really interesting, Corey, over the years, I’ve talked to a bunch of people that have taken the survey, and that have read the State of DevOps Report that comes out each year, and some of the consistent feedback I’ve heard from folks is that simply taking the survey and considering the questions that are asked as part of the survey gives great insight immediately into how their team can improve. What things, what capabilities are they lacking? Or what capabilities are they doing really well with and they don’t need to make investments on? They can immediately see that just by answering and carefully considering the questions that are part of the survey.Corey: This episode is sponsored by ExtraHop. ExtraHop provides threat detection and response for the Enterprise (not the starship). On-prem security doesn’t translate well to cloud or multi-cloud environments, and that’s not even counting IoT. ExtraHop automatically discovers everything inside the perimeter, including your cloud workloads and IoT devices, detects these threats up to 35 percent faster, and helps you act immediately. Ask for a free trial of detection and response for AWS today at extrahop.com/trial.Corey: Very often, in some cases looking at things like maturity models and the like, the actual report is less valuable than the exercise of filling it out and going through the process. I mean, compliance reports, audit framework, et cetera, often lead to the same outcomes. The question is, are you taking it seriously, or are you one of those folks who is filling out a survey because do this and you’ll be entered to win a $25 gift card somewhere? Probably Blockbuster because it no longer exists. I get those in my email constantly of, “Yeah, give half an hour of your time in return for some paltry chance to win something.”No, I have a job to do. And I worry if at that level of that approach, who are you actually getting that’s going to sit down and fill this thing out? That said, the State of DevOps Reports have been for a long time, sort of the gold standard in this space and I would encourage people listening to this to absolutely take the time to fill that out. cloud.google.com/devops.I’m looking forward to seeing what comes out of it. And I love it because of the casual shade you can use to throw at other companies, too. Like, “Are you an elite team?” With the implicit baked-in sentiment being, no, you’re not, but I want to hear you say it.Nathen: Yeah, one of the things that really sets DORA apart, also, I think, is just the—well, two of the things I guess I would say. One is the length of time that the research program has been running. It’s going on seven years now that this research program has been running, and so given that, you have tens of thousands of IT professionals that have taken the survey and provided insights into sort of what’s the state of our industry today, and where are we heading, but it’s also an academically rigorous survey. The survey and the research itself has always and continues to be completely platform and program agnostic. This is not a survey about Google Cloud.This is not a survey where we’re trying to help understand exactly what products on Google Cloud should you use in order to be an elite performer. No. That’s not what this is about. It is about, truly, capabilities that your team needs in order to improve their software delivery and operations performance. And I think that’s really, really important.Dr. Nicole Forsgren who founded DORA, she didn’t come up with all of these ideas: “Hey, I think that you get better by doing this.” No. Instead, she researched all of these ideas. She got this input from across organizations of all sizes, organizations in every industry, and that, I think, really sets it apart.And our ability to really stay committed to that academic rigor, and the platform-agnostic approach to capturing and investigating these capabilities, I think is so important to this research. And again, this is why you should participate in the survey because you truly are going to help us move the state of the art of our industry.Corey: No, historically, there’s been a challenge where the mantle of thought leadership in conjunction with Google have intersected because there’s a common trope—historical—and I think that it is no longer accurately true. It’s an easy cheap shot, but I don’t think it holds water like it once did. Where, “Oh, Googler. It’s another word for condescending.” And there is an element of “Oh, this is how DevOps should be; this is how we’re moving things forward.” How do you distance it from being Google says you should do it like this?Nathen: Yeah. This comes up a lot. And frankly, I get in conversations with customers asking, “How does Google do this? How does Google do that?” And my answer always is, “You know, I can tell you how Google does something, and that might be interesting, but the fact is, it’s not much more than that, much more than interesting. Because what really matters is how are you going to do this? How are you going to improve your outcomes, whether that’s you’re delivering faster, you’re delivering more reliable, you’re running more reliable services? You’re the experts. As I mentioned earlier, you’re the experts in your teams, in your technology, and your customers. So, I’m here to learn right along with you. How are you going to do this? How are you going to improve?” Knowing how Google does it, eh, it’s interesting, but it’s not the path that you will follow.Corey: I think that’s one of those statements that can’t ever be outright stated on a marketing website, somewhere; it’s one of those shifts that you have to live. And I think that Google’s done a pretty decent job of that. The condescending Googler jokes are dated at this point, and it’s not because there was ever an ad campaign about, we’re not condescending anymore. It was a very subtle shift in the way that Google spoke to its customers, spoke about themselves. I no longer feel the need to stand up in a blinding white rage in the Q&A portion of conference talks given by Google employees.A lot has changed, and it’s not one thing that I can point to, it’s a bunch of different things that all add up to dramatically shifted credibility models. Realistically, I feel like that is a microcosm of a DevOps transformation. It’s not a tool; it’s not a single person being hired; it’s not, we’re taking an agile class for three days for all of engineering, and now things will be better. It’s a whole bunch of sustained work with a whole bunch of thought, and effort put into making it an actual transformation, which is such a toxically overloaded term, I dare not use it.Nathen: Indeed. And there’s no maturity model that shows, are you there yet? And it is something that you don’t flip on or flip off like a switch, right? It doesn’t happen overnight. It takes iteration and iterative change across the entire organization.And just like every change that you have across an organization, there are places where it’s going better than other places. And how do you learn from that? I think that’s really, really important. And to recognize and to bring some of that humility to the table is so important.Corey: So, what’s interesting about folks that I talk to on this show—well, there are many interesting things, but one of the interesting things is, is that they have a higher rate than the general population of having at one point in their careers, written a book of some form, and you are, of course, no exception. You and Emily Freeman co-authored recently, a book entitled 97 Things every Cloud Engineer Should Know. And it’s interesting because it only has one nine in the title. Okay, that is at least an attempt at being available. I know it’s available wherever most books are sold. Tell me more.Nathen: Yeah, so first, let’s start with the 97. Why 97? Corey, I don’t know if this or not, but 100% is the wrong reliability target for just about everything. So, 97. That feels achievable.Corey: It also feels like three people said they would do it and then backed out at the last minute, but that’s my cynicism speaking.Nathen: Well, for better or worse, O’Reilly. Has a whole 97 Things series and this is part of it. So, it is, in fact, 97 things. The other thing that I think is really important about the book: you mentioned that Emily and I wrote it, and the beauty is, for a long time, I’ve wanted to have written a book, and I have never wanted to be writing a book.Corey: That is what every author has ever said. It’s, no one wants to write a book; they want to have written one. And then you get a couple of beers into people and ask them, “So, I’m debating writing a book. Should I?” The response is, “No. Absolutely not. No.” And at some point, when you calmed them down again, and they stop screaming, they tell you the horrifying stories, and you realize, “Oh, wow, I really never want to write a book.”Nathen: [laugh]. Yes. Well, the beauty of 97 Things and this book in particular, or the whole series, really, is its subtitle is Collective Wisdom from the Experts. So, in fact, we had over 80 different contributors sharing things that other cloud engineers should know. And I think this is also really, really important because having 80-plus contributors to this book gave us, not 97 things that Emily and Nathen think every cloud engineer should know, but instead, a wide variety of experience levels, a wide variety of perspectives, and so I think that is the thing that makes the book really powerful.It also means that those 80-some folks that contributed to the book, had to write a very short article. So, of course, with 80 authors and 97 Things, the book is not—it doesn’t weigh 27 pounds, right? It’s less than 300 pages long, where you get these 97 tidbits. But really, the hope and the intent behind the book is to give you an idea about what should you explore deeper and, just as importantly, who are some people that you can, maybe, reach out to and talk to about a particular topic, a particular thing that a cloud engineer should know. Here are 80 people that are here, helping you and really cheering you on as you take this journey into cloud engineering.Corey: I think there’s something to be said from having the stories for this is what we do, this is how we do it. But the lessons learned stories, those are the great ones, and it’s harder to get people on stage to talk about that without turning into, “And that’s how we snagged victory from the jaws of defeat.” No one ever gets on stage and says and that’s why the entire project was a boondoggle and four years later, we’re still struggling to recover. Especially, you know, publicly traded companies tend not to say those things. But it’s true.You wind up with people getting on stage and talking instead about these high-level amazing things that they’ve done in the project went flawlessly, and you turn to the person next to you and say, “Yeah, I wish I could work in a place like that.” And they say, “Yeah, me too.” And you check, and they work at the same place as the presenter. Because it’s conference-ware; it’s never a real story. I’m hoping that these stories go a bit more in-depth into the nitty-gritty of what worked, what didn’t work, and it’s not always ‘author as hero protagonist.’Nathen: Oh, you will definitely find that in this book. These are true stories. These are stories of pain, of heartache, of victory and success, and learnings along the way. Absolutely. And frankly, in the DevOps space, we do an okay job of talking openly about our failures.We often talk about things that we tried that went wrong, or epic failures in our systems, and then how we recovered from them. And yes, oftentimes, those stories have a great sort of storybook ending to them, but there’s a lot of truth in a lot of those stories as well because we all know that no organization is uniformly good at everything. That may be the stories that they want to share most, but, you know, there’s some truth in those stories that hopefully we can find. And certainly, in this book, you will find the good, the bad, the ugly, the learnings, and all of the lessons there.Corey: Where can people find it if they want to buy it?Nathen: Oh, you know, you can find it wherever you buy books. There are of course, ebooks, O’Reilly’s website, you know with the—Corey: Wherever fine books are pirated. Yes, yes.Nathen: That’s a good place to go for books, yeah. For sure.Corey: And we will, of course, throw a link to the book in the [show notes 00:29:12]. Thank you so much for taking the time to speak with me. If people want to learn more about the rest of what you’re up to, how you’re thinking about it, what wise wisdom you have for the rest of us, okay can they find you, other than the book?Nathen: Yeah, a great place to reach out to me is on Twitter. I am at @nathenharvey. But I should warn you, my father misspelled my name. So, it’s N-A-T-H-E-N-H-A-R-V-E-Y. So, you can find me on Twitter; reach out to me there.Corey: And we will of course include links to all of that in the [show notes 00:29:43] as well. Thank you so much for speaking to me today. I really appreciate it.Nathen: Thank you, Corey. It’s been a pleasure.Corey: Nathen Harvey, cloud developer advocate at Google. I’m Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you’ve enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you’ve hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry comment telling me that I’m completely wrong. You can instantly get DevOps in your environment if I only purchase whatever crap it is your company sells.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

Jonan Scheffler interviews Google Developer Advocate Amanda Lewis about DevOps Research, and Assessment (DORA), being hospitable to customers and finding creative ways to solve people's problems, and what exactly “a DevRel team does.” Should you find a burning need to share your thoughts or rants about the show, please spray them at devrel@newrelic.com. While you’re going to all the trouble of shipping us some bytes, please consider taking a moment to let us know what you’d like to hear on the show in the future. Despite the all-caps flaming you will receive in response, please know that we are sincerely interested in your feedback; we aim to appease. Follow us on the Twitters: @ObservyMcObserv.

Jez Humble is a developer advocate at Google and a lecturer at UC Berkeley, where he teaches classes on agile software development and product management. Jez brings more than 20 years of experience to these positions, including stints as vice president at Chef and deputy director of delivery architecture and infrastructure services for the federal government’s General Services Administration. Most recently, he founded DevOps Research and Assessment LLC (DORA), which was acquired by Google. Jez is also the other of several books, including the Jolt Award-winning Continuous Delivery. Join Corey and Jez as they talk about the differences between working for large organizations and nimble startups, the wonderful world of NIST, why Jez believes that Google acquired DORA, the five characteristics that mean you have a cloud according to the NIST, the difference between knowing what you should do vs. actually getting there, how to think about books written about technology, why Silicon Valley is one of the worst places in the world when it comes to the Dunning–Kruger effect, and more.

The Westrum model has been shown to predict software delivery performance. It also helps us get a quantifiable handle on the intangible concept of culture.  With concrete focus points, it is a fantastic way to start improving your culture. This episode covers the Westrum Model. Sources https://cloud.google.com/solutions/devops/devops-culture-westrum-organizational-culture https://inthecloud.withgoogle.com/state-of-devops-18/dl-cd.html https://qualitysafety.bmj.com/content/13/suppl_2/ii22 https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339   Transcript Culture - We know it is the foundation upon which we build high performing teams. Yet, it is a difficult topic to address. We struggle to quantify culture, and what does good culture mean? How can we approach improving our culture without resorting to jamborees and dancing around the bonfires? Team building can feel very disconnected from our everyday lives. The Westrum Typology of Organizational cultures is a model that helps us quantify our culture with focus on information flow in the organization. It has even been shown to drive software delivery performance. The Westrum model gives us an actionable approach to good culture. I'm Johan Abildskov, join me in the dojo to learn. In any conversation about transformations, whether digital, agile or DevOps, you can be certain that before much time has passed, someone clever will state “Culture eats strategy for breakfast”. This quote is from Peter Drucker and implies that no matter how much effort we put into getting the strategy perfect, execution will fail if we do not also improve the culture. Culture is to organizations what personality is to people. We can make all the new years resolutions, fancy diets and exercise plans, but if we do not change our habits, our patterns, or personality, even the best-laid plans will fail. While a human lapse in strategy might involve eating an extra cupcake and result in weight gain we had not planned for, an organizational lapse in culture might be accidentally scolding someone for bringing bad news to light, which results in an organization where problems and challenges are hidden. So it is important that we focus on establishing a healthy culture on top of which we can execute our clever strategies. Our culture is the behaviour that defines how we react as an organization.   Ron Westrum is an American sociologist, that has done research on the influence of culture to for instance patient outcomes in the health sector. He has built a model of organizational culture based on information flow through the organization. Being in the good end of this scale has been shown by the DevOps Research and Assessment team to be predictive of software delivery performance and organizational performance.   There are three categories of organizations in the Westrum model, Pathological or power oriented. Bureacratic or rule oriented and generative or performance oriented.    In pathological organizations, information is wielded as a weapon, used to fortify ones position, or withheld as leverage to be injected at the right moment to sabotage others, or cover ones own mistakes. Cooperation is discouraged as that can bring instability into the power balance, and the only accountability that is present is scapegoating and the blame game. Obviously this is a toxic environment, and the least performing organization type.   In the bureaucratic organizations the overarching theme is that it doesn't matter if we did something wrong or in a bad way, as long as we do it by the book. Responsibilities are accepted, but the priority is not sensemaking, the priority is that no one can claim we did something wrong. Bad news are typically ignored, by the logic that the process is right, and the process is working.    Generative organizations focus on outcome or performance. It doesn't matter who gets credit as long as the organization wins. Failures are treated as learning opportunities and might even be sought after in order to increase organizational learning. This increases transparency and allows local solutions to be exploited globally.   So from bad to good the three organizational types are Pathological, Bureaucratic and Generative.   So far I haven't said anything about the specific characteristics or properties of these types. Nor given you any hints as to how you can measure or improve your culture. The Westrum model is measured on six different properties. The way it is done is through ask the members on a scale from 1-7 how much the agree with each of the Westrum properties. We can average and use that to plot into the Westrum model. I have built a free tool you can use for this. You can find a link in the show notes at dojo.fm.  First, Westrum talks about cooperation on the team and across teams. We create cross-functional teams from each of the areas that take part in our software delivery, making sure that goals and incentives are aligned.    Second, we train the messengers that bring bad news. We should celebrate bad news, as they represent a huge learning opportunity, and takes a lot of vulnerability on behalf of the messenger. We can use techniques such as blameless post-mortems to create organizational learning from incidents.    Third, We share the risk across stakeholders, we also hold developers accountable for availability, and Ops for the speed with which features can be delivered. We set up the technological scaffolding that can enable this, such as providing development teams with metrics and insights from production environments.   Fourth, we encourage bridging. Or to use the original DevOps phrase, we break down silos. Common silos are business, Information Security, Quality Assurance, Development and Operations. Reach out beyond the boundaries and find shared goals and motivations. Figure out how you can make each other successful. The good news is that the most effective solution is to talk together. The bad news is that we as an industry tend to be very bad at sitting down and talking to each other. Management has a huge influence on this characteristic, as misaligned goals and incentives will destroy initiatives in this area.   Fifth is our ability to learn from failures. Modern distributed systems are typically so complex that it is unreasonable not to think of your services as always being degraded in some way or another. This is in stark contrast to the very risk-averse enterprise organization with zero tolerance for failures. When we learn from our failures, we might even inject them in our environments to maximize our learning. It doesn't matter how technologically savvy we are, if our competition is able to out-learn us.   Sixth and last is how we approach novelties when they are presented to us. If we are able to build a culture where employees are able to experiment, in a safe way, we will be able to innovate and improve continuously. This means that we have to challenge the misconception that developer efficiency comes from high utilization, and that we need to have a high level of control. If we can build autonomous teams that can experiment with their process, we will end up in a good place.   I have gotten real respect for the Westrum model as it takes something as intangible as culture and makes it concrete and measurable. If we measure this once in a while and address the categories where we are not doing so well, or where we are relapsing to unhealthy behaviour, we end up with something as rare as an actionable concrete strategy for improving our culture.  That is powerful.   So in summary, there are six categories of the Westrum model. High Cooperation, Training the messengers, sharing the risks, encouraging bridging, learning from failures and implementing novelty.  It can be easily measured, has been shown to drive software delivery performance, and has concrete focus areas that can guide you towards a better culture.    So what is holding you back?   This has been the DevOpsDojo on how to measure your culture with Westrum Typology of Organizational Culture. You can follow me on twitter @randomsort. If you have any questions, feedback or just want to reach out and suggest a topic, do not hesitate. You can find show notes with transcripts, links and more at dojo.fm. Support the show by leaving a review, sharing this episode with a friend or colleague or subscribing to the DevOpsDojo on your favourite podcast platform. Thank you for listening, keep learning.  

William Rowden is an executive coach and consultant here at Accenture | SolutionsIQ. His journey to leading transformation initiatives has piqued his curiosity in org development and adult developmental psychology. For the past few years he has been researching how these two inform each other – and how the focus of an organization’s leaders provides a good indicator for the success or failure of business agility transformation. He walks us through the different focuses that leaders – and indeed everyone – have: self-centric, group-centric, skill-centric and beyond. Drawing from the work of Robert Keegan, Chris Argyris, Bill Joiner, and more, Rowden provides useful information for agilists for dealing with leaders of many types – do they shoot the messenger or install feedback loops? Do they see agile as a process or a means to an end? Accenture | SolutionsIQ’s Bryan Stallings hosts. Listen to Rowden's previous episode: Adult Cognitive Development and the Agile Mindset References: - Bill Joiner and Stephen Josephs, Leadership Agility (2007) - Susanne R. Cook-Greuter, "Making the case for a developmental perspective," in Industrial and Commercial Training (2004) - The MAP Institute, "The Leadership Maturity Framework." - DevOps Research and Assessment, “DevOps Culture: Westrum Organizational Culture” - Robert Kegan and Lisa Laskow Lahey, An Everyone Culture: Becoming a Deliberately Developmental Organization (2016) - William R. Torbert and Steven S. Taylor, "Action Inquiry: Interweaving Multiple Qualities of Attention for Timely Action" The Agile Amped podcast is the shared voice of the Agile community, driven by compelling stories, passionate people, and innovative ideas. Together, we are advancing the impact of business agility.   Podcast library: www.agileamped.com   Connect with us on social media!  Instagram: https://www.instagram.com/agileamped/ LinkedIn: https://www.linkedin.com/company/solutionsiq/ Twitter: https://twitter.com/AgileAmped

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.

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.

Host Andre Pino returns to the DevOps Radio mic to talk to Dr. Nicole Forsgren, CEO and Chief Scientist at DevOps Research and Assessment (DORA), during DevOps World | Jenkins World. Nicole brings strong developer content and amazing energy to the latest episode as she shares key stats from the 2018 State of DevOps Report.

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.

with Nicole Forsgren (@nicolefv), Jez Humble (@jezhumble) and Sonal Chokshi (@smc90) From the old claim that "IT doesn't matter" and question of whether tech truly drives organizational performance, we've been consumed with figuring out how to measure -- and predict -- the output and outcomes, the performance and productivity of software. It's not useful to talk about what happens in one isolated team or successful company; we need to be able to make it happen at any company -- of any size, industry vertical, or architecture/tech stack. But can we break the false dichotomy of performance vs. speed; is it possible to have it all?  This episode of the a16z Podcast boldly goes where no man has gone before -- trying to answer those elusive questions -- by drawing on one of the largest, large-scale studies of software and organizational performance out there, as presented in the new book, Accelerate: The Science of Lean Software and DevOps -- Building and Scaling High Performing Technology Organizations by Nicole Forsgren, Jez Humble, and Gene Kim. Forsgren (co-founder and CEO at DevOps Research and Assessment - DORA; PhD in Management Information Systems; formerly at IBM) and Humble (co-founder and CTO at DORA; formerly at 18F; and co-author of The DevOps Handbook, Lean Enterprise, and Continuous Delivery) share the latest findings about what drives performance in companies of all kinds. But what is DevOps, really? And beyond the definitions and history, where does DevOps fit into the broader history and landscape of other tech movements (such as lean manufacturing, agile development, lean startups, microservices)? Finally, what kinds of companies are truly receptive to change, beyond so-called organizational "maturity" scores? And for pete's sake, can we figure out how to measure software productivity already?? All this and more in this episode!

Today, I am speaking with Nicole Forsgren. Nicole is an IT impacts expert who is best known for her work with tech professionals and as the lead investigator on the largest DevOps studies to date. She is a consultant, expert, and researcher in knowledge management, IT adoption and impacts, and DevOps. In a previous life, she was a professor, sysadmin, and hardware performance analyst. Nicole has been awarded public and private research grants (funders include NASA and the NSF), and her work has been featured in various media outlets, peer-reviewed journals, and conferences. She holds a PhD in management information systems and a master’s degree in accounting. Nicole is CEO and Chief Scientist at DevOps Research and Assessment (DORA).   Her first book, Accelerate: The Science of Lean Software and DevOps explores the topic of Building and Scaling High Performing Technology Organizations.   I had a great time chatting with Nicole and learning about, not only her Swedish ancestry, her favorite ice cream flavour and her love for working out - which might have something to do with the ice cream, but learning more about what makes a high performing team tick.   You will learn lots in this conversation, including: Why traditional performance measurement metrics such as utilisation and lines of code are flawed and what to use instead What characteristics differentiate high performing teams from low performing team and how to start embedding these characteristics into your organisation; and How to effectively drive culture change   This just scratches the surface of what we discussed so please sit back, walk, run or whatever it is you do when you listen to podcasts and enjoy my conversation with Nicole Forsgren.   Topics Discussed: What DevOps is and why it matters Waterfall and stage gate versus agile and DevOps Why speed is fundamental to success The research behind the book What differentiates high performers from low performers How to effectively measure performance Flaws in common measurement approaches Maturity models v capability models Change advisory boards How to do QA in a fast-moving team Breaking down silos The power of cross functional, self organised teams How to drive culture change Continuous delivery How to build a truly engaged organisation How to avoid burnout Simple things companies can do to transition   Show Notes: Get the Book: Pre-order on Amazon at: https://amzn.to/2wtaIW9 Web: Nicolefv.com Twitter: @nicolefv DORA: http://devops-research.com   The Business Case Alternative ebook: http://bit.ly/bizcaseebook/ Nudge (book): https://amzn.to/2Nh9ofX Thinking Fast and Slow (book): https://amzn.to/2LruWVI The Undoing Project: https://amzn.to/2BO8IO9   Join the conversation on Facebook: https://www.facebook.com/groups/futuresquared/ where you can discuss episodes, request guests, propose questions for forthcoming guests and access exclusive content and special offers! Listen on iTunes @ goo.gl/sMnEa0  Listen on Stitcher @ www.stitcher.com/podcast/future  Listen on Google Play @  bit.ly/FSGoog  ‍ If you've got any questions on this podcast feel free to send an email to steve@collectivecamp.us or tweet me on Twitter @steveglaveski or @future_squared  Follow me on Instagram: @thesteveglaveski Like us?  ‍ It'd make our day if you took 1 minute to show some love on iTunes, Stitcher or Soundcloud by subscribing, sharing and giving us a 5 star rating.  ‍ To sign up to our mailing list head to www.futuresquared.xyz  For more information on Collective Campus, our innovation hub, school and consultancy based in Australia and Singapore check out www.collectivecampus.io

DevOps is a hot topic, but is that heat driving adoption? Are organizations on the adoption path making headway in the cultural and technological changes necessary for DevOps success? A panel of DevOps experts discusses these and other issues in this freewheeling conversation. The Panelists Nicole Forsgen, Founder and CEO, DevOps Research and Assessment LLC, Beaverton, OR Leonid Igolnik, Product Development Executive, Startup Mentor and Advisor, Sand Hill Angels, San Francisco Bay Area. Alena Prokharchyk, Principal Software Engineer, Rancher Labs, Cupertino, CA Baruch Sadogursky, Developer Advocate, JFrog, Cupertino, CA Shay Shmeltzer, Director of Product Management, Oracle Cloud Development Tools, Redwood Shores, CA Kelly Shortridge, Product Manager at SecurityScorecard, NYC Coming Soon Combating Complexity An article in the September 2017 edition of the Atlantic warned of The Coming Software Apocalypse. Oracle's Chris Newcombe was interviewed for that article. In this podcast Chris joins Chris Richardson, Adam Bien, and Lucas Jellema to discuss heading off catastophic software failures. AI Beyond ChatbotsHow is Artificial Intelligence being applied to modern applications? What are the options and capabilities? What patterns are emerging in the application of AI? A panel of experts provides the answers to these and other questions.  

In this second episode of Season 4, I talk with Dr. Nicole Forsgren, the CEO and Chief Scientist at DevOps Research and Assessment. We chat about what DevOps is, the skills a DevOps career requires, and how anyone can get started in DevOps.

Dr. Nicole Forsgren, founder and CEO of DORA, DevOps Research and Analysis will be speaking at DOES London on June 5th and 6th to announce the findings of this years State of DevOps Survey. She will be joined by Jez Humble (her co-founder at DORA) and Nigel Kersten of Puppet. Dr. Forsgren gives us her take on why DOES is a special event for her and what we might see in this years survey analysis.

Is there a science to DevOps? Richard talks to Dr. Nicole Forsgren, who has a PhD in Information Management about her work with the DevOps Research and Assessment (DORA) organization. Nicole is one of the key people behind the State of DevOps report (published by Puppet). The conversation digs into some of the findings in that report, including the proof that stability and speed are not mutually exclusive - you can bring new features and products to market quickly while keeping your systems stable. Have a listen and a read!