Podcasts about devops report

This interview was recorded for GOTO State of the Art in October 2025.https://gotopia.techRead the full transcription of this interview here:https://gotopia.tech/articles/415Nathen Harvey - DORA Lead, Product Manager at Google Cloud & AuthorCharles Humble - Freelance Techie, Podcaster, Editor, Author & ConsultantRESOURCESNathenhttps://bsky.app/profile/nathenharvey.bsky.socialhttps://x.com/nathenharveyhttps://github.com/nathenharveyhttps://www.linkedin.com/in/nathenhttps://linktr.ee/nathenharveyhttp://nathenharvey.comCharleshttps://bsky.app/profile/charleshumble.bsky.socialhttps://linkedin.com/in/charleshumblehttps://mastodon.social/@charleshumblehttps://conissaunce.comLinkshttps://dora.devhttps://dora.dev/research/2025/dora-reporthttps://dora.dev/research/2024/dora-reporthttps://thenewstack.io/ebooks/kubernetes/kubernetes-at-the-edge-container-orchestration-at-scaleDESCRIPTIONCharles Humble speaks with Nathen Harvey, leader of Google's DORA research team, about the real impact of AI on software development.Drawing from surveys of nearly 5,000 practitioners, Nathen reveals a surprising finding: increased AI adoption initially correlates with decreased stability and throughput - the very metrics teams have optimized for decades. The conversation explores why this happens, what capabilities organizations need before scaling AI adoption, and how AI acts as an amplifier of existing systems rather than a silver bullet.Nathen introduces DORA's seven AI capabilities model and discusses critical issues around trust, documentation, skill devaluation, and the future of software delivery in an AI-native world.RECOMMENDED BOOKSEmily Freeman & Nathen Harvey • 97 Things Every Cloud Engineer Should Know • https://amzn.to/3UlWBLtCharles Humble • Professional Skills for Software Engineers • https://www.conissaunce.com/professional-skills-shortcutNicole Forsgren, Jez Humble & Gene Kim • Accelerate • https://amzn.to/442Rep0Kim, Humble, Debois, Willis & Forsgren • The DevOps Handbook • https://amzn.to/47oAf3lJez Humble & David Farley • Continuous Delivery • https://amzn.to/452ZRkyJez Humble, Joanne Molesky & Barry O'Reilly • Lean Enterprise • https://amzn.to/47pcOXDAdrienne Braganza Tacke • "Looks Good to Me": Constructive Code Reviews • https://amzn.to/3E75XrDYevgeniy Brikman • Fundamentals of DevOps and Software Delivery • https://amzn.to/3WMPMFUBlueskyTwitterInstagramLinkedInFacebookCHANNEL MEMBERSHIP BONUSJoin this channel to get early access to videos & other perks:https://www.youtube.com/channel/UCs_tLP3AiwYKwdUHpltJPuA/joinLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

The new DORA State of DevOps report explores the AI trust gap in the SDLC, culture's impact on DevOps success,  and the rise of platform engineering

In this episode, Andrey, Mattias, and Paulina break down the new DORA Accelerate State of DevOps report. What's changed since the last report? What do these insights mean for your team? Tune in for our insightful conversation!  Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

"2024 State of DevOps Report" ląduje na naszych biurkach! Czy AI już przejęło kontrolę nad DevOps? A może to tylko kolejna bańka technologiczna? W tym odcinku Patoarchitekci analizują cztery kluczowe metryki DORA. Odkrywamy, dlaczego poziom High to sensowny cel dla firm. Omawiamy wpływ AI na stabilność kodu i Platform Engineering. Chcesz wiedzieć, czy Twoja firma to DevOps Elite czy DevOps Meh? Posłuchaj i sprawdź, czy Twoje metryki są Elite, czy może czas na DevOps detox!   A teraz nie ma co się obijać!

This week, we discuss the latest DORA report and what happens when open-source projects make money. Plus, some thoughts on Halloween abroad in the Netherlands and Australia. Watch the YouTube Live Recording of Episode (https://www.youtube.com/watch?v=QcL0uQFjNkY) 491 (https://www.youtube.com/watch?v=QcL0uQFjNkY) Runner-up Titles This is a lifestyle business. The Benioff Line. Mahalo The innings in the marathon We're left picking up the trash 20 pounds of crap in a 10 pound sack Focus on all parts of the chain If any open source project creates value, it's going to create resentment. The Open Source Success Paradox Mad King for Cash. (In the world of Brandon's mind.) Rundown DORA 2024 State of DevOps Report (https://cloud.google.com/resources/devops/state-of-devops) L (https://softwaredefinedtalk.slack.com/archives/C6CDLDCVB/p1729668625078209)istener Chris did some live PDF reading in the SDT Slack (https://softwaredefinedtalk.slack.com/archives/C6CDLDCVB/p1729668625078209) Key findings and takeaways from this year's State of DevOps report (https://newsletter.getdx.com/p/2024-dora-report) DORA Community of Practice (https://dora.community/) AI is terrible at shift-left (DORA Models and Practices) (https://newsletter.cote.io/p/ai-is-terrible-at-shift-left?open=false#§dora) Trademarks and OSS The Wordpress Drama Interview (this got cited in a lawsuit (https://www.youtube.com/watch?v=OUJgahHjAKU) Elasticsearch is open source, again with Shay Banon (https://changelog.com/podcast/614) Linkerd Forever (https://buoyant.io/blog/linkerd-forever) Relevant to your Interests Excel enters its 40th year (https://www.theregister.com/2024/10/22/excel_enters_its_40th_year/) San Francisco to pay $212 million to end reliance on 5.25-inch floppy disks (https://arstechnica.com/gadgets/2024/10/212-million-contract-will-finally-get-san-francisco-trains-off-floppy-disks/) Linus Torvalds Comments On The Russian Linux Maintainers Being Delisted (https://www.phoronix.com/news/Linus-Torvalds-Russian-Devs) Several Linux Kernel Driver Maintainers Removed Due To Their Association To Russia (https://www.phoronix.com/news/Russian-Linux-Maintainers-Drop) Ghosts in the Machine - JSTOR Daily (https://daily.jstor.org/ghosts-in-the-machine/) Apple opens Private Cloud Compute to public scrutiny (https://www.theregister.com/2024/10/25/apple_private_cloud_compute/) #1467 OpenCost Incubation Proposal #1046 (vote closed) (https://github.com/cncf/toc/discussions/1467) Big Blue (https://buildingslack.com/big-blue/) Balatro creator admits his attempt to 100% his own roguelike game before the mobile port was doomed, and now he has "some words for John Balatro" (https://www.gamesradar.com/games/roguelike/balatro-creator-admits-his-attempt-to-100-percent-his-own-roguelike-game-before-the-mobile-port-was-doomed-and-now-he-has-some-words-for-john-balatro/) We finally have an 'official' definition for open source AI (https://techcrunch.com/2024/10/28/we-finally-have-an-official-definition-for-open-source-ai/) Introducing the analysis tool in Claude.ai (https://www.anthropic.com/news/analysis-tool) A Million People Play This Video Wargame. So Does the Pentagon. (https://www.wsj.com/politics/national-security/a-million-people-play-this-video-wargame-so-does-the-pentagon-e6388f50?mod=tech_lead_story) Apple's new Magic Keyboard, Magic Mouse, and Magic Trackpad have USB-C (https://www.theverge.com/2024/10/28/24275569/apple-usb-c-magic-keyboard-mouse-trackpad-no-lightning) Nonsense Severance season two teaser trailer shows the world's worst return-to-office policy in action (https://www.engadget.com/entertainment/tv-movies/severance-season-two-teaser-trailer-shows-the-worlds-worst-return-to-office-policy-in-action-142930296.html?guccounter=1&guce_referrer=aHR0cHM6Ly9uZXdzLmdvb2dsZS5jb20v&guce_referrer_sig=AQAAAKB3e3-ph307Dt1A-GNN2BkGZidUcGuIlF-9SUa05b35lAsup7k_0PSunw3bFWTOX1PhMZ3lnHtlu-iJGvK5TE_U_JEn560pHkGuwsG0E4pY2Mpo_ZmEIsLVc1LUHawBc8sjtHXpWZXQ5X7p76XwuYvdL_VU9vRZt4A0usKg7YFd) Few truly shocked that NFL player used illegal stream to watch his own team (https://arstechnica.com/gadgets/2024/10/nfl-player-illegally-streams-his-own-teams-game-garners-mostly-sympathy/) Listener Feedback T-Mobile back up Home Internet (https://www.t-mobile.com/home-internet/plans/5g-backup-internet-options) Conferences VMware Explore Barcelona (https://www.vmware.com/explore/eu), Nov 4-7, 2024, Coté speaking. GoTech World (https://www.gotech.world/), Bucharest, Nov 12- 13, 2204, Coté speaking. SREday Amsterdam (https://sreday.com/2024-amsterdam/), Nov 21, 2024, Coté speaking (https://sreday.com/2024-amsterdam/Michael_Cote_VMwarePivotal_We_Fear_Change), 20% off with code SRE20DAY DevOpsDayLA (https://www.socallinuxexpo.org/scale/22x/events/devopsday-la) at SCALE22x (https://www.socallinuxexpo.org/scale/22x), March 6-9, 2025, discount code DEVOP SDT News & Community Join our Slack community (https://softwaredefinedtalk.slack.com/join/shared_invite/zt-1hn55iv5d-UTfN7mVX1D9D5ExRt3ZJYQ#/shared-invite/email) Email the show: questions@softwaredefinedtalk.com (mailto:questions@softwaredefinedtalk.com) Free stickers: Email your address to stickers@softwaredefinedtalk.com (mailto:stickers@softwaredefinedtalk.com) Follow us on social media: Twitter (https://twitter.com/softwaredeftalk), Threads (https://www.threads.net/@softwaredefinedtalk), Mastodon (https://hachyderm.io/@softwaredefinedtalk), LinkedIn (https://www.linkedin.com/company/software-defined-talk/), BlueSky (https://bsky.app/profile/softwaredefinedtalk.com) Watch us on: Twitch (https://www.twitch.tv/sdtpodcast), YouTube (https://www.youtube.com/channel/UCi3OJPV6h9tp-hbsGBLGsDQ/featured), Instagram (https://www.instagram.com/softwaredefinedtalk/), TikTok (https://www.tiktok.com/@softwaredefinedtalk) Book offer: Use code SDT for $20 off "Digital WTF" by Coté (https://leanpub.com/digitalwtf/c/sdt) Sponsor the show (https://www.softwaredefinedtalk.com/ads): ads@softwaredefinedtalk.com (mailto:ads@softwaredefinedtalk.com) Recommendations Brandon: ESPN, Disney+ to Stream Live NFL Game Set in the World of ‘The Simpsons' (https://www.hollywoodreporter.com/tv/tv-news/the-simpsons-nfl-game-espn-disney-plus-altcast-1236046927/?utm_source=newsletter&utm_medium=email&utm_campaign=newsletter_axiosmediatrends&stream=top) Matt: Audio books on Spotify 200,000+ Audiobooks Are Now Available to Spotify Premium Listeners in the U.S (https://newsroom.spotify.com/2023-11-08/audiobooks-us-spotify-premium-users/) Coté: Impro (https://en.wikipedia.org/wiki/Impro:_Improvisation_and_the_Theatre) book (https://en.wikipedia.org/wiki/Impro:_Improvisation_and_the_Theatre). paper and pen. Best (https://bsky.app/profile/cote.io/post/3l7nrtcwsru2k) The Economist (https://bsky.app/profile/cote.io/post/3l7nrtcwsru2k) cover ever (https://bsky.app/profile/cote.io/post/3l7nrtcwsru2k). Photo Credits Artwork (https://unsplash.com/photos/white-and-black-printer-paper-WyxqQpyFNk8)

In this Screaming in the Cloud Summer Replay, we revisit our discussion with Nigel Kersten. When we spoke to him in 2021, he was the Field CTO at Puppet. Today, he works as the Chief Product Officer for Platform.sh. In this trip down memory, Nigel joins Corey to reflect on his time spent as a traveling contract trainer for Puppet, dive into the changes in DevOps since, and look back at how Docker handed over the keys and some of the attachments we have to a techno-social system. Nigel speaks on the innovations that have changed along the way and the impact they've had in the industry. Especially those who have a tendency to cling to “legacy.”Show Highlights:(0:00) Intro(1:18) Duckbill Group sponsor read(1:52) Corey's Puppet experience(3:49) What is Puppet?(5:04) Puppet's role in DevOps(8:12) Challenges in technology adoption(12:36) Issues with legacy in tech(18:26) The misconception of “limited” skilled workers(23:16) Duckbill Group sponsor read(24:00) Corporate communication breakdowns(25:22) State of DevOps Report(32:02) Cloud adoption and missteps(37:46) More from the report and NigelAbout Nigel Kersten:Nigel is a technical leader with 13 years of experience building teams and growing B2B startups as a CTO, VP of Engineering, and Head of Product, with substantial experience working with enterprise customers. Prior to that, he was recruited into the Google SRE org to develop an industry-leading infrastructure-as-code system.Links:Puppet: https://puppet.com2020 State of DevOps Report: https://puppet.com/resources/report/2020-state-of-devops-report/Original Episode:https://www.lastweekinaws.com/podcast/screaming-in-the-cloud/innovations-and-the-changing-devops-tides-of-tech-with-nigel-kersten/Sponsor:The Duckbill Group: https://www.duckbillgroup.com/

In this week's episode, we welcome Derek DeBellis, lead researcher on Google's DORA team, for a deep dive into the science and methodology behind DORA's research. We explore Derek's background, his role at Google, and how DORA intersects with other research disciplines. Derek takes us through DORA's research process step by step, from defining outcomes and factors to survey design, analysis, and structural equation modeling.Discussion points:(3:00) Derek's transition from Microsoft to the DORA team at Google(4:28) Derek talks about his connection to surveys(6:16) Derek's journey to becoming a quantitative user experience researcher(7:48) Derek simplifies DORA(8:19) DORA - Philosophy vs practice(11:09) Understanding desired outcomes(12:45) Self reported outcomes vs objective outcomes(16:16) Derek and Abi discuss the nuances of literature review(19:57) Derek details survey development(27:55) Pretesting issues(29:30) Designing surveys for other companies(35:02) Derek simplifies model analysis and validation techniques(38:48) Benchmarks: Balancing data limitations with method sensitivityMentions and Links:Derek DeBellis on LinkedInDX's guide to measuring GenAI adoption and impact2023 Accelerate State of DevOps Report

The 2024 State of DevOps Report: The Evolution of Platform Engineering is live! In this episode, we're taking you behind the scenes with the authors of the report and one of the people who helped run the survey.Download the 2024 report for free here!On this episode, join us as host Ben Ford, report authors Margaret Lee and David Sandilands, and project manager Stephanie Fairchild pull back the curtain on the 2024 State of DevOps Report.What are the characteristics of successful platforms? Why is the new practice driving a surge in security? Where is platform engineering going next? Learn more in this episode!Highlights:Why the State of DevOps Report pivoted to cover platform engineering last yearWhat we wanted to find out this yearThe big takeaways from the 2024 reportOur predictions for the next year of platform engineeringSpeakers:Ben Ford, Community Lead at Puppet by PerforceMargaret Lee, Manager of Product Management at Puppet by PerforceDavid Sandilands, Principal Solutions Architect at Puppet by PerforceStephanie Fairchild, Senior Manager at ClearPath StrategiesLinks:Download the 2024 State of DevOps Report: The Evolution of Platform EngineeringEmail Margaret at Margaret.Lee@perforce.comFind Ben on Mastodon, Twitter, and in the Puppet Community Slack as binford2kFind David on Mastodon and TwitterCheck out another episode with Ben, Margaret, and David about how return-to-office plans are shaping platform strategiesRead the episode transcriptFind Us Online:puppet.comApple PodcastsTwitterLinkedIn

What is a Sideways Test Pyramid in testing Have you seen the latest WebDriver.io feature that allows developers and teste to easily verify web page content and layout. What skill should you add to your tool kit after the recent announcement of 13billion dollars in this area? Find out in this episode of the Test Guild New Shows for the week of March 24 Time News Title Link 0:00 Register for LinkedIn NewsLetter https://links.testguild.com/wwA8x 0:36 TestResults.io  + TestGuild https://testguild.me/z36t2k 2:12 The sideways test pyramid https://testguild.me/qcnjxv 3:25 open source test automation project https://testguild.me/zaxxkz 4:25 Storybook 8 https://testguild.me/mz9qtz 5:35 WebDriver.IO Visual snapshot testing https://testguild.me/tyvscg 6:42 Learn Synthetic Monitoring Testing Webinar https://testguild.me/5ntk74 7:53 Puppet 2024 State of DevOps Report https://testguild.me/rjgq6w 8:29 Cleric AI SRE https://testguild.me/n5dstv 9:03 Follow the money 13 Billion  https://testguild.me/upwdg4

Link e riferimenti episodio:Accelerate https://amzn.to/3SwV85GThe 2023 State of DevOps Report https://cloud.google.com/devops/state-of-devops___________________________________________________________________Discover Learn Agile Practices: https://learnagilepractices.com/Subscribe to the newsletter: https://learnagilepractices.com/subscribeNeed help in developing your career in Software? Discover our coaching and mentorship program: https://learnagilepractices.com/coaching

Host Victoria Guido sits down with Steven Plappert, CEO of Forecastr, an online software designed to aid founders in financial modeling, which was born to help non-finance savvy founders understand and communicate their company's financial health. Despite the pandemic beginning right after Forecastr's launch in 2020, the company didn't pivot significantly thanks to extensive preparation and customer discovery before the launch. Steven delves into the operational and strategic aspects of Forecastr, highlighting the importance of balancing growth with financial sustainability, a consistent theme in their business strategy. Forecastr's significant development was integrating a strong human element into their software service, a move very well-received by their customers. Steven also outlines the company's key objectives, including cultivating a solid culture, achieving profitability, and exploring opportunities for exponential growth. Additionally, Steven discusses the importance of work-life balance, reflecting on his previous startup experience and emphasizing the necessity of balance for longevity and effectiveness in entrepreneurship. Victoria and Steven further explore how companies, including Forecastr and thoughtbot, incorporate these philosophies into their operations and culture. Forecastr (https://www.forecastr.co/) Follow Forecastr on LinkedIn (https://www.linkedin.com/company/forecastr/), X (https://twitter.com/forecastr), Instagram (https://www.instagram.com/forecastrco/), Facebook (https://www.facebook.com/ForecastrHQ), YouTube (https://www.youtube.com/forecastr), or TikTok (https://www.tiktok.com/@forecastrco). Follow Steven Plappert on LinkedIn (https://www.linkedin.com/in/steven-plappert-59477b3b/). Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Transcript: VICTORIA: This is the Giant R¬obots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Steven Plappert, CEO of Forecastr, an online software that helps founders who hate building financial models in Excel actually understand their numbers, predict runway, and get funded. Steven, thank you for joining us. STEVEN: Hey, yeah, Victoria, thanks for having me. I'm stoked to be here. What's up, guys? VICTORIA: Just to get us warmed up here a little bit, can you tell me what's going on in your world? STEVEN: Well, you know, what is going on in my world? I had a great year last year, very healthy. I have a loving fiancé, and I'm getting married this year, which is going to be super fun. And, obviously, running a business, which takes up more than its fair share of my life. But yeah, it's early Jan, so I've been kind of reflecting on my life, and I got a lot to be grateful for, Victoria, I really do. VICTORIA: That's wonderful. You know, I used to work with a VP of strategic growth who likened forming partnerships with companies as getting into a marriage and building that relationship and that level of trust and communication that you have, which I think is really interesting. STEVEN: Oh, for sure. Emily always, Emily is my fiancé, she always says that, you know, Forecastr is essentially my mistress, if you will, you know what I mean? Because, like, that's [laughs] where the rest of my time goes, isn't it? Between hanging out with her and working on the company, you know, so... VICTORIA: So, how long have you been in a relationship with your business around Forecastr? [laughs] STEVEN: Yeah, right? Yeah [laughs]. Four years with this one. So, you know, we started it actually January 1st of 2020, going into the pandemic, although we didn't know it at the time. And so, we just celebrated our four-year anniversary a few weeks ago. VICTORIA: Well, that's really exciting. So, I'm curious about when you started Forecastr, what was the essential problem that you were trying to solve that you had identified in the market? STEVEN: I'd say the main problem we were trying to solve is that, like, specifically founders, you know, startup founders, really struggle to get, like, a clear picture of their financial health or, like, just the financial aspect of their business. And then they also struggle to communicate that to investors because most founders aren't finance people. You know, like, most people that start a company they don't do it because they're excellent in even, like, business or finance or anything like that. They usually do it because, like, they've identified some problem; they've lived it; they've breathed it, you know what I mean? They're some kind of subject matter expert. They may be good at sales, or marketing, or product. But a lot of times, finance is, like, a weak part for them, you know, it's not something that they're strong in. And so, they really have a hard time, like, understanding the viability of the business and communicating the financial outcome of the company to investors and stuff like that. And my co-founder Logan and I live that because all we did all day was built financial models in Excel for startup founders working for a CFO shop called Venture First. So, that's what we really saw. We really saw that just, you know, it's really hard for folks to get this clear picture. And we thought a big part of that, at least, was just the fact that, you know, there's no great software for it. It was just like, people are using Excel, which, you know, for people that are great in finance, you know, works but for most people, doesn't. And so, yeah, I think that that's what kind of inspired Logan and I to fly the coop there at Venture First and start a company. VICTORIA: No, that's really interesting. So, you found this problem. You knew that this was an issue for founders, and you built this hypothesis and started it. I think you said, like, right before 2020, right before the pandemic. So, were there any decisions you made that once you got more information or once you got started, you decided to pivot? And, like, what were those pivot points for you early on? STEVEN: There wasn't a lot of pivoting early on, I will say. And a part of that is because, like, this isn't my first company. I started a company right out of college back in 2013 called FantasyHub. In that company, we pivoted a lot and, largely because we didn't really put a lot of forethought into that company when we launched it, you know, we didn't do any customer discovery. We just launched the company. And then we skinned our knees a bunch of times [laughs] as we scaled that company up and had to change gears a lot of times. In Forecastr, you know, we had actually been kind of building towards starting the company for 18 months. So, Logan and I actually had the idea originally in middle of 2018. And we decided at that time, look, like, we're not going to go launch this company right away because we got full-time jobs, and we might as well de-risk it. So, we spent about 12 to 18 months just doing a lot of customer discovery, kind of in stealth mode while at Venture First. After about six months, we brought it up to Venture First and said, "Hey, here's this idea for a company we have. We want to go do it." You know, to Venture First's credit, you know, rather than viewing that territorially and saying, "Hey, you know, there's a great new product line for our company," they really inspired us to go forward with it. They said, "Hey, this is great. We want to support you guys." They put some money in. We did some more discovery. We built a prototype. So, long-winded way of saying that by the time we actually got to the starting line in 2020, you know, we had 18 months' worth of really clear thought put into this thing. And we had been building in this space for years, you know, building financial models and Excel for founders. So, I think we had a great understanding of the customer. We had a great understanding of the market and the needs. We'd done our diligence in terms of distribution and figuring out how we wanted to generate, you know, a good, healthy funnel for the business. And so, it was really just kind of a matter of execution at that point. And, you know, here we are four years in, and there really hasn't been anything that we've done that's really pivoted the business that much across those four years, except for one moment, which was actually six months ago. So, in July of 2023, we did finally have our first kind of pivot moment where one of the interesting things about Forecastr versus some other solutions in the market is that we're not just a product, just a SaaS platform. There's a real strong human layer to our solution. We've always felt like a SaaS plus human model was the right model for financial modeling for startups because a lot of these startup founders don't have finance expertise on staff or inherently. And about six months ago, it wasn't as much of a pivot as it was a double down. You know, we really doubled down on that human element, you know, and now that human element isn't just through, like, a white glove onboarding and some email support. But we actually do give our customers an analyst in addition to the software that's with them for the lifetime of their subscription and is with them every step of the way. And so, that's the only time that we really made, like, a significant change into what we were doing. And it was just, I think, off the back of three years of saying, "Hey, like [chuckles], people really love the human element, you know, let's lean into that." VICTORIA: I love that you saw that you couldn't solve this problem with just technology and that you planned for and grew the people element as well. And I'm curious: what other decisions did you have to make as you were growing the business, how to scale the tech side or the people side? STEVEN: So many decisions, right? And that's why I tell people all the time, I'm like, you know, I've been a founder for 11 years now. And, in my opinion, by far, the hardest part about being a founder is that all day, every day, you have to make a bunch of decisions. And you hardly ever have enough data to, like, know, you're making the right decision. So, you got to make a bunch of judgment calls, and ultimately, these are judgment calls that could make or break your company. And it's really taxing. It's taxing on the mind. It's stressful, you know. It is not easy. So, you know, I think it's one of the really hard things about being an entrepreneur. I would say one of the most consistent decisions that we've had to make at the highest level is decisions around kind of capital preservation, fiscal responsibility, and investing in the growth. So, categorically, it's like, on the one hand, you have a desire to build the company kind of sustainably, to get to profitability, to have a healthy working model, you know, where you have some real staying power, you know. And that line of thinking leads you to, you know, be conscientious about investments that you're making that, you know, increase the burn. On the other hand, you have a desire to grow the company very quickly. You know, you have certain benchmarks you need to meet, you know, in order to be attractive to venture capitalists. And so, you have decisions that you want to make, you know, to invest in that growth. And so, I think that's a very consistent theme that's played out across the four years is Logan and I trying to walk that tightrope between growing 2 to 3X year over year and being really mindful of the company's burn, you know, both for equity preservation and just to build the company in a more sustainable way. And I think as financial professionals and founders, the finance person in Logan and I a lot of times wants to be more conservative. The founder in Logan and I, a lot of times, wants to be more aggressive. And so, we kind of just, like, let those two forces kind of play themselves out. And I think it creates, like, a nice, healthy tension. VICTORIA: That is really interesting, yeah. And sometimes you have to make a guess [chuckles] and go with it and then see the results of what happens. So, you're a financial forecasting company. What kind of, like, key results or objectives are you working towards this year with Forecastr? STEVEN: Yeah, great question. So, we're really mindful of this kind of stuff. I'd say, you know, it's something that we really consider at a deep level is, like, you have to ultimately set objectives, which are very aligning and clarifying, you know, at an executive level, and then those should kind of filter all the way down through the organization. Because so much, I think, of building a company is you have to kind of punch above your weight. You have to grow faster than [chuckles] the resources that you're putting into it might expect or whatever. I mean, you have limited resources, limited time, but you got to go really quickly. I think alignment is a big part of that, and that starts with setting clear objectives. So, we actually have three very clear objectives, really four. The first one is living up to our cultural values. You know, we're a culture-first organization. We believe that, like, culture, you know, kind of eats strategy for breakfast, that age-old kind of cliché, but it's true. It's just like, I think, you know, if you build a really good culture, people are just...they're happier. They're more productive. You get more done. So, that is our number one strategic objective. Number two is to become profitable. Like I mentioned, we want to become profitable. We want to build a sustainable company. So, by setting that objective, it kind of forces us to be conscientious about spend and only invest in areas that we think is, like, a one plus one equals three. Our third strategic objective is reach 5 million in annual recurring revenue by the end of the year. We're at 2.4 right now. We want to at least double year over year. That's kind of, like, the minimum threshold to keep playing the venture game. And then number four is unlock exponential growth opportunities. So, we definitely adopt the philosophy of, like, hey, we've got a model. It's working. We've got 700 customers, you know, we've got two and a half million in annual recurring revenue. So, like, 80% of our focus should be on becoming profitable and hitting $5 million in annual recurring revenue. Like, that's, like, the bread and butter there, just keep doing what's working. But 20% of our attention should be paid to, well, what could we be doing to, like, triple down on that, you know, to really start to create an exponential growth curve? And, for us, that stuff and, like, kind of the data in investor space, like, there's a lot of interesting things that we could do, of course, as long as it's consensual, anonymized, et cetera, safe and secure, you know, with the kind of data that we have on private companies, you know, anonymously benchmarking companies against their peers, things like that. And I think there's a really big opportunity that we have to serve investors as well, you know, and to create a better investor experience when it comes to financial reporting, also something that we think can unlock exponential growth. So, those are the four objectives that we have going into this year. VICTORIA: Well, I really appreciate that you had culture at number one, and it reminds me, you know, you said it's old adage, but it's true, and you can verify that in reports like the State of DevOps Report. The number one indicator of a high-security environment is the level of trust and culture that you have within your company, not necessarily the technology or tools that you're using. So, being a financial company, I think you're in a good position [chuckles] to have, like, you know, protect all those assets and protect your data. And yeah, I'm curious to hear more about what you said about just unlocking, like, exponential growth. It's hard to keep both the let's keep the lights on and keep running with what we have, and make room for these bigger strategic initiatives that are really going to help us grow as a company and be more sustainable over time. So, how do you make room for both of those things in a limited team? STEVEN: Yeah, it's a great question. And it's not easy, I would say. I mean, I think the way we make room for it probably on the frontend is just, like, being intentional about creating that space. I mean, ultimately, putting unlocking exponential growth opportunities on the strategic company roadmap, which is the document that kind of memorializes the four objectives that I just went through, that creates space inherently. It's one of four objectives on the board. And that's not just, like, a resource that sits, you know, in a folder somewhere. We use the OKR system, you know, which is a system for setting quarterly objectives and things like that. And these strategic objectives they make it on our OKR board, which filters down into our work. So, I think a big piece of creating the space is just as an executive and as a leader, you know, being intentional about [chuckles] putting it on the board and creating that space. The thing that you have to do, though, to be mindful is you have to make sure that you don't get carried away with it. I mean, like you said, at the end of the day, succeeding in a business requires a proper balancing of short-term and long-term priorities. You know, if you're focused too much on the short term, you know, you can kind of hamstring yourself in the long run. Yeah, maybe you build, like, a decent business, but you don't quite, you know, reach your highest potential because you're not investing in some of those things that take a while to develop and come to play in the long run. But if you're too focused on the long run, which is what these exponential opportunities really are, you know, it's very easy to lose your way [laughs] in the short term, and it's very easy to die along the way. You know, I do think of startups as much of a game of survival as anything. I always say survive until you thrive. And so, that's where the 80/20 comes in, you know, where we just kind of say, "Hey, look, like, 80% of our time and energy needs to be devoted to kind of short-term and less risky priorities, such as doubling down on what's already working. 20% of our time, thereabouts, can be devoted to some of these more long-term strategic objectives, like unlocking exponential growth. And I think it just takes a certain mindfulness and a certain intentionality to, like, every week when you're organizing your calendar, and you're, like, talking with your team and stuff like that, you're just always trying to make sure, hey, am I roughly fitting into that framework, you know? And it doesn't have to be exact. Some weeks, it may be more or less. But I think that's kind of how we approach it, you know, conceptually. VICTORIA: Oh, what a great perspective. I think that I really like hearing those words about, like, balance and, like, being intentional. MID-ROLL AD: Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future. thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices. Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff. VICTORIA: You mentioned earlier that you're getting married, so, like, maybe you can talk about how are you intentional with your own time and balancing your personal life and making room for these, you know, big life changes while dealing with also the stress of being in kind of a survivor mode with the company. STEVEN: Like I mentioned, this is my second company, and Emily, bless her heart, my fiancé, she's been with me my entire entrepreneurial career. We started dating the first month that I started my first company, FantasyHub. And in that company, I ran that company for three years. We took it through Techstars down in Austin. It was a consumer gaming company. Interesting company. It ended up being a failure but, like, super interesting and set me on my path. Yeah, I was a complete and total workaholic. I worked around the clock. It was a fantasy sports company, so weekends were our big time, and I worked seven days a week. I worked, like, a lot of 80-hour-plus weeks. And, you know, looking back on it, it was a lot of fun, but it was also miserable. And I also burned out, you know, about six months before the company failed. And had the company not failed when it did, you know, I don't know what the future would have held for us. I was really out of balance. You know, I had deprioritized physical health. I hadn't worked out in years. I wasn't healthy. I had deprioritized mental health. Emily almost left me as a part of that company because I wasn't giving her any attention. And so, you know, when that company failed, and I was left with nothing, you know, and I just was kind of, like, sitting there licking my wounds [laughs], you know, in my childhood bedroom at my parents' house, you know, I was like, you know what? Like, I don't know that that was really worth it, and I don't know that that was the right approach. And I kind of vowed...in that moment, I was like, you know, look, I'm a startup founder. I love building these companies, so I'm, like, definitely going to do it again, but I'm not going to give it my entire life. Like, regardless of your religious beliefs, like, we at least have one life to live. And in my opinion, there's a lot more to life than [chuckles] just cranking out work and building companies. Like, there's a whole world to explore, you know, and there's lots of things that I'm interested in. So, this time around, I'm very thoughtful about creating that balance in my life. I set hard guidelines. There's hard, like, guardrails, I guess I should say, when I start and end work, you know, and I really hold myself accountable to that. Emily holds me accountable to that. And I make sure that, like, I work really hard when I'm at work, but I take the mask off, you know, so to speak, when I'm at home. And I just kind of...I don't deprioritize the rest of my life like I did when I was running FantasyHub. So, I think it's super important. I think it's a marathon building companies. I think you got to do that. I think it's what's in the best interest of the company and you as an individual. So, I think it's something I do a lot better this time around. And I think we're all better off for it, not the least of which is, like, one of our six cultural values is live with balance, and that's why. You know, because, like, we adopt the philosophy that you don't have to work yourself to death to build a great company. You can build a great company working a pretty reasonable workload, you know what I mean? It's not easy. It is kind of a pressure cooker trying to get that much done in that little time, but I think we're living proof that it works. VICTORIA: And if you don't make time to rest, then your ability to make good decisions and build high-quality products really starts to suffer eventually, like, I think, is what you saw at the end there. So, I really appreciate you sharing that and that personal experience. And I'm glad to see the learning from that, and making sure that's a core part of your company values the next time you start a company makes a lot of sense to me. STEVEN: Yeah, totally, you know, yeah. And I've always remembered, although this might be an extreme and a privileged extreme, but, you know, J.P. Morgan, the person, was famous for saying, "I get more done in 9 months than I get in 12," in relationship to the fact that he would take his family over to Europe for, like, three months of the year and, like, summer in Europe and not work. And so, while that's probably an unrealistic, you know, ideal for a startup founder, there's some truth to it, you know what I mean? Like you said, like, you got to rest. And, in fact, if you rest more, you know, yeah, you might be working less hours. You'll actually get more done. You're a lot clearer while you're at work. It's a mindset game. It's a headspace game. And the better you can put yourself in that good mindset, that good headspace, the more effective you are. Yeah, there's just a lot of wisdom to that approach. VICTORIA: Right. And, you know, thoughtbot is a global company, so we have employees all over the world. And I think what's interesting about U.S-based companies, I'm interested in how Forecastr might even help you with this, is that when you start a company, you basically form, like, a mini-government for your employees. And you have input over to how much they paid, how much healthcare they get. You have input over their hours and how much leave and everything. And so, trying to balance all those costs and create a good environment for your employees and make sure they have enough time for rest and for personal care. How does Forecastr kind of help you also imagine all of those costs [laughs] and make sense of what you can offer as a company? STEVEN: I would say the main way that we help folks do that, and we really do play in that space, is just by giving you a clear picture of what the future holds for your company from a financial perspective. I mean, it's one of the things that I think is such a superpower when it comes to financial modeling, you know, it can really help you make better decisions along these lines because, like, what does a financial model do? A financial model just simulates your business into the future, specifically anything related to the cash flow of your business, you know, cash in, cash out, revenue expenses, and the like. And so, your people are in there, and what they're paid is in there and, you know, your revenue and your expenses, your cash flow, your runway, all that's in the model. One of the things I feel like we do really help people do is just get a clearer picture of like, hey, what do the next 3, 6, 12, you know, 24 months look like for my company? What is my runway? When am I going to run out of money? What do I need to do about that? Can I afford to give everybody a raise, or can I afford to max out my benefits plan or whatever that is? It's like, you can make those assessments more easily. You know, if you have a financial model that actually makes sense to you that you can look at and say, oh, okay, cool. Yeah, I can offer that, like, Rolls Royce benefits plan and still have 18 months' worth of runway, or maybe I can't [laughs]. And I have to say, "Sorry, guys, you know, like, we're cash-constrained, and this is all we can do for now. But maybe when we raise that next round and when we hit these growth milestones, you know, we can expand that." So yeah, I think it's all, for us, about just, like, helping founders make better decisions, whether they be your decisions around employees and benefits, et cetera, or growth, or fundraising, you know, through the power of, like, financial health and hygiene. VICTORIA: Great. Thank you. I appreciate you letting me bring it all the way back [laughs]. Yeah, let me see. Let me go through my list of questions and see what else we have here. Do you have any questions for me or thoughtbot? STEVEN: Yeah. I mean, so, like, how do you guys think about this kind of stuff? Like, you know, you said thoughtbot's a global company at this point, but the name would imply, you know, a very thoughtful one. So, I'd be curious in y'alls kind of approach to just, like, culture and balance and some of these things that we're talking about kind of, like, straddling that line, you know, between, like, working really hard, which you have to do to build a great company but, you know, being mindful of everything else that life has to offer. VICTORIA: Yeah. Well, I think thoughtbot, more than any other company I've ever worked for, really emphasizes the value of just, like, people really want you to have a work-life balance and to be able to take time off. And, you know, I think that for a company that does consulting and we're delivering at a certain quality, that means that we're delivering at the quality where if someone needs to take a week off for a vacation, there's enough documentation; there's enough backup support for that service to not be impacted. So, that gives us confidence to be able to take the time off [chuckles], and it also just ends up being a better product for our clients. Like, our team needs to be well-rested. They need to have time to invest in themselves and learning the latest technology, the latest upgrades, contributing to open source, and writing about the problems they're seeing, and contributing back to the community. So, we actually make time every Friday to spend on those types of projects. It's kind of like you were saying before, like, you get as much done in four days as many companies get in five because that time is very highly focused. And then you're getting the benefit of, you know, continually investing in new skills and making sure the people you're working with are at the level that you're paying for [laughs]. STEVEN: Yeah, right. No, that's super cool. That's super cool. VICTORIA: Yeah, and, actually, so we're all remote. We're a fully remote company, and we do offer some in-person events twice a year, so that's been a lot of fun for me. And also, getting to, like, go to conferences like RubyConf and RailsConf and meeting the community has been fantastic. Yeah, you have a lot of value of self-management. So, you have the ability to really adjust your schedule and communicate and work with what meets your needs. It's been really great. STEVEN: Yeah, I love that, too. And we're also a remote company, and I think getting together in person, like you just talked about it, is so important. We can only afford to do it once a year right now as an earlier-stage company. But as amazing as, you know, Zoom and things like this are, it's like, there's not really a perfect replacement for that in-person experience, you know. VICTORIA: I agree, and I also agree that, like, once a year is probably enough [laughter]. That's a great amount of time. Like, it really does help because there are so many ways to build relationships remotely, but sometimes, at least just meeting in person once is enough to be like, oh yeah, like, you build a stronger connection, and I think that's great. Okay. Let me see. What other questions do we have? Final question: is there anything else that you would like to promote? STEVEN: I guess it's my job to say we are a really awesome financial modeling platform and team in general. So, if you are a startup founder or you know a startup founder out there that just could use some help with their financial model, you know, it is definitely something that we'd love to do. And we do a ton of education and a ton of help. We've got a ton of resources that are even freely available as well. So, our role in the market is just to get out there and help folks build great financial models, whether that be on Forecastr or otherwise, and that's kind of the approach that we take to it. And our philosophy is like, if we can get out there and do that, you know, if we can be kind of the go-to resource for folks to build great models regardless, you know, of what that means for them, a rising tide will float all boats, and our boat the most of which, hopefully. So [laughs], if you need a model, I'm your guy. VICTORIA: Thank you so much for sharing that. And I have a fun question for you at the end. What is your favorite hike that you've been on in the last three years or ever, however long you want to go back? [laughs] STEVEN: Well, I would say, you know, I did have the great pleasure this year of returning to the Appalachian Trail to hike the Roan Highlands with a friend of mine who was doing a thru-hike. So, a friend of mine did a southbound thru-hike on the A.T. this year, went from Maine to Georgia. Good friend of mine. And I had not been on the Appalachian Trail since I did a thru-hike in 2017. So, I had not returned to the trail or to that whole community. It's just a very special community. It really is a group of, like, really awesome, eclectic people. And so, yeah, this last year, I got to go down to the Roan Highlands in Tennessee. It's a beautiful, beautiful area of Tennessee and in the Southeast, rolling hills and that kind of thing. And hike, for him, for, like, three or four days and just be a part of his journey. Had a ton of fun, met some awesome people, you know, great nature, and totally destroyed my body because I was not prepared to return to the grueling nature of the Appalachian Trail. So yeah, I'd have to say that one, Victoria. I'd have to say that was my favorite in the last couple of years for sure. VICTORIA: Yeah, it's beautiful there. I've hiked certain parts of it. So, I've heard that obviously the Appalachian Trail, which is the eastern side of the United States, was the earlier trail that was developed because of the dislocation of people over time and that they would create the trail by getting to a peak and then looking to another peak and being like, "Okay, that's where I'm going to go." So, when you say it's grueling, I was, like, a lot of up and down hills. And then what I've heard is that the Pacific Trail on the western part of the United States, they did more of figuring out how to get from place to place with minimizing the elevation change, and so it's a much more, like, sustainable hike. Have you ever heard that? STEVEN: Oh yeah, that is 100% true. In terms of, like, the absolute change in elevation, not, like, the highest elevation and the lowest, just, like, the change up and down, there's twice as much going up and down on the A.T. as there is on the Pacific Crest Trail. And the Pacific Crest Trail is graded for park animals, so it never gets steeper than, like, a 15% grade. So, it's real groovy, you know, on the PCT where you can just get into a groove, and you can just hike and hike and hike and hike for hours, you know, versus the A.T. where you're going straight up, straight down, straight up, straight down, a lot of big movements, very exhausting. I've hiked a good chunk of the PCT and then, obviously, the whole A.T., so I can attest, yes, that is absolutely true. VICTORIA: I feel like there's an analogy behind that and what Forecastr does for you. Like, you'll be able [laughs] to, like, smooth out your hills a little bit more [laughs] with your finances, yeah. STEVEN: [laughs] Oh, I love that. Absolutely. Well, and I've honestly, like, I've often likened, you know, building a company and hiking the Appalachian Trail because it is one of those things where one of the most clarifying things about hiking a long trail is you just have this one monster goal that's, you know, that's months and months ahead of you. But you just got to get up every day, and you just got to grind it out. And every day is grindy, and it's hard, you know, but every day you just get one step closer to this goal. And it's one of the cool things about a trail is that you kind of steep yourself in that one goal, you know, one-track mind. And, you know, like we were saying earlier, there's so much more to life. So, you can't and probably shouldn't do that with your startup. You should continue to invest in other aspects of your life. But maybe while you're within the four walls of your office or when you open up that laptop and get to work on your computer, you know, if you take that kind of similar approach where you got this big goal that's, you know, months or years away but every day you just got to grind it out; you just got to work hard; you got to do what you can to get 1 step closer. And, you know, one day you'll wake up and you'll be like, oh shit, like, I'm [laughs] pretty close, you know what I mean? Yeah, I think there's definitely some similarities to the two experiences. VICTORIA: I appreciate that, yeah. And my team is actually it's more like starting up a business within thoughtbot. So, I'm putting together, like, my three-year plan. It's very exciting. And I think, like, those are the types of things you want to have. It's the high-level goal. Where are we going? [chuckles] Are we on our track to get there? But then day to day, it's like, okay, like, let's get these little actions done that we need to do this week [laughs] to build towards that ultimate goal. Well, thank you so much for joining us today, Steven. I really enjoyed our conversation. Is there anything final you want to say? STEVEN: I just want to thank you, Victoria. I think it's a wonderful podcast that you guys put on, and I really appreciate the opportunity to be here and to chat with you. You're lovely to talk to. I enjoyed the conversation as well, and I hope everyone out there did, also. So, let's make it a great 2024. VICTORIA: Thank you so much. Yeah, this is actually my second podcast recording of the year, so very exciting for me. I appreciate it. Thanks so much for joining again. So, you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. And you can find me on X, formerly known as Twitter, @victori_ousg. And this podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Dave Mangot, CEO and founder of Mangoteque, joins Coreyon Screaming in the Cloud to explain how leveraging DevOps improves the lives of engineers and results in stronger businesses. Dave talks about the importance of exclusively working for private equity firms that act ethically, the key difference between venture capital and private equity, and how conveying issues and ideas to your CEO using language he understands leads to faster results. Corey and Dave discuss why successful business are built on two things: infrastructure as code and monitoring.About DaveDave Mangot, author of DevOps Patterns for Private Equity, helps portfolio companies get good at delivering software.  He is a leading consultant, author, and speaker as the principal at Mangoteque.  A DevOps veteran, Dave has successfully led digital, SRE, and DevOps transformations at companies such as Salesforce, SolarWinds, and Cable & Wireless. He has a proven track record of working with companies to quickly mature their existing culture to improve the speed, frequency, and resilience of their software service delivery.Links Referenced: Mangoteque: https://www.mangoteque.com DevOps Patterns for Private Equity: https://www.amazon.com/DevOps-Patterns-Private-Equity-organization/dp/B0CHXVDX1K “How to Talk Business: A Short Guide for Tech Leaders”: https://itrevolution.com/articles/how-to-talk-business-a-short-guide-for-tech-leaders/ 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: Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest today is someone that I have known for, well, longer than I've been doing this show. Dave Mangot is the founder and CEO at Mangoteque. Dave, thank you for joining me.Dave: Hey, Corey, it's great to be here. Nice to see you again.Corey: I have to say, your last name is Mangot and the name of your company is Mangoteque, spelled M-A-N-G-O-T-E-Q-U-E, if I got that correctly, which apparently I did. What an amazing name for a company. How on earth did you name a company so well?Dave: Yeah, I don't know. I have to think back, a few years ago, I was just getting started in consulting, and I was talking to some friends of mine who were giving me a bunch of advice—because they had been doing consulting for quite some time—about what my rates should be, about all kinds of—you know, which vendors I should work with for my legal advice. And I said, “I'm having a lot of trouble coming up with a name for the company.” And this guy, Corey Quinn, was like, “Hey, I got a name for you.” [laugh].Corey: I like that story, just because it really goes to show the fine friends of mine over at all of the large cloud services companies—but mostly AWS—that it's not that hard to name something well. The trick, I think, is just not to do it in committee.Dave: Yeah. And you know, it was a very small committee obviously of, like, three. But yeah, it's been great. I have a lot of compliments on the name of my company. And I was like, oh, “You know that guy, the QuinnyPig dude?” And they're like, “Yeah?” “Oh, yeah, it was—that was his idea.” And I liked it. And it works really well for the things that I do.Corey: It seems to. So, talk to you about what it is that you do because back when we first met and many, many years ago, you were an SRE manager at a now defunct observability company. This was so long ago, I don't think that they used the term observability. It was Librato, which, “What do you do?” “We do monitoring,” back when that didn't sound like some old-timey thing. Like, “Oh, yeah. Right, between the blacksmith and the cobbler.” But you've evolved significantly since you were doing the mundane, pedestrian tasks of keeping the service up and running. What do you do these days?Dave: Yeah, that was before the observability wars [laugh] [whatever you like 00:02:55] to call it. But over time, that company was owned by SolarWinds and I wound up being responsible for all the SolarWinds cloud company SRE organizations. So, started—ran a global organization there. And they were owned by a couple of private equity firms. And I got to know one of the firms rather well, and then when I left SolarWinds, I started working with private equity firm portfolio companies, especially software investments. And what I like to say is I teach people how to get good at delivering software.Corey: So, you recently wrote a book, and I know this because I make it a point to get a copy of the book—usually by buying it, but you beat me to it by gifting me one—of every guest I have on the show who's written a book. Sometimes that means I wind up with the eclectic collections of poetry, other times, I wind up with a number of different books around the DevOps and cloud space. And one of these days, I'm going to wind up talking to someone who wound up writing an encyclopedia or something, to where I have to back the truck around. But what I wanted to ask is about your title, of all things. It's called DevOps Patterns for Private Equity. And I have to ask, what makes private equity special?Dave: I think as a cloud economist, what you also just told me, is you owe me $17.99 for the book because it was gifted.Corey: Is that how expensive books are these days? My God, I was under the impression once you put the word ‘DevOps' in the title, that meant you're above 40 bucks, just as, you know, entrance starting fees here.Dave: I think I need to talk to my local cloud economist on how to price things. Yeah, the book is about things that I've basically seen at portfolio companies over the years. The thing about, you know, why private equity, I think it would be one question, just because I've been involved in the DevOps movement since pretty much the start, when John Willis calls me a DevOps OG, which I think is a compliment. But the thing that I like about working with private equity, and more specifically, private equity portfolio companies is, like I wrote in the book, they're serious. And serious means that they're not afraid to make a big investment, they're not afraid to change things quickly, they're not afraid to reorganize, or rethink, or whatever because a lot of these private equity firms have, how they describe it as a three to five year investment thesis. So, in three to five years, they want to have some kind of an exit event, which means that they can't just sit around and talk about things and try it and see what happens—Corey: In the fullness of time, 20 years from now. Yeah, it doesn't work that well. But let's back up a little bit here because something that I have noticed over the years is that, especially when it comes to financial institutions, the general level of knowledge is not terrific. For a time, a lot of people were very angry at Goldman Sachs, for example. But okay, fair enough. What does Goldman Sachs do? And the answer was generally incoherent.And again, I am in no way, shape or form, different from people who form angry opinions without having all of the facts. I do that myself three times before breakfast. My last startup was acquired by BlackRock, and I was the one that raised our hand internally, at the 40-person company when that was announced, as everyone was sort of sitting there stunned: “What's a BlackRock?” Because I had no idea. Well, for the next nine months, I assure you, I found out what a BlackRock is. But what is private equity? Because I see a lot of them getting beaten up for destroying companies. Everyone wants to bring up the Toys-R-Us story as a for instance. But I don't get the sense that that is the full picture. Tell me more.Dave: Yes. So, I'm probably not the best spokesperson for private equity. But—Corey: Because you don't work for a private equity firm, you only work with them, that makes you a terrific spokesperson because you're not [in 00:06:53] this position of, “Well, justify what your company does here,” situation, there's something to be said for objectivity.Dave: So, you know, like I wrote in the book, there are approximately 10,000 private equity firms in the United States. They are not all going to be ethical. That is just not a thing. I choose to work with a specific segment of private equity companies, and these private equity companies want to make a good business. That's what they're going for.And you and I, having had worked at many companies in our careers, know that there's a lot of companies out there that aren't a good business. You're like, “Why are we doing this? This doesn't make any sense. This isn't a good investment. This”—there's a lot of things and what I would call the professional level private equity firms, the ones at the top—and not all of them at the top are ethical, don't get me wrong; I have a blacklist here of companies I won't work for. I will not say who those companies are.Corey: I am in the same boat. I think that anyone who works in an industry at all and doesn't have a list of companies that they would not do business with, is, on some level, either haven't thought it through, hasn't been in business long enough, or frankly, as long as you're paying them, everything you can do is a-okay. And you know, I'm not going to sit here and say that those are terrible people, but I never wanted to do that soul-searching. I always thought the only way to really figure out where you stand is to figure it out in advance before there's money on the table. Like, do you want to go do contracting for a defense company? Well no, objectively, I don't, but that's a lot harder to say when they're sitting on the table with $20 million in front of you of, “Do you want to work with a defense company?” Because you can rationalize your way into anything when the stakes are high enough. That's where I've always stood on it. But please, continue.Dave: I'd love to be in that situation to turn down $20 million [laugh].Corey: Yeah, that's a hard situation to find yourself in, right?Dave: But regardless, there's a lot of different kinds of private equity firms. Generally the firms that I work with, they all want—not generally; the ones I work with want to make better companies. I have had operating partners at these companies tell me—because this always comes up with private equity—there's no way to cut your way to a good company. So, the private equity firms that I work with invest in these companies. Do they sell off unprofitable things? Of course they do. Do they try to streamline some things sometimes so that the company is only focused on X or Y, and then they tuck other companies into it—that's called a buy and build strategy or a platform strategy—yes. But the purpose of that is to make a better company.The thing that I see a lot of people in our industry—meaning, like, us tech kind of folks—get confused about is what the difference is between venture capital and private equity. And private equity, in general, is the thing that is the kind of financing that follows on after venture capital. So, in venture capital, you are trying to find product-market fit. The venture capitalists are putting all their bets down like they're in Vegas at re:Invent, and trying to figure out which bet is going to pay off, but they have no expectation that all of the bets are going to pay off. With private equity, the companies have product-market fit, they're profitable. If they're not profitable, they have a very clear line to profitability.And so, what these private equity firms are trying to do, no matter what the size of the company is, whether it's a 50-person company or a 5000-person company, they're trying to get these companies up to another level so that they're more profitable and more valuable, so that either a larger fish will gobble them up or they'll go out on the public markets, like onto the stock market, those kinds of things, but they're trying to make a company that's more valuable. And so, not everything looks so good [laugh] when you're looking at it from the outside, not understanding what these people are trying to do. That's not to say they're not complete jerks who are in private equity because there are.Corey: Because some parts are missing. Kidding. Kidding. Kidding.Dave: [laugh].Corey: It's a nuanced area, and it's complicated, just from the perspective of… finance is deceptively complicated. It looks simple, on some level, because on some level, you can always participate in finance. I have $10. I want to buy a thing that costs $7. How does that work? But it gets geometrically more complex the further you go. Financial engineering is very much a thing.And it is not at all obvious how those things interplay with different dynamics. One of the private equity outcomes, as you alluded to a few minutes ago, is the idea that they need to be able to rapidly effect change. It becomes a fast turnaround situation, and then have an exit event of some kind. So, the DevOps patterns that you write about are aligned with an idea of being effective, presumably, rather than, well, here's how you slowly introduce a sweeping cultural mindset shift across the organization. Like, that's great, but some of us don't have that kind of runway for what we're trying to achieve to be able to pull that off. So, I'm assuming that a lot of the patterns you talk about are emphasizing rapid results.Dave: Well, I think the best way to describe this, right, is what we've talked about is they want to make a better company. And for those of us who have worked in the DevOps movement for all these years, what's one great way of making a better company? Adopting DevOps principles, right? And so, for me, one of the things I love about my job is I get to go in and make engineers' lives better. No more working on weekends, no more we're only going to do deployments at 11 o'clock at night, no more we're going to batch things up and ship them three or four times a year, which all of us who've done DevOps stuff for years know, like, fastest way to have a catastrophe is batch up as many things as possible and release them all at once.So like, for me, I'm going in making engineers' lives better. When their lives are better, they produce better results because they're not stressed out, they're not burned out, they get to spend time with their families, all those kinds of things. When they start producing better results, the executives are happier. The executives can go to the investors and show all the great results they're getting, so the investors are happier. So, for me, I always say, like, I'm super lucky because I have a job that's win, win, win.And like, I'm helping them to make a better company, I'm helping them to ship faster, I'm helping them do things in the cloud, I'm helping them get more reliability, which helps them retain customers, all these things. Because we know from the—you know, remember the 2019 State of DevOps Report: highest performers are twice as likely to meet or exceed their organization's performance goals, and those can be customer retention, revenue, whatever those goals are. And so, I get to go in and help make a better company because I'm making people's lives better and, kind of, everybody wins. And so, for me, it's super rewarding.Corey: That's a good way of framing it. I have to ask, since the goal for private equity, as you said, is to create better companies, to effectively fix a bunch of things that, for better or worse, had not been working optimally. Let me ask the big, dumb, naive question here. Isn't that ostensibly the goal of every company? Now, everyone says it's their goal, but whether that is their goal or not, I think, is a somewhat separate question.Dave: Yeah. I—that should be the goal of every company, I agree. There are people who read my book and said, “Hey, this stuff applies far beyond private equity.” And I say, “Yeah, it absolutely does.” But there are constraints—[gold rat 00:15:10]—within private equity, about the timing, about the funding, about whatever, to get the thing to another level. And that's an interesting thing that I've seen is I've seen private equity companies take a company up to another level, have some kind of exit event, and then buy that company again years later. Which, like, what? Like, how could that be?Corey: I've seen that myself. It feels, on some level, like that company goes public, and then goes private, then goes public, then goes private to the same PE firm, and it's like, are you really a PE company or are you just secretly a giant cat, perpetually on the wrong side of a door somewhere?Dave: But that's because they will take it to a level, the company does things, things happen out in the market, and then they see another opportunity to grow them again. Where in a regular company—in theory—you're going to want to just get better all the time, forever. This is the Toyota thesis about continual improvement.Corey: I am curious as far as what you are seeing changing in the market with the current macroeconomic conditions, which is a polite way to say the industry going wonky after ten years of being relatively up and to the right.Dave: Yeah, well, I guess the fun thing is, we have interest rates, we had a pandemic, we had [laugh], like, all this exciting stuff. There's, you know, massive layoffs, [unintelligible 00:16:34] and then all this, kind of like, super churn-y things. I think the fun thing for me is, I went to a private equity conference in San Francisco, I don't know, a month ago or something like that, and they had all these panelists on stage pontificating about this and that and the other thing, and one of the women said something that I thought was really great, especially for someone like me. She said, “The next five to ten years in private equity are going to be about growth and operational efficiency.” And I was like, “That's DevOps. That's awesome.” [laugh].That really works well for me because, like, we want to have people twice as likely to meet or exceed their organization's performance goals. That's growth. And we want operational efficiency, right? Like, stop manually copying files around, start putting stuff in containers, do all these things that enable us to go fast speed and also do that with high quality. So, if the next five to ten years are going to be about growth and operational efficiency, I think it's a great opportunity for people to take in a lot of these DevOps principles.And so, the being on the Screaming in the Cloud podcast, like, I think cloud is a huge part of that. I think that's a big way to get growth and operational efficiency. Like, how better to be able to scale? How better to be able to Deming's PDSA cycle, right—Plan, Do, Study, Act—how better to run all these experiments to find out, like, how to get better, how to be more efficient, how to meet our customers' demands. I think that's a huge part of it.Corey: That is, I think, a very common sentiment as far as how folks are looking at things from a bigger picture these days. I want to go back as well to something you said earlier that I was joking around at the start of the episode about, “Wow, what an amazing name for the company. How did you come up with it?” And you mentioned that you had been asking a bunch of people for advice—or rather, you mentioned you had gotten advice from people. I want to clarify, you were in fact asking. I wasn't basically the human form of Clippy popping up, “It looks like you're starting a business. Let me give you unsolicited advice on what you should be doing.”What you've done, I think, is a terrific example of the do what I say not what I do type of problem, where you have focused on your positioning on a specific segment of the market: private equity firms and their portfolio companies. If I had been a little bit smarter, I would have done something similar in my own business. I would fix AWS bills for insurance companies in the Pacific Northwest or something like that, where people can hear the type of company they are reflected in the name of what it is that you do. I was just fortunate enough or foolish enough to be noisy enough in order to talk about what I do in a way that I was able to overcome that. But targeting the way that you have, I think is just so spot on. And it's clearly working out for you.Dave: I think a Corey Quinn Clippy would be very distracting in [laugh] my Microsoft Word, first of all [laugh]. Second of all—Corey: They're calling it Copilot now.Dave: [laugh]—there's this guy Corey and his partner Mike who turned me on to this guy, Jonathan Stark, who has his theory about your business. He calls it, like, elucidating, like, a Rolodex moment. So, if somebody's talking about X or Y, and they say, “Oh, yeah. You want to talk to Corey about that.” Or, “You want to talk to Mike about that.”And so, for me, working with private equity portfolio companies, that's a Rolodex moment. When people are like, “I'm at a portfolio company. We just got bought. They're coming in, and they want to understand what our spend is on the cloud, and this and that. Like, I don't know what I'm supposed to do here.” A lot of times people think of me because I tend to work on those kinds of problems. And so, it doesn't mean I can't work on other things, and I definitely do work on other things, I've definitely worked with companies that are not owned by private equity, but for me, that's really a place that I enjoy working, and thankfully, I get Rolodex moments from those things.Corey: That's the real value that I've found. The line I've heard is always it's not just someone at a party popping up and saying, “Oh, yeah, I have that problem.” But, “Oh, my God, you need to talk to this person I know who has that problem.” It's the introduction moment. In my case at least, it became very hard for me to find people self-identifying as having large AWS bills, just because, yeah, individual learners or small startup founders, for example, might talk about it here and there, but large companies do not tend to complain about that in Twitter because that tends to, you know, get them removed from their roles when they start going down that path. Do you find that it is easier for you to target what you do to people because it's easier to identify them in public? Because I assure you, someone with a big AWS bill is hard to spot out of a crowd.Dave: Well, I think you need to meet people where they are, I think is probably the best way of saying that. So, if you are—and this isn't something I need to explain to you, obviously, so this is more for your listeners, but like, if you're going to talk about, “Hey, I'm looking for companies with large AWS bills,” [pthhh] like that's, maybe kind of whatever. But if you say, “Hey, I want to improve your margins and your operational efficiencies,” all of a sudden, you're starting to speak their language, right? And that language is where people start to understand that, “Hey, Corey's talking about me.”Corey: A large part of how I talk about this was shaped by some of the early conversations I had. The way that I think about this stuff and the way that I talk is not necessarily what terms my customers use. Something that I found that absolutely changed my approach was having an investigative journalist—or a former investigative journalist, in this case—interview people I'd worked with to get case studies and testimonials from them. But what she would also do was get the exact phrasing that they use to describe the value that I did, and how they talked about what we'd done. Because that became something that was oh, you're effectively writing the rough draft of my marketing copy when you do that. Speaking in the language of your customer is so important, and I meet a lot of early-stage startups that haven't quite unlocked that bit of insight yet.Dave: And I think looking at that from a slightly different perspective is also super important. So, not only speaking the language of your customer, but let's say you're not a consultant like me or you. Let's say you work inside of a company. You need to learn to speak the language of business, right? And this is, like, something I wrote about in the beginning of the book about the guy in San Francisco who got locked up for not giving away the Cisco passwords, and Gavin Newsom had to go to his jail cell and all this other crazy stuff that happened is, technologists often think that the reason that they go to work is to play with technology. The reason we go to work is to enable the business.And—so shameless plug here I—wrote a paper that came out, like, two months ago with IT Revolution—so the people who do The Phoenix Project, and Accelerate, and The DevOps Handbook, and all that other stuff, I wrote this paper with, like, Courtney Kissler, and Paul Gaffney, and Scott Nasello, and a whole bunch of amazing technologists, but it's about speaking the language of business. And as technologists, if we want to really contribute and feel like the work that we're doing is contributing and valuable, you need to start understanding how those other people are talking. So, you and I were just talking about, like, operational efficiencies, and margins, and whatever. What is all that stuff? And figuring that out and being able to have that conversation with your CEO or whoever, those are the things that get people to understand exactly what you're trying to do, and what you're doing, and why this thing is so important.I talk to so many engineers that are like, “Ah, I talked to management and they just don't understand, and [da-dah].” Yeah, they don't understand because you're speaking technology language. They don't want to hear about, like, CNCF compliant this, that, and the—that doesn't mean anything to them. You need to understand in their lang—talk to them and their language and say like, “Hey, this is why this is good for the business.” And I think that's a really important thing for people to start to learn.Corey: So, a question that I have, given that you have been doing this stuff, I think, longer than I have, back when cloud wasn't really a thing, and then it was a thing, but it seemed really irresponsible to do. And then it went through several more iterations to the point where now it's everywhere. What's your philosophy of cloud?Dave: So, I'll go back to something that just came out, the 2023 State of DevOps Report just came out. I follow those things pretty closely. One of the things they talked about in the paper is one of the key differentiators to get your business to have what they call high organizational performance—again, this [laugh] is going back to business talk again—is what they call infrastructure flexibility. And I just don't think you can get infrastructure flexibility if you're not in the cloud. Can you do it? Absolutely.You know, back over a decade ago, I built out a bunch of stuff in a data center on what I called cloud principles. We could shoot things in the head, get new ones back, we did all kinds of things, we identified SKUs of, like, what kind of classes of machines we had. All that looks like a lot of stuff that you would just do in AWS, right? Like, I know, my C instances are compute. I know my M instances are memory. Like, they're all just SKUs, right?Corey: Yeah, that changed a little bit now to the point where they have so many different instance families that some of their names look like dumps of their firmware.Dave: [laugh]. That is probably true. But like, this idea that, like, I want to have this infrastructure flexibility isn't just my idea that it's going to turn out well. Like, the State of DevOps Report kind of proves it. And so, for me, like, I go back to some of the principles of the DevOps movement, and like, if you look at the DORA metrics, let's say you've got deployment frequency and lead time for changes. That's speed: how fast can I do something? And you've got time-to-recover, and you've got change failure rate. That's quality: how much can I ship without having problems, and how fast can I recover when I do?And I think this is one of the things I teach to a lot of my clients about moving into the cloud. If you want to be successful, you have to deliver with speed and quality. Speed: Infrastructure as Code, full stop. If I want to be able to go fast, I need to be able to destroy an environment, bring a new environment up, I need to be able to do that in minutes. That's speed.And then the second requirement, and the only other requirement, is build monitoring in from the start. Everything gets monitored. And that's quality. Like, if I monitor stuff, I know when I've deployed something that's spiking CPU. If that's monitored, I know that this thing is costing me a hell of a lot more than other things. I know all this stuff. And I can do capacity planning, I can do whatever the heck I want. But those are the two fundamental things: Infrastructure as Code and monitoring.And yes, like you said, I worked at a monitoring or observability company, so perhaps I'm slightly biased, but what I've seen is, like, companies that adopt those two principles, and everything else comes from that—so all my Kubernetes stuff and all those other things are not at odds with those principles—those are the people who actually wind up doing really well. And I think those are the people that have—State of DevOps Report—infrastructure flexibility, and that enables them to have higher organizational performance.Corey: I think you're onto something. Like, I still remember the days of having to figure out the number of people who you had in your ops team versus how many servers they could safely and reasonably run. And now that question has little, if any, meaning. If someone asked me, “Okay, so we're running right now 10,000 instances in our cloud environment. How many admins should it take us to run those?” The correct response is, “How the heck are you running those things?” Like, tell me more because the answer is probably terrifying. Because right now, if you do that correctly, it's you want to make a change to all of them or some subset of them? You change a parameter somewhere and computers do the heavy lifting.Dave: Yeah, I ran a content delivery network for cable and wireless. We had three types of machines. You know, it was like Windows Media Server and some squid-cache thing or whatever. And it didn't matter how many we had. It's all the same. Like, if I had 10,000 and I had 50,000, it's irrelevant. Like, they're all the same kind of crap. It's not that hard to manage a bunch of stuff that's all the same.If I have 10,000 servers and each one is a unique, special snowflake because I'm running in what I call a hosted configuration, I have 10,000 customers, therefore I have 10,000 servers, and each of them is completely different than the other, then that's going to be a hell of a lot harder to manage than 10,000 things that the load balancer is like [bbbrrrp bbbrrrp] [laugh] like, just lay it out. So, it's sort of a… kind of a nonsense question at this point. Like you're saying, like, it doesn't really matter how many. It's complexity. How much complexity do I have? And as we all say, in the DevOps movement, complexity isn't free. Which I'll bet is a large component of how you save companies money with The Duckbill Group.Corey: It goes even beyond that because cloud infrastructure is always less expensive than the people working on it, unless you do something terrifying. Otherwise, everything should be running an EC2 instances. Nothing higher-level built on top of it because if people's time is free, the cheapest thing you're going to get is a bunch of instances. The end. That is not really how you should be thinking about this.Dave: [laugh]. I know a lot of private equity firms that would love to find a place where time was free [laugh]. They could make a lot of money.Corey: Yeah. Pretty sure that the biggest—like, “What's your biggest competitive headwind?” You know [laugh], “Wage laws.” Like it doesn't work that way. I'm sorry, but it doesn't [laugh].I really want to thank you for taking the time to talk to me about what you're up to, how things are going over in your part of the universe. If people want to learn more, where's the best place for them to go to find you?Dave: They can go to mangoteque.com. I've got all the links to my blog, my mailing list. Definitely, if you're interested in this intersection of DevOps and private equity, sign up for the mailing list. For people who didn't get Corey's funky spelling of my last name, it is a play on the fact that it is French and I also work with technology companies. So, it's M-A-N-G-O-T-E-Q-U-E dot com.If you type that in—Mangoteque—to any search engine, obviously, you will find me. I am not difficult to find on the internet because I've been doing this for quite some time. But thank you for having me on the show. It's always great to catch up with you. I love hearing about what you're doing. I super appreciate you're asking me about the things that I'm working on, and you know, been a big help.Corey: No, it's deeply fascinating. It's neat to watch you continue to meet your market in a variety of different ways. Dave Mangot, CEO and founder of Mangoteque, which is excellently named. 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 episode, please leave a five-star review on your podcast platform of choice, along with an angry comment almost certainly filled with incoherent screaming because you tuned out just as soon as you heard the words ‘private equity.'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.

Tym razem rozkładamy na czynniki pierwsze świeżutki raport "State of DevOps Report" prosto z 2023 roku! Zagłębiamy się w DORA Metrics, aby zobaczyć, co naprawdę napędza wydajność naszych zespołów. Będzie też o user centricity – bo kto by pomyślał, że użytkownicy są ważni?

Als Knowledge-Worker sein Wissen teilen: Welche Arten gibt es und was ist für dich das Richtige?Leute im Tech-Bereich werden oft als Knowledge-Worker bezeichnet. Und es gibt auch noch diesen Mythos, dass im Team jeder alles wissen muss, damit jeder alles übernehmen kann. Wurde dieser Zustand jemals erreicht? Dennoch ist das Teilen von Wissen wichtig. Schon allein, um Flaschenhälse zu vermeiden und sich vom Bus-Faktor zu lösen.In dieser Episode sprechen wir über verschiedene Formate wie Hackathons, Code Challenges, interne Konferenzen und Guilds, Book-Clubs und Co. Wir teilen unsere Erfahrung und worauf es besonders ankommt, wenn du etwas ähnliches in deiner Firma starten möchtest.Bonus: Was Hardware-Buzzer und Jeopardy! spiele mit Knowledge Sharing zu tun haben.**** Diese Episode wird gesponsert von https://www.workshops.deOb öffentliche Schulungen, die du einfach buchen kannst oder maßgeschneiderte Schulungen für dein Unternehmen – Workshops.de bietet deutschsprachige Kurse in den Bereichen Angular, React, VueJS, Spring Boot, Typescript, Docker, Security, Data Science und den Grundlagen von HTML, CSS und JavaScript an.Alle Infos unter https://www.workshops.de****Das schnelle Feedback zur Episode:

This week's episode dives into the DORA research program and this year's State of DevOps Report. Nathen Harvey, who leads DORA at Google, shares the key findings from the research and what's changed since previous reports. Discussion points: (1:10) What DORA focuses on (2:17) Where the DORA metrics fit  (4:35) Introduction to user-centric software development (8:05) Impact of user-centricity on software delivery (9:40) Team performance vs. organizational performance  (13:50) Importance of internal documentation (15:19) Methodology for designing surveys (19:52) Impact of documentation on software delivery (23:11) Reemergence of the Elite cluster (25:55) Advice for leaders leveraging benchmarks (28:30) Redefining MTTR (33:45) Changing how Change Failure Rate is measured (36:45) Impact of AI on software delivery  (41:25) Impact of code review speed Mentions and links: Connect with Nathen on LinkedIn Listen to the previous episode with Nathen Read the 2023 State of Devops Report The DORA Quick Check Blog post: Documentation is like sunshine Join the DORA community DevEx: What Actually Drives Productivity

This episode is a special one for me since, for the first time, I have a reappearance in the show – my friend Nathen Harvey, the godfather of the DORA community! We talked about the community, the inaugural DORA Summit, and the freshly published 2023 State of DevOps Report. Nathen touched upon a couple of very interesting insights and shared a ton of advice!An interesting insight is about trunk-based development influencing burnout. Community is working hard to explain this so feel free to join the DORA community trunk-based development discussion that is scheduled for Thursday, December 7 at 6PM UTC. Join the DORA Community of Practice for details and an invitation to the discussion.Please leave a review on your favorite podcast platform or Podchaser, and subscribe to 0800-DEVOPS newsletter here.This interview is featured in 0800-DEVOPS #54 - 2023 State of DevOps Report with Nathen Harvey.[Check out podcast chapters if available on your podcast platform or use links below](0:00)Introduction (1:18)DORA community (6:49)2023 State of DevOps Report (28:25)DORA research and service organizations (31:21)Accelerate, second edition (34:36)Follow recommendations

What does this year's Accelerate State of DevOps Report 2023 mean for your team?LinearB & DORA have officially joined forces. On this week's episode of Dev Interrupted, co-host Conor Bronsdon interviews Nathen Harvey, Head of Google Cloud's DORA team. With data gathered from over 36,000 global professionals, this year's report investigated how top DevOps performers integrate technical, process, and cultural capabilities into their practices for success.Listen to learn how your team can focus on three core outcomes of DevOps: enhancing organizational value, boosting team innovation and collaboration, and promoting team member well-being and productivity.Show Notes:DORA's 2023 State of DevOps ReportGet your DORA Metrics free foreverLinearB's 2023 Software Engineering Benchmarks ReportSupport the show: Subscribe to our Substack Leave us a review Subscribe on YouTube Follow us on Twitter or LinkedIn Offers: Learn about Continuous Merge with gitStream Want to try LinearB? Book a Demo & use discount code "Dev Interrupted Podcast"

This week, we discuss measuring developer productivity, Unity licensing backlash, and some follow-up on Wireless Emergency Alerts. Plus, thoughts on coconuts. Watch the YouTube Live Recording of Episode (https://www.youtube.com/watch?v=bQtDvRPqXFs) 436 (https://www.youtube.com/watch?v=bQtDvRPqXFs) Runner-up Titles One day an ice machine will run on RISC-V Mo Developers Mo Problems W3C my ass. That's almost an aggressive blue. Wait. Do I live in an office complex? You pay the same Quarantine Quarters Maybe I have too much mindlessness Out of my way Costco, I'm going direct. Candy Corn Have you tried a bubble-sort? Omerta for developers Understand what you're measuring, or you'll just get measurements. KCNA23VMWEO20 Just make the bed Rundown Developer Productivity McKinsey Developer Productivity Review (https://dannorth.net/mckinsey-review/) Even longer rebuttal (https://newsletter.pragmaticengineer.com/p/measuring-developer-productivity). The only people who don't like metrics are the people being measured, or, developer productivity metrics quicksand (https://newsletter.cote.io/p/the-only-people-who-dont-like-metrics) Reports Kubernetes at Scale: Challenges, Priorities, Adoption Patterns, and Solutions (https://tanzu.vmware.com/content/analyst-reports/kubernetes-at-scale) Announcing the 2023 State of DevOps Report (https://cloud.google.com/blog/products/devops-sre/announcing-the-2023-state-of-devops-report) John Riccitiello is out at Unity, effective immediately (https://www.theverge.com/2023/10/9/23910441/unity-ceo-president-john-riccitiello-out-retire) Wireless Emergency Alerts (WEA) (https://www.fcc.gov/consumers/guides/wireless-emergency-alerts-wea) Relevant to your Interests Why companies still want in-house data centres (https://www.economist.com/business/2023/10/05/why-companies-still-want-in-house-data-centres) Understanding the Cyber Resilience Act: What Everyone involved in Open Source Development Should Know (https://www.linuxfoundation.org/blog/understanding-the-cyber-resilience-act) PayPal faces new antitrust lawsuit claiming it unfairly stifles competition with Stripe, Shopify and more (https://techcrunch.com/2023/10/05/paypal-faces-new-antitrust-lawsuit-claiming-it-unfairly-stifles-competition-with-stripe-shopify-and-more/) DuckDB Labs puts limit on free support, rules out VC funding (https://www.theregister.com/2023/10/05/duckdb_labs_puts_limit_on_vc_funds/) Genetics firm 23andMe says user data stolen in credential stuffing attack (https://www.bleepingcomputer.com/news/security/genetics-firm-23andme-says-user-data-stolen-in-credential-stuffing-attack/) Hackers are selling the data of millions lifted from 23andMe's genetic database (https://www.theverge.com/2023/10/7/23907330/23andme-leak-hackers-selling-user-dna-data) Datadog stumbles as Bank of America downgrades, citing recent checks (https://seekingalpha.com/news/4019064-datadog-stumbles-bank-of-america-downgrades-recent-checks) IBM CEO in damage control mode after AI job loss comments (https://www.itpro.com/technology/artificial-intelligence/ibm-ceo-in-damage-control-mode-after-ai-job-loss-comments) Google announces new generative AI search capabilities for doctors (https://www.cnbc.com/2023/10/09/google-announces-new-generative-ai-search-capabilities-for-doctors-.html) Be an Open Source Absolutist! (https://twitter.com/ID_AA_Carmack/status/1711737838889242880) Google Cloud mitigated largest DDoS attack, peaking above 398 million rps (https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/) Nonsense Ice Is Not Necessary. So Why Do Hotels Provide It for Free? (https://slate.com/human-interest/2015/08/why-are-there-ice-machines-in-so-many-hotels.html) Listener Feedback Biogen hiring Senior Manager, Solution Architecture, Global Commercial and Medical IT (hybrid work) (https://jobs.smartrecruiters.com/Biogen/743999935046183-senior-manager-solution-architecture-global-commercial-and-medical-it-hybrid-work-) RedHat hiring Principal Product Marketing Manager, OpenShift in Remote (https://us-redhat.icims.com/jobs/100399/principal-product-marketing-manager%2c-openshift/job?mode=view&mobile=true&width=428&height=739&bga=true&needsRedirect=false&jan1offset=-300&jun1offset=-240) Conferences Oct 17th SpringOne Tour Online (free!) (https://springonetour.io/?utm_source=cote&utm_campaign=devrel&utm_medium=newsletter&utm_content=newsletterUpcoming) - Coté talking about platform engineering. Oct 17th and 24th **talk series (yes, a “webinar”): Building a Path to Production: A Guide for Managers and Leaders in Platform Engineering (https://series.brighttalk.com/series/6011/?utm_source=cote&utm_campaign=devrel&utm_medium=newsletter&utm_content=newsletterUpcoming). Coté's doing this. Nov 6-9, 2023, KubeCon NA (https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/), SDT's a sponsor, Matt's there. Use this VMware discount code for 20% off: KCNA23VMWEO20. Nov 6-9, 2023 VMware Explore Barcelona (https://www.vmware.com/explore/eu.html), Coté's attending Nov 7–8, 2023 RISC-V Summit | Linux Foundation Events (https://events.linuxfoundation.org/riscv-summit/) Jan 29, 2024 to Feb 1, 2024 That Conference Texas (https://that.us/events/tx/2024/schedule/) If you want your conference mentioned, let's talk media sponsorships. SDT news & hype Join us in Slack (http://www.softwaredefinedtalk.com/slack). Get a SDT Sticker! Send your postal address to stickers@softwaredefinedtalk.com (mailto:stickers@softwaredefinedtalk.com) and we will send you free laptop stickers! Follow us: Twitch (https://www.twitch.tv/sdtpodcast), Twitter (https://twitter.com/softwaredeftalk), Instagram (https://www.instagram.com/softwaredefinedtalk/), Mastodon (https://hachyderm.io/@softwaredefinedtalk), BlueSky (https://bsky.app/profile/softwaredefinedtalk.com), LinkedIn (https://www.linkedin.com/company/software-defined-talk/), TikTok (https://www.tiktok.com/@softwaredefinedtalk), Threads (https://www.threads.net/@softwaredefinedtalk) and YouTube (https://www.youtube.com/channel/UCi3OJPV6h9tp-hbsGBLGsDQ/featured). Use the code SDT to get $20 off Coté's book, Digital WTF (https://leanpub.com/digitalwtf/c/sdt), so $5 total. Become a sponsor of Software Defined Talk (https://www.softwaredefinedtalk.com/ads)! Recommendations Brandon: macOS Sonoma (https://www.apple.com/macos/sonoma/) Matt: HomeSeek (https://www.homeseekgame.com/) - post apocalyptic SimCity Coté: Menewood (https://www.goodreads.com/en/book/show/60784675), finally out! Over 700 subscribers for my newsletter - are you subscribed (https://newsletter.cote.io)?! Photo Credits Header (https://unsplash.com/photos/dFoOWRT97_0) Artwork (https://unsplash.com/photos/umixjcVd0Ws)

In this episode of Phoenix Cast, hosts John, Rich, and Kyle discuss a trio of terrible items from the news.  They also discuss Google's state of DEVOPS report.  Share your thoughts with us on Twitter: @USMC_TFPhoenix (Now verified!) Follow MARFORCYBER & MCCOG on Twitter, LinkedIn, Facebook, and YouTube. Leave your review on Apple Podcasts. Links: Looney Tunables -  https://blog.qualys.com/vulnerabilities-threat-research/2023/10/03/cve-2023-4911-looney-tunables-local-privilege-escalation-in-the-glibcs-ld-so https://www.bleepingcomputer.com/news/security/exploits-released-for-linux-flaw-giving-root-on-major-distros/?mibextid=Zxz2cZ https://hackaday.com/2023/10/06/this-week-in-security-looney-tunables-not-a-0-day-and-curl-warning/ MoveIt - https://techcrunch.com/2023/08/25/moveit-mass-hack-by-the-numbers/?guccounter=1&guce_referrer=aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS8&guce_referrer_sig=AQAAAKI26YxLOJ3LtfPNiJcdBP7BjU5pY0NLPt_rZ1BSmhkA67JuGSVuYD5tuhnZTBdr6h-hdVsmq97cSlvBy-cClsH8C5uTJ5sLvcl9QDYYhdFqMu_8FDx4wLMOKUb7ixUEF2kg6NXDtajrK38ERHg4zm487zavIDNsKJrbDr4h-fGE https://www.darkreading.com/attacks-breaches/financial-firms-breached-in-moveit-cyberattacks-now-face-lawsuits https://www.bleepingcomputer.com/news/security/the-moveit-hack-and-what-it-taught-us-about-application-security/ https://www.progress.com/moveit https://www.bleepingcomputer.com/news/security/sony-confirms-data-breach-impacting-thousands-in-the-us/ Apple Zero Days: https://www.bleepingcomputer.com/news/apple/apple-emergency-update-fixes-new-zero-day-used-to-hack-iphones/?fbclid=IwAR1V3v3W0kJslsY59ayfrB0UswUzpE9bP0ARmlp1VDLDjx2po4WDUoKuGWs_aem_AVWQ2hLENrbnURcSsKrImQS79tU85DLt59xWTfeGF7ByyJ61n4Nt8jnosltfbzscecE&mibextid=Zxz2cZ https://support.apple.com/en-us/102657#:~:text=Mac%3A%20Choose%20Apple%20menu%20%EF%A3%BF,system%20files%22%20is%20turned%20on. State of DevOps Report: https://cloud.google.com/blog/products/devops-sre/announcing-the-2023-state-of-devops-report Industrial DevOps: https://itrevolution.com/product/industrial-devops-book/  National Security Commission on Artificial Intelligence: https://www.nscai.gov/

Want an example of a practical application of AI in enhancing user engagement and experience?  Or have you heard about a crowd-sourced experiment that used LLMs for testing And what feature was just released that Enhances Web App Testing with Microsoft Playwright Find out in this episode of the Test Guild New Shows for the week of Oct 8. So, grab your favorite cup of coffee or tea, and let's do this.   Time News Title Rocket Link 0:25  Applitoools FREE Account Offer https://applitools.info/joe  0:44 Opsera Secures $12M Funding to Boost AI in DevOps https://testguild.me/zrhhmw 1:32 Crowd-sourced experiment on using LLMs for testing https://testguild.me/sfl3bq 2:56 So We Shipped an AI Product. Did it Work? https://testguild.me/8ts5p5 4:00 GenAIEnhance Productivity  https://testguild.me/8oavzc 4:47 Announcing Microsoft Playwright Testing https://testguild.me/07xnh7 5:39 Accelerate State of DevOps Report 2023 https://testguild.me/0z0ahv 6:37 Changes in defense of Cypress Intellectual Property https://testguild.me/lq8ufy 7:51 Load Tests for Go Applications Running in Kubernetes https://testguild.me/f5km3r 8:48 Mastering API Testing with Katalon Studio and JMeter https://testguild.me/wlzn3a

Victoria and Will interview Rishi Malik, the Founder of Backstop.it and VP of Engineering at Varo Bank. They talk about Rishi's recent adventure at DEF CON, the renowned annual security conference that he's attended for six years, and describes how it has transformed from a mere learning experience into a thrilling competition for him and his team. The conference = their playground for tackling an array of security challenges and brain-teasing puzzles, with a primary focus on cloud security competitions. They talk about the significance of community in such events and how problem-solving through interaction adds value. Rishi shares his background, tracing his path from firmware development through various tech companies to his current roles in security and engineering management. The vital topic of security in the fintech and banking sector highlights the initial concerns people had when online banking emerged. Rishi navigates through the technical intricacies of security measures, liability protection, and the regulatory framework that safeguards online banking for consumers. He also highlights the evolving landscape, where technological advancements and convenience have bolstered consumer confidence in online banking. Rishi shares his unique approach to leadership and decision-making, and pearls of wisdom for budding engineers starting their careers. His advice revolves around nurturing curiosity and relentlessly seeking to understand the "why" behind systems and processes. __ Backstop.it (https://backstop.it/) Follow Backstop.it on X (https://twitter.com/wearebackstop). Varo Bank (https://www.varomoney.com/) Follow Varo Bank on Instagram (https://www.instagram.com/varobank/), Facebook (https://www.facebook.com/varomoney/), X (https://twitter.com/varobank), YouTube (https://www.youtube.com/varomoney), or LinkedIn (https://www.linkedin.com/company/varobank/). Follow Rishi Malik on LinkedIn (https://www.linkedin.com/in/rishilmalik/). Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Transcript: VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. WILL: And I'm your other host, Will Larry. And with us today is Rishi Malik, Founder of Backstop.it and VP of Engineering at Varo Bank. Rishi, thank you for joining us. RISHI: Thanks for having me. I'm excited to be here. VICTORIA: Yes, Rishi. I'm so excited to talk with you today about your security background and get into your role at Varo and Backstop IT. But first, I wanted to hear a little bit more about your recent experience attending DEF CON. How was that? RISHI: It was awesome. I do have quite the background in security at this point. And one of the things I started doing early on, as I was getting up to speed and learning more about the security-specific side of things, was beginning to attend DEF CON itself. So, I've now gone six years straight. And it started out as just kind of experiencing the conference and security and meeting folks. But it's progressed to where I now bring a team of people where we go and we compete. We have a good time. But we do get to kind of bring the security side of things into the software engineering and engineering leadership stuff that we all do on a day-to-day basis. VICTORIA: Yeah. And what kind of puzzles do you solve with your team when you attend DEF CON? RISHI: There's definitely a lot of variety there, which I think is part of the fun. So, DEF CON frequently has electronic badges, you know, with random puzzles on there that you have to solve. Some of it are cryptographic. Some of them are kind of random cultural things. Sometimes there's music challenges based around it. Sometimes, it's social and interactive. And you have to go find the right type of badge or the right person behind it to unlock something. So, all of those, you know, typically exist and are a ton of fun. Primarily, in the last few years, we've been focusing more on the cloud CTF. So, in this case, it's our team competing against other teams and really focused on cloud security. So, it's, you know, figuring out vulnerabilities in, you know, specially designed puzzles around AWS and GCP, the application side of things as well, and competing to see how well you can do. Three years ago, the last couple of years, we've not won it, but we've been pretty competitive. And the great thing is the field is expanding as more and more people get into CTF themselves but, more importantly, into cloud infrastructure and cloud knowledge there. So, it's just great to see that expansion and see what people are into, what people are learning, and how challenging some of these things can be. VICTORIA: I love the idea of having a puzzle at a conference where you have to find a specific person to solve it. And yeah, I'm always interested in ways where we can have these events where you're getting together and building community and growing expertise in a field but in a way that makes it fun [laughs] and isn't just life-draining long, like, talks about random stuff. RISHI: [laughs] I think what you're touching on there is crucial. And you said the word community, and, to me, that is, you know, a big part of what DEF CON and, you know, hacking and security culture is. But it is, I think, one of the things that kind of outside of this, we tend to miss it more, you know, specifically, like, focused conferences. It is more about kind of the content, you know, the hallway track is always a thing. But it's less intentional than I personally, at this stage, really prefer, you know. So, I do like those things where it is encouraging interaction. For me, I'd rather go to happy hour with some people who are really well versed in the subject that they're in rather than even necessarily listening to a talk from them on what they're doing. Simply because I think the community aspect, the social aspect, actually gets you more of the information that is more relevant to what you're doing on a day-to-day basis than just consuming it passively. VICTORIA: I agree because consuming it passively or even intentionally remotely, there are things that you didn't even think to think about [laughs] that aren't going to come up just on your own. You have to have another person there who's...Actually, I have a good friend who's co-working with me this week who's at Ticketmaster. And so, just hearing about some of the problems they have and issues there has been entertaining for me. So yeah, I love that about DEF CON, and I love hearing about community stories and fun ways that companies can get a benefit out of coming together and just putting good content out there. RISHI: Absolutely. I think problem-solving is where you get the most value out of it as a company and as a business. VICTORIA: Yeah, maybe that's a good segue to tell me a little bit more about your background and how you came to be where you are today. RISHI: Yeah. For me growing up, I was always that problem-solver type of person. So, I think that's what kind of naturally gravitated me towards tech and, you know, hardware and software engineering. You know, so, for me, I go back quite a while. I'd been doing a lot of development, you know, in the early days of my career. I started out doing firmware development back in the days of large tape libraries, right? So, if you think about, like, big businesses back before cloud was a big thing and even back before SSDs were a thing, you know, it was all spinning disks. It was all tape. And that's kind of the area that I started in. So, I was working on robots that actually move tapes around these giant tape libraries that are, you know, taller than I am that you can walk inside of because they're so big, for big corporations to be able to backup their data on an overnight basis. You have to do that kind of stuff. Then I started going into smaller and smaller companies, into web tech, into startups, then into venture-backed startups. And then, eventually, I started my own company and did that for a while. All of this is really just kind of, you know, software engineering in a nutshell, lots of different languages, lots of different technologies. But really, from the standpoint of, here's a whole bunch of hard problems that need to be solved. Let's figure out how we can do that and how we can make some money by solving some of these problems. That eventually kind of led me down the security path as well and the engineering management side of things, which is what I do now, both at Backstop...is a security consulting business and being VP of Engineering at Varo Bank. WILL: How was your journey? Because you started as an intern in 2003. RISHI: [laughs] WILL: And then, you know, 20 years later. So, how was your journey through all of that? [laughs] RISHI: [laughs] You know, I hadn't actually put it together that it has been 20 years this year until you said that. So, that's awesome. It's been a blast, you know. I can honestly say it's been wildly different than what I imagined 20 years ago and interesting in different ways. I think I'm very fortunate to be able to say that. When I started out as an intern in 2003, technologies were very different. I was doing some intern shifts with the federal government, you know, so the pace was wildly different. And when I think of where technology has come now, and where the industry has gone, and what I get to do on a day-to-day basis, I'm kind of just almost speechless at just how far we've come in 20 years, how easy some things are, how remarkably hard some other things are that should honestly be easy at this point, but just the things that we can do. I'm old enough that I remember cell phones being a thing and then smartphones coming out and playing with them and being like, yeah, this is kind of mediocre. I don't really know why people would want this. And the iPhone coming out and just changing the game and being like, okay, now I get it. You know, to the experience of the internet and, you know, mobile data and everywhere. It's just phenomenal the advances that we've had in the last 20 years. And it makes me excited for the next 20 years to see what we can do as we go forward. VICTORIA: I'm going to take personal offense to someone knowing that technology being too old [laughs], but, yeah, because it really wasn't that long ago. And I think one thing I always think about having a background in civic tech and in financial tech as well is that the future is here; it's just not evenly distributed. So, now, if you're building a new company, of course, the default is to go straight to the cloud. But many companies and organizations that have been around for 60-80 years and using the internet right when it first came out are still in really old technologies that just simply work. And maybe they're not totally sure why, and change is difficult and slow. So, I wonder if you have any experience that you can take from the banking or fintech industry on how to make the most out of modern security and compliance platforms. RISHI: Yeah, you know, I think most people in tech especially...and the gray hairs on me are saying the younger folks in tech especially don't realize just how much older technologies still exist and will exist for quite some time. When you think of banking itself, you know, most of the major companies that you can think of, you know, in the U.S. especially but kind of across the world that are the top tier names of banks, and networks, and stuff like that, still run mainframes. When you swipe your credit card, there's a very good chance that is processed on a mainframe. And that's not a bad thing. But it's just, you know when you talk to younger engineers, it's not something that kind of crosses their mind. They feel like it is old-tech. The bulk of businesses don't actually run on the cloud. Having been through it, I've racked and stacked servers and had to figure out how to physically take hardware across, you know, country borders and things like those lines. And now, when I do want to spin up a server somewhere else, it's just a different AWS region. So, it's remarkably easy, at this point, to solve a lot of those problems. But once you're up and live and you have customers, you know, where downtime is impactful or, you know, the cost of moving to the cloud or modernizing your technology is substantial, things tend to move a lot slower. And I think you see that, especially when it comes to security, because we have more modern movements like DevOps bringing security into it. And with a lot of the, you know, the modern security and compliance platforms that exist, they work very, very well for what they do, especially when you're a startup or your whole tech stack is modernized. The biggest challenges, I think, seem to come in when you have that hybrid aspect of it. You do have some cloud infrastructure you have to secure. You do have some physical data centers you have to secure. You have something that is, you know, on-premise in your office. You have something that is co [inaudible 10:01] somewhere else. Or you also have to deal with stuff like, you know, much less modern tech, you know, when it comes to mainframes and security and kind of being responsible for all of that. And I think that is a big challenge because security is one of those things where it's, you know, if you think of your house, you can have the strongest locks on your door and everything else like that. But if you have one weak point, you have a window that's left open, that's all it takes. And so, it has to be all-inclusive and holistic. And I think that is remarkably hard to do well, even despite where technology has come to these days. WILL: Speaking of securities, I remember when the Internet banking started a couple of years ago. And some of the biggest, I guess, fears were, like, the security around it, the safety. Because, you know, your money, you're putting your money in it, and you can't go to a physical location to talk to anyone or anything. And the more and more you learn about it...at first, I was terrified of it because you couldn't go talk to someone. But the more and more I learned about it, I was like, oh, there's so much security around it. In your role, what does that look like for you? Because you have such a huge impact with people's money. So, how do you overcome that fear that people have? RISHI: There's, I think, a number of steps that kind of go into it. And, you know, in 2023, it's certainly a little bit easier than it used to be. But, you know, very similar, I've had the same questions, you know, and concerns that you're describing. And I remember using one of the first banks that was essentially all digital and kind of wondering, you know, where is my money going? What happens if something goes wrong? And all of those types of things. And so, I think there is kind of a number of different aspects that go into it. One is, you know, obviously, the technical aspects of security, you know, when you put your credit card number in on the internet, you know, is it encrypted? You know, is it over, you know, TLS? What's happening there? You know, how safe and secure is all that kind of thing? You know, at this point, pretty much everyone, at least in the U.S., has been affected by credit card breaches, huge companies like Home Depot and Target that got cards accessed or, you know, just even the smaller companies when you're buying something random from maybe something...a smaller website on the internet. You know, that's all a little bit better now. So, I think what you have there was just kind of a little bit of becoming comfortable with what exists now. The other aspect, though, I think, then comes into, well, what happens when something goes wrong? And I think there's a number of aspects that are super helpful for that. I think the liability aspect of credit card, you know, companies saying, you know, and the banks "You're not liable for a fraudulent transaction," I think that was a very big and important step that really helps with that. And on top of that, then I think when you have stuff like the FDIC, you know, and insurance in the U.S., you know, that is government-backed that says, you know what? Even if this is an online-only digital bank, you're safe. You're protected. The government's got your back in that regard. And we're going to make sure that's covered. At Varo, that's one of the key things that we think about a lot because we are a bank. Now, most FinTechs, actually, aren't banks, right? They partner with other third-party banks to provide their financial services. Whereas at Varo, we are federally regulated. And so, we have the full FDIC protection. We get the benefits of that. But it also means that we deal with the regulation aspects and being able to prove that we are safe and secure and show the regulators that we're doing the right things for our customers. And I think that's huge and important because, obviously, it's safety for customers. But then it changes how you begin to think about how you're designing products, and how you're [inaudible 13:34] them, and, you know, how you're marketing them. Are we making a mobile app that shows that we're safe, and secure, and stable? Or are we doing this [inaudible 13:42] thing of moving too fast and breaking things? When it's people's money, you have to be very, very dialed into that. You still have to be able to move fast, but you have to show the protection and the safety that people have because it is impactful to their lives. And so, I think from the FinTech perspective, that's a shift that's been happening over the last couple of years to continue that. The last thing I'll say, too, is that part of it has just come from technology itself and the comfort there. It used to be that people who were buying, you know, items on the internet were more the exception rather than the rule. And now with Amazon, with Shopify, with all the other stuff that's out there, like, it's much more than a norm. And so, all of that just adds that level of comfort that says, I know I'm doing the right things as a consumer, that I'm protected. If I, you know, do have problems, my bank's got my back. The government is watching out for what's happening and trying to do what they can do to regulate all of that. So, I think all of that has combined to get to that point where we can do much more of our banking online and safely. And I think that's a pretty fantastic thing when it comes to what customers get from that. I am old enough that I remember having to figure out times to get to the bank because they're open nine to five, and, you know, I have to deposit my paycheck. And, you know, I work nine to five, and maybe more hours pass, and I had no idea when I can go get that submitted. And now, when I have to deposit something, I can just take a picture with my phone, and it safely makes it to my account. So, I think the convenience that we have now is really amazing, but it has certainly taken some time. And I think a number of different industry and commercial players kind of come together and make that happen. MID-ROLL AD: Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future. thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices. Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff. VICTORIA: I appreciate that perspective on approaching security from the user experience of wanting safety. And I'm curious if we can talk in contrast from that experience to the developer experience with security. And how do you, as a new leader in this financial product company, prioritize security and introduce it from a, like, building a safety culture perspective? RISHI: I think you just said that very eloquently. It is a safety culture. And cultural changes are hard. And I think for quite some time in the developer industry, security was either an afterthought or somebody else's problem. You know, it's the security team that has to think about it. It's, you know, and even these days, it's the red team that's going to go, you know, find these answers or whatever I'm shipping as a developer. My only thing to focus on is how fast I can ship, or, you know, what I'm shipping, rather than how secure is what I'm shipping. And so, I think to really be effective at that, it is a cultural shift. You have to think and talk about security from the outset. And you have to bake those processes into how you build product. Those security conversations really do need to start at the design phase. And, you know, thinking about a mobile app for a bank as an example, you know, it starts when you're just thinking about the different screens on a mobile app that people are going to go through. How are people interpreting this? You know, what is the [inaudible 17:23], and the feeling, and the emotions, that we're building towards? You know, is that safe and secure or, you know, is it not? But then it starts getting to the architecture and the design of the systems themselves to say, well, here's how they're going to enter information, here's how we're passing this back and forth. And especially in a world where a lot of software isn't just 100% in-house, but we're calling other partners for that, you know, be it, you know, infrastructure or risk, you know, or compliance, or whatever else it may be, how are we protecting people's data? How are we making sure our third parties are protecting people's data? You know, how are we encrypting it? How are we thinking about their safety all the way through? Again, even all the way down to the individual developer that's writing code, how are we verifying they're writing good, high-quality, secure code? Part of it is training, part of it is culture, part of it is using good tooling around that to be able to make sure and say, when humans make mistakes because we are all human and we all will make mistakes, how are we catching that? What are the layers do we have to make sure that if a mistake does happen, we either catch it before it happens or, you know, we have defense in depth such that that mistake in and of itself isn't enough to cause a, you know, compromise or a problem for our customers? So, I think it starts right from the start. And then, every kind of step along the way for delivering value for customers, also let's add that security and privacy and compliance perspective in there as well. VICTORIA: Yes, I agree. And I don't want to work for a company where if I make a small human mistake, I'm going to potentially cost someone tens or however many thousands of dollars. [laughs] WILL: I have a question around that. How, as a leader, how does that affect you day to day? Because I feel like there's some companies, maybe thoughtbot, maybe other companies, that a decision is not as critical as working as a bank. So, you, as a leader, how do you handle that? RISHI: There's a couple of things I try and consider in any given big or important decision I have to make, the aspects around, like, you know, the context, what the decision is, and that type of stuff. But from a higher level, there's kind of two things I try and keep in mind. And when I say keep in mind, like, when it's a big, impactful decision, I will actually go through the steps of, you know, writing it down or talking this out loud, sometimes by myself, sometimes with others, just, again, to make sure we are actually getting to the meat of it. But the first thing I'm trying to think of is kind of the Amazon idea of one-way versus two-way doors. If we make this decision and this is the wrong decision, what are the ramifications of that? You know, is it super easy to undo and there's very little risk with it? Or is it once we've made this decision or the negative outcome of this decision has happened, is it unfixable to a certain degree? You know, and that is a good reminder in my head to make sure that, you know, A, I am considering it deeply. And that, B, if it is something where the ramifications, you know, are super huge, that you do take the time, and you do the legwork necessary to make sure you're making a good, valid decision, you know, based on the data, based on the risks involved and that there's a deep understanding of the problem there. The second thing I try to think of is our customers. So, at Varo, our customers aren't who most banks target. A lot of banks want you to take all your money, put it in there, and they're going to loan that money out to make their money. And Varo is not that type of bank, and we focus on a pretty different segment of the market. What that means is our customers need their money. They need it safely and reliably, and it needs to be accurate when they have it. And what I mean by that is, you know, frequently, our customers may not have, you know, hundreds or a thousand dollars worth of float in their bank accounts. So, if they're going and they're buying groceries and they can't because there's an error on our side because we're down, and because the transactions haven't settled, then that is very, very impactful to them, you know, as an individual. And I think about that with most of these decisions because being in software and being in engineering I am fortunate enough that I'm not necessarily experiencing the same economic struggles that our customers may have. And so, that reminder helps me to think about it from their perspective. In addition, I also like to try and think of it from the perspective...from my mom, actually, who, you know, she is retired age. She's a teacher. She's non-technical. And so, I think about her because I'd say, okay, when we're making a product or a design decision, how easy is it for her to understand? And my biases when I think about that, really kind of come into focus when I think about how she would interpret things. Because, you know, again, for me, I'm in tech. I think about things, you know, very analytically. And I just have a ton of experience across the industry, which she doesn't have. So, even something as simple as a little bit of copy for a page that makes a ton of sense to me, when I think about how she would interpret it, it's frequently wildly different. And so, all of those things, I think, kind of come together to help make a very strong and informed decision in these types of situations where the negative outcomes really do matter. But you are, you know, as Varo is, you're a startup. And you do need to be able to build more products quickly because our customers have needs that aren't being met by the existing banking industry. And so, we need to provide value to them so that their lives are a bit better. VICTORIA: I love that focus on a specific market segment and their needs and solving for that problem. And we know that if you're at a certain income level, it's more expensive [laughs] because of the overdraft fees and other things that can cause you problems. So, I really appreciate that that's the mission at Varo, and that's who you're focusing on to create a better banking product that makes more sense. I'm curious if there were any surprises and challenges that you could share from that discovery process and finding out, you know, exactly what were those things where your mom was, like, uh, actually, I need something completely different. [laughs] RISHI: Yeah, so, [chuckles] I'm chuckling because, you know, it's not, like, a single kind of time or event. It's, you know, definitely an ongoing process. But, you know, as actually, we were talking, you know, about earlier in terms of being kind of comfortable with doing things digital and online, that in and of itself is something that even in 2023, my mom isn't as comfortable or as confident as, you know, say, maybe the three of us are. As an example, when sending money, you know, kind of like a peer-to-peer basis, like, if I'm sending my mom a little bit of money, or she's sending me something, you're kind of within the family. Things that I would think would be kind of very easy and straightforward actually do cause her a little bit more concern. Okay, I'm entering my debit card number into this so that it can get, you know, the cash transferred into my bank account. You know, again, for me, it didn't even cross my mind, actually, that that would be something uncomfortable. But for my mom, that was something where she actually had some concerns about it and was messaging me. Her kind of personal point of view on that was, I would rather use a credit card for this and get the money on a credit card instead of a debit card because the debit card is linked to a bank account, and the security around that needs to be, you know, much tighter. And so, it made her more uncomfortable entering that on her phone. Whereas even a credit card it would have given her a little bit more peace of mind simply because it wasn't directly tied to her bank account. So, that's just, you know, the most recent example. I mean, honestly, that was earlier today, but it's something I hadn't thought of. And, again, for most of our customers, maybe that's not the case and how they think. But for folks that are at that retirement age, you know, in a world where there are constant barrages of scam, you know, emails, and phone calls, and text messages going around, the concern was definitely there. VICTORIA: That happened to me. Last week, I was on vacation with my family, and we needed to pay my mom for the house we'd rented. And I had to teach her how to use Zelle and set up Zelle. [laughter] It was a week-long process. But we got there, and it works [laughs] now. But yeah, it's interesting what concerns they have. And the funny part about it was that my sister-in-law happens to be, like, a lawyer who prevents class action lawsuits at a major bank. And she reassured us that it was, in fact, secure. [laughs] I think it's interesting thinking about that user experience for security. And I'm curious, again, like, compare again with the developer experience and using security toolings. And I wonder if you had any top recommendations on tools that make the developer experience a little more comfortable and feeling like you're deploying with security in mind. RISHI: That, in particular, is a bit of a hard question to answer. I try and stay away from specific vendors when it comes to that because I think a lot of it is contextual. But I could definitely talk through, like, some of the tools that I use and the way I like to think about it, especially from the developer perspective. I think, first off, consider what aspect of the software development, you know, lifecycle you're in. If you are an engineer writing, you know, mostly application code and dealing with building product and features and stuff like that, start from that angle. I could even take a step back and say security as an industry is very, very wide at this point. There is somebody trying to sell you a tool for basically every step in the SDLC process, and honestly, before and after to [inaudible 26:23]. I would even almost say it's, to some extent, kind of information and vendor overload in a lot of ways. So, I think what's important is to think about what your particular aspect of that is. Again, as an application engineer, or if you're building cloud infrastructure, or if you're an SRE, you know, or a platform team, kind of depending on what you are, your tooling will be different. The concepts are all kind of similar ideas, but how you go about what you build will be different. In general, I like to say, from the app side of things, A, start with considering the code you're writing. And that's a little bit cultural, but it's also kind of more training. Are you writing code with a security mindset? are you designing systems with a security mindset? These aren't things that are typically taught, you know, in school if you go get a CS degree, or even in a lot of companies in terms of the things that you should be thinking about. So, A, start from there. And if you don't feel like you think about, you know, is this design secure? Have we done, you know, threat modeling on it? Are we considering all of the error paths or the negative ways people can break the system? Then, start from that and start going through some of the security training that exists out there. And there's a lot of different aspects or avenues by which you can get that to be able to say, like, okay, I know I'm at least thinking about the code I write with a security mindset, even if you haven't actually changed anything about the code you're writing yet. What I actually think is really helpful for a lot of engineers is to have them try and break things. It's why I like to compete in CTFs, but it's also why I like to have my engineers do the same types of things. Trying to break software is both really insightful from the aspect that you don't get when you're just writing code and shipping it because it's not something you have time to do, but it's also a great way to build up some of the skills that you need to then protect against. And there's a lot of good, you know, cyber ranges out there. There's lots of good, just intentionally vulnerable applications that you can find on GitHub but that you can just run, you know, locally even on your machine and say, okay, now I have a little web app stood up. I know this is vulnerable. What do I do? How do I go and break it? Because then all of a sudden, the code that you're writing you start to think about a little bit differently. It's not just about how am I solving this product problem or this development problem? But it's, how am I doing this in a way that is safe and secure? Again, as an application side of things, you know, just make sure you know the OWASP Top 10 inside and out. Those are the most basic things a lot of engineers miss. And it only takes, again, one miss for it to be critical. So, start reviewing it. And then, you start to think about the tooling aspect of it. People are human. We're going to make mistakes. So, how do we use the power of technology to be able to stop this? You know, and there is static scanning tools. Like, there's a whole bunch of different ones out there. You know, Semgrep is a great one that's open source just to get started with that can help you find the vulnerable code that may exist there. Consider the SQL queries that you're writing, and most importantly, how you're writing them. You know, are you taking user input and just chucking it in there, or are you sanitizing it? When I ask these questions, for a lot of engineers, it's not usually yes or no. It's much more of an, well, I don't know. Because in software, we do a really good job of writing abstraction layers. But that also means, you know, to some extent, there may be a little bit of magic in there, or a lack thereof of magic that you don't necessarily know about. And so, you have to be able to dive into the libraries. You have to know what you're doing to even be able to say something like, oh no, this SQL query is safe from this user input because we have sanitized it. We have, you know, done a prepared statement, whatever it may be. Or, no, actually, we are just doing something here that's been vulnerable, and we didn't realize we were, and so now that's something we have to address. So, I think, like, that aspect in and of itself, which isn't, you know, a crazy ton of things. It's not spending a ton of money on different tools. But it's just internalizing the fact that you start to think a little bit differently. It provides a ton of value. The last thing on that, too, is to be able to say, especially if you're coming from a development side, or even just from a founder or a startup side of things, what are my big risks? What do I need to take care of first? What are the giant holes or flaws? You know, and what is my threat model around that? Obviously, as a bank, you have to care very deeply right from the start. You know, if you're not a bank, if you're not dealing with financial transactions, or PII, or anything like that, there are some things that you can deal with a little bit later. So, you have to know your industry, and you have to know what people are trying to do and the threat models and the threat vectors that can exist based on where you are. WILL: That's amazing. You know, earlier, we talked about you being an engineer for 20 years, different areas, and stuff like that. Do you have any advice for engineers that are starting out right now? And, you know, from probably year one to year, you know, anything under ten years of experience, do you have any advice that you usually give engineers when you're chatting with them? RISHI: The advice I tend to give people who are just starting out is be the type of person that asks, "How does this work?" Or "Why does this work?" And then do the work to figure out the answer. Maybe it is talking to someone; maybe it's diving into the details; maybe it's reading a book in some aspect that you haven't had much exposure to. When I look at my career and when I look at the careers of folks around me and the people that I've seen be most successful, both in engineering but also on the business side, that desire to know why something is the case is I think, one of the biggest things that determines success. And then the ability to answer that question by putting in the right types of work, the right types of scientific method and processes and such, are the other factor. So, to me, that's what I try and get across to people. I say that mostly to junior folks because I think when you're getting started, it's really difficult. There's a ton out there. And we've, again, as software engineers, and hardware engineers, and cloud, and all this kind of stuff, done a pretty good job of building a ton of abstraction layers. All of our abstraction layers [inaudible 32:28] to some degree. You know, so as you start, you know, writing a bunch of code, you start finding a bunch of bugs that you don't necessarily know how to solve and that don't make any sense in the avenue that you've been exposed to. But as soon as you get into the next layer, you understand how that works begin to make a lot more sense. So, I think being comfortable with saying, "I have no idea why this is the case, but I'm going to go find out," makes the biggest difference for people just starting out their career. WILL: I love that advice. Not too long ago, my manager encouraged me to write a blog post on something that I thought that I really knew. And when I started writing that blog post, I was like, oh boy, I have no idea. I know how to do it, but I don't know the why behind it. And so, I was very thankful that he encouraged me to write a blog post on it. Because once you start explaining it to other people, I feel you really have to know the whys. And so, I love that advice. That's really good advice. VICTORIA: Me too. And it makes sense with what we see statistically as well in the DORA research. The DevOps Research Association publishes a survey every year, the State of DevOps Report. And one of the biggest findings I remember from last year's was that the most secure and reliable systems have the most open communication and high trust among the teams. And so, being able to have that curiosity as a junior developer, you need to be in an environment where you can feel comfortable asking questions [laughs], and you can approach different people, and you're encouraged to make those connections and write blog posts like Will was saying. RISHI: Absolutely, absolutely. I think you touched on something very important there as well. The psychological safety really makes a big difference. And I think that's critical for, again, like, folks especially earlier in their career or have recently transitioned to tech, or whatever the case may be. Because asking "Why?" should be something that excites people, and there are companies where that's not necessarily the case, right? Where you asking why, it seems to be viewed as a sign that you don't know something, and therefore, you're not as good as what you should be, you know, the level you should be at or for whatever they expect. But I do think that's the wrong attitude. I think the more people ask why, the more people are able and comfortable to be able to say, "I don't know, but I'm going to go find out," and then being able to be successful with that makes way better systems. It makes way safer and more secure systems. And, honestly, I think it makes humans, in general, better humans because we can do that. VICTORIA: I think that's a great note to start to wrap up on. Is there any questions that you have for me or Will? RISHI: Yeah. I would love to hear from both of you as to what you see; with the experiences that you have and what you do, the biggest impediments or speed bumps are when it comes to developers being able to write and ship secure code. VICTORIA: When we're talking with new clients, it depends on where they are in really the adoption of their product and the maturity of their organization. Some early founders really have no technology experience. They have never managed an IT organization. You know, setting up basic employee account access and IDs is some of the initial steps you have to take to really get to where you can do identity management, and permissions management, and all the things that are really table stakes for security. And then others have some progress, and they have a fair amount of data. And maybe it's in that situation, like you said before, where it's really a trade-off between the cost and benefit of making those changes to a more secure, more best practice in the cloud or in their CI/CD pipeline or wherever it may be. And then, when you're a larger organization, and you have to make the trade-offs between all of that, and how it's impacting your developer experience, and how long are those deployed times now. And you might get fewer rates of errors and fewer rates of security vulnerabilities. But if it's taking three hours for your deployments to go out [laughs] because there's so many people, and there's so many checks to go through, then you have to consider where you can make some cuts and where there might be more efficiencies to be gained. So, it's really interesting. Everyone's on a different point in their journey. And starting with the basics, like you said, I love that you brought up the OWASP Top 10. We've been adopting the CIS Controls and just doing a basic internal security audit ourselves to get more ready and to be in a position where... What I'm familiar with as well from working in federal agencies, consulting, maintaining some of the older security frameworks can be a really high cost, not only in terms of auditing fees but what it impacts to your organization to, like, maintain those things [laughs] and the documentation required. And how do you do that in an agile way, in a way that really focuses on addressing the actual purpose of the requirements over needing to check a box? And how do we replicate that for our clients as well? RISHI: That is super helpful. And I think the checkbox aspect that you just discussed I think is key. It's a difficult position to be in when there are boxes that you have to check and don't necessarily actually add value when it comes to security or compliance or, you know, a decrease in risk for the company. And I think that one of the challenges industry-wide has always been that security and compliance in and of itself tends to move a little bit slower from a blue team or a protection perspective than the rest of the industry. And so, I mean, I can think of, you know, audits that I've been in where, you know, just even the fact that things were cloud-hosted just didn't make sense to the auditors. And it was a struggle to get them to understand that, you know, there is shared responsibility, and this kind of stuff exists, and AWS is taking care of some things, and we're taking care of some other things when they've just been developed with this on-premise kind of mentality. That is one of the big challenges that still exists kind of across the board is making sure that the security work that you're doing adds security value, adds business value. It isn't just checking the box for the sake of checking the box, even when that's sometimes necessary. VICTORIA: I am a pro box checker. RISHI: [laughs] VICTORIA: Like, I'll get the box checked. I'll use Trello and Confluence and any other tool besides Excel to do it, too. We'll make it happen with less pain, but I'd rather not do it [laughs] if we don't have to. RISHI: [laughs] VICTORIA: Let's make it easy. No, I love it. Is there anything else that you want to promote? RISHI: No, I don't think there's anything else I want to promote other than I'm going to go back to what I said just earlier, like, that culture. And if, you know, folks are out there and you have junior engineers, you have engineers that are asking "Why?", you have people that just want to do the right thing and get better, lean into that. Double down on those types of folks. Those are the ones that are going to make big differences in what you do as a business, and do what you can to help them out. I think that is something we don't see enough of in the industry still. And I would love for that to change. VICTORIA: I love that. Thank you so much, Rishi, for joining us. RISHI: Thanks for having me. This was a great conversation. I appreciate the time. VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. WILL: And you could find me on Twitter @will23larry. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Rishi Malik.

Guest: Isaac Hepworth, PM focused on Software Supply Chain Security @ Google Cooked questions: Why is everyone talking about SBOMs all of a sudden? Why does this matter to a typical security leader? Some software vendors don't want SBOM, and this reminds us of the food safety rules debates in the past, how does this analogy work here? One interesting challenge in the world of SBOMs and unintended consequences is that large well resourced organizations may be better equipped to produce SBOMs than small independent and open source projects. Is that a risk? Is the SBOM requirement setting the government up to be overly reliant on megacorps and are we going to unintentionally ban open source from the government?  What is the relationship between SBOM and software liability? Is SBOM a step to this? Won't software liability kill open source? How does Google prepare for EO internally; how do we use SBOM and other related tools? To come back to the food analogy, SBOMs are all well and good, but the goal is not that consumers know they're eating lead, but rather that our food becomes healthier. Where are we heading in the next five years to improve software supply chain "health and safety"? Resources: Full video of this episode (YouTube / LinkedIn) “Executive Order on Improving the Nation's Cybersecurity” “M-22-18 Memorandum For The Heads of Executive Departments and Agencies“ SLSA.dev  “How to SLSA Part 3 - Putting it all together” Assured Open Source Software NIST Secure Software Development Framework (SSDF) “Linking Up The Pieces: Software Supply Chain Security at Google and Beyond” (ep24) “2022 Accelerate State of DevOps Report and Software Supply Chain Security” (ep100)

Jon and Jay analyse the findings of Puppet's recent report on the state of DevOps and platform engineering. The pair discuss what they thought was lacking from the report, the difference between platform teams and platform engineering teams, and Jon finds an excuse to have a rant about the term 'cognitive load'.

Guest:  Brandon Evans, Infosec Consultant and Certified Instructor and Course Author at SANS Topics: What got you interested in security and motivated you to make this your area of focus? You came from a developer background, right? Occasionally, we hear the sentiment that “developers don't care about security,” how would you counter it (and would you?)? How do we encourage developers and operations to use the appropriate security controls and settings in the cloud? Is “encourage” the right word? Can we really do “secure by default” but for developers? What do you think are the main application security issues that developers need to deal with in the cloud? You mentioned software supply chain security, do you treat this as a part of application security? How important is this, realistically, for an average organization and its developers? Going to our favorite subject of threat detection, how do you think we can better encourage developers to supply the logs necessary for our detection and response teams to act upon? Resources: “Cloud Security: Making Cloud Environments a Safer Place” ebook by SANS SANS.org/cloud site “The Phoenix Project” book by Gene Kim et al “The Unicorn Project” book by Gene Kim “Next Special - Log4j Reflections, Software Dependencies and Open Source Security” (EP87) “2022 Accelerate State of DevOps Report and Software Supply Chain Security” (EP100) “Linking Up The Pieces: Software Supply Chain Security at Google and Beyond” (EP24)

This episode, I wanted to take a quick look at the 2022 edition of the State of DevOps Report. I've talked a number of times about the State of DevOps report. I originally introduced it back in episode 13, and last year I devoted seven episodes, 120-126, to a deep-dive into the 2021 edition. ----- Find this episodes show notes at: https://red-folder.com/podcasts/161 Have an idea for an episode topic, or want to see what is coming up: https://red-folder.com/podcasts/roadmap

Laura Maguire is a Researcher at Jeli.io, the first dedicated instant analysis platform that combines more comprehensive data to deliver more proactive solutions and identify problems. Victoria talks to Laura about incident management, giving companies a powerful tool to learn from their incidents, and what types of customers are ideal for taking on a platform like Jeli.io. Jeli.io (https://www.jeli.io/) Follow Jeli.io on Instagram (https://www.instagram.com/jeli_io/), Twitter (https://twitter.com/jeli_io) or LinkedIn (https://www.linkedin.com/company/jeli-inc/). Follow Laura Maguire on Twitter (https://twitter.com/LauraMDMaguire) or LinkedIn (https://www.linkedin.com/in/lauramaguire/). Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Transcript: VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Laura Maguire, Researcher at Jeli, the first dedicated instant analysis platform that combines more comprehensive data to deliver more proactive solutions and identify problems. Laura, thank you for joining me. LAURA: Thanks for having me, Victoria. VICTORIA: This might be a very introductory level question but just right off the bat, what is an incident? LAURA: What we find is a lot of companies define this very differently across the space, but typically, it's where they are seeing an impact, either a customer impact or a degradation of their service. This can be either formally, it kind of impacts their SLOs or their SLAs, or informally it's something that someone on the team notices or someone, you know, one of their users notice as being degraded performance or something not working as intended. VICTORIA: Gotcha. From my background being in IT operations, I'm familiar with incidents, and it's been a practice in IT for a long time. But what brought you to be a part of building this platform and creating a product around incidents? LAURA: I am a, let's say, recovering safety professional. VICTORIA: [chuckles] LAURA: I started my career in the safety and risk management realm within natural resource industries in the physical world. And so I worked with people who were at the sharp end in high-risk, high-consequence type work. And they were really navigating risk and navigating safety in the real world. And as I was working in this domain, I noticed that there was a delta between what was being said, created safety, and helped risk management and what I was actually seeing with the people that I was working with on the front lines. And so I started to pull the thread on this, and I thought, is work as done really the same as work as written or work as prescribed? And what I found was a whole field of research, a whole field of practice around thinking about safety and risk management in the world of cognitive work. And so this is how people think about risk, how they manage risk, and how do they interpret change and events in the world around them. And so as I started to do my master's degree in human factors and system safety and then later my Ph.D. in cognitive systems engineering, I realized that whether you are on the frontlines of a wildland fire or you're on the frontlines of responding to an incident in the software realm, the ways in which people detect, diagnose, and repair the issues that they're facing are quite similar in terms of the cognitive work. And so when I was starting my Ph.D. work, I was working with Dr. David Woods at the Cognitive Systems Engineering Lab at The Ohio State University. And I came into it, and I was thinking I'm going to work with astronauts, or with fighter pilots, or emergency room doctors, these really exciting domains. And he was like, "We're going to have you work with software engineers." And at first, I really failed to see the connection there, but as I started to learn more about site reliability engineering, about DevOps, about the continuous deployment, continuous integration world, I realized software engineers are really at the forefront of managing critical digital infrastructure. They're keeping up the systems that run society, both for recreation and pleasure in the sense of Netflix, for example, as well as the critical functions within society like our 911 call routing systems, our financial markets. And so the ability to study how software engineers detect outages, manage outages, and work together collaboratively across the team was really giving us a way to study this kind of work that could actually feed back into other types of domains like emergency response, like emergency rooms, and even back to the fighter pilots and astronauts. VICTORIA: Wow, that's so interesting. And so is your research that went into your Ph.D. did that help you help define the product strategy and kind of market fit for what you've been building at Jeli? LAURA: Yeah, absolutely. So Nora Jones, who is the founder and CEO of Jeli, reached out to me at a conference and told me a little bit about what she was thinking about, about how she wanted to support software engineers using a lot of this literature and a lot of the learnings from these other domains to build this product to help support incident management in software engineering. So we base a lot of our thinking around how to help support this cognitive work and how to help resilient performance in these very dynamic, these very changing large scale, you know, distributed software systems on this research, as well as the research that we do with our own users and with our own members from learning from incidents in software engineering Slack community that Nora and several other fairly prominent names within the software community started, Lorin Hochstein, John Allspaw Dr. Richard Cook, Jessica DeVita, Ryan Kitchens, and I may be missing someone else but...and myself, oh, Will Galego as well. Yeah, we based a lot of our understandings, really deep qualitative understandings of what is work like for software engineers when they're, you know, in continuous deployment type environments. And we've translated this into building a product that we think helps but not hinders by getting in the way of engineers while they're under time pressure and there's a lot of uncertainty. And there's often quite a bit of stress involved with responding to incidents. VICTORIA: Right. And you mentioned resilience engineering. And for those who don't know, David Woods, who you worked on with your Ph.D., wrote "Resilience Engineering: Concepts and Precepts." So maybe you could talk a little bit about resilience engineering and what that really means, not just in technology but in the people who were running the tools, right? LAURA: Yeah. So resilience engineering is different from how we think about protecting and defending our software systems. And it's different in the sense that we aren't just thinking about how do we prevent incidents from happening again, like, how do we fix things that have happened to us in the past? But how do we better understand the ways in which our systems operate under a wide variety of conditions? So that includes normal operating conditions as well as abnormal or anomalous operating conditions, such as an incident response. And so resilience engineering was kind of this way of thinking differently about predicting failure, about managing failure, and navigating these kinds of worlds. And one of the fundamental differences about it is it sees people as being the most adaptive component within the system of work. So we can have really good processes and practices around deploying code; we can institute things like cross-checking and peer review of code; we can have really good robust backup and failover systems, but ultimately, it's very likely that in these kinds of complex and adaptive always-changing systems that you're going to encounter problems that you weren't able to anticipate. And so this is where the resilience part comes in because if you're faced with a novel problem, if you're faced with an issue you've never seen before, or a hidden dependency within your system, or an unanticipated failure mode, you have to adapt. You have to be able to take all of the information that's available to you in the moment. You have to interpret that in real-time. You have to think of who else might have skills, knowledge, expertise, access to information, or access to certain kinds of systems or software components. And you have to bring all of those people together in real-time to be able to manage the problem at hand. And so this is really quite a different way of thinking about supporting this work than just let's keep the runbooks updated, and let's make sure that we can write prescriptive processes for everything that we're going to encounter. Because this really is the difference that I saw when I was talking about earlier about that work is done versus work is prescribed. The rules don't cover all of the situations. And so you have to think of how do you help people adapt? How do you help people access information in real-time to be able to handle unforeseen failures? VICTORIA: Right. That makes a lot of sense. It's an interesting evolution of site reliability engineering where you're thinking about the users' experience of your site. It's also thinking about the people who are running your site and what their experience is, and what freedom they have to be able to solve the problems that you wouldn't be able to predict, right? LAURA: Yeah, it's a really good point, actually, because there is sort of this double layer in the product that we are building. So, as you mentioned earlier, we are an incident analysis platform, and so what does that mean? Well, it means that we pull in data whenever there's been an incident, and we help you to look at it a little bit more deeply than you may if you're just following a template and sort of reconstructing a timeline. And so we pull in the actual Slack data that, you know, say, an ops channel or an incident channel that's been spun up following a report of a degraded performance or of an outage. And we look very closely at how did people talk to one another? Who did they bring into the incident? What kinds of things did they think were relevant and important at different points in time? And in doing this, it helps us to understand what information was available to people at different points in time. Because after the incident and after it's been resolved, people often look back and say, "Oh, there's nothing we can learn from that. We figured out what it was." But if we go back and we start looking at how people detected it, how they diagnosed it, who they brought into the event, we can start to unpack these patterns and these ways of understanding how do people work together? What information is useful at different points in time? Which helps us get a deeper understanding of how our systems actually work and how they actually fail. VICTORIA: Right. And I see there are a few different ways the platform does that: there's a narrative builder, a people view, and also a visual timeline. So, do you find that combining all those things together really gives companies a powerful tool to learn from their incidents? LAURA: Yeah. So let me talk a little bit about each of those different components. Our MVP of the product we started out with this understanding of the incident analyst and the incident investigator who, you know, was ready to dive in and ready to understand their incident and apply some qualitative analysis techniques to thinking about their incidents. And what we found was there are a number of these people who are really interested in this deep dive within the software industry. But there's a broader subset of folks that they work with who maybe only do these kinds of incident analysis every once in a while, and they're not as interested in going quite as deep. And so the narrative builder is really this kind of bridge between those two types of users. And what it does is helps construct a timeline which is typically what most companies do to help drive the discussion that they might have in a post-mortem or to drive their kind of findings in their summary report. And it helps them take this closer look at the interactions that happened in that slack transcript and raise questions about what kinds of uncertainties there were, point out who was involved, or interesting aspects of the event at that point in time. And it helps them to summarize what was happening. What did people think was happening at this point in time to create this story about the incident? And the story element is really important because we all learn from stories. It helps bring to life some of the details about what was hard, who was involved, how did they get brought in, what the sources of technical failure were, and whether those were easy or difficult to understand and to repair once the source of the failure was actually understood. And so that narrative builder helps reconstruct this timeline in a much richer way but also do it very efficiently. And as you mentioned, the visual timeline is something that we've created to help that lightweight user or that every once in a while user to go a little bit deeper on their analysis. And how we do that is because it lays out the progression of the event in a way that helps you see, oh, this maybe wasn't straightforward. We didn't detect it in the beginning, and then diagnose it, and then repair it at the end. What happened actually was the detection was intermittent. The signals about what was going wrong was intermittent, and so that was going on in parallel with the diagnosis. The diagnosis took a really long time, and that may have been because we can also see the repair was happening concurrently. And so it starts to show these kinds of characteristics about whether the incident was difficult, whether it was challenging and hard, or whether it was simple and straightforward. This helps lend a bit more depth to metrics like MTTR and TTD by saying, oh, there was a lot more going on in this incident than we initially thought. The last thing that you mentioned was the people view, and so that really sets our product apart from other products in that we look at the sociotechnical system. So it's not just about the software that broke; it is about who was involved in managing that system, in repairing that system, and in communicating about that system outwardly. And so the people view this kind of pulls in some HR data. It helps us to understand who was involved. How long have they been in their role? Were they on-call? Were they not on-call? And other kinds of irrelevant details that show us what was their engagement or their interaction with this event. And so when we start to bring in the socio part of the sociotechnical system, we can identify things like what knowledge do we have within the organization? Is that knowledge well-distributed, or is it just isolated in one or two people? And so those people are constantly getting pulled into incidents when they may be not on-call, which can start to show us whether or not these folks are in danger of burning out or whether their knowledge might need to be transferred more broadly throughout the organization. So this is kind of where the resilience piece comes in because it helps us to distribute knowledge. It helps us to identify who is relevant and useful and how do they partner and collaborate with other people, and their knowledge and skill sets to be able to manage some of the outages that they face? VICTORIA: That's wonderful because one of my follow-up questions would be, as a CEO, as a founder, what kind of insights or choices do you get to make now that you have this insight to help make your team more resilient? [laughs] LAURA: So if this is a manager, or a founder, or a CEO that is looking at their data in Jeli, they can start to understand how to resource their teams more appropriately, as I mentioned, how to spread that knowledge around. They can start to see what parts of their system are creating the most problems or what parts of their system do they have maybe less insight into how it works, how it interacts with other parts of the system, and what this actually means for their ability to meet their SLOs or their SLAs. So it gives you a more in-depth understanding of how your business is actually operating on both the technical side of things, as well as on the people side of things. VICTORIA: That makes a lot of sense. Thank you for that overview of the platform. There's the incident analysis platform, and you also have the bot, the response chatbot. Can you tell me a little bit more about that? LAURA: Yeah, absolutely. We think that incident management should be conducted wherever your work actually takes place, and so for most of our customers and a lot of folks that we know about in the industry, that's Slack. And so, if you are communicating in real-time with your team in Slack, we think that you should stay there. And so, we built this incident management bot that is free and will be free for the lifetime of the product. Because we think that this is really the fundamental basis for helping you manage your incidents more efficiently and more effectively. So it's a pretty lightweight bot. It gives kind of some guardrails or some guidance around collaboration by spinning up a new incident channel, helping you to bring the right kinds of responders into that, helping you to communicate to interested stakeholders by broadcasting to channels they might be in. It kind of nudges you to think about how to communicate about what's happening during different stages of the event progression. And so it's prompting you in a very lightweight way; hey, do you have a status update? Do you have a summary of what the current thinking is? What are the hypotheses about what's going on? Who's conducting what kinds of activities right now? So that if I'm a responder that's coming into the event after 20-30 minutes after it started, I can very quickly come up to speed, understand what's going on, who's doing what, and figure out what's useful for me to do to help step in and not disrupt the incident management that's underway right now. Our users can choose to use the bot independently of the incident analysis platform. But of course, being able to ingest that incident into Jeli it helps you understand who's been involved in the incident, if they've been involved in similar incidents in the past, and helps them start to see some patterns and some themes that emerge over time when you start to look at incidents across the organization. VICTORIA: That makes sense. And I love that it's free and that there's something for every type of organization to take advantage of there. And I wonder if at Jeli you have data about what type of customer is it who'd be targeted or really ideal to take on this kind of platform. LAURA: So most organizations...I was actually recently at SREcon EMEA, and there was a really interesting series of talks; one was SRE for Enterprise, and the next talk was SRE for Startups. And so it was a very thought-provoking discussion around is SRE for everyone, so site reliability engineering? Even smaller teams are starting to have to be responsible for reliability and responsible for running their service. And so we kind of have built our platform thinking about how do we help not just big enterprises or organizations that may have dedicated teams for this but also small startups to learn from their incidents. So internally, we actually call incidents opportunities as in they are learning opportunities for checking out how does your system actually work? How do your people work together? What things were difficult and challenging about the incident? And how do you talk about those things as a team to help create more resilient performance in future? So in terms of an ideal customer, it's really folks that are interested in conducting these sort of lightweight but in-depth looks at how their system actually works on both the people side of things and the technical side of things. Those who we found are most successful with our product are interested in not so much figuring out who did the thing and who can they blame for the incident itself but rather how do they learn from what happened? And would another engineer, or another product owner, another customer service representative, whoever the incident may be sort of focused around, would another person in their shoes have taken the same actions that they took or made the same decisions that they made? Which helps us understand from a systems level how do we repair or how do we adjust the system of work surrounding folks so that they are better supported when they're faced with uncertainty, or with that kind of time pressure, or that ambiguity about what's actually going on? VICTORIA: And I love that you said that because part of the reason [laughs] I invited you on to the podcast is that a lot of companies I have experience with don't think about incidents until it happens to them, and then it can be a scramble. It can impact their customer base. It can stress their team out. But if you go about creating...the term obviously you all use is psychological safety on your team, and maybe you use some of the free tools from Jeli like the Post-Incident Guide and the Incident Analysis 101 blog to set your team up for success from the beginning, then you can increase your customer loyalty and your team loyalty as well to the company. Is that your experience? LAURA: Yeah, absolutely. So one thing that I have learned throughout my career, you know, starting way back in forestry and looking at safety and risk in that domain, was as soon as there is an accident or even a serious near miss, right away, everybody gets sweaty palms. Everybody is concerned about, uh-oh, am I going to get blamed for this? Am I going to get fired? Am I going to get publicly shamed for the decisions that I made when I was in this situation? And what that response, that reaction does is it drives a lot of the communication and a lot of the understanding of the conditions that that person was in. It drives that underground. And it's important to allow people to talk about here's what I was seeing, here's what I was experiencing because, in these kinds of complex systems, information is not readily available to people. The signals are not always coming through loud and clear about what's going on or about what the appropriate actions to take are. Instead, it's messy; it's loud, it's noisy. There are usually multiple different demands on that person's attention and on their time, and they're often managing trade-offs: do I keep the system down so that I can gather more information about what's actually going on, or do I just try and bring it up as quickly as I can so that there's less impact to users? Those kinds of decisions are having to be made under pressure. So when we create these conditions of psychological safety, when we say you know what? This happened. We want to learn from it. We've already made this investment. Richard Cook mentioned in the very first SNAFU Catchers Report, which was a report that came out of Ohio State, that incidents are unplanned investments into understanding how your system works. And so you've already had the incident. You've already paid the price of that downtime or of that outage. So you might as well extract some learning from it so that you can help create a safer and more resilient system in the future. So by helping people to reconstruct what was actually happening in real-time, not what they were retrospectively saying, "Oh, I should have done this," well, you didn't do that. So let's understand why you thought at that moment in time that was the right way to respond because, more than likely, other people in that same position would have made that same choice. And so it helps us to think more broadly about ways that we can support decision-making and sense-making under conditions of stress and uncertainty. And ultimately, that helps your system be more resilient and be more reliable for your customers. VICTORIA: What a great reframing: unplanned investment. [laughs] And if you don't learn from it, then you're going to lose out on what you've already invested that time in resolving it, right? LAURA: Absolutely. MID-ROLL AD: Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you're tight on time and investment, which is why we've created targeted 1-hour remote workshops to help you develop a concrete plan for your product's next steps. Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. Find out how we can help you move the needle at: tbot.io/entrepreneurs. VICTORIA: Getting more into that psychological safety and how to create that culture where people feel safe telling about what really happened, but how does that relate to...Jeli says that they are a people software. [laughs] Talk to me more about that. Like, what advice do you give founders and CEOs on how to create that psychological safety which makes them be more resilient in these types of incidents? LAURA: So you mentioned the Howie Guide that we published last year, and this is our guidance around how to do incident analysis, how to help your team start to learn from their incidents, and Howie stands for how we got here. And that's really important, that language because what it says is there's a history that led up to this incident. And most teams, when they've had an outage, they'll kind of look backwards from that outage, maybe an hour, maybe a day, maybe to the last deploy. But they don't think about how the decisions got made to use that piece of software in the first place. They don't think about how did engineers actually get on-boarded to being on-call. They don't necessarily think about what kinds of skills, and knowledge, and expertise when we're hiring a DevOps engineer, and I'm using air quotes here or an SRE. What kinds of skills and knowledge do they actually have? Those are very broad terms. And what it means to be a DevOps engineer or an SRE is quite underspecified. And so the knowledge behind the folks that you might hire into the company is going to necessarily be very diverse. It's going to be partial and incomplete in many ways because not everyone can know everything about the system. And so, we need to have multiple diverse perspectives about how the system works, how our customers use that system, what kinds of pressures and constraints exist within our company that allow us some possibilities over others. We need to bring all of those perspectives together to get a more reflective picture of what was actually happening before this incident took place and how we actually got here. This reframing helps a lot of people disarm that initial defensiveness response or that initial, oh, shoot; I'm going to get in trouble for this kind of response. And it says to them, "Hey, you're a part of this bigger system of work. You are only one piece of this puzzle. And what we want to try and do is understand what was happening within the company, not just what you did, what you said, and what you decided." So once people realize that you're not just trying to find fault or place blame, but you're really trying to understand their work, and you're trying to understand their work with other teams and other vendors, and trying to understand their work relative to the competing demands that were going on, so those are some of the things that help create psychological safety. About ten years ago, John Allspaw and the team at Etsy put out The Etsy Debriefing Facilitation Guide, which also poses a number of questions and helps to frame the post-incident learnings in a way that moves it from the individual and looks more collectively at the company as a whole. And so these things are helpful for founders or for CEOs to help bring forward more information about what's really going on, more information about what are the real risks and threats and opportunities within the company, and gives you an opportunity to step back and do what we call microlearning, which is sharing knowledge about how the system works, sharing understandings of what people think is going on, and what people know about the system. We don't typically talk about those things unless there's a reason to, and incidents kind of give us that reason because they're uncomfortable and they can be painful. They can be very public. They can be very disruptive to what we think about how resilient and reliable we actually are. And so if you can kind of step away from this defensiveness and step away from this need to place blame and instead try and understand the conditions, you will get a lot more learning and a lot more resilience and reliability out of your teams and out of your systems. VICTORIA: That makes sense to me. And I'd like to draw a connection between that and some other things you mentioned with The 2022 Accelerate State of DevOps Report that highlights that the people who are often responding to those incidents or in that high-stress situation tend to be historically underrepresented or historically excluded groups. And so do you see that having this insight into both who is actually taking on a lot of the work when these incidents happen and creating that psychological safety can make a better environment for diversity, equity, inclusion at a company as well? LAURA: Well, I think anytime you work to establish trust and transparency, and you focus on recognizing the skills that people do have, the knowledge that they do have, and not over assuming that someone knows something or that they have been involved in the discussions that may have been relevant to an incident, anytime you focus on that trust and transparency you are really signaling to people within your organization that you value their contributions and that you recognize that they've come to work and trying to do a good job. But they have multiple competing demands on their attention and on their time. And so we're not making assumptions about people being complacent, or people being reckless or being sloppy in their work. So that creates an environment where people feel more willing to speak up and to talk about some of the challenges that they might face, to talk about the ways in which it's not clear to them how certain parts of the system work or how certain teams actually operate. So you're just opening the channels for communication, which helps to share more knowledge. It helps to share more information about what teams are doing at different points in time. And this helps people to preemptively anticipate how a change that they might be making in their part of the system could be influencing up or downstream teams. And so this helps create more resilience because now you're thinking laterally about your system and about your involvement across teams and across boundary lines. And an example of this is if a marketing team...this is a story that Nora tells quite a bit; if a marketing team is, say, launching a Super Bowl commercial for their company but they don't actually tell the engineers on-call that that is about to happen, you can create all sorts of breakdowns when all of a sudden you have this surge of traffic to your website because people see the Super Bowl commercial and they want to go to the site. And then you have a single person who's trying to respond to that in real-time. So, instead, when you do start thinking about that trust and transparency, you're helping teams to help each other and to think more broadly about how their work is actually impacting other parts of the system. So from a diversity and inclusion and underrepresented groups perspective, this is creating the conditions for more people to be involved, more people to feel like their voice is going to be heard, and that their perspective actually matters. VICTORIA: That sounds really powerful, and I'm glad we were able to touch on that. Shifting gears a little bit, I wanted to talk about two different questions; so one is if you could travel back in time to when Jeli first started, what advice would you give yourself, your past self? LAURA: I would encourage myself to recognize that our ability to experiment is fundamental to our ability to learn. And learning is what helps us to iterate faster. Learning is what helps us to reflect on the tool that we're building or the feature that we're building and what this actually means to our users. I actually copped that advice to myself from CEO Zoran Perkov of the Long-Term Stock Exchange. They launched a whole new stock market during the pandemic with a fully remote team. And I had interviewed him for an article that I wrote about resilient leadership. And he said to me, like, "My job as a CEO is 100% about protecting our ability to experiment as a company because if we stop learning, we're not going to be able to iterate. We're not going to be able to adapt to the changes that we see in the market and in our users." So I think I would tell myself to continually experiment. One of the things that I talk to our customers about a lot because many of them are implementing new incident management programs or they're trying to level up their engineering teams around incident analysis, and I would say, "This doesn't have to be a fully-fleshed out program where you know all of the ways in which this is going to unfold." It's really about trying experiments, conduct some training, start small. Do one incident analysis on a really particularly spicy incident that you may have had or a really challenging incident where a lot of people were surprised by what happened. Bring together that group and say, "Hey, we're going to try something a little bit different here. We'll use some questions from the Howie Guide. We'll use the format and the structure from the Etsy Debriefing Guide. And we're just going to try and learn what we can about this event. We're not going to try and place blame. We're not going to try and generate corrective actions. We just want to see what we can learn from this." Then ask people that were involved, "How did this go? What did we learn from it? What should we do differently next time?" And continually iterate on those small, little experiments so that you can grow your product and grow your team's capacity. I think it took us a little bit of time to figure that out within the organization, but once we did, we were just able to collaborate more effectively work more effectively by integrating some of the feedback that we were getting from our users. And then the last piece of advice that I would give myself is to really invest in cross-discipline coordination and collaboration. Engineers, designers, researchers, CEOs they all have a different view of the product. They all have a different understanding of what the goals and priorities are. And those mental models of the product and of what the right thing to do is are constantly changing. And they all have different language that they use to talk about the product and to talk about their processes for integrating this understanding of the changing conditions and the changing user into the product. And so I would say invest in establishing common ground across the different disciplines within your team to be able to talk about what people are seeing, to be able to stop and identify when we're making assumptions about what other people know or what other people's orientation towards the problem or towards the product are. And spend a little bit of time saying, "When I say this is important, I'm saying it's important because of XYZ, not just this is important." So spending a little bit of time elaborating on what your mental model is and where you're drawing from can help the teams work more effectively together across those disciplines. VICTORIA: That's pretty powerful advice. You're iterating and experimenting at Jeli. What's on the horizon that you are...what new experiments are you excited about? LAURA: One of the things that has been front and center for us since we started is this idea of cross-incident analysis. And so we've kind of built out a number of different features within the product, being able to help tag the incident with the relevant services and technologies that were involved, being able to identify which teams were involved, and also being able to identify different kinds of themes or patterns that emerge from individual incidents. So all of this data that we can get from mostly just from the ingested incident itself or from the incident that you bring into Jeli but also from the analysis that you do on it this helps us start to be able to see across incidents what's happening not just with the technical side of things. So is it always Travis that is causing a problem? Are there components that work together that kind of have these really hidden and strange interdependencies that are really hard for the team to actually cope with? What kinds of themes are emerging across your suite of opportunities, your suite of incidents that you've ingested? Some of the things that we're starting to see from those experiments is an ability to look at where are your knowledge islands within your organization? Do you have an engineer who, if they were to leave, would take the majority of your systems knowledge about your database, or about your users, or about some critical aspect of your system that would disappear with all of that tacit knowledge? Or are there engineers that work really effectively together during really difficult incidents? And so you can start to unpack what are these characteristics of these people, and of these teams, and of these technologies that offer both opportunities or threats to your organization? So basically, what we're doing is we're helping you to see how your system performs under different kinds of conditions, which I think as a safety and risk professional working in a variety of different domains for the last 15 years, I think this is really where the rubber hits the road in helping teams be more reliable, and be more resilient, and more proactive about where investments in maintenance, or training, or headcount are going to have the biggest bang for your buck. VICTORIA: That makes a lot of sense. In my experience, sometimes those decisions are made more on intuition or on limited data so having a more full picture to rely on probably produces better results. [laughs] LAURA: Yeah, and I think that we all want to be data-driven, thinking about not only the quantitative data is how many incidents do we have around certain parts of the system, or certain teams, or certain services? But also, the qualitative side of things is what does this actually mean? And what does this mean to our ability to grow and change over time and to scale? The partnership of that quantitative data and qualitative data means we're being data-driven on a whole other level. VICTORIA: Wonderful. And it seems like we're getting close to the end of our time here. Is there anything else you want to give as a final takeaway to our listeners? LAURA: Yeah. So I think that we are, you know, as a domain, as a field, software engineering is increasingly becoming responsible for not only critical infrastructure within society, but we have a responsibility to our users and to each other within our companies to help make work better, help make our services more reliable and more resilient over time. And there's a variety of lessons that we can learn from other domains. As I mentioned before, aviation, healthcare, nuclear power all of those kinds of domains have been thinking about supporting cognitive work and supporting frontline operators. And we can learn from this history and this literature that exists out there. There is a GitHub repo that Lorin Hochstein has curated with a number of other folks with the industry that points to some of these resources. And as well, we'll be hosting the first Learning From Incidents in Software Engineering Conference in Denver in February, February 15 and 16th. And one feature of this conference that I'm super excited about is affectionately called CasesConf. And it is going to be an opportunity for software engineers from a variety of organizations to tell real stories about incidents that they had, how they handled them, what was challenging, what went surprisingly well, and just what is actually going on within their organizations. And this is kind of a new thing for the software industry to be talking very publicly about failures and sharing the messy details of our incidents. This won't be a recorded part of the conference. It is going to be conducted under the Chatham House Rule, which is participants who are in the room while these stories are being told can share some of the stories but not any identifying details about the company or the engineers that were involved. And so this kind of real-world situations helps us to, as I talked about before, with that psychological safety, helps us to say this is the reality of operating complex systems. They're going to fail. We're going to have to learn from them. And the more that we can talk at an industry level about what's going on and about what kinds of things are creating problems or opportunities for each other, the more we're going to be able to lift the bar for the industry as a whole. So you can check out register.learningfromincidents.io for more information about the conference. And we can link Lorin's resilience engineering GitHub repo in the notes as well. VICTORIA: Wonderful. Well, I was looking for an excuse to come to Denver in February anyways. LAURA: We would love to have ya. VICTORIA: Thank you. And thank you so much for taking time to share with us today, Laura. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Laura Maguire.

About GeneGene Kim is a multiple award-winning CTO, researcher and author, and has been studying high-performing technology organizations since 1999. He was founder and CTO of Tripwire for 13 years. He has written six books, including The Unicorn Project (2019), The Phoenix Project (2013), The DevOps Handbook (2016), the Shingo Publication Award winning Accelerate (2018), and The Visible Ops Handbook (2004-2006) series. Since 2014, he has been the founder and organizer of DevOps Enterprise Summit, studying the technology transformations of large, complex organizations.Links: The Phoenix Project: https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/1942788290/ The Unicorn Project: https://www.amazon.com/Unicorn-Project-Developers-Disruption-Thriving/dp/B0812C82T9 The DevOps Enterprise Summit: https://events.itrevolution.com/ @RealGeneKim TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Cloud Economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: If you asked me to rank which cloud provider has the best developer experience, I'd be hard-pressed to choose a platform that isn't Google Cloud. Their developer experience is unparalleled and, in the early stages of building something great, that translates directly into velocity. Try it yourself with the Google for Startups Cloud Program over at cloud.google.com/startup. It'll give you up to $100k a year for each of the first two years in Google Cloud credits for companies that range from bootstrapped all the way on up to Series A. Go build something, and then tell me about it. My thanks to Google Cloud for sponsoring this ridiculous podcast.Corey: This episode is brought to us by our friends at Pinecone. They believe that all anyone really wants is to be understood, and that includes your users. AI models combined with the Pinecone vector database let your applications understand and act on what your users want… without making them spell it out. Make your search application find results by meaning instead of just keywords, your personalization system make picks based on relevance instead of just tags, and your security applications match threats by resemblance instead of just regular expressions. Pinecone provides the cloud infrastructure that makes this easy, fast, and scalable. Thanks to my friends at Pinecone for sponsoring this episode. Visit Pinecone.io to understand more.Corey Quinn: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by a man who needs no introduction but gets one anyway. Gene Kim, most famously known for writing The Phoenix Project, but now the Wall Street Journal best-selling author of The Unicorn Project, six years later. Gene, welcome to the show.Gene Kim: Corey so great to be on. I was just mentioning before how delightful it is to be on the other side of the podcast. And it's so much smaller in here than I had thought it would be.Corey Quinn: Excellent. It's always nice to wind up finally meeting people whose work was seminal and foundational. Once upon a time, when I was a young, angry Unix systems administrator—because it's not like there's a second type of Unix administrator—[laughing] The Phoenix Project was one of those texts that was transformational, as far as changing the way I tended to view a lot of what I was working on and gave a glimpse into what could have been a realistic outcome for the world, or the company I was at, but somehow was simultaneously uplifting and incredibly depressing all at the same time. Now, The Unicorn Project does that exact same thing only aimed at developers instead of traditional crusty ops folks.Gene Kim: [laughing] Yeah, yeah. Very much so. Yeah, The Phoenix Project was very much aimed at ops leadership. So, Bill Palmer, the protagonist of that book was the VP of Operations at Parts Unlimited, and the protagonist in The Unicorn Project is Maxine Chambers, Senior Architect, and Developer, and I love the fact that it's told in the same timeline as The Phoenix Project, and in the first scene, she is unfairly blamed for causing the payroll outage and is exiled to The Phoenix Project, where she recoils in existential horror and then finds that she can't do anything herself. She can't do a build, she can't run her own tests. She can't, God forbid, do her own deploys. And I just love the opening third of the book where it really does paint that tundra that many developers find themselves in where they're just caught in decades of built-up technical debt, unable to do even the simplest things independently, let alone be able to independently develop tests or create value for customers. So, it was fun, very much fun, to revisit the Parts Unlimited universe.Corey Quinn: What I found that was fun about—there are few things in there I want to unpack. The first is that it really was the, shall we say, retelling of the same story in, quote/unquote, “the same timeframe”, but these books were written six years apart.Gene Kim: Yeah, and by the way, I want to first acknowledge all the help that you gave me during the editing process. Some of your comments are just so spot on with exactly the feedback I needed at the time and led to the most significant lift to jam a whole bunch of changes in it right before it got turned over to production. Yeah, so The Phoenix Project is told, quote, “in the present day,” and in the same way, The Unicorn Project is also told—takes place in the present day. In fact, they even start, plus or minus, on the same day. And there is a little bit of suspension of disbelief needed, just because there are certain things that are in the common vernacular, very much in zeitgeist now, that weren't six years ago, like “digital disruption”, even things like Uber and Lyft that feature prominently in the book that were just never mentioned in The Phoenix Project, but yeah, I think it was the story very much told in the same vein as like Ender's Shadow, where it takes place in the same timeline, but from a different perspective.Corey Quinn: So, something else that—again, I understand it's an allegory, and trying to tell an allegorical story while also working it into the form of a fictional work is incredibly complicated. That's something that I don't think people can really appreciate until they've tried to do something like it. But I still found myself, at various times, reading through the book and wondering, asking myself questions that, I guess, say more about me than they do about anyone else. But it's, “Wow, she's at a company that is pretty much scapegoating her and blaming her for all of us. Why isn't she quitting? Why isn't she screaming at people? Why isn't she punching the boss right in their stupid, condescending face and storming out of the office?” And I'm wondering how much of that is my own challenges as far as how life goes, as well as how much of it is just there for, I guess, narrative devices. It needed to wind up being someone who would not storm out when push came to shove.Gene Kim: But yeah, I think she actually does the last of the third thing that you mentioned where she does slam the sheet of paper down and say, “Man, you said the outage is caused by a technical failure and a human error, and now you're telling me I'm the human error?” And just cannot believe that she's been put in that position. Yeah, so thanks to your feedback and the others, she actually does shop her resume around. And starts putting out feelers, because this is no longer feeling like the great place to work that attracted her, eight years prior. The reality is for most people, is that it's sometimes difficult to get a new job overnight, even if you want to. But I think that Maxine stays because she believes in the mission. She takes a great deal of pride of what she's created over the years, and I think like most great brands, they do create a sense of mission and there's a deep sense of the customers they serve. And, there's something very satisfying about the work to her. And yeah, I think she is very much, for a couple of weeks, very much always thinking about, she won't be here for long, one way or another, but by the time she stumbles into the rebellion, the crazy group of misfits, the ragtag bunch of misfits, who are trying to find better ways of working and willing to break whatever rules it takes to take over the very ancient powerful order, she falls in love with a group. She found a group of kindred spirits who very much, like her, believe that developer productivity is one of the most important things that we can do as an organization. So, by the time that she looks up with that group, I mean, I think she's all thoughts of leaving are gone.Corey Quinn: Right. And the idea of, if you stick around, you can theoretically change things for the better is extraordinarily compelling. The challenge I've seen is that as I navigate the world, I've met a number of very gifted employees who, frankly wind up demonstrating that same level of loyalty and same kind of loyalty to companies that are absolutely not worthy of them. So my question has always been, when do I stick around versus when do I leave? I'm very far on the bailout as early as humanly possible side of that spectrum. It's why I'm a great consultant but an absolutely terrible employee.Gene Kim: [laughing] Well, so we were honored to have you at the DevOps Enterprise Summit. And you've probably seen that The Unicorn Project book is really dedicated to the achievements of the DevOps Enterprise community. It's certainly inspired by and dedicated to their efforts. And I think what was so inspirational to me were all these courageous leaders who are—they know what the mission is. I mean, they viscerally understand what the mission is and understand that the ways of working aren't working so well and are doing whatever they can to create better ways of working that are safer, faster, and happier. And I think what is so magnificent about so many of their journeys is that their organization in response says, “Thank you. That's amazing. Can we put you in a position of even more authority that will allow you to even make a more material, more impactful contribution to the organization?” And so it's been my observation, having run the conference for, now, six years, going on seven years is that this is a population that is being out promoted—has been promoted at a rate far higher than the population at large. And so for me, that's just an incredible story of grit and determination. And so yeah, where does grit and determination becomes sort of blind loyalty? That's ultimately self-punishing? That's a deep question that I've never really studied. But I certainly do understand that there is a time when no amount of perseverance and grit will get from here to there, and that's a fact.Corey Quinn: I think that it's a really interesting narrative, just to see it, how it tends to evolve, but also, I guess, for lack of a better term, and please don't hold this against me, it seems in many ways to speak to a very academic perspective, and I don't mean that as an insult. Now, the real interesting question is why I would think, well—why would accusing someone of being academic ever be considered as an insult, but my academic career was fascinating. It feels like it aligns very well with The Five Ideals, which is something that you have been talking about significantly for a long time. And in an academic setting that seems to make sense, but I don't see it thought of or spoken of in the same way on the ground. So first, can you start off by giving us an intro to what The Five Ideals are, and I guess maybe disambiguate the theory from the practice?Gene Kim: Oh for sure, yeah. So The Five Ideals are— oh, let's go back one step. So The Phoenix Project had The Three Ways, which were the principles for which you can derive all the observed DevOps practices from and The Four Types of Work. And so in The Five Ideals I used the concept of The Five Ideals and they are—the first—Corey Quinn: And the next version of The Nine whatever you call them at that point, I'm sure. It's a geometric progression.Gene Kim: Right or actually, isn't it the pri—oh, no. four isn't, four isn't prime. Yeah, yeah, I don't know. So, The Five Ideals is a nice small number and it was just really meant to verbalize things that I thought were very important, things I just gravitate towards. One is Locality and Simplicity. And briefly, that's just, to what degree can teams do what they need to do independently without having to coordinate, communicate, prioritize, sequence, marshal, deconflict, with scores of other teams. The Second Ideal is what I think the outcomes are when you have that, which is Focus, Flow and Joy. And so, Dr. Mihaly Csikszentmihalyi, he describes flow as a state when we are so engrossed in the work we love that we lose track of time and even sense of self. And that's been very much my experience, coding ever since I learned Clojure, this functional programming language. Third Ideal is Improvement of Daily Work, which shows up in The Phoenix Project to say that improvement daily work is even more important than daily work itself. Fourth Ideal is Psychological Safety, which shows up in the State of DevOps Report, but showed up prominently in Google's Project Oxygen, and even in the Toyota production process where clearly it has to be—in order for someone to pull the andon cord that potentially stops the assembly line, you have to have an environment where it's psychologically safe to do so. And then Fifth Ideal is Customer Focus, really focus on core competencies that create enduring, durable business value that customers are willing to pay for, versus context, which is everything else. And yeah, to answer your question, Where did it come from? Why do I think it is important? Why do I focus on that? For me, it's really coming from the State of DevOps Report, that I did with Dr. Nicole Forsgren and Jez Humble. And so, beyond all the numbers and the metrics and the technical practices and the architectural practices and the cultural norms, for me, what that really tells the story of is of The Five Ideals, as to what one of them is very much a need for architecture that allows teams to work independently, having a higher predictor of even, continuous delivery. I love that. And that from the individual perspective, the ideal being, that allows us to focus on the work we want to do to help achieve the mission with a sense of flow and joy. And then really elevating the notion that greatness isn't free, we need to improve daily work, we have to make it psychologically safe to talk about problems. And then the last one really being, can we really unflinchingly look at the work we do on an everyday basis and ask, what the customers care about it? And if customers don't care about it, can we question whether that work really should be done or not. So that's where for me, it's really meant to speak to some more visceral emotions that were concretized and validated through the State of DevOps Report. But these notions I am just very attracted to.Corey Quinn: I like the idea of it. The question, of course, is always how to put these into daily practice. How do you take these from an idealized—well, let's not call it a textbook, but something very similar to that—and apply it to the I guess, uncontrolled chaos that is the day-to-day life of an awful lot of people in their daily jobs.Gene Kim: Yeah. Right. So, the protagonist is Maxine and her role in the story, in the beginning, is just to recognize what not great looks like. She's lived and created greatness for all of her career. And then she gets exiled to this terrible Phoenix project that chews up developers and spits them out and they leave these husks of people they used to be. And so, she's not doing a lot of problem-solving. Instead, it's this recoiling from the inability for people to do builds or do their own tests or be able to do work without having to open up 20 different tickets or not being able to do their own deploys. She just recoil from this spending five days watching people do code merges, and for me, I'm hoping that what this will do, and after people read the book, will see this all around them, hopefully, will have a similar kind of recoiling reaction where they say, “Oh my gosh, this is terrible. I should feel as bad about this as Maxine does, and then maybe even find my fellow rebels and see if we can create a pocket of greatness that can become like the sublimation event in Dr. Thomas Kuhn's book, The Structure of Scientific Revolutions.” Create that kernel of greatness, of which then greatness then finds itself surrounded by even more greatness.Corey Quinn: What I always found to be fascinating about your work is how you wind up tying so many different concepts together in ways you wouldn't necessarily expect. For example, when I was reviewing one of your manuscripts before this went to print, you did reject one of my suggestions, which was just, retitle the entire thing. Instead of calling it The Unicorn Project. Instead, call it Gene Kim's Love Letter to Functional Programming. So what is up with that?Gene Kim: Yeah, to put that into context, for 25 years or more, I've self-identified as an ops person. The Phoenix Project was really an ops book. And that was despite getting my graduate degree in compiler design and high-speed networking in 1995. And the reason why I gravitated towards ops, because that was my observation, that that's where the saves were made. It was ops who saved the customer from horrendous, terrible developers who just kept on putting things into production that would then blow up and take everyone with it. It was ops protecting us from the bad adversaries who were trying to steal data because security people were so ineffective. But four years ago, I learned a functional programming language called Clojure and, without a doubt, it reintroduced the joy of coding back into my life and now, in a good month, I spend half the time—in the ideal—writing, half the time hanging out with the best in the game, of which I would consider this to be a part of, and then 20% of time coding. And I find for the first time in my career, in over 30 years of coding, I can write something for years on end, without it collapsing in on itself, like a house of cards. And that is an amazing feeling, to say that maybe it wasn't my inability, or my lack of experience, or my lack of sensibilities, but maybe it was just that I was sort of using the wrong tool to think with. That comes from the French philosopher Claude Lévi-Strauss. He said of certain things, “Is it a good tool to think with?” And I just find functional programming is such a better tool to think with, that notions like composability, like immutability, what I find so exciting is that these things aren't just for programming languages. And some other programming languages that follow the same vein are, OCaml, Lisp, ML, Elixir, Haskell. These all languages that are sort of popularizing functional programming, but what I find so exciting is that we see it in infrastructure and operations, too. So Docker is fundamentally immutable. So if you want to change a container, we have to make a new one. Kubernetes composes these containers together at the level of system of systems. Kafka is amazing because it usually reveals the desire to have this immutable data model where you can't change the past. Version control is immutable. So, I think it's no surprise that as our systems get more and more complex and distributed, we're relying on things like immutability, just to make it so that we can reason about them. So, it is something I love addressing in the book, and it's something I decided to double down on after you mentioned it. I'm just saying, all kidding aside is this a book for—Corey Quinn: Oh good, I got to make it worse. Always excited when that happens.Gene Kim: Yeah, I mean, your suggestion really brought to the forefront a very critical decision, which was, is this a book for technology leaders, or even business leaders, or is this a book developers? And, after a lot of soul searching, I decided no, this is a book for developers, because I think the sensibilities that we need to instill and the awareness we need to create these things around are the developers and then you just hope and pray that the book will be good enough that if enough engineers like it, then engineering leaders will like it. And if enough engineering leaders like it, then maybe some business leaders will read it as well. So that's something I'm eagerly seeing what will happen as the weeks, months, and years go by. Corey Quinn: This episode is sponsored in part by DataStax. The NoSQL event of the year is DataStax Accelerate in San Diego this May from the 11th through the 13th. I've given a talk previously called the myth of multi-cloud, and it's time for me to revisit that with... A sequel! Which is funny given that it's a NoSQL conference, but there you have it. To learn more, visit datastax.com that's D-A-T-A-S-T-A-X.com and I hope to see you in San Diego. This May.Corey Quinn: One thing that I always admired about your writing is that you can start off trying to make a point about one particular aspect of things. And along the way you tie in so many different things, and the functional programming is just one aspect of this. At some point, by the end of it, I half expected you to just pick a fight over vi versus Emacs, just for the sheer joy you get in effectively drawing interesting and, I guess, shall we say, the right level of conflict into it, where it seems very clear that what you're talking about is something thing that has the potential to be transformative and by throwing things like that in you're, on some level, roping people in who otherwise wouldn't weigh in at all. But it's really neat to watch once you have people's attention, just almost in spite of what they want, you teach them something. I don't know if that's a fair accusation or not, but it's very much I'm left with the sense that what you're doing has definite impact and reverberations throughout larger industries.Gene Kim: Yeah, I hope so. In fact, just to reveal this kind of insecurity is, there's an author I've read a lot of and she actually read this blog post that she wrote about the worst novel to write, and she called it The Yeomans Tour of the Starship Enterprise. And she says, “The book begins like this: it's a Yeoman on the Starship Enterprise, and all he does is admire the dilithium crystals, and the phaser, and talk about the specifications of the engine room.” And I sometimes worry that that's what I've done in The Unicorn Project, but hopefully—I did want to have that technical detail there and share some things that I love about technology and the things I hate about technology, like YAML files, and integrate that into the narrative because I think it is important. And I would like to think that people reading it appreciate things like our mutual distaste of YAML files, that we've all struggled trying to escape spaces and file names inside of make files. I mean, these are the things that are puzzles we have to solve, but they're so far removed from the business problem we're trying to solve that really, the purpose of that was trying to show the mistake of solving puzzles in our daily work instead of solving real problems.Corey Quinn: One thing that I found was really a one-two punch, for me at least, was first I read and give feedback on the book and then relatively quickly thereafter, I found myself at my first DevOps Enterprise Summit, and I feel like on some level, I may have been misinterpreted when I was doing my live-tweeting/shitposting-with-style during a lot of the opening keynotes, and the rest, where I was focusing on how different of a conference it was. Unlike a typical DevOps Days or big cloud event, it wasn't a whole bunch of relatively recent software startups. There were serious institutions coming out to have conversations. We're talking USAA, we're talking to US Air Force, we're talking large banks, we're talking companies that have a 200-year history, where you don't get to just throw everything away and start over. These are companies that by and large, have, in many ways, felt excluded to some extent, from the modern discussions of, well, we're going to write some stuff late at night, and by the following morning, it's in production. You don't get to do that when you're a 200-year-old insurance company. And I feel like that was on some level interpreted as me making fun of startups for quote/unquote, “not being serious,” which was never my intention. It's just this was a different conversation series for a different audience who has vastly different constraints. And I found it incredibly compelling and I intend to go back.Gene Kim: Well, that's wonderful. And, in fact, we have plans for you, Mr. Quinn.Corey Quinn: Uh-oh.Gene Kim: Yeah. I think when I say I admire the DevOps Enterprise community. I mean that I'm just so many different dimensions. The fact that these, leaders and—it's not leaders just in terms of seniority on the organization chart—these are people who are leading technology efforts to survive and win in the marketplace. In organizations that have been around sometimes for centuries, Barclays Bank was founded in the year 1634. That predates the invention of paper cash. HMRC, the UK version of the IRS was founded in the year 1200. And, so there's probably no code that goes that far back, but there's certainly values and—Corey Quinn: Well, you'd like to hope not. Gene Kim: Yeah, right. You never know. But there are certainly values and traditions and maybe even processes that go back centuries. And so that's what's helped these organizations be successful. And here are a next generation of leaders, trying to make sure that these organizations see another century of greatness. So I think that's, in my mind, deeply admirable.Corey Quinn: Very much so. And my only concern was, I was just hoping that people didn't misinterpret my snark and sarcasm as aimed at, “Oh, look at these crappy—these companies are real companies and all those crappy SAS companies are just flashes in the pan.” No, I don't believe that members of the Fortune 500 are flash in the pan companies, with a couple notable exceptions who I will not name now, because I might want some of them on this podcast someday. The concern that I have is that everyone's work is valuable. Everyone's work is important. And what I'm seeing historically, and something that you've nailed, is a certain lack of stories that apply to some of those organizations that are, for lack of a better term, ossified into their current process model, where they there's no clear path for them to break into, quote/unquote, “doing the DevOps.”Gene Kim: Yeah. And the business frame and the imperative for it is incredible. Tesla is now offering auto insurance bundled into the car. Banks are now having to compete with Apple. I mean, it is just breathtaking to see how competitive the marketplaces and the need to understand the customer and deliver value to them quickly and to be able to experiment and innovate and out-innovate the competition. I don't think there's any business leader on the planet who doesn't understand that software is eating the world and they have to that any level of investment they do involves software at some level. And so the question is, for them, is how do they get educated enough to invest and manage and lead competently? So, to me it really is like the sleeping giant awakening. And it's my genuine belief is that the next 50 years, as much value as the tech giants have created: Facebook, Amazon, Netflix, Google, Microsoft, they've generated trillions of dollars of economic value. When we can get eighteen million developers, as productive as an engineer at a tech giant is, that will generate tens of trillions of dollars of economic value per year. And so, when you generate that much economic activity, all problems become solvable, you look at climate change, you take a look at the disparity between rich and poor. All things can be fixed when you significantly change the economic economy in this way. So, I'm extremely hopeful and I know that the need for things like DevOps are urgent and important.Corey Quinn: I guess that that's probably the best way of framing this. So you wrote one version that was aimed at operators back in 2013, this one was aimed at developers, and effectively retails and clarifies an awful lot of the same points. As a historical ops person, I didn't feel left behind by The Unicorn Project, despite not being its target market. So I guess the question on everyone's mind, are you planning on doing a third iteration, and if so, for what demographic?Gene Kim: Yeah, nothing at this point, but there is one thing that I'm interested in which is the role of business leaders. And Sarah is an interesting villain. One of my favorite pieces of feedback during the review process was, “I didn't think I could ever hate Sarah more. And yet, I did find her even to be more loathsome than before.” She's actually based on a real person, someone that I worked with.Corey Quinn: That's the best part, is these characters are relatable enough that everyone can map people they know onto various aspects of them, but can't ever disclose the entire list in public because that apparently has career consequences.Gene Kim: That's right. Yes, I will not say who the character is based on but there's, in the last scene of the book that went to print, Sarah has an interesting interaction with Maxine, where they meet for lunch. And, I think the line was, “And it wasn't what Maxine had thought, and she's actually looking forward to the next meeting.” I think that leaves room for it. So one of the things I want to do with some friends and colleagues is just understand, why does Sarah act the way she does? I think we've all worked with someone like her. And there are some that are genuinely bad actors, but I think a lot of them are doing something, based on genuine, real motives. And it would be fun, I thought, to do something with Elizabeth Henderson, who we decided to start having a conversation like, what does she read? What is her background? What is she good at? What does her resume look like? And what caused her to—who in technology treated her so badly that she treats technology so badly? And why does she behave the way she does? And so I think she reads a lot of strategy books. I think she is not a great people manager, I think she maybe has come from the mergers and acquisition route that viewed people as fungible. And yeah, I think she is definitely a creature of economics, was lured by an external investor, about how good it can be if you can extract value out of the company, squeeze every bit of—sweat every asset and sell the company for parts. So I would just love to have a better understanding of, when people say they work with someone like a Sarah, is there a commonality to that? And can we better understand Sarah so that we can both work with her and also, compete better against her, in our own organizations?Corey Quinn: I think that's probably a question best left for people to figure out on their own, in a circumstance where I can't possibly be blamed for it.Gene Kim: [laughing].That can be arranged, Mr. Quinn.Corey Quinn: All right. Well, if people want to learn more about your thoughts, ideas, feelings around these things, or of course to buy the book, where can they find you?Gene Kim: If you're interested in the ideas that are in The Unicorn Project, I would point you to all of the freely available videos on YouTube. Just Google DevOps Enterprise Summit and anything that's on the plenary stage are specifically chosen stories that very much informed The Unicorn Project. And the best way to reach me is probably on Twitter. I'm @RealGeneKim on Twitter, and feel free to just @ mention me, or DM me. Happy to be reached out in whatever way you can find me. Corey Quinn: You know where the hate mail goes then. Gene, thank you so much for taking the time to speak with me, I appreciate it.Gene Kim: And Corey, likewise, and again, thank you so much for your unflinching feedback on the book and I hope you see your fingerprints all over it and I'm just so delighted with the way it came out. So thanks to you, Corey. Corey Quinn: As soon as my signed copy shows up, you'll be the first to know.Gene Kim: Consider it done. Corey Quinn: Excellent, excellent. That's the trick, is to ask people for something in a scenario in which they cannot possibly say no. Gene Kim, multiple award-winning CTO, researcher, and author. Pick up his new book, The Wall Street Journal best-selling The Unicorn Project. 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 Apple Podcasts. If you hated this podcast, please leave a five-star review on Apple Podcasts and leave a compelling comment.Announcer: This has been this week's episode of Screaming in the Cloud. You can also find more Corey at ScreamingintheCloud.com or wherever fine snark is sold.This has been a HumblePod production. Stay humble.

Guests: John Speed Meyers, Security Data Scientist, Chainguard Todd Kulesza, User Experience Researcher, Google Topics: How did you get involved with this year's Accelerate State of DevOps Report (DORA report)? So what is DORA and why did you decide to focus on supply chain security for the 2022 report? What are the big learnings from this year's report? What's the difference between SLSA and SSDF? Is one spicy and the other savory? How're companies adopting these and how is adoption going?  Are there other areas that DevOps can be a contributor in the overall security landscape?  How can CISOs rope DevOps fully into their security gang? Operationally, how should security and developers and DevOps come together to keep vulnerabilities out in the first place? How should security and developers and DevOps come together to respond quickly to vulnerabilities when they're discovered? How do security and developers and DevOps come together to prove to their auditors and customers that they're doing a good job of the above? Resources: 2022 Accelerate State of DevOps Report "New insights for defending the software supply chain" blog (and new report) SLSA.dev site Secure Software Development Framework at NIST “Linking Up The Pieces: Software Supply Chain Security at Google and Beyond” (ep24) “Sharing The Mic In Cyber with STMIC Hosts Lauren and Christina: Representation, Psychological Safety, Security” (ep92) Go vulncheck tool  “Reflections on Trusting Trust” paper  (1984)

Nathen Harvey needs little introduction in DevOps community. He is Developer Advocate at Google, co-author of State of DevOps Report and co-author of a great book called “97 Things Every Cloud Engineer Should Know”. We talked about insights and surprises from this year's State of DevOps Report. And Nathen shared his view on recent hot takes that “DevOps is dead”

2022 Accelerate State of DevOps Report – Patoarchitekci sprawdzają, w jaką stronę może się zmienić raport, który rok temu był czysto techniczny. Posłuchaj i dowiedz się, jaki jest teraz.Nasze sociale i linki -> https://linktr.ee/patoarchitekciMateriały do odcinka znajdziesz na: https://patoarchitekci.io/47

This week we give a little previous of what will be at the SpringOne conference, then cover some recent conferences. We then discuss the sudden emergence of "platform engineering" as a thing, and finish out by discussing what the kids are calling "FinOps," getting a handle on how much you're spending on cloud stuff.   As always, with your pals @egrigson, @benbravo73, & @cote.   Check out the livestream video if you like that kind of thing. Show Notes   SpringOne Dec 6th and 8th. Check out the workshops and sessions. Escaping the Legacy Trap - Coté's talk with Marc. You can get the legacy trap booklet when you register for the webinar we did on the topic - also, watch the recording! Use the code COTE200 to get $200 off registration. News Conferences: Hashiconf announcements - RedMonk round-up. eBPF summit sessions are now online (it was 28th/29th Sept). Kong Summit. Platform Engineering Corner: boy, that's a thing now! Charity Major's piece. There was a whole conference. Paula has a good updated overview. Istio has joined the CNCF as incubating. Google published their 2022 Accelerate State of DevOps Report with lots of focus on security and platform-think. Surveys: Sysdig Threat Report. Buoyant's Service Mesh survey results. Cloud costs corner - Wan cloud report, PDF.  Ben's new video “Deploy Your Python Apps To Production In Seconds”

This week we give a little previous of what will be at the SpringOne conference, then cover some recent conferences. We then discuss the sudden emergence of "platform engineering" as a thing, and finish out by discussing what the kids are calling "FinOps," getting a handle on how much you're spending on cloud stuff.   As always, with your pals @egrigson, @benbravo73, & @cote.   Check out the livestream video if you like that kind of thing. Show Notes   SpringOne Dec 6th and 8th. Check out the workshops and sessions. Escaping the Legacy Trap - Coté's talk with Marc. You can get the legacy trap booklet when you register for the webinar we did on the topic - also, watch the recording! Use the code COTE200 to get $200 off registration. News Conferences: Hashiconf announcements - RedMonk round-up. eBPF summit sessions are now online (it was 28th/29th Sept). Kong Summit. Platform Engineering Corner: boy, that's a thing now! Charity Major's piece. There was a whole conference. Paula has a good updated overview. Istio has joined the CNCF as incubating. Google published their 2022 Accelerate State of DevOps Report with lots of focus on security and platform-think. Surveys: Sysdig Threat Report. Buoyant's Service Mesh survey results. Cloud costs corner - Wan cloud report, PDF.  Ben's new video “Deploy Your Python Apps To Production In Seconds”

This week we discuss why Google abandons products, the 2022 State of DevOps Report and Elon's texts. Plus, some thoughts on glasses… Watch the YouTube Live Recording of Episode 380. (https://www.youtube.com/watch?v=4N8MwCBPgWY) Runner-up Titles Leave it all in Brighttalk Let's talk about it and I'll read it later Killed by Google Wins Again Tell that to the WeWork founder Buy somebody who's already on the Moon Anyone from software thinks they can do anything Lots of learnings. I hate DNS, but I've never seen a domain name I didn't buy. A good Brandon issue Rundown Google's Incentives Google is shutting down Stadia (https://www.theregister.com/2022/09/29/google_shuts_down_stadia/) Stadia shutdown shows Google's struggle to innovate (https://www.axios.com/newsletters/axios-login-555c72e1-380a-4a69-affe-e8260ae5734e.html?chunk=0&utm_term=emshare#story0) Google insiders explain why Google launches many products and then abandons them. (https://twitter.com/petergyang/status/1576985038511448064) 2022 State of DevOps Report (https://cloud.google.com/blog/products/devops-sre/dora-2022-accelerate-state-of-devops-report-now-out) Elon Musk's Texts Shatter the Myth of the Tech Genius (https://newsletters.theatlantic.com/galaxy-brain/email/1f916f2d-db1b-43a8-85c1-46a56ab97e19/) Relevant to your Interests GitLab beats expectations with impressive revenue growth, but its stock falls anyway (https://siliconangle.com/2022/09/06/gitlab-beats-expectations-impressive-revenue-growth-stock-falls-anyway/) Two Former eBay Executives Sentenced to Prison for Cyberstalking (https://www.justice.gov/usao-ma/pr/two-former-ebay-executives-sentenced-prison-cyberstalking) We're excited to announce that the transaction to combine Citrix and TIBCO (https://buff.ly/3fzCIBL) Can a Zebra Change Its Stripes? (https://www.newcomer.co/p/can-a-zebra-change-its-stripes) VR & AR headset designers should consider how their customers look like when wearing them (https://twitter.com/werner/status/1576625132675936256?s=46&t=setZxlR2Skv0eAetpRREYw) CEO Tim Cook says Apple avoids the word 'metaverse' (https://twitter.com/ballmatthew/status/1576732541435854848) DALL·E Now Available Without Waitlist (https://openai.com/blog/dall-e-now-available-without-waitlist) Introducing Make-A-Video: An AI system that generates videos from text (https://ai.facebook.com/blog/generative-ai-text-to-video/?utm_content=null) The Thorny Problem of Keeping the Internet's Time (https://www.newyorker.com/tech/annals-of-technology/the-thorny-problem-of-keeping-the-internets-time?utm_source=newsletter&utm_medium=email&utm_campaign=newsletter_axioslogin&stream=top) Postgres WASM by Snaplet and Supabase (https://twitter.com/supabase/status/1576943402687631365) Linux 6.0 arrives with support for newer chips, core fixes, and oddities (https://arstechnica.com/gadgets/2022/10/linux-6-0-arrives-with-support-for-newer-chips-core-fixes-and-oddities/) The Most Visited Website in Every Country (That Isn't A Search Engine) (https://www.hostinger.com/tutorials/the-most-visited-website-in-every-country) Bridgewater Founder Ray Dalio Hands Over Control of Firm (https://www.wsj.com/articles/bridgewater-founder-ray-dalio-hands-over-control-of-firm-11664902335) World's First Laptop with RISC-V Processor Now Available (https://www.tomshardware.com/news/risc-v-laptop-world-first) ‎CoRecursive: Coding Stories: Android's Unlikely Success on Apple Podcasts (https://podcasts.apple.com/gb/podcast/corecursive-coding-stories/id1330329512?i=1000581376850) Database 2x2 (https://twitter.com/jaminball/status/1577699834965786624?s=46&t=-tpbK02723C_6-I9GeLdGQ) Pat Gelsinger came back to turn Intel around (https://www.theverge.com/2022/10/4/23385652/pat-gelsinger-intel-chips-act-ohio-manufacturing-chip-shortage) State Of Developer Relations (https://www.stateofdeveloperrelations.com/) Red Hat Storage strategy update (https://www.redhat.com/en/blog/red-hat-storage-strategy-update) IBM Redefines Hybrid Cloud Application and Data Storage Adding Red Hat Storage to IBM Offerings (https://newsroom.ibm.com/2022-10-04-IBM-Redefines-Hybrid-Cloud-Application-and-Data-Storage-Adding-Red-Hat-Storage-to-IBM-Offerings) IBM + Red Hat: Doubling Down on Hybrid Cloud Storage (https://www.ibm.com/cloud/blog/announcements/ibm-red-hat-doubling-down-on-hybrid-cloud-storage) DevOps Is Dead. Embrace Platform Engineering (https://thenewstack.io/devops-is-dead-embrace-platform-engineering/) Nonsense Kim Kardashian pays over $1 million to settle SEC charges linked to a crypto promo on her Instagram (https://www.cnbc.com/2022/10/03/kim-kardashian-settles-sec-charges-instagram-crypto-promotion.html) Test drive new McLaren Formula 1 themes in your Chrome browser (https://blog.google/products/chrome/test-drive-new-mclaren-formula-1-themes-in-your-chrome-browser/) Tacos Are a Staple in Austin. How Is Inflation Impacting Taco Spots? (https://austin.eater.com/2022/9/30/23353698/inflation-austin-taco-restaurants-2022) Google Japan's latest version of it's new keyboard, G-Board (https://www.youtube.com/watch?v=9G3DWHf1xX0) "The Re-Org Rag (I'm My Own VP)" (https://twitter.com/forrestbrazeal/status/1577298602371809281?s=20&t=J0Sf49X9mn4QazmqXin3tQ) Conferences Sydney Cloud FinOps Meetup (https://events.finops.org/events/details/finops-sydney-cloud-finops-presents-sydney-cloud-finops-meetup/), online, Oct 13, 2022 Matt's presenting KubeCon North America (https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/), Detroit, Oct 24 – 28, 2022 SpringOne Platform (https://springone.io/?utm_source=cote&utm_medium=podcast&utm_content=sdt), SF, December 6–8, 2022 THAT Conference Texas Call For Counselors (https://that.us/call-for-counselors/tx/2023/) Jan 16-19, 2023 CloudNativeSecurityCon North America (https://events.linuxfoundation.org/cloudnativesecuritycon-north-america/), Seattle, Feb 1 – 2, 2023 Sponsors Teleport — The easiest, most secure way to access infrastructure. (https://goteleport.com/?utm_campaign=eg&utm_medium=partner&utm_source=sdt) SDT news & hype Join us in Slack (http://www.softwaredefinedtalk.com/slack). Get a SDT Sticker! Send your postal address to stickers@softwaredefinedtalk.com (mailto:stickers@softwaredefinedtalk.com) and we will send you free laptop stickers! Follow us on Twitch (https://www.twitch.tv/sdtpodcast), Twitter (https://twitter.com/softwaredeftalk), Instagram (https://www.instagram.com/softwaredefinedtalk/), LinkedIn (https://www.linkedin.com/company/software-defined-talk/) and YouTube (https://www.youtube.com/channel/UCi3OJPV6h9tp-hbsGBLGsDQ/featured). Use the code SDT to get $20 off Coté's book, (https://leanpub.com/digitalwtf/c/sdt) Digital WTF (https://leanpub.com/digitalwtf/c/sdt), so $5 total. Become a sponsor of Software Defined Talk (https://www.softwaredefinedtalk.com/ads)! Recommendations Brandon: Why the Voice Inside Your Head Can Sound Like a Jerk (https://www.theringer.com/2022/9/20/23363052/voice-inside-head-sound-jerk-emotion-regulation-self-talk) ****(Podcast) The Chatter Toolbox (https://www.ethankross.com/wp-content/uploads/sites/14/2021/02/Chatter-Toolbox-by-Ethan-Kross.pdf) (PDF) Matt: Keyboard.io Model 100 (https://www.indiegogo.com/projects/the-keyboardio-model-100--4/) Coté: classic microplane (https://amzn.to/3Mkcu2o). Photo Credits Glasses Banner (https://unsplash.com/photos/qmnpqDwla_E)

Dan Stein is an engineering manager at General Bioinformatics. Dan Stein is also DJ Fresh, a multi-million selling artist with two UK number one records. Learn about the surprising overlap between these two careers. Do you have something cool to share? Some questions? Let us know: web: kubernetespodcast.com mail: kubernetespodcast@google.com twitter: @kubernetespod and @craigbox Chatter of the week Trevor Noah stepping down as host of Daily Show Follow @craigbox to learn what’s next News of the week Google Cloud adds GPU support to Autopilot Pricing CVE-2021-36782 in Rancher State of DevOps Report for 2022 Congratulations to the 27 Summer LFX Program CNCF interns Reviewing the 2019 Kubernetes security audit Links from the interview DJ Fresh Atari 800 and Atari ST Pong Atari BASIC Commodore Amiga OctaMED Fatboy Slim and the Atari ST Dogs on Acid music forum Taylor Hawkins Tribute Concerts Abolishing the high tax rate in the UK, or not Breakbeat Kaos Hold Your Colour by Pendulum Kryptonite by DJ Fresh Gold Dust Subsequent hits: Louder Hot Right Now Kyma (sound design language) and Max/MSP We Got Coders General Bioinformatics NGS gene sequencing Ensembl Hasura GraphQL Playground NCBI - National Center for Biotechnology Information Max Martin How Music Works by John Powell Learning: Treehouse Udemy 3Blue1Brown Codeacademy DJ Fresh’s new single, Higher DJ Fresh on Facebook Dan Stein on Twitter

On the show this week, we're talking updated DevOps practices for 2022 with hosts Stephanie Wong and Chloe Condon and our guests Nathen Harvey and Derek DeBellis. Nathen and Derek start the show with a thorough discussion of DORA, the research program dedicated to helping organizations improve software delivery and operations, and the state of DevOps report that Google publishes every year. This year, the DevOps research team strengthened their focus on security and discovered that one of the biggest predictors in security practice adoption is company culture. Open, communicative, and trustful company cultures are some of the best for accepting and implementing optimized security practices. Derek tells us how company cultures are measured and scored for this purpose and Nathen talks about team and individual burnout and its affects on culture. Low, medium, high, and elite teams are another indicator of culture, and Nathen explains how teams earn their label through four keys of software delivery performance. Each year, they let the data show these four clusters of team performance. But this year there were only three, and Derek talks more about this phenomenon and why the elite cluster seems to have disappeared. When operational performance analysis was added, the four clusters reemerged and were renamed to better suit the new analysis metrics. Nathen details these four new clusters: starting, which performs neither well nor poorly and may be just starting out; flowing, teams that are performing well across throughput, stability, and operational performance; slowing teams, which don't have high throughput but excel in other areas; and retiring teams, which are reliable but not actively developing projects. We discuss how companies may shift from one cluster to another and how much context can affect this shift. We talk about key findings in the 2022 DevOps report, especially in the security space. Some of the most notable include the adoption of DevOps security practices and the decreased incidence of burnout on teams who leverage security practices. Nathen and Derek elaborate on how this year's research changed from last year and what remained the same. Nathen Harvey Nathen works with teams helping them learn about and apply the findings of our research into high performing teams. He's been involved in the DevOps community for more than a decade. Derek DeBellis Derek is a Quantitative User Experience Researcher at Google, where Derek focuses on survey research, logs analysis, and figuring out ways to measure concepts central to product development. Derek has published on Human-AI interaction, the impact of Covid-19's onset on smoking cessation, designing for NLP errors and the role of UX in ensuring privacy. Cool things of the week Try out Cloud Spanner databases at no cost with new free trial instances blog Chipotle Is Testing More Artificial Intelligence Solutions To Improve Operations article Gyfted uses Google Cloud AI/ML tools to match tech workers with the best jobs blog Interview 2022 Accelerate State of DevOps Report blog DevOps site 2022 State of the DevOps Report Report site DORA site DORA Community site SLSA site Security Software Development Framework site Westrum organizational culture site Google finds culture, not tech, is the biggest predictor of DevOps security outcomes article GCP Podcast Episode 205: DevOps with Nathen Harvey and Jez Humble podcast GCP Podcast Episode 284: State of DevOps Report 2021 with Nathen Harvey and Dustin Smith podcast GCP Podcast Episode 290: Resiliency at Shopify with Camilo Lopez and Tai Dickerson podcast What's something cool you're working on? Steph is working on talks for DevFest Nantes and a Google Cloud dev conference in London. She'll be talking about subsea fiber optics and Google Cloud networking products. Chloe is a Noogler, so she's been working on learning as much as she can! She is excited to make her podcast debut this week! Hosts Stephanie Wong and Chloe Condon

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

The 2021 “Accelerate State of DevOps” report from Google is out! In this episode, Mike Kavis talks with Google's Nathen Harvey and Deloitte's Manoj Mishra about the report's most compelling findings. Among them: DevOps and SRE are complementary; successful SRE equals knowing your customer; documentation is critical, but it should be organic; and there's a newly-announced “Reliability” metric. The group also discusses customer satisfaction and the new “Release Management” role in DevOps/SRE.

Episode SummaryIn this episode, Nigel gives his views on the current state of DevOps adoption, the role of security in DevOps, and gives us some clues from the State of DevOps Report 2021 that will help organisations accelerate their DevOps journey.Nigel's BioNigel is a Field CTO at Puppet where he is responsible for bringing product knowledge and a senior technical operations perspective to Puppet field teams and customers, working on services strategy and representing the customer back into the product organization. He works with many of Puppet's largest customers on the cultural and organizational changes necessary for large scale DevOps implementations. He has been deeply involved in Puppet's DevOps initiatives, and regularly speaks around the world about the adoption of DevOps in the enterprise and IT organizational transformation.Episode LinksState of DevOps Reports:  https://puppet.com/resources/?refinementList%5Btype%5D%5B0%5D=Report&page=1&configure%5BhitsPerPage%5D=18Nigel's LinkedIn: linkedin.com/in/nigelkerstenNigel's Twitter: @nigelkerstenThis podcast is brought to you by our sponsors:  Prisma Cloud and DynaminetYour HostsSteve Giguere: https://www.linkedin.com/in/stevegiguere/Glenn Wilson: https://www.linkedin.com/in/glennwilson/DevSecOps - London GatheringKeep in touch with our events associated with this podcast via our website https://dsolg.com

In this episode, Bhavin and Ryan interview Umair Mufti, the product owner of Portworx Data Services; the new database as a service for Kubernetes. They discuss Umair's experience at Dreamworks Animation creating a database as a service platform as well as why he felt is was necessary to build it and some of the lessons learned along the way. Show links https://softwareengineeringdaily.com/2019/01/11/why-is-storage-on-kubernetes-is-so-hard/ https://www.dataversity.net/data-container-architecture-answers-and-challenges/ https://www.youtube.com/watch?v=5n_Jz4VO_Tg (Chris Adkins) Arc Enabled DS's https://thenewstack.io/maintaining-data-resiliency-in-the-age-of-kubernetes/ State of DevOps Report: https://services.google.com/fh/files/misc/state-of-devops-2021.pdf https://cloud.google.com/blog/products/storage-data-transfer/google-cloud-launches-backups-for-gke https://portworx.com/products/portworx-data-services/ https://blogs.vmware.com/virtualblocks/2021/09/28/announcing-vsan-7-update-3/

Nigel Kersten is Field CTO at Puppet and one of the authors of the 2021 State of DevOps Report. I talked to Nigel about the 10th anniversary of the Report, the latest insights, and how come some enterprises are stuck on their DevOps journey. It was also interesting to hear what happens behind the curtains to produce the Report that we all sometimes take for granted. Do. Not. Miss.Subscribe to 0800-DEVOPS newsletter here.Show notes:This interview is featured in 0800-DEVOPS #29 - 2021 State of DevOps Report with Nigel Kersten.

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!

Guest Speakers: Nikhil Kaul & Dustin Smith Google joins us to discuss what the State of DevOps Report is and focus areas of research for this year's survey. Tune in to learn more. Support the show

Guest Speaker: Nigel KerstenNow in its tenth year, Puppet has opened its annual State of DevOps Report and we would like to invite listeners to take part. Nigel Kersten has been the primary author over the years and he joins us today to unpack what a decade of research has uncovered. Take the Survey: https://survey-d.dynata.com/survey/selfserve/53b/2103608?list=4&sponsor=6#? Support the show (https://cd.foundation/podcast/podcast-submission-form/)

Alanna Brown is Sr. Director Marketing at Puppet and a person standing behind the State of DevOps report from the very beginning. I talked with Alanna about key insights from the latest 2020 State of DevOps but we also touched upon the past and how the report came to life, a story that few people are familiar with.Subscribe to 0800-DEVOPS newsletter here.Show notes:This interview is featured in 0800-DEVOPS #20 - 2020 State of DevOps Report.2020 State of DevOps is available here.

In episode 7 of season 2 of The Pipeline: All Things CD & DevOps I sit down with two community members, CircleCI & Puppet, to talk about the State of DevOps Report 2020. First, we dive into how our guests started their journey into DevOps and then key findings of the 2020 report. Tune in to listen to Alanna Brown & Michael Stahnke to learn more about the State of DevOps Report 2020. Support the show

On The Secure Developer, we often hear a lot of opinions and experiences from people who are working in development, so today we're turning to the data, to figure out what works and what doesn't in the world of DevOps and SecDevOps. Joining us for a panel discussion on the topic is Alanna Brown, Senior Marketing Director at Puppet and mastermind behind the State of DevOps Report, Gareth Rushgrove, Product Director at Snyk and curator of Devops Weekly, and Alyssa Miller, Application Security Advocate, also at Synk. In this show, we get a lay of the land and take a look at the state of where things stand. In this section of the discussion, we hear about vulnerabilities and the mixed bag of data that our panelists have seen around remediation. While there are some positive developments in the space, there are also some areas, like on the container side, where there is great room for improvement. The conversation then moves to security practices and which security controls are effectively deployed and which are not. We gain great insights into the role that integration plays in the efficacy of controls. While it's not all sunshine and roses, there are encouraging shifts happening around security thinking. From there, we move onto talking about infrastructure as code security and shared responsibility. Again, the panelists present their varied data findings, which paints an interesting picture. Finally, we wrap the show up with consolidating the discussion, where the panelists highlight what they think is key going forward. To hear more from this fascinating, data-rich discussion, tune in today!

Unsurprisingly, many high performing organizations in the DevOps space are simultaneously the best in security and in operations too. In this episode, we sit down to talk with Gene Kim about his work on the saves that get made by organizations who have great operations, and how this fits into their security. Gene Kim is the founder of Tripwire, author of The Unicorn Project and The Phoenix Project and has also co-authored The DevOps Handbook and the State of DevOps Report amongst other texts. He has been studying high performing technology organizations for much of his life and has a rich history in both the security and the DevOps sides. Today we get the change to talk to Gene about the five ideals for optimizing performance in the DevOps space that can be found in The Unicorn Project, particularly from the lens of security.We also chat to Gene about the four hypotheses that the DevOps report he co-authored rested on, and some of the interesting and unexpected conclusions that he and his collaborators came to. This conversation spans many key aspects of the DevOps industry and how locality, flow, daily improvement, psychological safety, and customer focus have the power to augment huge changes for the better, so make sure you don't miss it!Show notes and transcript can be found here 

SpringOne Platform is in just one week! Richard and Coté talk about the conference, some of their highlights, and some quick food recommendations (burgers!). Perhaps too quick! We also cover some recent news in .Net, serverless, and Azure security. Richard discusses a DevOps Report webinar he did with Dr. Nicole Forsgren, and Coté gives an overview of the new book he's working on (The Business Bottleneck) and preview of a two part webinar on the topic (part one, part two). There's still time to register for SpringOne Platform. It's Oct 7th to 10th in Austin, Texas - Coté's home town! Use the code S1P200_Cote to get $200 off.

This episode is brought to you by KingswaySoft. Nick and Colin are joined by special guest Eugene Van Staden. Eugene, Colin and Nick discuss building a set of ALM/DevOps tools for PowerApps Portals deployments. Learn about the importance of healthy ALM, the available open-source tools and the challenges of applying automated DevOps to Portal projects. Show Notes and Links: Eugene's contact info: eugenevs@outlook.com https://github.com/hmdvs - Eugene will eventually post some of his templates and companion app samples there. 2019 State of DevOps Report https://puppet.com/resources/whitepaper/state-of-devops-report Andrew Vogel's tools: https://www.powershellgallery.com/packages/Microsoft.Xrm.DevOps.Data.PowerShell/1.3.0 https://github.com/abvogel/Microsoft.Xrm.DevOps.Data Scott Durow's Task Runner https://github.com/scottdurow/SparkleXrm/wiki/spkl Microsoft Doc's Configuration Data Migration Tool https://docs.microsoft.com/en-us/dynamics365/customer-engagement/portals/migrate-portal-configuration Music: www.purple-planet.com