Podcasts about unicorn project

"Plus il y a de gens, plus Git est efficace" Le D.E.V. de la semaine est Olivier Jacques, consultant ProServe chez Amazon Web Services. Dans cet épisode, nous explorons l'évolution de Git en 2024, alors que nous allons bientôt fêter ses 20 ans. Nous discutons de l'importance de Git dans la gestion du code et examinons plusieurs stratégies d'utilisation au sein des équipes de développement. Olivier présente une typologie de cinq méthodes, comme la stratégie trunk-based, qui favorise l'intégration continue, et aborde les défis liés à chacune d'elles, ainsi que GitFlow, et les branches par environnement (à éviter !). Il met en lumière l'importance du contexte d'équipe et de la culture organisationnelle dans le choix de la stratégie la plus adaptée, tout en soulignant que l'efficacité d'une méthode dépend également de sa mise en &oeliguvre au sein de l'équipe. Liens évoqués pendant l'émission Atlassian : Git workflows.IT Revolution : Accelerate, The Unicorn Project, The Phoenix Project, Team TopologiesGregor Hohpe : Cloud Strategy, Platform Strategy, et son blog sur des sujets d'architecture moderne du logiciel. 🎙️ Soutenez le podcast If This Then Dev ! 🎙️ Chaque contribution aide à maintenir et améliorer nos épisodes. Cliquez ici pour nous soutenir sur Tipeee 🙏Archives | Site | Boutique | TikTok | Discord | Twitter | LinkedIn | Instagram | Youtube | Twitch | Job Board |

In this episode of Book Overflow, Carter and Nathan finish their discussion of The Unicorn Project by Gene Kim. Written in the style of a novel, join them as they discuss how businesses bet big on new ideas, dealing with layoffs, and executive politicking! -- Books Mentioned in this Episode -- Note: As an Amazon Associate, we earn from qualifying purchases. ---------------------------------------------------------- The Unicorn Project by Gene Kim https://amzn.to/3XJFg2u (paid link) ---------------- Spotify: https://open.spotify.com/show/5kj6DLCEWR5nHShlSYJI5L Apple Podcasts: https://podcasts.apple.com/us/podcast/book-overflow/id1745257325 X: https://x.com/bookoverflowpod Carter on X: https://x.com/cartermorgan Nathan's Functionally Imperative: www.functionallyimperative.com ---------------- Book Overflow is a podcast for software engineers, by software engineers dedicated to improving our craft by reading the best technical books in the world. Join Carter Morgan and Nathan Toups as they read and discuss a new technical book each week! The full book schedule and links to every major podcast player can be found at https://www.bookoverflow.io

In this episode of Book Overflow, Carter and Nathan discuss Part Two of The Unicorn Project by Gene Kim. Written in the style of a novel, join them as they discuss the protagonist Maxine's journey of transforming the failing Phoenix Project from a big ball of mud into an agile, efficient architecture! -- Books Mentioned in this Episode -- Note: As an Amazon Associate, we earn from qualifying purchases. ---------------------------------------------------------- The Unicorn Project by Gene Kim https://amzn.to/3XJFg2u (paid link) ---------------- Spotify: https://open.spotify.com/show/5kj6DLCEWR5nHShlSYJI5L Apple Podcasts: https://podcasts.apple.com/us/podcast/book-overflow/id1745257325 X: https://x.com/bookoverflowpod Carter on X: https://x.com/cartermorgan Nathan's Functionally Imperative: www.functionallyimperative.com ---------------- Book Overflow is a podcast for software engineers, by software engineers dedicated to improving our craft by reading the best technical books in the world. Join Carter Morgan and Nathan Toups as they read and discuss a new technical book each week! The full book schedule and links to every major podcast player can be found at https://www.bookoverflow.io

In this episode of Book Overflow, Carter and Nathan discuss the part one of The Unicorn Project by Gene Kim. Written in the style of a novel, join them as they discuss the protagonist Maxine's journey of being assigned to a failing project, working within a maddening bureaucracy, fighting for easy local development! -- Books Mentioned in this Episode -- Note: As an Amazon Associate, we earn from qualifying purchases. ---------------------------------------------------------- The Unicorn Project by Gene Kim https://amzn.to/3XJFg2u (paid link) ---------------- Spotify: https://open.spotify.com/show/5kj6DLCEWR5nHShlSYJI5L Apple Podcasts: https://podcasts.apple.com/us/podcast/book-overflow/id1745257325 X: https://x.com/bookoverflowpod Carter on X: https://x.com/cartermorgan Nathan's Functionally Imperative: www.functionallyimperative.com ---------------- Book Overflow is a podcast for software engineers, by software engineers dedicated to improving our craft by reading the best technical books in the world. Join Carter Morgan and Nathan Toups as they read and discuss a new technical book each week! The full book schedule and links to every major podcast player can be found at https://www.bookoverflow.io

This interview was recorded for GOTO Unscripted.https://gotopia.techRead the full transcription of this interview hereGene Kim - Author, Researcher, DevOps Enthusiast & Founder of IT RevolutionCharles Humble - Freelance Techie, Podcaster, Editor, Author & ConsultantRESOURCESGenehttps://twitter.com/RealGeneKimhttps://www.linkedin.com/in/realgenekimhttp://www.realgenekim.meCharleshttps://twitter.com/charleshumblehttps://linkedin.com/in/charleshumblehttps://mastodon.social/@charleshumblehttps://conissaunce.comLinkshttps://youtu.be/vLHFuQjJR8Yhttps://youtu.be/5_rrQND3lpQhttps://youtu.be/dMwGfRINpz0https://youtu.be/KDHyxnLdOqchttps://youtu.be/AxqX9ovGViwhttps://youtu.be/JAl3QFae_dEhttps://youtu.be/l3XwpSKqNZwhttps://youtu.be/wtmW89I941Ihttps://youtu.be/5OjqD-ow8GEhttps://youtu.be/hIwVqt6qtc4DESCRIPTIONJoin Gene Kim and Charles Humble as they demystify the complexities of organizational dynamics, offering a comprehensive guide to navigating challenges and fostering success through his five ideals, backed by real-world stories and expert discussions.Discover the keys to organizational success with Gene Kim and Charles Humble in an insightful conversation, backed by real-world stories and expert discussions. [...]RECOMMENDED BOOKSGene Kim & Steve Spear • Wiring the Winning OrganizationGene Kim • The Unicorn ProjectGene Kim, Kevin Behr & George Spafford • The Phoenix ProjectGene Kim, Nicole Forsgren & Jez Humble • AccelerateGene Kim, Jez Humble, Patrick Debois, John Willis & Nicole Forsgren • The DevOps HandbookGene Kim & John Willis • Beyond The Phoenix ProjectDaniel Kahneman • Thinking, Fast and SlowElisabeth Hendrickson • Explore It!Gerald M. Weinberg • Becoming a Technical LeaderTwitterInstagramLinkedInFacebookLooking 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!

In this episode of the CTO Advisor Podcast, Keith Townsend interviews Gene Kim, the renowned author of "The Phoenix Project" and "The Unicorn Project." Gene shares his experiences and insights from his extensive DevOps and IT leadership career, exploring how these fictional narratives reflect real-world challenges and triumphs in technology transformations. Gene discusses the role [...]

Guest Bio: Mark Schwartz joined AWS as an Enterprise Strategist and Evangelist in July 2017. In this role, Mark works with enterprise technology executives to share experiences and strategies for how the cloud can help them increase speed and agility while devoting more of their resources to their customers. Mark has extensive experience as an IT leader in the government, private sector, and the nonprofit world, and with organizations ranging from startup to large. Prior to joining AWS, he was CIO of US Citizenship and Immigration Services (in the Department of Homeland Security), where he led a large digital transformation effort, moving the agency to the cloud, introducing and refining DevOps and Agile techniques, and adopting user-centric design approaches. From his work at USCIS, he developed a reputation for leading transformation in organizations that are resistant to change, obsessed with security, subject to considerable regulation and oversight, and deeply bureaucratic. Before USCIS, Mark was CIO of Intrax Cultural Exchange, a leader in global youth exchange programs, and CEO of a software company. Mark is the author of The Art of Business Value , A Seat at the Table: IT Leadership in the Age of Agility, War, Peace and IT and The Delicate Art of Bureaucracy. Mark speaks at conferences internationally on such subjects as DevOps, Leading Change, Driving Innovation in IT, and Managing Agility in Bureaucratic Organizations. He has been recognized as a Computerworld Premier IT Leader and received awards for Leadership in Technology Innovation, the Federal 100 IT Leaders, and a CIO Magazine 100 award. Mark has both a BS and MA degree from Yale University, and an MBA from Wharton.   Social Media/ Website: Mark's LinkedIn Profile: https://www.linkedin.com/in/innovativecio Mark's AWS Executive Insights page with links to all his blogs posts and books https://aws.amazon.com/ar/executive-insights/enterprise-strategists/mark-schwartz/  Books/ Resources: The Delicate Art of Bureaucracy: Digital Transformation with the Monkey, the Razor and the Sumo Wrestler by Mark Schwartz https://www.amazon.co.uk/Delicate-Art-Bureaucracy-Transformation-Wrestler-ebook/dp/B086XM4WCK/ The Art of Business Value by Mark Schwartz https://www.amazon.co.uk/Art-Business-Value-Mark-Schwartz/dp/1942788045 A Seat at the Table: IT Leadership in the Age of Agility by Mark Schwartz https://www.amazon.co.uk/Seat-Table-Leadership-Age-Agility/dp/1942788118/ War, Peace and IT: Business Leadership, Technology, and Success in the Digital Age by Mark Schwartz https://www.amazon.co.uk/War-Peace-Business-Leadership-Technology/dp/1942788711 Reaching Cloud Velocity: A Leader's Guide to Success in the AWS Cloud by Jonathan Allen et al https://www.amazon.co.uk/Reaching-Cloud-Velocity-Leaders-Success/dp/B086PTDP51 Ahead in the Cloud: Best Practices for Navigating the Future of Enterprise IT by Stephen Orban https://www.amazon.co.uk/Ahead-Cloud-Practices-Navigating-Enterprise-ebook/dp/B07BYQTGJ7 Engineers of Victory: The Problem Solvers Who Turned the Tide in the Second World War by Paul Kennedy https://www.amazon.co.uk/Engineers-Victory-Problem-Solvers-Turned-ebook/dp/B00ADNPCC0 The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win by Gene Kim https://www.amazon.co.uk/Phoenix-Project-Devops-Helping-Business/dp/1942788290/ The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data by Gene Kim https://www.amazon.co.uk/Unicorn-Project-Disruption-Redshirts-Overthrowing/dp/1942788762   Interview Transcript Ula Ojiaku:  Mark, thank you so much for making the time for this conversation. Mark Schwartz: Thank you, my pleasure. Ula Ojiaku: Great. Now let's start with you know, the question I usually ask my guests: who's Mark? What makes him tick? Mark Schwartz:  And they can answer that question. It's not a hard one. where to start? Um, you know, I always enjoy my work. That's a thing about me. I like to think that people have fun working with me because I tend to laugh a lot. And even you know, when the work is boring, I find ways to make it interesting. I just enjoy doing things and accomplishing things. I think if we're going to talk about my books, and some of the things I've done later, an important thing to realize is that, I started out, you know, when I went, when I was in high school, when I went to college, I was pretty sure I wanted to study computer science and get involved with these computer things. But when I was actually studying, I realized there were all these other interesting areas, I'm just, you know, endlessly curious. And so, I wound up studying all kinds of other things, in addition. And the result was that when I finished college, I decided to go to graduate school in philosophy. And I spent a few years getting a master's degree in philosophy. And the fact that I'm curious about so many things and read so many different things, I think it enters into a lot of what I do. I like to pull analogies from non-IT related fields and, and, and I'll call upon all the things I've learned in all sorts of different areas, as I'm writing and speaking and working. Ula Ojiaku:  It shines through in your book, definitely. Mark Schwartz:  Yes, I think it does. That's partly an explanation for what you see in my books. I think, um, you know, I sometimes say that I have trouble reading business books generally. Because I kind of find them boring. They tend to make the same point over and over again, and to be very just so one directional, you know, just on the same subject, and it's a little bit odd because in every other subject, the books tend to refer to other books in other fields and there's this extra dimension and that helps you understand what the author is getting at. But in business books, they, you know, aside from having a quote now and then from a famous leader or something, they don't tend to do that, they don't, they don't sort of call upon the whole history of literature and writing. And so, I have a little bit of fun in writing my books in trying to see if I can add an extra dimension just by reference and by bringing in other things that are a little bit orthogonal to the subject matter. Ula Ojiaku:  And that kind of, you know, brings home the point that life isn't black and white. It's actually a complex or a complex kind of, you know, maze and of different disciplines, different ideologies and different viewpoints that make it what it is really. Mark Schwartz:  Yeah well, of course, that was part of the fun of my recent book on Bureaucracy. You know, because I know we all, we want to throw up when we encounter bureaucracy, you know, it disturbs us in so many ways. And one of the things I wanted to say in the book is, well, actually bureaucracy is all around you all the time in unexpected places and it usually doesn't drive you crazy, actually. Yeah... Ula Ojiaku:  Well, I have a lot of questions for you on your book, The Delicate Art of Bureaucracy, which is a catchy, catchy title on its own, very clever. But before we get to that, what do you do when you're not working? I know, you said you love work and you've also said that you're curious about so many things, which means that you read broadly - that's my interpretation. So, what do you do when you're not ‘working'? Mark Schwartz:  Yes, I read broadly, is one thing. In the past, I played the guitar a lot. And I don't quite as much lately. I don't know why, you know, I'll start doing it again. I'm sure at some point. But while I was living in San Francisco, I was actually playing in bars and coffee shops, I have a singer, who I performed with. Ula Ojiaku: Really? Wow! Mark Schwartz: And that was really fun. And then the other thing I do is travel, I've really traveled a lot. And, yeah, there was one period in my life where for about five years, I was bumming around the world with a backpack with you know, occasional returns to the States to work a little bit and make some money and then go traveling again. So, one of the joys of my current job is that, I get to do a lot of traveling to interesting places. Ula Ojiaku:  So, where would you say is your ideal getaway destination? Mark Schwartz:  Oh, let's see. I'm a big fan of Brazil. That, I have good friends there and it's really nice to see them and the atmosphere is always kind of fun there. Ula Ojiaku: Okay. Mark Schwartz: I don't know what I've discovered so many places around the world that I've really loved being. I lived in Japan for a year and that is a place that I love to go to, especially for the food. Yeah, I like good food. But I don't know I've found so many places that made me feel like I'd like to spend more time there. And of course, you can't really spend more time everywhere. Ula Ojiaku:  Interesting. So, let's, let's go to your book, “The Art of Delicate Bureaucracy”. What was the inspiration behind that book? Mark Schwartz:  Well, for all of my books, before I wrote, before I wrote them, I was thinking, ‘why hasn't anybody else written a book on this topic?' People don't write books on bureaucracy, at least not, you know, popular books, there are academic books on bureaucracy. And the same thing happened to me with my first book, “The Art of Business Value”, where I said to myself, we keep talking about business value in the IT world, like, is it obvious what it means? You know, what, why isn't anybody writing a book about what business value means? So, bureaucracy is one of those things. I have a lot of experience with it first of all, I was a CIO in a government agency. But it turns out, it's not just the government, whenever I tell people about my government experience, when I speak at a conference, people come up to me afterwards and say, ‘Oh, my company's just like that. I work for a financial services company; we have lots of bureaucracy'. And I work with a lot of people who are trying to pull off some sort of digital transformation, which is change on a big scale, that's changing traditional organizations on a big scale. And bureaucracy is always in their way because bureaucracy tends to resist change; it strongly tends to resist change. So, if you're doing a big change, then you're probably going to come up against it. So, I thought maybe with my experience as a bureaucrat, or at least experience in the big bureaucracy, I could give some pointers to people who are trying to cause big change, and yet are facing bureaucratic obstacles. And I can't imagine that there's any organization, at least any large organization that does not have bureaucratic obstacles to digital transformation. So, that got me started on it. And then as I started to think about bureaucracy and research it, I realized this is actually a really interesting topic. Ula Ojiaku:  You had an interesting introduction to the book. You said, “we are bureaucrats all.” Why that claim, you actually were saying, everyone is a bureaucrat, and I know you made a statement that's similar to that earlier on in this conversation - why? Mark Schwartz:  Well, of course, I have to define in the book, what I mean by bureaucracy and all that. And I follow the generally what's accepted as the academic definition. It mostly comes from the sociologist Max Vabre, who is writing around 1920. And, and he talks a lot about bureaucracy, and it's fairly complicated, but I simplify it in the book. Basically, what it comes down to is a bureaucracy is a way of organizing socially, that has rigid formal roles for people and rigid formal rules. And that's the essence of it. You know, bureaucracy, there are rules and they have to be applied uniformly to everybody. And there's a division of labor and you know, a hierarchy. So, it has rigid roles of people who have to sign off on things and approve things. So, with that is the definition. I think it, it connects with the very human tendency to try to structure things and constantly improve them and optimize them. So, if you find a good way of doing something, you tend to turn it into a rule, you know, this is the way it should be done from now on. Ula Ojiaku: Best practice! Mark Schwartz: It's the best practice. Yeah, yeah, exactly. And also, we, in, social organization, we'd like people to be accountable or responsible for things. And we know that you can't hold somebody accountable unless they have authority to perform their role. So, when you put those things together, it's very natural for us to set up these organizational systems, where we assign roles to people, and give them authority, and we make rules that encapsulate the best way to do things. And, essentially, that's bureaucracy. So, bureaucracy, I find, is everywhere around us in one form or another. But it doesn't drive us crazy most of the time, so we don't notice it. Ula Ojiaku:  Maybe if it's serving us, then we wouldn't notice it. But… Mark Schwartz:  It does serve. And if you look at the cases where it does drive us crazy, they have certain things in common. And in the book, I say there are three characteristics that bureaucracies often take on which they don't need to, it's not part of the definition of bureaucracy, but they often take on these characteristics. And it's those three characteristics that are what drive us crazy. And so, the goal, ultimately is to eliminate those three characteristics or turn them into something else. Ula Ojiaku: I know that the listeners would be curious to know what the three characteristics of bureaucracy that drive us crazy are? Is that so or should I just tell them go buy the book? Mark Schwartz: Yeah, go buy the book! Well, let me tell you the three characteristics, and also their opposite, which is what we really want. So, the first characteristic that drives us crazy, I think, is that bureaucracies tend to be bloated instead of lean, that would be the opposite in my view. There's no reason why a bureaucracy has to be bloated and wasteful. It could be lean, but it's one of those things that bureaucracy tends to become. So that's the first one. The second one is that bureaucracies tend to petrify, as opposed to learning. So, when I say petrifies, I mean that the rules and the bureaucracy don't change, or don't change as often as they should, or don't change continuously, which is really what rules should do. Now, that's not necessarily a characteristic of bureaucracy, but the definition, the definition says the rules have to be applied rigorously. You know, once you have a rule, everybody has to follow it. But it doesn't say that the rules have to stay the same forever, they can change. The opposite of a petrified bureaucracy is a learning bureaucracy, where the rules are constantly adjusted, based on what the people in the organization learn. And there are plenty of good examples of learning bureaucracies out there. And your goal is to transform the one into the other, the petrified into the learning. The third is, bureaucracies tend to be coercive, rather than enabling. Coercive, meaning that they're there to control employee behavior, to force employees to behave in ways that otherwise they wouldn't want to. They tend to be ‘no' saying, they say ‘no', a lot. Your bureaucracy for your expense reporting policy in your company probably says, ‘no that expense is no good because X Y and Z.' There are plenty of examples of enabling bureaucracies, where the point is not to stop you from doing things or force you to do something you don't want to. But the bureaucracy provides a support structure, provide best practices, as you said, that help you do your job well. And there's no reason why bureaucracies can't do that. So, the three bad characteristics are bloat, coercion, and petrify. Ula Ojiaku: Okay, nice. So, it sounds like the way you've described bureaucracy, when you look at it from a positive slant, would it be the same thing as guardrails, putting guardrails in place, or giving people the right degree of freedom? Mark Schwartz: Yeah, that's exactly the idea. What I find is that guardrails and automation are ways of implementing bureaucracy, that lead to those three good characteristics rather than the bad ones. Let's say in software development, in DevOps, for example, it's a good idea to put guardrails, security guardrails, for example, around what people can do, and automated security tests and things like that. Because then the developers or the DevOps teams, they can go charging ahead full speed, knowing that they can't do anything wrong, you know, because the guardrails are there. And they get immediate feedback, if they do something that's going to put them outside the guardrails and they can just immediately fix it. So, it's very empowering for them, lets them move fast. And it also gets rid of that coercive element of you know, I write some code and then somebody comes in afterwards and says, ‘no, you can't deploy that'. That's annoying. Instead, I can run the security tests myself, as a developer, see if there's anything that's problematic, fix it right away if I want to, so it's all under my control. But the end result is still the same. The bureaucracy is still there. It's just automated and implemented as guardrails. Ula Ojiaku:  It's enabling, like you said before, instead of hindering. Mark Schwartz:  And it's lean, because it's very inefficient and wasteful, if you write some code, and then at the very end of the development process, somebody finds a security flaw. And now you have to remember what you were doing. And, you know, go back and relearn your code and make changes then, so that's wasteful, as opposed to lean. It's coercive, as opposed to enabling. And if you're good at doing these things, then you keep updating your guardrails and your security tests based on new security threats you learn about or new policies or whatever. So, you make a learning bureaucracy as well. Ula Ojiaku:  Interesting. In the book as well, you said you want us to be calm, chaos monkeys, knights of Ockham, lean sumo wrestlers, very interesting oxymoron there. And you know, black belt experts, could you tell us more about those terms? Why did you use those terms? Mark Schwartz:  Because they made me laugh of course. Ula Ojiaku: Well, they made me laugh too. Mark Schwartz: So, I thought about what I learned about coping with bureaucracy, especially in my government job, but also from reading and from talking to other people. And I realized I had about, you know, 30 techniques for coping with bureaucracy, I call them plays. And I just grabbed those 30 techniques, but I thought about it, and I realized they divided into three. And the three, I could sort of associate with a personality, almost. You know, that these 10 plays are associated with this personality, these 10 plays are associated with this one. And I came up with these three personalities that I thought describe those plays. And the three personalities are the monkey, and the razor, and the sumo wrestler. And, you know, I think, I could stop right there, because it's probably obvious why I associate those with these plays, but I will go a little further. Ula Ojiaku: Please… Mark Schwartz: So, I realized that some of the things we did, the ones that I call the plays of the monkey, the way of the monkey, those things had to do with provoking. You know, monkeys are mischievous, provocative, and sometimes annoying. And a bunch of the techniques had to do with trying to be provocative. And the razor and I'll give you some examples in a minute. The razor, to me is all about being lean. It's about trimming away waste. And it also refers to the philosophical principle of Ockham's razor. Ockham was a medieval philosopher, right, William of Ockham. And he's generally credited with an idea that something like if you have a choice between a simple explanation, and a complicated explanation, you should prefer the simple one. That's not really what he said. But that's, that's what most people associated with him. That's the principle of Ockham's razor. And, and so it's called a principle of ontological parsimony, meaning, you shouldn't presuppose the existence of more things than you need to, in order to explain something. So, you know, don't make up nymphs. And you know, I don't know, water dryads and whatever's to explain something that you can equally just explain through simple physical laws. Ula Ojiaku:  Just saying, 'keep it simple...' Mark Schwartz:  Yeah, keep it simple, in a way, right? So that's called the principle of ontological parsimony. And I said, there's a similar principle of bureaucratic parsimony, which says that if you're trying to implement a control, and you can do it in a simple way, or you could do it in a really complicated way, do it a simple way. And so, it's a principle of leanness because I find that bureaucracies, when they get bloated, they have these really complicated wasteful ways of doing something that they could they could accomplish exactly the same thing, but in a simpler way. So that's the razor. And then a sumo wrestler. Well, Sumo is the sport where, you know, two massive people sort of bang into each other, right? And the goal is you want to push your opponent out of the ring, or you want to make them fall and touch the ground with something other than their feet. And if you can do either of those things, you win. So, if you're a big massive person and you're trying to accomplish those things, you might think that the best thing to do is charge your opponent and push really hard. But if your opponent then just either dodges or just is soft and lets you push, well, you're probably going to go flying out of the ring, right? So, one of the principles in Sumo is you want to use your opponent's strength against them. And if they push hard, now, go ahead, give them a little pull. And, you know, let them push even harder. And I realized that some of these techniques for overcoming bureaucracy have to do with using bureaucracy actually, on your side, you know, the using the strength of bureaucracy against it. So that's why the sumo wrestler. So, I'll give you examples now on each one, now that I've described my three personalities. So, the monkey does what is sometimes referred to as provoking and inspecting or provoking and observing, in parallel with the Agile principle of inspect and adapt. So, provoke and observe, what the monkey does is try something that's probably outside the rules, or at least is, you know, a borderline and watches what happens. So, an example where we use this is that we have these rules in Homeland Security that essentially said, if you were going to do an IT project, you have to produce 87 documents. And each document had a template, and you have to fill in each section of the template. And these documents would run to hundreds of pages. And so, using the persona of the monkey, let's say, we started to turn in these documents. But in each section of the template, we just wrote a one sentence, one sentence answer, you know, we're very short answer instead of writing pages and pages. And we wanted to see what would happen if we did that, because there was no rule that said, it had to be a really long answer. And eventually, we started to provoke even more, we just left out sections that we thought didn't make any sense for what we were doing. And all of this was unprecedented, you know, it caused a lot of fear. It turned out, and this sometimes happens, that the enforcers of this policy, they were happy when they said, “We've never wanted anybody to write these really long answers to these things, we have to read them. And you know, the intention wasn't to slow people down. As long as you're giving us the right information. That's all we need.” So, in this case, provoking just it turned out that we could defeat a bunch of bureaucracy there, we could, we could make things a lot leaner because nobody objected. But sometimes people do object. And if they do, then you learn exactly what the resistance is, who it is, is resisting, and that gives you valuable information, when you're trying to figure out how to overcome it. So that's the monkey. You know, let's try something a little playful and mischievous, and see what happens. The razor, well, that one follows also on my 87 documents, because we then set up an alternative way of doing things that had only 15 documents. And where there had been 13 gate reviews required for each project. We reduced it to two. And so, all we did, you know, we just used our little razor to trim away all the excess stuff that was in the bureaucratic requirements. And then we showed people that those 15 documents and those two gate reviews accomplished exactly the same thing as the 87 documents and the 13 gate reviews. That's the principle of the razor, that's how the razor works. The sumo wrestler, also a favorite of mine. So, we were trying to convince the bureaucracy to let us do DevOps and to be agile, and it was resisting. And people kept pointing to a policy that said, you can't do these things. And so, we wrote our own policy. And it was a very good bureaucratic policy looked exactly like every bureaucratic document out there. But it essentially said you must use DevOps and you must be agile on it, you know, it set up a perfect bureaucracy around that it's set up ways of checking to make sure everybody was using DevOps. And the theory behind it was the auditors when they came to audit us and said we were being naughty because we were doing DevOps. Their argument was we looked at the policy and we looked at what you're doing, and they were different. And that's the way auditing works. That was the, you know, GAO, the Government Accountability Office, and the Inspector General and all that. So, we figured if we had a policy that said you must do DevOps, and they audited us, well, they would actually be enforcing the policy, you know, they'd be criticizing any part of the organization that was not using DevOps and I thought that's great. So, this is how you use the strength of the bureaucracy against the bureaucracy or not really, against even, you know, it's perfectly good, perfect… Ula Ojiaku:  To help the bureaucracy yeah, to help them to improve, improve the organization. But thinking about the monkey though, being provocative and mischievous, do you think that there has to be an element of you know, relationship and trust in place first, before… you can't just you know… you're new, and you've just gotten through the door and you start being a monkey… you probably will be taken back to wherever you came from! What do you think? Mark Schwartz:  Well, it helps if you're giggling while you do it. But you know, I think the goal here is to figure out the right levers that are going to move things. And sometimes you do have to push a little bit hard, you know, you do need to take people out of their comfort zone. Usually, you want to do these things in a way that takes into account people's feelings, and you know, is likely to move them in the right direction, rather than making them dig in their heels. But I'll give you a couple of examples of Monkey tactics that are less comfortable for people. One is simply, you know, there's a status quo bias. It's a known, well-known cognitive bias; people tend to prefer the status quo or look the other way about it's failings and stuff. So often, when you're trying to make a change, people say, we're fine the way we are, you know, everything's okay. So, one of the things the monkey tries to do is, is to make it clear that the status quo is not acceptable, you know, to show people that it actually if they think about it, it's no good. And so, for example, when we decided to move to the cloud, instead of working in our DHS data center, people said - of course at the time it was a big concern, ‘was the cloud secure enough?' And in the persona of the monkey, the right response is, ‘are we secure enough now?' You know, ‘don't you realize that we're not happy with our security posture today?' ‘It's not like, the cloud has proved itself. I mean, we have to compare our security in the cloud versus our security in the data center. And yes, I'm very sure it'll be better in the cloud and here's why…' But you can't start from the assumption that you are fine right now. In general, when we're talking about the cloud, that's the situation. Companies are using their own data centers. And it's like, you know, we have to teach them that they can do better in the cloud. But the truth is that they're not happy in their own data centers, if they think about it, right? There are security issues, there are performance issues, there are cost issues. And they're aware of those issues, right, they just look the other way. And because they're comfortable with the status quo, so the monkey has to sort of shake people up and say, ‘It's not okay, what you're doing now!' Another example, and this is really harsh, and I wouldn't use it in most cases. But let's say that this was in Homeland Security. Let's say that Homeland Security is enforcing a very bureaucratic process that results in IT projects, taking five years instead of six months. And let's say, you know, the process is there on paper, the rules say, ‘Do this', the people are interpreting the rules in a way that makes things take five years. Sometimes, the monkey has to go to somebody who's in their way and say, ‘We are in the Department of Homeland Security, this IT project is going to make people more secure in the homeland. Are you comfortable with the fact that you are preventing people from being more secure for the next four and a half years, when we could…' You know, it's a matter of personalizing it. And that sometimes is what's necessary to get people to start thinking creatively about how they can change the bureaucracy. You know, ‘I hate to say it, but you're a murderer', you know, essentially is the message. It's a monkey message. And like I said, you know, it's not the preferred way to go about doing things. But if you have to, I mean, the lives of people are at stake, and you've got to find a way to get there. Ula Ojiaku:  So how can leaders because your book, The Art of Business Value, in your book, you said that “leaders create the language of the organization, and they set up incentives and define value in a way that elicits desired outcomes.” So, in essence, I understand that statement to mean that leaders set the tone, and you know, kind of create the environment for things to happen. So, how can leaders implement or apply bureaucracy in a way that enables an organization where, before it was seen as a hindrance, how can they do this? Mark Schwartz:  My thought process was, if we all agree, we're gonna try to maximize business value? How do we know what we mean by it? And I realized, a lot of Agile people, you know, people in our Agile and DevOps community, were being a little bit lazy. You know, they were thinking, ‘Oh, business value, you know, it's returns on investment, or, you know, it's up to the business (to define) what's business value.' The tech people just, you know, do the work of providing a solution. And to me, that's too lazy. If you're going to be agile, be it you have to be more proactive about making sure you're delivering business value. So, you have to understand what it means. You have to actually do the work of, you know, figuring out what it means. And what it means is not at all obvious. And, you know, you might think it has something to do with return on investment or shareholder value or something like that. But when you really closely examine it, that is not the right way to define it, when it comes to deciding what its efforts to prioritize and all that that's, you know, the case that the book makes, and I explain why that's true. Instead, I say you have to think of business value within the context of the business's strategy and its objectives as a business. There's no like, abstract, this has more business value than this because we calculated an ROI or something like that, that doesn't work reprioritizing. It's always asked within the context of a particular business strategy. And the business strategy is a direction from leadership. There might be input from everybody else, but ultimately, you have leaders in the organization who are deciding what the strategic objectives are. So, for example, if you are a traditional bank, or traditional financial services company, and you look around you and you see there are all these new FinTech companies that are disrupting the industry, and you're worried, well there are a lot of different ways you can respond to those disruptive FinTechs. And how you're going to choose to respond depends on your preferences, it depends on the situation of your company, in the industry, the history of your company, all of those things. But of the many ways you can respond to that disruption, you're going to choose one as the leader of your enterprise. Well, what adds business value is whatever supports that direction you choose to go. You can't think of business value outside of that direction, you know. That's the case that I make. So, leaders don't just set the tone and the culture there, they're actually setting strategic direction that determines what has business value. And then the people who are executing the agile teams have to take it upon themselves to make sure that whatever they're doing is going to add business value in that sense.   So, the role of leadership then becomes direction setting and visioning for the future and communicating the vision to the people who are working and providing feedback, you know, on whether things are actually adding business value or not . And that's the key responsibility. Now, in order to do that, in order to motivate people to deliver according to that idea of business value, there are certain techniques as a leader that you have to keep in mind, there are ways that you get people, you get a big organization to sort of follow you. And one of the ones that's become most important to me to think about after talking to a lot of leaders about how they're running their organizations, and what's working, is using middle management as a lever for accomplishing those things. So often, I'll talk to leaders of a business, and they'll say, our problem is the frozen middle, middle management is, you know, they're just not changing the way we want, we want to, we want to cause a big transformation, but middle management is getting in the way. And I tell them, ‘that's pretty much a myth.' You know, ‘that's not actually what's happening, let's look more closely at your organization.' Almost always, middle management is still trying to do the best they can, given the situation that they're in. And the way that you get them to align themselves behind the change is, you change their incentives or their role definition, or how you tell them what you're expecting from them, you don't say “change”, you know, and start doing X and Y, you change what success looks like for their position. And then they adapt to it by becoming engaged and finding ways to get there. So, there's almost always a leadership problem when you have that frozen middle effect. And, and I've seen it work really well that, you know, all of a sudden, you get this big leverage, because you just do a little bit of tweaking of role definitions, and bring everybody into solving the problem. And actually, there's an example, I love to talk about a history book, like I said before, I like to bring in other things, right? It's called the Engineers of Victory. And it's about World War Two, the Allies realized that they had to solve a set of problems, I think there was six or so problems. One of them was how do you land troops on a beach that's heavily defended? They realize they were just not going to be able to win the war until they could do that. But nobody knew how to do it. Because, you know, obviously, the bad guys are there on the beach, they're dug in, they put barbed wire everywhere, and mines, and you know, all this stuff. And it's just going to be a slaughter if you try to land on the beach. So, this book, Engineers of Victory, makes the case that what really won the war, was figuring out those solutions. And who was responsible for figuring out those solutions? It was middle management, basically. It was the, you know, within the structure of the army, it was the people not at the top who had big authority, you know, the generals, and it was not the troops themselves, because they weren't in a position to figure out these things. It was middle management that could see across different parts of the organization that could try things and see whether they worked or not, that, you know, essentially could run their own mini skunkworks projects. And eventually, they came up with the solutions to these problems. So, I think that's very encouraging for the role of middle management, you know, that a lot of problems have to be solved at that layer in order to pull off a transformation. And it really can be done. And this is a beautiful example of it. Ula Ojiaku:  It reminds me of, you know, my experience in a few transformation initiatives. So, the middle, the people who are termed to be in the frozen middle, are, like you said, they want to do what's best for the company, and they show up wanting to do their best work, but it's really about finding out, ‘Where do I fit in, (with) all this change that's happening?' You know, ‘if my role is going away, if the teams are going to be more empowered, that means I'm not telling them what to do, but then what do I do now?' So, the clarity of what the ‘New World' means for them, and what's in it for them, would help, you know, make them more effective. Mark Schwartz: And the mistake that's often made is to say to them, ‘start doing DevOps' or, you know, ‘start doing agile or something.' Because if you don't change the definition of success, or you don't change the incentives that, you know, then it's just, make work and they're going to resist it. You know, if you say your incentive is to get really fast feedback or you know, one of the other goals of DevOps, because of the following reasons, it helps the business this way, so let's try to reduce cycle time as much as possible for producing software. Okay, that's a change in the incentive, or the, you know, the definition of success, rather than just telling somebody you have to do DevOps, you know, read a book and figure it out. Ula Ojiaku:  So, what other books because you mentioned the Engineers of Victory, are there any other books you would recommend for the listener to go check out if they wanted to learn more about what we've talked about today? Mark Schwartz:  Well, I think, you know, obviously, my books referred to War and Peace by Tolstoy, Moby Dick, another great one. You know, you probably need to read my books to figure out why those are the right books to read and Engineers of Victory. As I said, I think that one's a great one. Within the field, there are some DevOps books that that I like a lot, of course, Gene Kim's books, The Phoenix Project, and now The Unicorn Project, the sequel to that. Because those are books that give you a feel for the motivation behind all the things that we do. The Mechanics of Things, there are plenty of books out there that help you learn the mechanics of how to do continuous integration and continuous delivery. And then the cloud is I think it's really transformative. You know, it's the cloud itself is a tremendous enabler. I work at AWS, of course but I'm not saying this because I work at AWS, it's more than I work at AWS because I believe these things. And my teammates have written some good books on the cloud. Reaching Cloud Velocity, for example, by Jonathan Allen and Thomas Blood is a great one for reading up on how the cloud can be transformative. But my other teammates, Gregor Hope, has written a number of books that are really good, Stephen Orban did A Head in the Cloud. So, I think those are all… should be at the top of people's reading lists. And then, of course, I recommend my books, because they make me laugh, and they might make you laugh, too. Ula Ojiaku:  Definitely made me laugh, but they've also given me things to think about from a new perspective. So, I totally agree. And so, where can people find you if they want to reach out to you? Mark Schwartz:  Yeah, LinkedIn is a great place to find me. If you're with a company that is an AWS customer, feel free to talk to your account manager, the sales team from AWS and ask them to put you in touch with me, is another easy way. LinkedIn is kind of where I organize my world from so find me there. Ula Ojiaku:  Okay. Sounds great. And any final words for the audience or for the listeners. Mark Schwartz:  Um, I, I have found that these things that you want to do to take advantage of the digital world, and I think we're all sort of pointing ourselves in that direction, there are these amazing things you can do in the digital world. They're sometimes challenging to get there, but it's very possible to get there. And one thing I've learned a lot at Amazon is the idea of working backwards, you know, you get that picture in your head for where you want to be and then you say to yourself, ‘I can get there. Let me work backwards and figure out what I have to do in order to get there.' And you might be wrong, you know, you should test hypotheses, you start moving in the right direction, and of course, correct as you need to. But you can do it with confidence that others are doing it and you can too no matter what your organization is, no matter how much you think you're a snowflake and you know different from every other organization. You can still do it. And with just some good intention and good thinking you can figure out how to how to get there. Ula Ojiaku:  Thank you so much, Mark. That was a great close for this conversation and again, I really appreciate your making the time for this interview. Thank you. Mark Schwartz: Thanks for having me. Ula Ojiaku: You're welcome.  

Should we look beyond technology organizations to learn essential lessons on how to innovate and run successful, complex technology organizations? Gene Kim believes so and contains unbridled curiosity for transformation across industries, as seen in his most recent book Wiring the Winning Organization. Gene Kim returns to share new lessons in change-making for leaders and companies tackling an array of challenges. Gene Kim is a bestselling author of several books on technology innovation, DevOps, and organizational strategy. He founded and served as CTO of Tripwire for thirteen years, an enterprise security software company, and is the founder of IT Revolution. Gene offers an engineering perspective with an executive-eye view. In this episode, Gene discusses being inspired by Toyota and his goal to lead great organizations toward the most effective, liberated problem-solving capabilities. He shares how coordination is the layer that is the difference-maker in a successful company and offers several case studies across industries. Gene highlights three key factors in a cohesive organization: 1) independence of action, 2) time (for practice and planning, and experimentation and implementation), and 3) actionable feedback that reaches the right people at the right time. Gene offers a metaphor from his book—moving a couch—that exemplifies his experience in communication and coordination. With this simple metaphor, Gene shares how small, cross-functional teams with the right number of collaborators are a great tool for success. Join Gene in Las Vegas from August 20 to 22, 2024, at the Enterprise Technology Leadership Summit (formerly DevOps Enterprise Summit). (01:40) – Gene Kim returns(04:22) – Layer three as difference-maker(09:22) – Healthcare case studies(11:55) – Three mechanisms for a cohesion(15:04) – The CheckBox Project(20:29) – “Slowification”(26:55) – “Great in the large, great in the small”(29:03) – Specialization of roles and coordination(34:34) – The technology leader's bossGene Kim is an author, researcher, and technology leader studying high-performing technology organizations since 1999. Gene founded and served as Chief Technology Officer of Tripwire, Inc. for thirteen years, an enterprise security software company. He is the WSJ bestselling author of Wiring the Winning Organization, The Unicorn Project, and co-author of The Phoenix Project, The DevOps Handbook, and the Shingo Publication Award-winning Accelerate. Since 2014, he has organized the Enterprise Technology Leadership Summit (formerly DevOps Enterprise Summit), studying the technology transformations of large, complex organizations.If you'd like to receive new episodes as they're published, please subscribe to Innovation and the Digital Enterprise in Apple Podcasts, Google Podcasts, Spotify, or wherever you get your podcasts. If

Today I'm talking to Gene Kim. Over the years Gene's work has had a huge influence on me. From books he authored and co-authored including The Unicorn Project, Phoenix Project, DevOps Handbook, and Accelerate, to his advocacy and community building with the DevOps Enterprise Summit, now called the Enterprise Technology Leadership Summit. I recently finished reading Gene's latest book Wiring the Winning Organization which he co-wrote with Steven Spear. The themes of slowification, simplification, and amplification have already started to seep into my day-to-day conversations. The book is filled with case studies, but also creative metaphors like Gene and Steven moving a couch, which is where our chat starts. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit cutlefish.substack.com

“What are the right ways that we can change that organizational wiring so that people can actually do work easily and well? That's really the goal and if you can make that happen, that is the key to high performance.” In this episode, Adam talks to Gene Kim, author of The Phoenix Project and The Unicorn Project, researcher, DevOps enthusiast, and founder of IT Revolution. The two discuss topics including the concept of the danger zone and the winning zone in organizations, the challenges and consequences of poor leadership on individuals and the broader organization, and the importance of codifying and sharing knowledge to drive positive change. Gene also shares his journey in the world of technology, what motivates him, and his advice for the SAFe community. Like what you hear? Connect with Gene on LinkedIn. Explore SAFe courses here.

What will the future bring to the workplace — and more importantly, how can organizations start adapting now? It's pretty clear by now that the way of working is changing rapidly. The eruption of generative AI greatly impacted how we see work, and its potential is enormous. There seems to be no limit to what it can do — and that's both exciting and frightening. But regardless of how we feel about it, there's a unifying thought popping into every leader's mind, "If we don't know how this will evolve, how can I prepare for it?" Gene Kim, author of "Wiring The Winning Organization," is here to help. In this webinar, he'll discuss, along with host Matt Beran, several ideas to wire your teams in a way flexible enough to adapt to the speed of change. In addition, they will explore multiple options to leverage automation and AI to build efficient IT services today. So, come join Gene and Matt in this webinar — and get a free AI tools map for service and support! Webinar topics: - Where we stand, and where the IT industry is heading. - How companies are working towards adaptability. - What the greatest organizations are doing TODAY to prepare for tomorrow. - The role of automation and AI in the future workplace. - How to create management systems that liberate people's minds. For the past 25 years, Gene Kim has been studying high-performing technology organizations. He is a Wall Street Journal bestselling author, researcher, and multiple award-winning CTO. He founded Tripwire, Inc. and acted as its CTO for 13 years. Some of his most famous books include "Wiring the Winning Organization," "The Unicorn Project," "The DevOps Handbook," and "The Phoenix Project."

How can leaders wire their organizations to win? Gene Kim explains that work consists of three layers - the objects we work on, the tools we use, and the social connections between people. Successful leaders focus on this third "social circuitry" layer to integrate functions, remove barriers, create independence between teams, amplify weak signals of failure, and practice "slowification" - strategically slowing down to speed up long-term results. He also introduces two other principles - "simplification" and "amplification." Simplification involves breaking down complex problems into manageable parts, while amplification focuses on creating a management system that ensures even the weakest signals of failure are detected and addressed early. Meet Gene Gene's Story: Gene Kim is the co-author of several influential books, including The Unicorn Project, The Phoenix Project, and The DevOps Handbook. His latest book is Wiring the Winning Organization. Gene was the founder and CTO of Tripwire, Inc for 13 years, an enterprise security software company. In 2014, he launched DevOps Enterprise Summit, an annual event that has attracted over 10,000 technology leaders to date. He has spoken at over 100 companies and conferences, including Apple, Target, IBM, Nike, Principal Financial, lululemon, and Microsoft. His books have sold over 1 million copies. https://itrevolution.com/ https://www.linkedin.com/in/realgenekim/   Book Recommendations Wiring the Winning Organization: Liberating Our Collective Greatness through Slowification, Simplification, and Amplification by Gene Kim and Steven J. Spear  Examining the shareholder wealth effects of announcements of newly created CIO positions by Dr. Vernon J Richardson  Like this? Creating Dream Teams with Mike Zani Nurturing a Team That Flourishes with Dan Pontefract The Science of High Performance Teams with Dr. David Burkus Join Our Community If you want to view our live podcast episodes, hear about new releases, or chat with others who enjoy this podcast join one of our communities below. Join the Facebook Group Join the LinkedIn Group   Leave a Review If you liked this conversation, we'd be thrilled if you'd let others know by leaving a review on Apple Podcasts. Here's a quick guide for posting a review. Review on Apple: https://remarkablepodcast.com/itunes    Podcast Better! Sign up with Libsyn and get up to 2 months free! Use promo code: RLP  

As a special treat in what we think is our 50th studio episode, we have an extended conversation with none other than Gene Kim, industry thought leader and author of The DevOps Handbook, the seminal Pheonix Project, the Unicorn Project, and now Wiring the winning organisation.  Gene is one of the true thought leaders in modern tech and its exciting to explore the themes of Cloud Realties with him!The gang talk about Genes early work, then deep dive into his new work, which reaches outside the realms of tech and talks about what it takes to become a modern organisation. TLDR:01:00 Easy to let facts get in the way of a good story04:30 Extended cloud conversation with Gene Kim 43:10 Playing with AI! GuestGene Kim: https://www.linkedin.com/in/realgenekim/HostsDave Chapman: https://www.linkedin.com/in/chapmandr/Sjoukje Zaal: https://www.linkedin.com/in/sjoukjezaal/Rob Kernahan: https://www.linkedin.com/in/rob-kernahan/ProductionMarcel Van Der Burg: https://www.linkedin.com/in/marcel-van-der-burg-99a655/Dave Chapman: https://www.linkedin.com/in/chapmandr/SoundBen Corbett: https://www.linkedin.com/in/ben-corbett-3b6a11135/Louis Corbett:  https://www.linkedin.com/in/louis-corbett-087250264/

Gene Kim (@RealGeneKim, Author, Organizational Operations Researcher) talks about the challenges of organizing a team, group, or company to be successful in simple and complex tasks. SHOW: 789CLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotwNEW TO CLOUD? CHECK OUT OUR OTHER PODCAST - "CLOUDCAST BASICS"SHOW SPONSORS:Learn More About Azure Offerings : Learn more about Azure Migrate and Modernize & Azure Innovate!Azure Free Cloud Resource Kit : Step-by-step guidance, resources and expert advice, from migration to innovation.CloudZero – Cloud Cost Visibility and Savings​​CloudZero provides immediate and ongoing savings with 100% visibility into your total cloud spendSHOW NOTES:Wiring the Winning Organization (book) (w/ Steven Spear)The Unicorn Project (homepage)The Unicorn Project (resource guide)The Unicorn Project on The Cloudcast (Eps. 433)The Phoenix Project on The Cloudcast (Eps.79)The DevOps HandbookDevOps Enterprise Summit (event)Topic 1 - Welcome back. It's been way too long. What have you been up to lately? Tell us a little bit about your co-author and where the research for this book came from.Topic 2 - This is a different type of book than The Phoenix Project or Unicorn Project, in that it seems more about managerial structure and research than the inspirational story-telling of past books. Is this addressing a different audience, or you felt that it needed a different framework to make the biggest impact? Topic 3 - At the core of the book are three concepts, amplification (where are the problems) which results in slowificaion (create space for problem solving) and simplification (make problems themselves easier to solve). Walk us through each of these. Topic 4 - As I was reading this book, the thing that jumped out at me the most was the importance of alignment between problem scope, how teams or individuals were aligned, and how much flexibility could be given to different parts of the problem/solution. Topic 5 - The Phoenix and Unicorn Projects inspired a generation of IT professionals to be the champion of the change in their organization. What feedback have you gotten from the readers of Wiring the Winning Organization so far? Topic 6 - These days everyone wants learnings to be quick and with immediate results. Is there a TikTok version of the learnings from this book that anyone could use immediately? FEEDBACK?Email: show at the cloudcast dot netTwitter: @cloudcastpodInstagram: @cloudcastpodTikTok: @cloudcastpod

Phoenix Project author, Gene Kim, is back on Troubleshooting Agile to discuss the groundbreaking theories of organizational management described in his new book, Wiring the Winning Organization. In this episode (part three of three), Gene discusses how and why you should be "simplifying” and “amplifying" in your DevOps team. Links: - Wiring the Winning Organization: https://itrevolution.com/product/wiring-the-winning-organization/ - Twitter: https://twitter.com/RealGeneKim - LinkedIn: https://www.linkedin.com/in/realgenekim/ - Steve Yegge Amazon Platform Rant: https://gist.github.com/chitchcock/1281611 - Investments Unlimited: https://itrevolution.com/product/investments-unlimited/ - Nyquist–Shannon sampling theorem https://en.wikipedia.org/wiki/Nyquist–Shannon_sampling_theorem - High Output Management: https://bookshop.org/p/books/high-output-management-andrew-s-grove/6730629 - Ratio (cookbook) https://bookshop.org/p/books/ratio-the-simple-codes-behind-the-craft-of-everyday-cooking-michael-ruhlman/8881759 -------------------------------------------------- About Our Guest Gene Kim is a Wall Street Journal bestselling author, researcher, and multiple award-winning CTO. He has been studying high-performing technology organizations since 1999 and was the founder and CTO of Tripwire for 13 years. He is the author of six books, The Unicorn Project (2019), and co-author of the Shingo Publication Award winning Accelerate (2018), The DevOps Handbook (2016), and The Phoenix Project (2013). Since 2014, he has been the founder and organizer of DevOps Enterprise Summit, studying the technology transformations of large, complex organizations. -------------------------------------------------- Order your copy of our book, Agile Conversations at agileconversations.com Plus, get access to a free mini training video about the technique of Coherence Building when you join our mailing list. We'd love to hear any thoughts, ideas, or feedback you have about the show. Email us at info@agileconversations.com -------------------------------------------------- About Your Hosts Douglas Squirrel and Jeffrey Fredrick first met while working together at TIM group in 2013. A decade later, they remain united in their passion for growing organisations through better conversations. Squirrel is an advisor, author, keynote speaker, coach, and consultant, helping companies of all sizes make huge, profitable improvements in their culture, skills, and processes. You can find out more about his work here: https://douglassquirrel.com/index.html Jeffrey is Vice President of Engineering at ION Analytics, Organiser at CITCON, the Continuous Integration and Testing Conference, author and speaker. You can connect with him here: https://www.linkedin.com/in/jfredrick/

Register here to win an "Introduction to ESM" book: https://bit.ly/3RMDADo! Same as every year, December arrives with trends, predictions, and the need to try to take a glimpse at the future. For the IT industry in particular, 2023 brought several changes – and a few game-changers. The eruption of AI is clearly a hot topic, and we have also witnessed a more profound shift towards experience, as well as a focus on capabilities and measuring value. And since we're not fortune-tellers, we brought a panel of experts to reveal what's in store for 2024 in the IT Service Management world. Should we be prepared for another groundbreaking innovation? Is there something else we need to prepare for? Only time will tell – but you can listen for some spoilers and predictions! Rob England, Claire Agutter, and Mark Smalley join Matt Beran to discuss the future of Service Management, specifically focusing on IT and other shared service functions. Formerly known as “The IT Skeptic”, Rob England is an active contributor to ITIL Service Strategy, The Unicorn Project, The Agile Manager, Open Management, The DevOps Handbook, a lead author of the VeriSM digital framework. Claire Agutter is currently the Director at ITSM Zone and Scopism. She's a Service Management trainer, consultant, author, and Chief Architect for VeriSM. She was recognized as an HDI Top 25 Thought Leader in 2018 and 2019 and was nominated as one of Computer Weekly's 50 Women in Tech. Self-defined as The IT Paradigmologist, Mark Smalley is an ITIL author and co-author, IT Management consultant and trainer, advisor, and former ambassador of organizations such as DevOps Agile Skills Association and ASL BiSL Foundation.

Phoenix Project author, Gene Kim, is back on Troubleshooting Agile to discuss the groundbreaking theories of organizational management described in his new book, Wiring the Winning Organization. In this episode (part two of three), Gene describes the “Danger Zone”, and the first of three mechanisms for exiting the high-risk zone: Slowification. Links: - Wiring the Winning Organization: https://itrevolution.com/product/wiring-the-winning-organization/ - Twitter: https://twitter.com/RealGeneKim - LinkedIn: https://www.linkedin.com/in/realgenekim/ - The MIT Sailing System: https://videos.itrevolution.com/watch/871558334/ - Look Back Less: https://world.hey.com/jason/look-back-less-848e9db0 -------------------------------------------------- About Our Guest Gene Kim is a Wall Street Journal bestselling author, researcher, and multiple award-winning CTO. He has been studying high-performing technology organizations since 1999 and was the founder and CTO of Tripwire for 13 years. He is the author of six books, The Unicorn Project (2019), and co-author of the Shingo Publication Award winning Accelerate (2018), The DevOps Handbook (2016), and The Phoenix Project (2013). Since 2014, he has been the founder and organizer of DevOps Enterprise Summit, studying the technology transformations of large, complex organizations. -------------------------------------------------- Order your copy of our book, Agile Conversations at agileconversations.com Plus, get access to a free mini training video about the technique of Coherence Building when you join our mailing list. We'd love to hear any thoughts, ideas, or feedback you have about the show. Email us at info@agileconversations.com -------------------------------------------------- About Your Hosts Douglas Squirrel and Jeffrey Fredrick first met while working together at TIM group in 2013. A decade later, they remain united in their passion for growing organisations through better conversations. Squirrel is an advisor, author, keynote speaker, coach, and consultant, helping companies of all sizes make huge, profitable improvements in their culture, skills, and processes. You can find out more about his work here: https://douglassquirrel.com/index.html Jeffrey is Vice President of Engineering at ION Analytics, Organiser at CITCON, the Continuous Integration and Testing Conference, author and speaker. You can connect with him here: https://www.linkedin.com/in/jfredrick/

Phoenix Project author, Gene Kim, joins us on Troubleshooting Agile to discuss the groundbreaking theories of organizational management described in his new book, Wiring the Winning Organization. In this episode (part one of three), Gene talks about his mission to improve the way work is done at the world's largest organizations, how that led to his collaboration with coauthor Dr. Steven Spear, and their “parsimonious” theories of workplace organization. Links: Wiring the Winning Organization: https://itrevolution.com/product/wiring-the-winning-organization/ Twitter: https://twitter.com/RealGeneKim - LinkedIn: https://www.linkedin.com/in/realgenekim/ -------------------------------------------------- About Our Guest Gene Kim is a Wall Street Journal bestselling author, researcher, and multiple award-winning CTO. He has been studying high-performing technology organizations since 1999 and was the founder and CTO of Tripwire for 13 years. He is the author of six books, The Unicorn Project (2019), and co-author of the Shingo Publication Award winning Accelerate (2018), The DevOps Handbook (2016), and The Phoenix Project (2013). Since 2014, he has been the founder and organizer of DevOps Enterprise Summit, studying the technology transformations of large, complex organizations. -------------------------------------------------- Order your copy of our book, Agile Conversations at agileconversations.com Plus, get access to a free mini training video about the technique of Coherence Building when you join our mailing list. We'd love to hear any thoughts, ideas, or feedback you have about the show. Email us at info@agileconversations.com -------------------------------------------------- About Your Hosts Douglas Squirrel and Jeffrey Fredrick first met while working together at TIM group in 2013. A decade later, they remain united in their passion for growing organisations through better conversations. Squirrel is an advisor, author, keynote speaker, coach, and consultant, helping companies of all sizes make huge, profitable improvements in their culture, skills, and processes. You can find out more about his work here: https://douglassquirrel.com/index.html Jeffrey is Vice President of Engineering at ION Analytics, Organiser at CITCON, the Continuous Integration and Testing Conference, author and speaker. You can connect with him here: https://www.linkedin.com/in/jfredrick/

Episode page with video, transcript, and more My guests for Episode #493 of the Lean Blog Interviews Podcast are Gene Kim and Steve Spear, co-authors of the new book Wiring the Winning Organization: Liberating Our Collective Greatness through Slowification, Simplification, and Amplification. Joining us for the first time is Gene Kim, a Wall Street Journal bestselling author, researcher who has been studying high-performing technology organizations since 1999 – He was the founder and CTO of Tripwire for 13 years. He is the author of six books, The Unicorn Project (2019), and co-author of the Shingo Publication Award-winning Accelerate (2018), The DevOps Handbook (2016), and The Phoenix Project (2013). Since 2014, he has been the founder and organizer of DevOps Enterprise Summit, (now the Enterprise Technology Leadership Summit) studying the technology transformations of large, complex organizations. He lives in Portland, OR, with his wife and family. Dr. Steven J. Spear, DBA, MS, MS is a senior lecturer at the MIT Sloan School of Management, a Senior Fellow at the Institute for Healthcare Improvement, and author of influential publications like the book The High-Velocity Edge, and the HBR articles “Decoding the DNA of the Toyota Production System,” and “Fixing Healthcare from the Inside, Today.”  An advisor to corporate and governmental leaders across a range of fields, he is also the founder of See to Solve, a business process software company. He has a doctorate from Harvard, masters degrees in mechanical engineering and management from MIT, and a bachelor's degree in economics from Princeton.  Steve was previously a guest give times in episodes 58, 87, 262, 358, and 386. Questions, Notes, and Highlights: Gene — what's your “Lean” origin story or however you would frame or label it? Steve — what's a key highlight of your Lean origin story? “The ultimate learning machine” – Toyota Backstory on working together on this book? How many copied 2 pizza teams from Amazon and failed?? What puts some companies in the “danger zone” and how is that detected if it's not obvious? The andon cord was a way to speak up Steve – see, solve, share? A 4th step? See, safe to speak, solve, share? You write about recurring problems in a workplace. How do you think the behavior of managers punishing people for problems gets in the way of solving problems? The podcast is sponsored by Stiles Associates, now in its 30th year of business. They are the go-to Lean recruiting firm serving the manufacturing, private equity, and healthcare industries. Learn more. This podcast was also brought to you by Arena, a PTC Business. Arena is the proven market leader in Cloud Product Lifecycle Management (PLM) with over 1,400 customers worldwide. Visit the link arenasolutions.com/lean to learn more about how Arena can help speed product releases with one connected system. This podcast is part of the #LeanCommunicators network.   

Legends don't need introductions, but I'll write a light one, nevertheless. Gene Kim is the author or co-author of many significant books from DevOps space (The Phoenix Project, The Unicorn Project, Accelerate, The DevOps Handbook, to name a few) and the mastermind behind the amazing DevOps Enterprise Summit conference. I spoke with Gene about rewiring our organizations to set them for success.

Esta semana en Discovering Tech Stories #103 tenemos una nueva cita con nuestro compañero Marcel Gozalbo, co-founder & CTO de Opground, que entrevistará a Business Intelligence Analyst @ Unicorn Project. Repasamos toda la experiencia de nuestra invitada a través de sus primeros pasos y el desarrollo de su carrera. Deja like, comenta y suscríbete a nuestras redes sociales a través de Opground, el primer reclutador virtual, para estar al día de todas las novedades de DISCOVERING TECH STORIES. Web: https://opground.com YouTube: https://www.youtube.com/@opground_ai/playlists?sub_confirmation=1 Spotify: https://open.spotify.com/show/0sXMqFKJDxJu5XDn2NeH0B?si=kG3aYbA-QzamOmkVqx7T0Q&nd=1 Apple Podcast: https://podcasts.apple.com/es/podcast/discovering-tech-stories/id1557637563?l=es #discoveringtechstories #opground #developers #entrevista

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)

Direct .mp3 file download. We talk with Ryan Price about how to start a new Drupal project the right way, including development environment setup, code base setup, initial modules, Git setup, and common newbie mistakes. URLs mentioned Docksal DDEV drupal/recommended-project Composer template Admin Toolbar Devel phpcs, phpcbf Pathauto Redirect Metatag Webform The Phoenix Project The Unicorn Project DrupalEasy News Professional module development - 15 weeks, 90 hours, live, online course. Drupal Career Online - 12 weeks, 77 hours, live online, beginner-focused course. Audio transcript We're using the machine-driven Amazon Transcribe service to provide an audio transcript of this episode. Subscribe Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher. If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

CJ & The Duke decide to just hit the record button and run with it.  This jam session covered the following:Iterative DevelopmentRecombination & InnovationPerils of Context SwitchingPursuing the Unicorn ProjectOffshoring and International ConsultingPricing Your WorkVery special thanks to our sponsor, Clear Skye the optimized identity governance & security solution built natively on ServiceNow.ABOUT USCory and Robert are vendor agnostic freelance ServiceNow architects.Cory is the founder of TekVoyant.Robert is the founder of The Duke Digital MediaSponsor Us!

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.

About AmyAmy Tobey has worked in tech for more than 20 years at companies of every size, working with everything from kernel code to user interfaces. These days she spends her time building an innovative Site Reliability Engineering program at Equinix, where she is a principal engineer. When she's not working, she can be found with her nose in a book, watching anime with her son, making noise with electronics, or doing yoga poses in the sun.Links Referenced: Equinix Metal: https://metal.equinix.com Personal Twitter: https://twitter.com/MissAmyTobey Personal Blog: https://tobert.github.io/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by our friends at Vultr. Optimized cloud compute plans have landed at Vultr to deliver lightning-fast processing power, courtesy of third-gen AMD EPYC processors without the IO or hardware limitations of a traditional multi-tenant cloud server. Starting at just 28 bucks a month, users can deploy general-purpose, CPU, memory, or storage optimized cloud instances in more than 20 locations across five continents. Without looking, I know that once again, Antarctica has gotten the short end of the stick. Launch your Vultr optimized compute instance in 60 seconds or less on your choice of included operating systems, or bring your own. It's time to ditch convoluted and unpredictable giant tech company billing practices and say goodbye to noisy neighbors and egregious egress forever. Vultr delivers the power of the cloud with none of the bloat. “Screaming in the Cloud” listeners can try Vultr for free today with a $150 in credit when they visit getvultr.com/screaming. That's G-E-T-V-U-L-T-R dot com slash screaming. My thanks to them for sponsoring this ridiculous podcast.Corey: Finding skilled DevOps engineers is a pain in the neck! And if you need to deploy a secure and compliant application to AWS, forgettaboutit! But that's where DuploCloud can help. Their comprehensive no-code/low-code software platform guarantees a secure and compliant infrastructure in as little as two weeks, while automating the full DevSecOps lifestyle. Get started with DevOps-as-a-Service from DuploCloud so that your cloud configurations are done right the first time. Tell them I sent you and your first two months are free. To learn more visit: snark.cloud/duplo. Thats's snark.cloud/D-U-P-L-O-C-L-O-U-D.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Every once in a while I catch up with someone that it feels like I've known for ages, and I realize somehow I have never been able to line up getting them on this show as a guest. Today is just one of those days. And my guest is Amy Tobey who has been someone I've been talking to for ages, even in the before-times, if you can remember such a thing. Today, she's a Senior Principal Engineer at Equinix. Amy, thank you for finally giving in to my endless wheedling.Amy: Thanks for having me. You mentioned the before-times. Like, I remember it was, like, right before the pandemic we had beers in San Francisco wasn't it? There was Ian there—Corey: Yeah, I—Amy: —and a couple other people. It was a really great time. And then—Corey: I vaguely remember beer. Yeah. And then—Amy: And then the world ended.Corey: Oh, my God. Yes. It's still March of 2020, right?Amy: As far as I know. Like, I haven't checked in a couple years.Corey: So, you do an awful lot. And it's always a difficult question to ask someone, so can you encapsulate your entire existence in a paragraph? It's—Amy: [sigh].Corey: —awful, so I'd like to give a bit more structure to it. Let's start with the introduction: You are a Senior Principal Engineer. We know it's high level because of all the adjectives that get put in there, and none of those adjectives are ‘associate' or ‘beginner' or ‘junior,' or all the other diminutives that companies like to play games with to justify paying people less. And you're at Equinix, which is a company that is a bit unlike most of the, shall we say, traditional cloud providers. What do you do over there and both as a company, as a person?Amy: So, as a company Equinix, what most people know about is that we have a whole bunch of data centers all over the world. I think we have the most of any company. And what we do is we lease out space in that data center, and then we have a number of other products that people don't know as well, which one is Equinix Metal, which is what I specifically work on, where we rent you bare-metal servers. None of that fancy stuff that you get any other clouds on top of it, there's things you can get that are… partner things that you can add-on, like, you know, storage and other things like that, but we just deliver you bare-metal servers with really great networking. So, what I work on is the reliability of that whole system. All of the things that go into provisioning the servers, making them come up, making sure that they get delivered to the server, make sure the API works right, all of that stuff.Corey: So, you're on the Equinix cloud side of the world more so than you are on the building data centers by the sweat of your brow, as they say?Amy: Correct. Yeah, yeah. Software side.Corey: Excellent. I spent some time in data centers in the early part of my career before cloud ate that. That was sort of cotemporaneous with the discovery that I'm the hardware destruction bunny, and I should go to great pains to keep my aura from anything expensive and important, like, you know, the SAN. So—Amy: Right, yeah.Corey: Companies moving out of data centers, and me getting out was a great thing.Amy: But the thing about SANs though, is, like, it might not be you. They're just kind of cursed from the start, right? They just always were kind of fussy and easy to break.Corey: Oh, yeah. I used to think—and I kid you not—that I had a limited upside to my career in tech because I sometimes got sloppy and I was fairly slow at crimping ethernet cables.Amy: [laugh].Corey: That is very similar to growing up in third grade when it became apparent that I was going to have problems in my career because my handwriting was sloppy. Yeah, it turns out the future doesn't look like we predicted it would.Amy: Oh, gosh. Are we going to talk about, like, neurological development now or… [laugh] okay, that's a thing I struggle with, too right, is I started typing as soon as they would let—in fact, before they would let me. I remember in high school, I had teachers who would grade me down for typing a paper out. They want me to handwrite it and I would go, “Cool. Go ahead and take a grade off because if I handwrite it, you're going to take two grades off my handwriting, so I'm cool with this deal.”Corey: Yeah, it was pretty easy early on. I don't know when the actual shift was, but it became more and more apparent that more and more things are moving towards a world where you could type. And I was almost five when I started working on that stuff, and that really wound up changing a lot of aspects of how I started seeing things. One thing I think you're probably fairly well known for is incidents. I want to be clear when I say that you are not the root cause as—“So, why are things broken?” “It's Amy again. What's she gotten into this time?” Great.Amy: [laugh]. But it does happen, but not all the time.Corey: Exa—it's a learning experience.Amy: Right.Corey: You've also been deeply involved with SREcon and a number of—a lot of aspects of what I will term—and please don't yell at me for this—SRE culture—Amy: Yeah.Corey: Which is sometimes a challenging thing to wind up describing or putting a definition around. The one that I've always been somewhat partial to is, “SRE is DevOps, except you worked at Google for a while.” I don't know how necessarily accurate that is, but it does rile people up.Amy: Yeah, it does. Dave Stanke actually did a really great talk at SREcon San Francisco just a couple weeks ago, about the DORA report. And the new DORA report, they split SRE out into its own function and kind of is pushing against that old model, which actually comes from Liz Fong-Jones—I think it's from her, or older—about, like, class SRE implements DevOps, which is kind of this idea that, like, SREs make DevOps happen. Things have evolved, right, since then. Things have evolved since Google released those books, and we're all just figured out what works and what doesn't a little bit.And so, it's not that we're implementing DevOps so much. In fact, it's that ops stuff that kind of holds us back from the really high impact work that SREs, I think, should be doing, that aren't just, like, fixing the problems, the symptoms down at the bottom layer, right? Like what we did as sysadmins 20 years ago. You know, we'd go and a lot of people are SREs that came out of the sysadmin world and still think in that mode, where it's like, “Well, I set up the systems, and when things break, I go and I fix them.” And, “Why did the developers keep writing crappy code? Why do I have to always getting up in the middle of the night because this thing crashed?”And it turns out that the work we need to do to make things more reliable, there's a ceiling to how far away the platform can take us, right? Like, we can have the best platform in the world with redundancy, and, you know, nine-way replicated data storage and all this crazy stuff, and still if we put crappy software on top, it's going to be unreliable. So, how do we make less crappy software? And for most of my career, people would be, like, “Well, you should test it.” And so, we started doing that, and we still have crappy software, so what's going on here? We still have incidents.So, we write more tests, and we still have incidents. We had a QA group, we still have incidents. We send the developers to training, and we still have incidents. So like, what is the thing we need to do to make things more reliable? And it turns out, most of it is culture work.Corey: My perspective on this stems from being a grumpy old sysadmin. And at some point, I started calling myself a systems engineer or DevOps or production engineer, or SRE. It was all from my point of view, the same job, but you know, if you call yourself a sysadmin, you're just asking for a 40% pay cut off the top.Amy: [laugh].Corey: But I still tended to view the world through that lens. I tended to be very good at Linux systems internals, for example, understanding system calls and the rest, but increasingly, as the DevOps wave or SRE wave, or Google-isation of the internet wound up being more and more of a thing, I found myself increasingly in job interviews, where, “Great, now, can you go wind up implementing a sorting algorithm on the whiteboard?” “What on earth? No.” Like, my lingua franca is shitty Bash, and no one tends to write that without a bunch of tab completions and quick checking with manpages—die.net or whatnot—on the fly as you go down that path.And it was awful, and I felt… like my skill set was increasingly eroding. And it wasn't honestly until I started this place where I really got into writing a fair bit of code to do different things because it felt like an orthogonal skill set, but the fullness of time, it seems like it's not. And it's a reskilling. And it made me wonder, does this mean that the areas of technology that I focused on early in my career, was that all a waste? And the answer is not really. Sometimes, sure, in that I don't spend nearly as much time worrying about inodes—for example—as I once did. But every once in a while, I'll run into something and I looked like a wizard from the future, but instead, I'm a wizard from the past.Amy: Yeah, I find that a lot in my work, now. Sometimes things I did 20 years ago, come back, and it's like, oh, yeah, I remember I did all that threading work in 2002 in Perl, and I learned everything the very, very, very hard way. And then, you know, this January, did some threading work to fix some stability issues, and all of it came flooding back, right? Just that the experiences really, more than the code or the learning or the text and stuff; more just the, like, this feels like threads [BLEEP]-ery. Is a diagnostic thing that sometimes we have to say.And then people are like, “Can you prove it?” And I'm like, “Not really,” because it's literally thread [BLEEP]-ery. Like, the definition of it is that there's weird stuff happening that we can't figure out why it's happening. There's something acting in the system that isn't synchronized, that isn't connected to other things, that's happening out of order from what we expect, and if we had a clear signal, we would just fix it, but we don't. We just have, like, weird stuff happening over here and then over there and over there and over there.And, like, that tells me there's just something happening at that layer and then have to go and dig into that right, and like, just basically charge through. My colleagues are like, “Well, maybe you should look at this, and go look at the database,” the things that they're used to looking at and that their experiences inform, whereas then I bring that ancient toiling through the threading mines experiences back and go, “Oh, yeah. So, let's go find where this is happening, where people are doing dangerous things with threads, and see if we can spot something.” But that came from that experience.Corey: And there's so much that just repeats itself. And history rhymes. The challenge is that, do you have 20 years of experience, or do you have one year of experience repeated 20 times? And as the tide rises, doing the same task by hand, it really is just a matter of time before your full-time job winds up being something a piece of software does. An easy example is, “Oh, what's your job?” “I manually place containers onto specific hosts.” “Well, I've got news for you, and you're not going to like it at all.”Amy: Yeah, yeah. I think that we share a little bit. I'm allergic to repeated work. I don't know if allergic is the right word, but you know, if I sit and I do something once, fine. Like, I'll just crank it out, you know, it's this form, or it's a datafile I got to write and I'll—fine I'll type it in and do the manual labor.The second time, the difficulty goes up by ten, right? Like, just mentally, just to do it, be like, I've already done this once. Doing it again is anathema to everything that I am. And then sometimes I'll get through it, but after that, like, writing a program is so much easier because it's like exponential, almost, growth in difficulty. You know, the third time I have to do the same thing that's like just typing the same stuff—like, look over here, read this thing and type it over here—I'm out; I can't do it. You know, I got to find a way to automate. And I don't know, maybe normal people aren't driven to live this way, but it's kept me from getting stuck in those spots, too.Corey: It was weird because I spent a lot of time as a consultant going from place to place and it led to some weird changes. For example, “Oh, thank God, I don't have to think about that whole messaging queue thing.” Sure enough, next engagement, it's message queue time. Fantastic. I found that repeating myself drove me nuts, but you also have to be very sensitive not to wind up, you know, stealing IP from the people that you're working with.Amy: Right.Corey: But what I loved about the sysadmin side of the world is that the vast majority of stuff that I've taken with me, lives in my shell config. And what I mean by that is I'm not—there's nothing in there is proprietary, but when you have a weird problem with trying to figure out the best way to figure out which Ruby process is stealing all the CPU, great, turns out that you can chain seven or eight different shell commands together through a bunch of pipes. I don't want to remember that forever. So, that's the sort of thing I would wind up committing as I learned it. I don't remember what company I picked that up at, but it was one of those things that was super helpful.I have a sarcastic—it's a one-liner, except no sane editor setting is going to show it in any less than three—of a whole bunch of Perl, piped into du, piped into the rest, that tells you one of the largest consumers of files in a given part of the system. And it rates them with stars and it winds up doing some neat stuff. I would never sit down and reinvent something like that today, but the fact that it's there means that I can do all kinds of neat tricks when I need to. It's making sure that as you move through your career, on some level, you're picking up skills that are repeatable and applicable beyond one company.Amy: Skills and tooling—Corey: Yeah.Amy: —right? Like, you just described the tool. Another SREcon talk was John Allspaw and Dr. Richard Cook talking about above the line; below the line. And they started with these metaphors about tools, right, showing all the different kinds of hammers.And if you're a blacksmith, a lot of times you craft specialized hammers for very specific jobs. And that's one of the properties of a tool that they were trying to get people to think about, right, is that tools get crafted to the job. And what you just described as a bespoke tool that you had created on the fly, that kind of floated under the radar of intellectual property. [laugh].So, let's not tell the security or IP people right? Like, because there's probably billions and billions of dollars of technically, like, made-up IP value—I'm doing air quotes with my fingers—you know, that's just basically people's shell profiles. And my God, the Emacs automation that people have done. If you've ever really seen somebody who's amazing at Emacs and is 10, 20, 30, maybe 40 years of experience encoded in their emacs settings, it's a wonder to behold. Like, I look at it and I go, “Man, I wish I could do that.”It's like listening to a really great guitar player and be like, “Wow, I wish I could play like them.” You see them just flying through stuff. But all that IP in there is both that person's collection of wisdom and experience and working with that code, but also encodes that stuff like you described, right? It's just all these little systems tricks and little fiddly commands and things we don't want to remember and so we encode them into our toolset.Corey: Oh, yeah. Anything I wound up taking, I always would share it with people internally, too. I'd mention, “Yeah, I'm keeping this in my shell files.” Because I disclosed it, which solves a lot of the problem. And also, none of it was even close to proprietary or anything like that. I'm sorry, but the way that you wind up figuring out how much of a disk is being eaten up and where in a more pleasing way, is not a competitive advantage. It just isn't.Amy: It isn't to you or me, but, you know, back in the beginning of our careers, people thought it was worth money and should be proprietary. You know, like, oh, that disk-checking script as a competitive advantage for our company because there are only a few of us doing this work. Like, it was actually being able to, like, manage your—[laugh] actually manage your servers was a competitive advantage. Now, it's kind of commodity.Corey: Let's also be clear that the world has moved on. I wound up buying a DaisyDisk a while back for Mac, which I love. It is a fantastic, pretty effective, “Where's all the stuff on your disk going?” And it does a scan and you can drive and collect things and delete them when trying to clean things out. I was using it the other day, so it's top of mind at the moment.But it's way more polished than that crappy Perl three-liner. And I see both sides, truly I do. The trick also, for those wondering [unintelligible 00:15:45], like, “Where is the line?” It's super easy. Disclose it, what you're doing, in those scenarios in the event someone is no because they believe that finding the right man page section for something is somehow proprietary.Great. When you go home that evening in a completely separate environment, build it yourself from scratch to solve the problem, reimplement it and save that. And you're done. There are lots of ways to do this. Don't steal from your employer, but your employer employs you; they don't own you and the way that you think about these problems.Every person I've met who has had a career that's longer than 20 minutes has a giant doc somewhere on some system of all of the scripts that they wound up putting together, all of the one-liners, the notes on, “Next time you see this, this is the thing to check.”Amy: Yeah, the cheat sheet or the notebook with all the little commands, or again the Emacs config, sometimes for some people, or shell profiles. Yeah.Corey: Here's the awk one-liner that I put that automatically spits out from an Apache log file what—the httpd log file that just tells me what are the most frequent talkers, and what are the—Amy: You should probably let go of that one. You know, like, I think that one's lifetime is kind of past, Corey. Maybe you—Corey: I just have to get it working with Nginx, and we're good to go.Amy: Oh, yeah, there you go. [laugh].Corey: Or S3 access logs. Perish the thought. But yeah, like, what are the five most high-volume talkers, and what are those relative to each other? Huh, that one thing seems super crappy and it's coming from Russia. But that's—hmm, one starts to wonder; maybe it's time to dig back in.So, one of the things that I have found is that a lot of the people talking about SRE seem to have descended from an ivory tower somewhere. And they're talking about how some of the best-in-class companies out there, renowned for their technical cultures—at least externally—are doing these things. But there's a lot more folks who are not there. And honestly, I consider myself one of those people who is not there. I was a competent engineer, but never a terrific one.And looking at the way this was described, I often came away thinking, “Okay, it was the purpose of this conference talk just to reinforce how smart people are, and how I'm not,” and/or, “There are the 18 cultural changes you need to make to your company, and then you can do something kind of like we were just talking about on stage.” It feels like there's a combination of problems here. One is making this stuff more accessible to folks who are not themselves in those environments, and two, how to drive cultural change as an individual contributor if that's even possible. And I'm going to go out on a limb and guess you have thoughts on both aspects of that, and probably some more hit me, please.Amy: So, the ivory tower, right. Let's just be straight up, like, the ivory tower is Google. I mean, that's where it started. And we get it from the other large companies that, you know, want to do conference talks about what this stuff means and what it does. What I've kind of come around to in the last couple of years is that those talks don't really reach the vast majority of engineers, they don't really apply to a large swath of the enterprise especially, which is, like, where a lot of the—the bulk of our industry sits, right? We spend a lot of time talking about the darlings out here on the West Coast in high tech culture and startups and so on.But, like, we were talking about before we started the show, right, like, the interior of even just America, is filled with all these, like, insurance and banks and all of these companies that are cranking out tons of code and servers and stuff, and they're trying to figure out the same problems. But they're structured in companies where their tech arm is still, in most cases, considered a cost center, often is bundled under finance, for—that's a whole show of itself about that historical blunder. And so, the tech culture is tend to be very, very different from what we experience in—what do we call it anymore? Like, I don't even want to say West Coast anymore because we've gone remote, but, like, high tech culture we'll say. And so, like, thinking about how to make SRE and all this stuff more accessible comes down to, like, thinking about who those engineers are that are sitting at the computers, writing all the code that runs our banks, all the code that makes sure that—I'm trying to think of examples that are more enterprise-y right?Or shoot buying clothes online. You go to Macy's for example. They have a whole bunch of servers that run their online store and stuff. They have internal IT-ish people who keep all this stuff running and write that code and probably integrating open-source stuff much like we all do. But when you go to try to put in a reliability program that's based on the current SRE models, like SLOs; you put in SLOs and you start doing, like, this incident management program that's, like, you know, you have a form you fill out after every incident, and then you [unintelligible 00:20:25] retros.And it turns out that those things are very high-level skills, skills and capabilities in an organization. And so, when you have this kind of IT mindset or the enterprise mindset, bringing the culture together to make those things work often doesn't happen. Because, you know, they'll go with the prescriptive model and say, like, okay, we're going to implement SLOs, we're going to start measuring SLIs on all of the services, and we're going to hold you accountable for meeting those targets. If you just do that, right, you're just doing more gatekeeping and policing of your tech environment. My bet is, reliability almost never improves in those cases.And that's been my experience, too, and why I get charged up about this is, if you just go slam in these practices, people end up miserable, the practices then become tarnished because people experienced the worst version of them. And then—Corey: And with the remote explosion as well, it turns out that changing jobs basically means their company sends you a different Mac, and the next Monday, you wind up signing into a different Slack team.Amy: Yeah, so the culture really matters, right? You can't cover it over with foosball tables and great lunch. You actually have to deliver tools that developers want to use and you have to deliver a software engineering culture that brings out the best in developers instead of demanding the best from developers. I think that's a fundamental business shift that's kind of happening. If I'm putting on my wizard hat and looking into the future and dreaming about what might change in the world, right, is that there's kind of a change in how we do leadership and how we do business that's shifting more towards that model where we look at what people are capable of and we trust in our people, and we get more out of them, the knowledge work model.If we want more knowledge work, we need people to be happy and to feel engaged in their community. And suddenly we start to see these kind of generational, bigger-pie kind of things start to happen. But how do we get there? It's not SLOs. It maybe it's a little bit starting with incidents. That's where I've had the most success, and you asked me about that. So, getting practical, incident management is probably—Corey: Right. Well, as I see it, the problem with SLOs across the board is it feels like it's a very insular community so far, and communicating it to engineers seems to be the focus of where the community has been, but from my understanding of it, you absolutely need buy-in at significantly high executive levels, to at the very least by you air cover while you're doing these things and making these changes, but also to help drive that cultural shift. None of this is something I have the slightest clue how to do, let's be very clear. If I knew how to change a company's culture, I'd have a different job.Amy: Yeah. [laugh]. The biggest omission in the Google SRE books was [Ers 00:22:58]. There was a guy at Google named Ers who owns availability for Google, and when anything is, like, in dispute and bubbles up the management team, it goes to Ers, and he says, “Thou shalt…” right? Makes the call. And that's why it works, right?Like, it's not just that one person, but that system of management where the whole leadership team—there's a large, very well-funded team with a lot of power in the organization that can drive availability, and they can say, this is how you're going to do metrics for your service, and this is the system that you're in. And it's kind of, yeah, sure it works for them because they have all the organizational support in place. What I was saying to my team just the other day—because we're in the middle of our SLO rollout—is that really, I think an SLO program isn't [clear throat] about the engineers at all until late in the game. At the beginning of the game, it's really about getting the leadership team on board to say, “Hey, we want to put in SLIs and SLOs to start to understand the functioning of our software system.” But if they don't have that curiosity in the first place, that desire to understand how well their teams are doing, how healthy their teams are, don't do it. It's not going to work. It's just going to make everyone miserable.Corey: It feels like it's one of those difficult to sell problems as well, in that it requires some tooling changes, absolutely. It requires cultural change and buy-in and whatnot, but in order for that to happen, there has to be a painful problem that a company recognizes and is willing to pay to make go away. The problem with stuff like this is that once you pay, there's a lot of extra work that goes on top of it as well, that does not have a perception—rightly or wrongly—of contributing to feature velocity, of hitting the next milestone. It's, “Really? So, we're going to be spending how much money to make engineers happier? They should get paid an awful lot and they're still complaining and never seem happy. Why do I care if they're happy other than the pure mercenary perspective of otherwise they'll quit?” I'm not saying that it's not worth pursuing; it's not a worthy goal. I am saying that it becomes a very difficult thing to wind up selling as a product.Amy: Well, as a product for sure, right? Because—[sigh] gosh, I have friends in the space who work on these tools. And I want to be careful.Corey: Of course. Nothing but love for all of those people, let's be very clear.Amy: But a lot of them, you know, they're pulling metrics from existing monitoring systems, they are doing some interesting math on them, but what you get at the end is a nice service catalog and dashboard, which are things we've been trying to land as products in this industry for as long as I can remember, and—Corey: “We've got it this time, though. This time we'll crack the nut.” Yeah. Get off the island, Gilligan.Amy: And then the other, like, risky thing, right, is the other part that makes me uncomfortable about SLOs, and why I will often tell folks that I talk to out in the industry that are asking me about this, like, one-on-one, “Should I do it here?” And it's like, you can bring the tool in, and if you have a management team that's just looking to have metrics to drive productivity, instead of you know, trying to drive better knowledge work, what you get is just a fancier version of more Taylorism, right, which is basically scientific management, this idea that we can, like, drive workers to maximum efficiency by measuring random things about them and driving those numbers. It turns out, that doesn't really work very well, even in industrial scale, it just happened to work because, you know, we have a bloody enough society that we pushed people into it. But the reality is, if you implement SLOs badly, you get more really bad Taylorism that's bad for you developers. And my suspicion is that you will get worse availability out of it than you would if you just didn't do it at all.Corey: This episode is sponsored by our friends at Revelo. Revelo is the Spanish word of the day, and its spelled R-E-V-E-L-O. It means “I reveal.” Now, have you tried to hire an engineer lately? I assure you it is significantly harder than it sounds. One of the things that Revelo has recognized is something I've been talking about for a while, specifically that while talent is evenly distributed, opportunity is absolutely not. They're exposing a new talent pool to, basically, those of us without a presence in Latin America via their platform. It's the largest tech talent marketplace in Latin America with over a million engineers in their network, which includes—but isn't limited to—talent in Mexico, Costa Rica, Brazil, and Argentina. Now, not only do they wind up spreading all of their talent on English ability, as well as you know, their engineering skills, but they go significantly beyond that. Some of the folks on their platform are hands down the most talented engineers that I've ever spoken to. Let's also not forget that Latin America has high time zone overlap with what we have here in the United States, so you can hire full-time remote engineers who share most of the workday as your team. It's an end-to-end talent service, so you can find and hire engineers in Central and South America without having to worry about, frankly, the colossal pain of cross-border payroll and benefits and compliance because Revelo handles all of it. If you're hiring engineers, check out revelo.io/screaming to get 20% off your first three months. That's R-E-V-E-L-O dot I-O slash screaming.Corey: That is part of the problem is, in some cases, to drive some of these improvements, you have to go backwards to move forwards. And it's one of those, “Great, so we spent all this effort and money in the rest of now things are worse?” No, not necessarily, but suddenly are aware of things that were slipping through the cracks previously.Amy: Yeah. Yeah.Corey: Like, the most realistic thing about first The Phoenix Project and then The Unicorn Project, both by Gene Kim, has been the fact that companies have these problems and actively cared enough to change it. In my experience, that feels a little on the rare side.Amy: Yeah, and I think that's actually the key, right? It's for the culture change, and for, like, if you really looking to be, like, do I want to work at this company? Am I investing my myself in here? Is look at the leadership team and be, like, do these people actually give a crap? Are they looking just to punt another number down the road?That's the real question, right? Like, the technology and stuff, at the point where I'm at in my career, I just don't care that much anymore. [laugh]. Just… fine, use Kubernetes, use Postgres, [unintelligible 00:27:30], I don't care. I just don't. Like, Oracle, I might have to ask, you know, go to finance and be like, “Hey, can we spend 20 million for a database?” But like, nobody really asks for that anymore, so. [laugh].Corey: As one does. I will say that I mostly agree with you, but a technology that I found myself getting excited about, given the time of the recording on this is… fun, I spent a bit of time yesterday—from when we're recording this—teaching myself just enough Go to wind up being together a binary that I needed to do something actively ridiculous for my camera here. And I found myself coming away deeply impressed by a lot of things about it, how prescriptive it was for one, how self-contained for another. And after spending far too many years of my life writing shitty Perl, and shitty Bash, and worse Python, et cetera, et cetera, the prescriptiveness was great. The fact that it wound up giving me something I could just run, I could cross-compile for anything I need to run it on, and it just worked. It's been a while since I found a technology that got me this interested in exploring further.Amy: Go is great for that. You mentioned one of my two favorite features of Go. One is usually when a program compiles—at least the way I code in Go—it usually works. I've been working with Go since about 0.9, like, just a little bit before it was released as 1.0, and that's what I've noticed over the years of working with it is that most of the time, if you have a pretty good data structure design and you get the code to compile, usually it's going to work, unless you're doing weird stuff.The other thing I really love about Go and that maybe you'll discover over time is the malleability of it. And the reason why I think about that more than probably most folks is that I work on other people's code most of the time. And maybe this is something that you probably run into with your business, too, right, where you're working on other people's infrastructure. And the way that we encode business rules and things in the languages, in our programming language or our config syntax and stuff has a huge impact on folks like us and how quickly we can come into a situation, assess, figure out what's going on, figure out where things are laid out, and start making changes with confidence.Corey: Forget other people for a minute they're looking at what I built out three or four years ago here, myself, like, I look at past me, it's like, “What was that rat bastard thinking? This is awful.” And it's—forget other people's code; hell is your own code, on some level, too, once it's slipped out of the mental stack and you have to re-explore it and, “Oh, well thank God I defensively wound up not including any comments whatsoever explaining what the living hell this thing was.” It's terrible. But you're right, the other people's shell scripts are finicky and odd.I started poking around for help when I got stuck on something, by looking at GitHub, and a few bit of searching here and there. Even these large, complex, well-used projects started making sense to me in a way that I very rarely find. It's, “What the hell is that thing?” is my most common refrain when I'm looking at other people's code, and Go for whatever reason avoids that, I think because it is so prescriptive about formatting, about how things should be done, about the vision that it has. Maybe I'm romanticizing it and I'll hate it and a week from now, and I want to go back and remove this recording, but.Amy: The size of the language helps a lot.Corey: Yeah.Amy: But probably my favorite. It's more of a convention, which actually funny the way I'm going to talk about this because the two languages I work on the most right now are Ruby and Go. And I don't feel like two languages could really be more different.Syntax-wise, they share some things, but really, like, the mental models are so very, very different. Ruby is all the way in on object-oriented programming, and, like, the actual real kind of object-oriented with messaging and stuff, and, like, the whole language kind of springs from that. And it kind of requires you to understand all of these concepts very deeply to be effective in large programs. So, what I find is, when I approach Ruby codebase, I have to load all this crap into my head and remember, “Okay, so yeah, there's this convention, when you do this kind of thing in Ruby”—or especially Ruby on Rails is even worse because they go deep into convention over configuration. But what that's code for is, this code is accessible to people who have a lot of free cognitive capacity to load all this convention into their heads and keep it in their heads so that the code looks pretty, right?And so, that's the trade-off as you said, okay, my developers have to be these people with all these spare brain cycles to understand, like, why I would put the code here in this place versus this place? And all these, like, things that are in the code, like, very compact, dense concepts. And then you go to something like Go, which is, like, “Nah, we're not going to do Lambdas. Nah”—[laugh]—“We're not doing all this fancy stuff.” So, everything is there on the page.This drives some people crazy, right, is that there's all this boilerplate, boilerplate, boilerplate. But the reality is, I can read most Go files from top to the bottom and understand what the hell it's doing, whereas I can go sometimes look at, like, a Ruby thing, or sometimes Python and e—Perl is just [unintelligible 00:32:19] all the time, right, it's there's so much indirection. And it just be, like, “What the [BLEEP] is going on? This is so dense. I'm going to have to sit down and write it out in longhand so I can understand what the developer was even doing here.” And—Corey: Well, that's why I got the Mac Studio; for when I'm not doing A/V stuff with it, that means that I'll have one core that I can use for, you know, front-end processing and the rest, and the other 19 cores can be put to work failing to build Nokogiri in Ruby yet again.Amy: [laugh].Corey: I remember the travails of working with Ruby, and the problem—I have similar problems with Python, specifically in that—I don't know if I'm special like this—it feels like it's a SRE DevOps style of working, but I am grabbing random crap off a GitHub constantly and running it, like, small scripts other people have built. And let's be clear, I run them on my test AWS account that has nothing important because I'm not a fool that I read most of it before I run it, but I also—it wants a different version of Python every single time. It wants a whole bunch of other things, too. And okay, so I use ASDF as my version manager for these things, which for whatever reason, does not work for the way that I think about this ergonomically. Okay, great.And I wind up with detritus scattered throughout my system. It's, “Hey, can you make this reproducible on my machine?” “Almost certainly not, but thank you for asking.” It's like ‘Step 17: Master the Wolf' level of instructions.Amy: And I think Docker generally… papers over the worst of it, right, is when we built all this stuff in the aughts, you know, [CPAN 00:33:45]—Corey: Dev containers and VS Code are very nice.Amy: Yeah, yeah. You know, like, we had CPAN back in the day, I was doing chroots, I think in, like, '04 or '05, you know, to solve this problem, right, which is basically I just—screw it; I will compile an entire distro into a directory with a Perl and all of its dependencies so that I can isolate it from the other things I want to run on this machine and not screw up and not have these interactions. And I think that's kind of what you're talking about is, like, the old model, when we deployed servers, there was one of us sitting there and then we'd log into the server and be like, I'm going to install the Perl. You know, I'll compile it into, like, [/app/perl 558 00:34:21] whatever, and then I'll CPAN all this stuff in, and I'll give it over to the developer, tell them to set their shebang to that and everything just works. And now we're in a mode where it's like, okay, you got to set up a thousand of those. “Okay, well, I'll make a tarball.” [laugh]. But it's still like we had to just—Corey: DevOps, but [unintelligible 00:34:37] dev closer to ops. You're interrelating all the time. Yeah, then Docker comes along, and add dev is, like, “Well, here's the container. Good luck, asshole.” And it feels like it's been cast into your yard to worry about.Amy: Yeah, well, I mean, that's just kind of business, or just—Corey: Yeah. Yeah.Amy: I'm not sure if it's business or capitalism or something like that, but just the idea that, you know, if I can hand off the shitty work to some other poor schlub, why wouldn't I? I mean, that's most folks, right? Like, just be like, “Well”—Corey: Which is fair.Amy: —“I got it working. Like, my part is done, I did what I was supposed to do.” And now there's a lot of folks out there, that's how they work, right? “I hit done. I'm done. I shipped it. Sure. It's an old [unintelligible 00:35:16] Ubuntu. Sure, there's a bunch of shell scripts that rip through things. Sure”—you know, like, I've worked on repos where there's hundreds of things that need to be addressed.Corey: And passing to someone else is fine. I'm thrilled to do it. Where I run into problems with it is where people assume that well, my part was the hard part and anything you schlubs do is easy. I don't—Amy: Well, that's the underclass. Yeah. That's—Corey: Forget engineering for a second; I throw things to the people over in the finance group here at The Duckbill Group because those people are wizards at solving for this thing. And it's—Amy: Well, that's how we want to do things.Corey: Yeah, specialization works.Amy: But we have this—it's probably more cultural. I don't want to pick, like, capitalism to beat on because this is really, like, human cultural thing, and it's not even really particularly Western. Is the idea that, like, “If I have an underclass, why would I give a shit what their experience is?” And this is why I say, like, ops teams, like, get out of here because most ops teams, the extant ops teams are still called ops, and a lot of them have been renamed SRE—but they still do the same job—are an underclass. And I don't mean that those people are below us. People are treated as an underclass, and they shouldn't be. Absolutely not.Corey: Yes.Amy: Because the idea is that, like, well, I'm a fancy person who writes code at my ivory tower, and then it all flows down, and those people, just faceless people, do the deployment stuff that's beneath me. That attitude is the most toxic thing, I think, in tech orgs to address. Like, if you're trying to be like, “Well, our liability is bad, we have security problems, people won't fix their code.” And go look around and you will find people that are treated as an underclass that are given codes thrown over the wall at them and then they just have to toil through and make it work. I've worked on that a number of times in my career.And I think just like saying, underclass, right, or caste system, is what I found is the most effective way to get people actually thinking about what the hell is going on here. Because most people are just, like, “Well, that's just the way things are. It's just how we've always done it. The developers write to code, then give it to the sysadmins. The sysadmins deploy the code. Isn't that how it always works?”Corey: You'd really like to hope, wouldn't you?Amy: [laugh]. Not me. [laugh].Corey: Again, the way I see it is, in theory—in theory—sysadmins, ops, or that should not exist. People should theoretically be able to write code as developers that just works, the end. And write it correct the first time and never have to change it again. Yeah. There's a reason that I always like to call staging environments in places I work ‘theory' because it works in theory, but not in production, and that is fundamentally the—like, that entire job role is the difference between theory and practice.Amy: Yeah, yeah. Well, I think that's the problem with it. We're already so disconnected from the physical world, right? Like, you and I right now are talking over multiple strands of glass and digital transcodings and things right now, right? Like, we are detached from the physical reality.You mentioned earlier working in data centers, right? The thing I miss about it is, like, the physicality of it. Like, actually, like, I held a server in my arms and put it in the rack and slid it into the rails. I plugged into power myself; I pushed the power button myself. There's a server there. I physically touched it.Developers who don't work in production, we talked about empathy and stuff, but really, I think the big problem is when they work out in their idea space and just writing code, they write the unit tests, if we're very lucky, they'll write a functional test, and then they hand that wad off to some poor ops group. They're detached from the reality of operations. It's not even about accountability; it's about experience. The ability to see all of the weird crap we deal with, right? You know, like, “Well, we pushed the code to that server, but there were three bit flips, so we had to do it again. And then the other server, the disk failed. And on the other server…” You know? [laugh].It's just, there's all this weird crap that happens, these systems are so complex that they're always doing something weird. And if you're a developer that just spends all day in your IDE, you don't get to see that. And I can't really be mad at those folks, as individuals, for not understanding our world. I figure out how to help them, and the best thing we've come up with so far is, like, well, we start giving this—some responsibility in a production environment so that they can learn that. People do that, again, is another one that can be done wrong, where it turns into kind of a forced empathy.I actually really hate that mode, where it's like, “We're forcing all the developers online whether they like it or not. On-call whether they like it or not because they have to learn this.” And it's like, you know, maybe slow your roll a little buddy because the stuff is actually hard to learn. Again, minimizing how hard ops work is. “Oh, we'll just put the developers on it. They'll figure it out, right? They're software engineers. They're probably smarter than you sysadmins.” Is the unstated thing when we do that, right? When we throw them in the pit and be like, “Yeah, they'll get it.” [laugh].Corey: And that was my problem [unintelligible 00:39:49] the interview stuff. It was in the write code on a whiteboard. It's, “Look, I understood how the system fundamentally worked under the hood.” Being able to power my way through to get to an outcome even in language I don't know, was sort of part and parcel of the job. But this idea of doing it in artificially constrained environment, in a language I'm not super familiar with, off the top of my head, it took me years to get to a point of being able to do it with a Bash script because who ever starts with an empty editor and starts getting to work in a lot of these scenarios? Especially in an ops role where we're not building something from scratch.Amy: That's the interesting thing, right? In the majority of tech work today—maybe 20 years ago, we did it more because we were literally building the internet we have today. But today, most of the engineers out there working—most of us working stiffs—are working on stuff that already exists. We're making small incremental changes, which is great that's what we're doing. And we're dealing with old code.Corey: We're gluing APIs together, and that's fine. Ugh. I really want to thank you for taking so much time to talk to me about how you see all these things. If people want to learn more about what you're up to, where's the best place to find you?Amy: I'm on Twitter every once in a while as @MissAmyTobey, M-I-S-S-A-M-Y-T-O-B-E-Y. I have a blog I don't write on enough. And there's a couple things on the Equinix Metal blog that I've written, so if you're looking for that. Otherwise, mainly Twitter.Corey: And those links will of course be in the [show notes 00:41:08]. Thank you so much for your time. I appreciate it.Amy: I had fun. Thank you.Corey: As did I. Amy Tobey, Senior Principal Engineer at Equinix. 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, or on the YouTubes, smash the like and subscribe buttons, as the kids say. Whereas if you've hated this episode, same thing, five-star review all the platforms, smash the buttons, but also include an angry comment telling me that you're about to wind up subpoenaing a copy of my shell script because you're convinced that your intellectual property and secrets are buried within.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

What is, what isn't, what should be and what shouldn't be service management. Join Matt on a philosophical chat about IT with the former IT Skeptic - yes, we asked what happened with our favorite blog (and he answered!). Rob England is known for contributing to ITIL Service Strategy, The Unicorn Project, The Agile Manager, Open Management, The DevOps Handbook, and as the lead author of the VeriSM digital framework. Founding groups like itSMF New Zealand and WellyBAM (Business Agility Meetup), Rob connects IT professionals across regions and continents. Working with Dr. Cherry Vu as part of their consulting team for Teal Unicorn, they change organizations and leadership with a myriad of business challenges.

Preventive care plans allow vet clinics to both better communicate with pet parents and increase compliance. This week, Shawn & Ivan speak with Tina Wiseman of MWI Animal Health about leveraging technology for practice enablement and client engagement. Tina recommends The Unicorn Project by Gene Kim (amzn.to/3vz2ADu) & Essentialism by Greg McKeown (amzn.to/3sCuYmm). Learn more about Tina at mwiah.com.

Guest Bio: Mark Schwartz joined AWS as an Enterprise Strategist and Evangelist in July 2017. In this role, Mark works with enterprise technology executives to share experiences and strategies for how the cloud can help them increase speed and agility while devoting more of their resources to their customers. Mark has extensive experience as an IT leader in the government, private sector, and the nonprofit world, and with organizations ranging from startup to large. Prior to joining AWS, he was CIO of US Citizenship and Immigration Services (in the Department of Homeland Security), where he led a large digital transformation effort, moving the agency to the cloud, introducing and refining DevOps and Agile techniques, and adopting user-centric design approaches. From his work at USCIS, he developed a reputation for leading transformation in organizations that are resistant to change, obsessed with security, subject to considerable regulation and oversight, and deeply bureaucratic. Before USCIS, Mark was CIO of Intrax Cultural Exchange, a leader in global youth exchange programs, and CEO of a software company. Mark is the author of The Art of Business Value , A Seat at the Table: IT Leadership in the Age of Agility, War, Peace and IT and The Delicate Art of Bureaucracy. Mark speaks at conferences internationally on such subjects as DevOps, Leading Change, Driving Innovation in IT, and Managing Agility in Bureaucratic Organizations. He has been recognized as a Computerworld Premier IT Leader and received awards for Leadership in Technology Innovation, the Federal 100 IT Leaders, and a CIO Magazine 100 award. Mark has both a BS and MA degree from Yale University, and an MBA from Wharton.   Social Media/ Website: Mark's LinkedIn Profile: https://www.linkedin.com/in/innovativecio Mark's AWS Executive Insights page with links to all his blogs posts and books https://aws.amazon.com/ar/executive-insights/enterprise-strategists/mark-schwartz/  Books/ Resources: The Delicate Art of Bureaucracy: Digital Transformation with the Monkey, the Razor and the Sumo Wrestler by Mark Schwartz https://www.amazon.co.uk/Delicate-Art-Bureaucracy-Transformation-Wrestler-ebook/dp/B086XM4WCK/ The Art of Business Value by Mark Schwartz https://www.amazon.co.uk/Art-Business-Value-Mark-Schwartz/dp/1942788045 A Seat at the Table: IT Leadership in the Age of Agility by Mark Schwartz https://www.amazon.co.uk/Seat-Table-Leadership-Age-Agility/dp/1942788118/ War, Peace and IT: Business Leadership, Technology, and Success in the Digital Age by Mark Schwartz https://www.amazon.co.uk/War-Peace-Business-Leadership-Technology/dp/1942788711 Reaching Cloud Velocity: A Leader's Guide to Success in the AWS Cloud by Jonathan Allen et al https://www.amazon.co.uk/Reaching-Cloud-Velocity-Leaders-Success/dp/B086PTDP51 Ahead in the Cloud: Best Practices for Navigating the Future of Enterprise IT by Stephen Orban https://www.amazon.co.uk/Ahead-Cloud-Practices-Navigating-Enterprise-ebook/dp/B07BYQTGJ7 Engineers of Victory: The Problem Solvers Who Turned the Tide in the Second World War by Paul Kennedy https://www.amazon.co.uk/Engineers-Victory-Problem-Solvers-Turned-ebook/dp/B00ADNPCC0 The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win by Gene Kim https://www.amazon.co.uk/Phoenix-Project-Devops-Helping-Business/dp/1942788290/ The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data by Gene Kim https://www.amazon.co.uk/Unicorn-Project-Disruption-Redshirts-Overthrowing/dp/1942788762   Interview Transcript Ula Ojiaku:  Mark, thank you so much for making the time for this conversation. Mark Schwartz: Thank you, my pleasure. Ula Ojiaku: Great. Now let's start with you know, the question I usually ask my guests: who's Mark? What makes him tick? Mark Schwartz:  And they can answer that question. It's not a hard one. where to start? Um, you know, I always enjoy my work. That's a thing about me. I like to think that people have fun working with me because I tend to laugh a lot. And even you know, when the work is boring, I find ways to make it interesting. I just enjoy doing things and accomplishing things. I think if we're going to talk about my books, and some of the things I've done later, an important thing to realize is that, I started out, you know, when I went, when I was in high school, when I went to college, I was pretty sure I wanted to study computer science and get involved with these computer things. But when I was actually studying, I realized there were all these other interesting areas, I'm just, you know, endlessly curious. And so, I wound up studying all kinds of other things, in addition. And the result was that when I finished college, I decided to go to graduate school in philosophy. And I spent a few years getting a master's degree in philosophy. And the fact that I'm curious about so many things and read so many different things, I think it enters into a lot of what I do. I like to pull analogies from non-IT related fields and, and, and I'll call upon all the things I've learned in all sorts of different areas, as I'm writing and speaking and working. Ula Ojiaku:  It shines through in your book, definitely. Mark Schwartz:  Yes, I think it does. That's partly an explanation for what you see in my books. I think, um, you know, I sometimes say that I have trouble reading business books generally. Because I kind of find them boring. They tend to make the same point over and over again, and to be very just so one directional, you know, just on the same subject, and it's a little bit odd because in every other subject, the books tend to refer to other books in other fields and there's this extra dimension and that helps you understand what the author is getting at. But in business books, they, you know, aside from having a quote now and then from a famous leader or something, they don't tend to do that, they don't, they don't sort of call upon the whole history of literature and writing. And so, I have a little bit of fun in writing my books in trying to see if I can add an extra dimension just by reference and by bringing in other things that are a little bit orthogonal to the subject matter. Ula Ojiaku:  And that kind of, you know, brings home the point that life isn't black and white. It's actually a complex or a complex kind of, you know, maze and of different disciplines, different ideologies and different viewpoints that make it what it is really. Mark Schwartz:  Yeah well, of course, that was part of the fun of my recent book on Bureaucracy. You know, because I know we all, we want to throw up when we encounter bureaucracy, you know, it disturbs us in so many ways. And one of the things I wanted to say in the book is, well, actually bureaucracy is all around you all the time in unexpected places and it usually doesn't drive you crazy, actually. Yeah... Ula Ojiaku:  Well, I have a lot of questions for you on your book, The Delicate Art of Bureaucracy, which is a catchy, catchy title on its own, very clever. But before we get to that, what do you do when you're not working? I know, you said you love work and you've also said that you're curious about so many things, which means that you read broadly - that's my interpretation. So, what do you do when you're not ‘working'? Mark Schwartz:  Yes, I read broadly, is one thing. In the past, I played the guitar a lot. And I don't quite as much lately. I don't know why, you know, I'll start doing it again. I'm sure at some point. But while I was living in San Francisco, I was actually playing in bars and coffee shops, I have a singer, who I performed with. Ula Ojiaku: Really? Wow! Mark Schwartz: And that was really fun. And then the other thing I do is travel, I've really traveled a lot. And, yeah, there was one period in my life where for about five years, I was bumming around the world with a backpack with you know, occasional returns to the States to work a little bit and make some money and then go traveling again. So, one of the joys of my current job is that, I get to do a lot of traveling to interesting places. Ula Ojiaku:  So, where would you say is your ideal getaway destination? Mark Schwartz:  Oh, let's see. I'm a big fan of Brazil. That, I have good friends there and it's really nice to see them and the atmosphere is always kind of fun there. Ula Ojiaku: Okay. Mark Schwartz: I don't know what I've discovered so many places around the world that I've really loved being. I lived in Japan for a year and that is a place that I love to go to, especially for the food. Yeah, I like good food. But I don't know I've found so many places that made me feel like I'd like to spend more time there. And of course, you can't really spend more time everywhere. Ula Ojiaku:  Interesting. So, let's, let's go to your book, “The Art of Delicate Bureaucracy”. What was the inspiration behind that book? Mark Schwartz:  Well, for all of my books, before I wrote, before I wrote them, I was thinking, ‘why hasn't anybody else written a book on this topic?' People don't write books on bureaucracy, at least not, you know, popular books, there are academic books on bureaucracy. And the same thing happened to me with my first book, “The Art of Business Value”, where I said to myself, we keep talking about business value in the IT world, like, is it obvious what it means? You know, what, why isn't anybody writing a book about what business value means? So, bureaucracy is one of those things. I have a lot of experience with it first of all, I was a CIO in a government agency. But it turns out, it's not just the government, whenever I tell people about my government experience, when I speak at a conference, people come up to me afterwards and say, ‘Oh, my company's just like that. I work for a financial services company; we have lots of bureaucracy'. And I work with a lot of people who are trying to pull off some sort of digital transformation, which is change on a big scale, that's changing traditional organizations on a big scale. And bureaucracy is always in their way because bureaucracy tends to resist change; it strongly tends to resist change. So, if you're doing a big change, then you're probably going to come up against it. So, I thought maybe with my experience as a bureaucrat, or at least experience in the big bureaucracy, I could give some pointers to people who are trying to cause big change, and yet are facing bureaucratic obstacles. And I can't imagine that there's any organization, at least any large organization that does not have bureaucratic obstacles to digital transformation. So, that got me started on it. And then as I started to think about bureaucracy and research it, I realized this is actually a really interesting topic. Ula Ojiaku:  You had an interesting introduction to the book. You said, “we are bureaucrats all.” Why that claim, you actually were saying, everyone is a bureaucrat, and I know you made a statement that's similar to that earlier on in this conversation - why? Mark Schwartz:  Well, of course, I have to define in the book, what I mean by bureaucracy and all that. And I follow the generally what's accepted as the academic definition. It mostly comes from the sociologist Max Vabre, who is writing around 1920. And, and he talks a lot about bureaucracy, and it's fairly complicated, but I simplify it in the book. Basically, what it comes down to is a bureaucracy is a way of organizing socially, that has rigid formal roles for people and rigid formal rules. And that's the essence of it. You know, bureaucracy, there are rules and they have to be applied uniformly to everybody. And there's a division of labor and you know, a hierarchy. So, it has rigid roles of people who have to sign off on things and approve things. So, with that is the definition. I think it, it connects with the very human tendency to try to structure things and constantly improve them and optimize them. So, if you find a good way of doing something, you tend to turn it into a rule, you know, this is the way it should be done from now on. Ula Ojiaku: Best practice! Mark Schwartz: It's the best practice. Yeah, yeah, exactly. And also, we, in, social organization, we'd like people to be accountable or responsible for things. And we know that you can't hold somebody accountable unless they have authority to perform their role. So, when you put those things together, it's very natural for us to set up these organizational systems, where we assign roles to people, and give them authority, and we make rules that encapsulate the best way to do things. And, essentially, that's bureaucracy. So, bureaucracy, I find, is everywhere around us in one form or another. But it doesn't drive us crazy most of the time, so we don't notice it. Ula Ojiaku:  Maybe if it's serving us, then we wouldn't notice it. But… Mark Schwartz:  It does serve. And if you look at the cases where it does drive us crazy, they have certain things in common. And in the book, I say there are three characteristics that bureaucracies often take on which they don't need to, it's not part of the definition of bureaucracy, but they often take on these characteristics. And it's those three characteristics that are what drive us crazy. And so, the goal, ultimately is to eliminate those three characteristics or turn them into something else. Ula Ojiaku: I know that the listeners would be curious to know what the three characteristics of bureaucracy that drive us crazy are? Is that so or should I just tell them go buy the book? Mark Schwartz: Yeah, go buy the book! Well, let me tell you the three characteristics, and also their opposite, which is what we really want. So, the first characteristic that drives us crazy, I think, is that bureaucracies tend to be bloated instead of lean, that would be the opposite in my view. There's no reason why a bureaucracy has to be bloated and wasteful. It could be lean, but it's one of those things that bureaucracy tends to become. So that's the first one. The second one is that bureaucracies tend to petrify, as opposed to learning. So, when I say petrifies, I mean that the rules and the bureaucracy don't change, or don't change as often as they should, or don't change continuously, which is really what rules should do. Now, that's not necessarily a characteristic of bureaucracy, but the definition, the definition says the rules have to be applied rigorously. You know, once you have a rule, everybody has to follow it. But it doesn't say that the rules have to stay the same forever, they can change. The opposite of a petrified bureaucracy is a learning bureaucracy, where the rules are constantly adjusted, based on what the people in the organization learn. And there are plenty of good examples of learning bureaucracies out there. And your goal is to transform the one into the other, the petrified into the learning. The third is, bureaucracies tend to be coercive, rather than enabling. Coercive, meaning that they're there to control employee behavior, to force employees to behave in ways that otherwise they wouldn't want to. They tend to be ‘no' saying, they say ‘no', a lot. Your bureaucracy for your expense reporting policy in your company probably says, ‘no that expense is no good because X Y and Z.' There are plenty of examples of enabling bureaucracies, where the point is not to stop you from doing things or force you to do something you don't want to. But the bureaucracy provides a support structure, provide best practices, as you said, that help you do your job well. And there's no reason why bureaucracies can't do that. So, the three bad characteristics are bloat, coercion, and petrify. Ula Ojiaku: Okay, nice. So, it sounds like the way you've described bureaucracy, when you look at it from a positive slant, would it be the same thing as guardrails, putting guardrails in place, or giving people the right degree of freedom? Mark Schwartz: Yeah, that's exactly the idea. What I find is that guardrails and automation are ways of implementing bureaucracy, that lead to those three good characteristics rather than the bad ones. Let's say in software development, in DevOps, for example, it's a good idea to put guardrails, security guardrails, for example, around what people can do, and automated security tests and things like that. Because then the developers or the DevOps teams, they can go charging ahead full speed, knowing that they can't do anything wrong, you know, because the guardrails are there. And they get immediate feedback, if they do something that's going to put them outside the guardrails and they can just immediately fix it. So, it's very empowering for them, lets them move fast. And it also gets rid of that coercive element of you know, I write some code and then somebody comes in afterwards and says, ‘no, you can't deploy that'. That's annoying. Instead, I can run the security tests myself, as a developer, see if there's anything that's problematic, fix it right away if I want to, so it's all under my control. But the end result is still the same. The bureaucracy is still there. It's just automated and implemented as guardrails. Ula Ojiaku:  It's enabling, like you said before, instead of hindering. Mark Schwartz:  And it's lean, because it's very inefficient and wasteful, if you write some code, and then at the very end of the development process, somebody finds a security flaw. And now you have to remember what you were doing. And, you know, go back and relearn your code and make changes then, so that's wasteful, as opposed to lean. It's coercive, as opposed to enabling. And if you're good at doing these things, then you keep updating your guardrails and your security tests based on new security threats you learn about or new policies or whatever. So, you make a learning bureaucracy as well. Ula Ojiaku:  Interesting. In the book as well, you said you want us to be calm, chaos monkeys, knights of Ockham, lean sumo wrestlers, very interesting oxymoron there. And you know, black belt experts, could you tell us more about those terms? Why did you use those terms? Mark Schwartz:  Because they made me laugh of course. Ula Ojiaku: Well, they made me laugh too. Mark Schwartz: So, I thought about what I learned about coping with bureaucracy, especially in my government job, but also from reading and from talking to other people. And I realized I had about, you know, 30 techniques for coping with bureaucracy, I call them plays. And I just grabbed those 30 techniques, but I thought about it, and I realized they divided into three. And the three, I could sort of associate with a personality, almost. You know, that these 10 plays are associated with this personality, these 10 plays are associated with this one. And I came up with these three personalities that I thought describe those plays. And the three personalities are the monkey, and the razor, and the sumo wrestler. And, you know, I think, I could stop right there, because it's probably obvious why I associate those with these plays, but I will go a little further. Ula Ojiaku: Please… Mark Schwartz: So, I realized that some of the things we did, the ones that I call the plays of the monkey, the way of the monkey, those things had to do with provoking. You know, monkeys are mischievous, provocative, and sometimes annoying. And a bunch of the techniques had to do with trying to be provocative. And the razor and I'll give you some examples in a minute. The razor, to me is all about being lean. It's about trimming away waste. And it also refers to the philosophical principle of Ockham's razor. Ockham was a medieval philosopher, right, William of Ockham. And he's generally credited with an idea that something like if you have a choice between a simple explanation, and a complicated explanation, you should prefer the simple one. That's not really what he said. But that's, that's what most people associated with him. That's the principle of Ockham's razor. And, and so it's called a principle of ontological parsimony, meaning, you shouldn't presuppose the existence of more things than you need to, in order to explain something. So, you know, don't make up nymphs. And you know, I don't know, water dryads and whatever's to explain something that you can equally just explain through simple physical laws. Ula Ojiaku:  Just saying, 'keep it simple...' Mark Schwartz:  Yeah, keep it simple, in a way, right? So that's called the principle of ontological parsimony. And I said, there's a similar principle of bureaucratic parsimony, which says that if you're trying to implement a control, and you can do it in a simple way, or you could do it in a really complicated way, do it a simple way. And so, it's a principle of leanness because I find that bureaucracies, when they get bloated, they have these really complicated wasteful ways of doing something that they could they could accomplish exactly the same thing, but in a simpler way. So that's the razor. And then a sumo wrestler. Well, Sumo is the sport where, you know, two massive people sort of bang into each other, right? And the goal is you want to push your opponent out of the ring, or you want to make them fall and touch the ground with something other than their feet. And if you can do either of those things, you win. So, if you're a big massive person and you're trying to accomplish those things, you might think that the best thing to do is charge your opponent and push really hard. But if your opponent then just either dodges or just is soft and lets you push, well, you're probably going to go flying out of the ring, right? So, one of the principles in Sumo is you want to use your opponent's strength against them. And if they push hard, now, go ahead, give them a little pull. And, you know, let them push even harder. And I realized that some of these techniques for overcoming bureaucracy have to do with using bureaucracy actually, on your side, you know, the using the strength of bureaucracy against it. So that's why the sumo wrestler. So, I'll give you examples now on each one, now that I've described my three personalities. So, the monkey does what is sometimes referred to as provoking and inspecting or provoking and observing, in parallel with the Agile principle of inspect and adapt. So, provoke and observe, what the monkey does is try something that's probably outside the rules, or at least is, you know, a borderline and watches what happens. So, an example where we use this is that we have these rules in Homeland Security that essentially said, if you were going to do an IT project, you have to produce 87 documents. And each document had a template, and you have to fill in each section of the template. And these documents would run to hundreds of pages. And so, using the persona of the monkey, let's say, we started to turn in these documents. But in each section of the template, we just wrote a one sentence, one sentence answer, you know, we're very short answer instead of writing pages and pages. And we wanted to see what would happen if we did that, because there was no rule that said, it had to be a really long answer. And eventually, we started to provoke even more, we just left out sections that we thought didn't make any sense for what we were doing. And all of this was unprecedented, you know, it caused a lot of fear. It turned out, and this sometimes happens, that the enforcers of this policy, they were happy when they said, “We've never wanted anybody to write these really long answers to these things, we have to read them. And you know, the intention wasn't to slow people down. As long as you're giving us the right information. That's all we need.” So, in this case, provoking just it turned out that we could defeat a bunch of bureaucracy there, we could, we could make things a lot leaner because nobody objected. But sometimes people do object. And if they do, then you learn exactly what the resistance is, who it is, is resisting, and that gives you valuable information, when you're trying to figure out how to overcome it. So that's the monkey. You know, let's try something a little playful and mischievous, and see what happens. The razor, well, that one follows also on my 87 documents, because we then set up an alternative way of doing things that had only 15 documents. And where there had been 13 gate reviews required for each project. We reduced it to two. And so, all we did, you know, we just used our little razor to trim away all the excess stuff that was in the bureaucratic requirements. And then we showed people that those 15 documents and those two gate reviews accomplished exactly the same thing as the 87 documents and the 13 gate reviews. That's the principle of the razor, that's how the razor works. The sumo wrestler, also a favorite of mine. So, we were trying to convince the bureaucracy to let us do DevOps and to be agile, and it was resisting. And people kept pointing to a policy that said, you can't do these things. And so, we wrote our own policy. And it was a very good bureaucratic policy looked exactly like every bureaucratic document out there. But it essentially said you must use DevOps and you must be agile on it, you know, it set up a perfect bureaucracy around that it's set up ways of checking to make sure everybody was using DevOps. And the theory behind it was the auditors when they came to audit us and said we were being naughty because we were doing DevOps. Their argument was we looked at the policy and we looked at what you're doing, and they were different. And that's the way auditing works. That was the, you know, GAO, the Government Accountability Office, and the Inspector General and all that. So, we figured if we had a policy that said you must do DevOps, and they audited us, well, they would actually be enforcing the policy, you know, they'd be criticizing any part of the organization that was not using DevOps and I thought that's great. So, this is how you use the strength of the bureaucracy against the bureaucracy or not really, against even, you know, it's perfectly good, perfect… Ula Ojiaku:  To help the bureaucracy yeah, to help them to improve, improve the organization. But thinking about the monkey though, being provocative and mischievous, do you think that there has to be an element of you know, relationship and trust in place first, before… you can't just you know… you're new, and you've just gotten through the door and you start being a monkey… you probably will be taken back to wherever you came from! What do you think? Mark Schwartz:  Well, it helps if you're giggling while you do it. But you know, I think the goal here is to figure out the right levers that are going to move things. And sometimes you do have to push a little bit hard, you know, you do need to take people out of their comfort zone. Usually, you want to do these things in a way that takes into account people's feelings, and you know, is likely to move them in the right direction, rather than making them dig in their heels. But I'll give you a couple of examples of Monkey tactics that are less comfortable for people. One is simply, you know, there's a status quo bias. It's a known, well-known cognitive bias; people tend to prefer the status quo or look the other way about it's failings and stuff. So often, when you're trying to make a change, people say, we're fine the way we are, you know, everything's okay. So, one of the things the monkey tries to do is, is to make it clear that the status quo is not acceptable, you know, to show people that it actually if they think about it, it's no good. And so, for example, when we decided to move to the cloud, instead of working in our DHS data center, people said - of course at the time it was a big concern, ‘was the cloud secure enough?' And in the persona of the monkey, the right response is, ‘are we secure enough now?' You know, ‘don't you realize that we're not happy with our security posture today?' ‘It's not like, the cloud has proved itself. I mean, we have to compare our security in the cloud versus our security in the data center. And yes, I'm very sure it'll be better in the cloud and here's why…' But you can't start from the assumption that you are fine right now. In general, when we're talking about the cloud, that's the situation. Companies are using their own data centers. And it's like, you know, we have to teach them that they can do better in the cloud. But the truth is that they're not happy in their own data centers, if they think about it, right? There are security issues, there are performance issues, there are cost issues. And they're aware of those issues, right, they just look the other way. And because they're comfortable with the status quo, so the monkey has to sort of shake people up and say, ‘It's not okay, what you're doing now!' Another example, and this is really harsh, and I wouldn't use it in most cases. But let's say that this was in Homeland Security. Let's say that Homeland Security is enforcing a very bureaucratic process that results in IT projects, taking five years instead of six months. And let's say, you know, the process is there on paper, the rules say, ‘Do this', the people are interpreting the rules in a way that makes things take five years. Sometimes, the monkey has to go to somebody who's in their way and say, ‘We are in the Department of Homeland Security, this IT project is going to make people more secure in the homeland. Are you comfortable with the fact that you are preventing people from being more secure for the next four and a half years, when we could…' You know, it's a matter of personalizing it. And that sometimes is what's necessary to get people to start thinking creatively about how they can change the bureaucracy. You know, ‘I hate to say it, but you're a murderer', you know, essentially is the message. It's a monkey message. And like I said, you know, it's not the preferred way to go about doing things. But if you have to, I mean, the lives of people are at stake, and you've got to find a way to get there. Ula Ojiaku:  So how can leaders because your book, The Art of Business Value, in your book, you said that “leaders create the language of the organization, and they set up incentives and define value in a way that elicits desired outcomes.” So, in essence, I understand that statement to mean that leaders set the tone, and you know, kind of create the environment for things to happen. So, how can leaders implement or apply bureaucracy in a way that enables an organization where, before it was seen as a hindrance, how can they do this? Mark Schwartz:  My thought process was, if we all agree, we're gonna try to maximize business value? How do we know what we mean by it? And I realized, a lot of Agile people, you know, people in our Agile and DevOps community, were being a little bit lazy. You know, they were thinking, ‘Oh, business value, you know, it's returns on investment, or, you know, it's up to the business (to define) what's business value.' The tech people just, you know, do the work of providing a solution. And to me, that's too lazy. If you're going to be agile, be it you have to be more proactive about making sure you're delivering business value. So, you have to understand what it means. You have to actually do the work of, you know, figuring out what it means. And what it means is not at all obvious. And, you know, you might think it has something to do with return on investment or shareholder value or something like that. But when you really closely examine it, that is not the right way to define it, when it comes to deciding what its efforts to prioritize and all that that's, you know, the case that the book makes, and I explain why that's true. Instead, I say you have to think of business value within the context of the business's strategy and its objectives as a business. There's no like, abstract, this has more business value than this because we calculated an ROI or something like that, that doesn't work reprioritizing. It's always asked within the context of a particular business strategy. And the business strategy is a direction from leadership. There might be input from everybody else, but ultimately, you have leaders in the organization who are deciding what the strategic objectives are. So, for example, if you are a traditional bank, or traditional financial services company, and you look around you and you see there are all these new FinTech companies that are disrupting the industry, and you're worried, well there are a lot of different ways you can respond to those disruptive FinTechs. And how you're going to choose to respond depends on your preferences, it depends on the situation of your company, in the industry, the history of your company, all of those things. But of the many ways you can respond to that disruption, you're going to choose one as the leader of your enterprise. Well, what adds business value is whatever supports that direction you choose to go. You can't think of business value outside of that direction, you know. That's the case that I make. So, leaders don't just set the tone and the culture there, they're actually setting strategic direction that determines what has business value. And then the people who are executing the agile teams have to take it upon themselves to make sure that whatever they're doing is going to add business value in that sense.   So, the role of leadership then becomes direction setting and visioning for the future and communicating the vision to the people who are working and providing feedback, you know, on whether things are actually adding business value or not . And that's the key responsibility. Now, in order to do that, in order to motivate people to deliver according to that idea of business value, there are certain techniques as a leader that you have to keep in mind, there are ways that you get people, you get a big organization to sort of follow you. And one of the ones that's become most important to me to think about after talking to a lot of leaders about how they're running their organizations, and what's working, is using middle management as a lever for accomplishing those things. So often, I'll talk to leaders of a business, and they'll say, our problem is the frozen middle, middle management is, you know, they're just not changing the way we want, we want to, we want to cause a big transformation, but middle management is getting in the way. And I tell them, ‘that's pretty much a myth.' You know, ‘that's not actually what's happening, let's look more closely at your organization.' Almost always, middle management is still trying to do the best they can, given the situation that they're in. And the way that you get them to align themselves behind the change is, you change their incentives or their role definition, or how you tell them what you're expecting from them, you don't say “change”, you know, and start doing X and Y, you change what success looks like for their position. And then they adapt to it by becoming engaged and finding ways to get there. So, there's almost always a leadership problem when you have that frozen middle effect. And, and I've seen it work really well that, you know, all of a sudden, you get this big leverage, because you just do a little bit of tweaking of role definitions, and bring everybody into solving the problem. And actually, there's an example, I love to talk about a history book, like I said before, I like to bring in other things, right? It's called the Engineers of Victory. And it's about World War Two, the Allies realized that they had to solve a set of problems, I think there was six or so problems. One of them was how do you land troops on a beach that's heavily defended? They realize they were just not going to be able to win the war until they could do that. But nobody knew how to do it. Because, you know, obviously, the bad guys are there on the beach, they're dug in, they put barbed wire everywhere, and mines, and you know, all this stuff. And it's just going to be a slaughter if you try to land on the beach. So, this book, Engineers of Victory, makes the case that what really won the war, was figuring out those solutions. And who was responsible for figuring out those solutions? It was middle management, basically. It was the, you know, within the structure of the army, it was the people not at the top who had big authority, you know, the generals, and it was not the troops themselves, because they weren't in a position to figure out these things. It was middle management that could see across different parts of the organization that could try things and see whether they worked or not, that, you know, essentially could run their own mini skunkworks projects. And eventually, they came up with the solutions to these problems. So, I think that's very encouraging for the role of middle management, you know, that a lot of problems have to be solved at that layer in order to pull off a transformation. And it really can be done. And this is a beautiful example of it. Ula Ojiaku:  It reminds me of, you know, my experience in a few transformation initiatives. So, the middle, the people who are termed to be in the frozen middle, are, like you said, they want to do what's best for the company, and they show up wanting to do their best work, but it's really about finding out, ‘Where do I fit in, (with) all this change that's happening?' You know, ‘if my role is going away, if the teams are going to be more empowered, that means I'm not telling them what to do, but then what do I do now?' So, the clarity of what the ‘New World' means for them, and what's in it for them, would help, you know, make them more effective. Mark Schwartz: And the mistake that's often made is to say to them, ‘start doing DevOps' or, you know, ‘start doing agile or something.' Because if you don't change the definition of success, or you don't change the incentives that, you know, then it's just, make work and they're going to resist it. You know, if you say your incentive is to get really fast feedback or you know, one of the other goals of DevOps, because of the following reasons, it helps the business this way, so let's try to reduce cycle time as much as possible for producing software. Okay, that's a change in the incentive, or the, you know, the definition of success, rather than just telling somebody you have to do DevOps, you know, read a book and figure it out. Ula Ojiaku:  So, what other books because you mentioned the Engineers of Victory, are there any other books you would recommend for the listener to go check out if they wanted to learn more about what we've talked about today? Mark Schwartz:  Well, I think, you know, obviously, my books referred to War and Peace by Tolstoy, Moby Dick, another great one. You know, you probably need to read my books to figure out why those are the right books to read and Engineers of Victory. As I said, I think that one's a great one. Within the field, there are some DevOps books that that I like a lot, of course, Gene Kim's books, The Phoenix Project, and now The Unicorn Project, the sequel to that. Because those are books that give you a feel for the motivation behind all the things that we do. The Mechanics of Things, there are plenty of books out there that help you learn the mechanics of how to do continuous integration and continuous delivery. And then the cloud is I think it's really transformative. You know, it's the cloud itself is a tremendous enabler. I work at AWS, of course but I'm not saying this because I work at AWS, it's more than I work at AWS because I believe these things. And my teammates have written some good books on the cloud. Reaching Cloud Velocity, for example, by Jonathan Allen and Thomas Blood is a great one for reading up on how the cloud can be transformative. But my other teammates, Gregor Hope, has written a number of books that are really good, Stephen Orban did A Head in the Cloud. So, I think those are all… should be at the top of people's reading lists. And then, of course, I recommend my books, because they make me laugh, and they might make you laugh, too. Ula Ojiaku:  Definitely made me laugh, but they've also given me things to think about from a new perspective. So, I totally agree. And so, where can people find you if they want to reach out to you? Mark Schwartz:  Yeah, LinkedIn is a great place to find me. If you're with a company that is an AWS customer, feel free to talk to your account manager, the sales team from AWS and ask them to put you in touch with me, is another easy way. LinkedIn is kind of where I organize my world from so find me there. Ula Ojiaku:  Okay. Sounds great. And any final words for the audience or for the listeners. Mark Schwartz:  Um, I, I have found that these things that you want to do to take advantage of the digital world, and I think we're all sort of pointing ourselves in that direction, there are these amazing things you can do in the digital world. They're sometimes challenging to get there, but it's very possible to get there. And one thing I've learned a lot at Amazon is the idea of working backwards, you know, you get that picture in your head for where you want to be and then you say to yourself, ‘I can get there. Let me work backwards and figure out what I have to do in order to get there.' And you might be wrong, you know, you should test hypotheses, you start moving in the right direction, and of course, correct as you need to. But you can do it with confidence that others are doing it and you can too no matter what your organization is, no matter how much you think you're a snowflake and you know different from every other organization. You can still do it. And with just some good intention and good thinking you can figure out how to how to get there. Ula Ojiaku:  Thank you so much, Mark. That was a great close for this conversation and again, I really appreciate your making the time for this interview. Thank you. Mark Schwartz: Thanks for having me. Ula Ojiaku: You're welcome.

This week we cover the often missed functionality of Azure DevOps to help you manage work better. Whether it's product management or running a migration, you can use DevOps boards to track your waterfall, scrum and even wagile projects! Garry, Al and Kevin talk through the different things to consider and why it is worth finding out more.Intro of DevOps Dojo - Azure DevOps Blog (microsoft.com)https://docs.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management?view=azure-devops&tabs=agile-processDevOps tutorial | Microsoft AzureThe Phoenix Project - Book (itrevolution.com)The Unicorn Project | by Gene Kim (author of The Phoenix Project) (itrevolution.com)

Gene Kim is the co-author of the Phoenix Project and the Unicorn Project. Anyone involved in software development has read his books, or have heard him speak. Those that haven't, probably haven't fully appreciated the effort it takes to ship quality software that we use everyday. In this podcast Gene talks about the evolution of DevOps, his favourite inspirations, how enterprises are evolving into software development houses, and how to benchmark your DevOps maturity. His story telling includes a fantastic 'mind altering' reflection on running, maintaining, and developing the software that runs the Navy, as well as 'software updates that can be deployed' whilst a car is driving. You will buy his book, or one of the books he recommends during this podcast.Gene talks fast, is super resourceful, so it's awesome to have this recorded so you can hit pause and reflect!

Things are worse than we ever thought, but that doesn't prevent us from taking a victory lap. Plus, Chris levels up his Mac skillz and gets his MacBook Pro under control.

In this episode, Sanona Williams, Mental Health Counselor, and Stephanie Swanigan Gaulman, Founder of The Unicorn Project, joins the conversation. Together we discuss tge importance of mental health therapy and overcoming barriers to access. --- Support this podcast: https://anchor.fm/rtconsult/support

In this episode of Mik + One, Mik sits down with Gene Kim, best-selling author of The Phoenix Project and The Unicorn Project, as well as co-author of The DevOps Handbook. In this episode, Gene chats to Mik about the next book that he's working on, and provides many insights into: - The journey of the Unicorn Project, the effect it had on technology leaders and how it changed their perspectives - A deeper look into the importance of Psychological safety and how this links to an organization's structure and dynamics - Successful communication paths within an organization in order to improve culture, maximize flow and see successful results, faster - The properties and prerequisites of high performing, dynamic learning organizations and advice to help teams become one - The effective patterns that leadership can adopt to enable an effective communication architecture and organizational structure in order to maximize flow faster and more efficiently Tasktop are proud sponsors of the virtual DevOps Enterprise Summit Europe, taking place on May 18th-20th, 2021. Visit us virtually at our virtual booth, and don't miss our speaking sessions, live demos, happy hours, giveaways and more. We have limited passes at 50% off the full ticket price for the first 100 people who use our special discount code. If you would like to claim one, please email events@tasktop.com. Subscribe to the Mik + One podcast today so you never miss an episode and don't forget to leave your review. Follow Mik on Twitter: @mik_kersten #MikPlusOne www.tasktop.com For more information about Gene Kim and to view the full list of additional resources, visit: https://projecttoproduct.org/podcast/gene-kim-ep-31/

Project Managers will make or break your business. We expect them to do a lot. One of the biggest challenges in our businesses is the ability to attract, train, motivate, and retain top Project Managers.  In this episode we hear from three exceptional professionals who came through the Project Manager ranks and now operate their own custom building businesses.  Show highlights include: Why working on unsuccessful projects is a blessing in disguise (4:34) 3 things your project manager needs to have to thrive in the role (5:28)  Why encouraging your project managers to make mistakes makes them a better project manager (13:00)  As a manager you deserve that title...you deserve autonomy (19:33) The weird way giving your project managers raises can make them complacent (28:07)  How to create a roster of potential unicorn project managers lining up to work for you (35:49)  You need to be genuine and vulnerable to create the proper culture (41:39) To get the most out of this podcast, head over to https://buildernuggets.com  and join our active community of like-minded builders and remodelers.

In this episode of the Art of Modern Ops, Cornelia Davis and Wall Street Journal bestselling author, Gene Kim discuss the ways of working with DevOps as portrayed in Gene's ground breaking books on DevOps. In “The Phoenix Project” Gene describes how the 3 ways: Flow (System Thinking), Feedback and Continual Experimentation and learning, help the operations teams during their digital transformation. Although DevOps starts with development, we hear Gene discuss his thought process around why Phoenix Project revolves around Operations. In the follow up “The Unicorn Project”, we view the same problem from the lens of the Developer who uses the 5 ideals: locality / simplicity, focus / flow / joy, improvement of daily work, psychological safety and customer focus during their digital transformation. Here, Gene circles back to his roots as a developer to bring to light key elements of successful development. Cornelia and Gene riff on how the teamwork between Dev and Ops is crucial to winning the game.Gene Kim “All the hopes dreams and aspirations of the organization, as people think about digital transformation, will be done through the act of development.[...].So much of infrastructure and operations are really now in service of elevating developer productivity” 

Business Book Movement - Notion360. Revisión Online del Libro: The Unicorn Project - Gene Kim. Invitado: Monica Limachi Lopeza. Únete a nuestra comunidad en Discord a través del siguiente enlace: https://bookmovement.co/discord See acast.com/privacy for privacy and opt-out information.

Your business is sitting on an untapped data goldmine. But how do you transform your organization into a mining machine? In the latest episode of Cloudspotting, three data experts join podcast hosts Alex and Sai to break down the complex topic of utilizing data in your organization. Show notes: Recommended read - The Unicorn Project by Gene Kim https://www.goodreads.com/en/book/show/44333183-the-unicorn-project Recommended read - Hands-On Machine Learning with Scikit-Learn, Keras, and Tensorflow by Aurélien Géron https://www.goodreads.com/en/book/show/40363665-hands-on-machine-learning-with-scikit-learn-keras-and-tensorflow Recommended read - The Rack We Built: The Good, The Bad, and the Ugly of Creating Company Culture by Lorenzo Gómez https://www.goodreads.com/book/show/55681761-the-rack-we-built Special Guests: Ben Morgan-Smith, Mark McQuade, and Nirmal Ranganathan.

On this episode of The Artists of Data Science, we get a chance to hear from Carlos Mercado, a data scientist, economist and urban studies enthusiast. Throughout his career, he's had a diverse range of experience, including time as a freight broker, a year long stint teaching English in Korea and working as a data science freelancer. He's currently a senior data scientist at a global consulting firm. Carlos shares with us his journey into data science, the importance of building your brand, and tips for those who want to break into the field. Carlos is an example of someone who has worked hard to learn the fundamentals, and his story shows that it is possible to break into data science! WHAT YOU'LL LEARN [5:16] Where is the field heading? [10:23] Carlos's background in economics, and how it relates to data science [23:52] Lessons regarding how to get the job you want [30:39] How to use reframing and paradoxes for your mindset [45:24] Advice on building a resume for data science [51:40] Building your personal brand QUOTES [23:12] “...without the history, you're not going to have context.” [25:51] “...your resume is a sales document. So if you don't include it in your sale, they're not going to know to buy.” [29:33} “...the most important part of data science, besides knowing math, is being able to communicate to business people and making sure that they understand...” FIND CARLOS ONLINE LinkedIn: https://www.linkedin.com/in/crmercado/ SHOW NOTES [00:01:36] Introduction of our guest [00:02:52] Let's talk about how you first heard of Data science and what drew you to the field. [00:05:12] Where do you see the field headed in the next two to five years? [00:06:42] How to be a great data scientist [00:08:31] Natural language process and voice data [00:10:15] What is economics and why data scientists should care [00:11:12] Economics and big data [00:14:11] Bitcoin and Data Science [00:17:24] What you need to know about GIS, Urban Economics, and Data Science [00:22:26] Do you have any other resources or articles that are kind of covering that topic that our readers can go check out if they want to learn more? [00:23:24] Lessons learned in the data science job search process [00:26:58] What you've learned about Data science working for a psychiatrist at a nonprofit school. [00:30:20] Reframe and Paradox [00:34:36] What it's like working as a consulting data scientist [00:39:09] How does this differ from working in a regular organization? [00:40:34] Phoenix project and Unicorn Project [00:41:04] Freelancing as a data scientist [00:45:15] How to make a good data science resume [00:49:57] How to make a good data science project [00:51:33] How to build your data science brand [00:53:05] The qualities that Carlos looks for in a data scientist [00:54:06] What's the one thing you want people to learn from your story? [00:54:49] The lightning round Special Guest: Carlos Mercado.

The Unicorn Project เป็นหนังสือนวนิยายของเล่มล่าสุดของ Gene Kim ที่ต่อยอดมาจากหนังสือเล่มดัง The Phoenix Project แต่เล่มนี้จะเน้นในมุมของการทำ Digital transformation มากขึ้น ซึ่งถ้าใครกำลังจะทำ Digital transformation นี่จะเป็นหนังสือที่ Must-read เลย 5 Ideal สำคัญ ได้แก่: 1. Locality and Simplicity 2. Focus, Flow, and Joy 3. Improvement of Daily Work 4. Psychological Safety 5. Customer Focus Excerpt: https://res.infoq.com/articles/unicorn-project/en/resources/TUP_Excerpt5_New-1573742362384.pdf

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 

440: In this interview, Gene elaborates on each of the five ideals the book introduces, which are locality and simplicity, focus, flow, and joy, the improvement of daily work, psychological safety, and customer focus. For each one, he provides his definition, examples of it working and not working, and explains why it is important. We also discuss why the days of taylorism, project management, and people treating others as fungible and replaceable resources is coming to an end, why he writes his books as novels, among other topics.

In this episode of Mik + One, Mik continues the conversation with Gene Kim, best-selling author of The Phoenix Project and The Unicorn Project, as well as co-author of The DevOps Handbook for the second part of their discussion. This episode centers around: - Insight into the the Third Ideal: Improvement of Daily Work -- why focusing on the improvement of daily work is even more crucial than the daily work itself, and the implications this has on technical debt - The increasing significance of the Fourth Ideal: Psychological Safety -- and its impact on organizational culture and performance - The ideation of the Fifth Ideal: Customer Focus -- and why leaders must prioritize top-level business goals and what customers value over everything else in order to achieve success in a modern transformation New episode every two weeks. Subscribe to the Mik + One podcast today so you never miss an episode and don't forget to leave your review. Follow Mik on Twitter: @mik_kersten #MikPlusOne www.projecttoproduct.org www.tasktop.com About Gene Kim: Gene Kim is a Wall Street Journal bestselling author, researcher, and multiple award-winning CTO. He has been studying high-performing technology organizations since 1999 and was the founder and CTO of Tripwire for 13 years. He is the author of six books, The Unicorn Project (2019), and co-author of the Shingo Publication Award winning Accelerate (2018), The DevOps Handbook (2016), and The Phoenix Project (2013). Since 2014, he has been the founder and organizer of DevOps Enterprise Summit, studying the technology transformations of large, complex organizations. In 2007, ComputerWorld added Gene to the “40 Innovative IT People to Watch Under the Age of 40” list, and he was named a Computer Science Outstanding Alumnus by Purdue University for achievement and leadership in the profession. He lives in Portland, OR, with his wife and family. @RealGeneKim

Introducing the first episode of Mik + One, Mik sits down with Gene Kim, best-selling author of The Phoenix Project and The Unicorn Project, as well as co-author of The DevOps Handbook. In the first half of this special two-part episode, Mik and Gene talk about: - Gene's journey, and how it led to The Unicorn Project - The motivation and origins behind the Five Ideals and how to put them into practice - The profound wisdom of the First Ideal: Locality and Simplicity -- and why leaders should use it as a test to identify whether they are progressing in the right direction - The Second Ideal: Focus, Flow and Joy -- why it resonates so much with Mik, and it's impact and importance to generating outcomes Tune in next time for part two of this lively discussion, as Mik and Gene continue the conversation around the Five Ideals. Next episode in two weeks. Subscribe to the Mik + One podcast today so you never miss an episode and don't forget to leave your review. Follow Mik on Twitter: @mik_kersten #MikPlusOne www.projecttoproduct.org www.tasktop.com *About Gene Kim:* Gene Kim is a Wall Street Journal bestselling author, researcher, and multiple award-winning CTO. He has been studying high-performing technology organizations since 1999 and was the founder and CTO of Tripwire for 13 years. He is the author of six books, The Unicorn Project (2019), and co-author of the Shingo Publication Award winning Accelerate (2018), The DevOps Handbook (2016), and The Phoenix Project (2013). Since 2014, he has been the founder and organizer of DevOps Enterprise Summit, studying the technology transformations of large, complex organizations. In 2007, ComputerWorld added Gene to the “40 Innovative IT People to Watch Under the Age of 40” list, and he was named a Computer Science Outstanding Alumnus by Purdue University for achievement and leadership in the profession. He lives in Portland, OR, with his wife and family. @RealGeneKim

  Gene 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 the DevOps Enterprise Summit, studying the technology transformations of large, complex organizations. In 2007, ComputerWorld added Gene to the “40 Innovative IT People to Watch Under the Age of 40” list, and he was named a Computer Science Outstanding Alumnus by Purdue University for achievement and leadership in the profession. He lives in Portland, OR, with his wife and family.   THE FIRST IDEAL: Locality and Simplicity THE SECOND IDEAL: Focus, Flow, and Joy THE THIRD IDEAL: Improvement of Daily Work THE FOURTH IDEAL: Psychological Safety THE FIFTH IDEAL: Customer Focus   Links http://www.realgenekim.me/ https://twitter.com/RealGeneKim https://www.linkedin.com/in/realgenekim/ https://itrevolution.com/faculty/gene-kim/   Resources Team of Teams Project to Product Resource Guide To The Unicorn Project (Part 1)   "Tempting Time" by Animals As Leaders used with permissions - All Rights Reserved   × Subscribe now! Never miss a post, subscribe to The 6 Figure Developer Podcast! Are you interested in being a guest on The 6 Figure Developer Podcast? Click here to check availability!  

Maxine, the fictional character in Gene Kim's latest book “The Unicorn Project,” likely shares your plight. In this edition of The New Stack Makers podcast, Kim, who is also the author of the seminal and now classic “The Phoenix Project,” discusses Maxine's daily struggles — and without disclosing spoilers — successes. Maxine shares the developer's modern-day angst in this paradoxically open source and DevOps Renaissance. While her plight is fictional, Maxine shows how developers, with management's backing, can transform an enterprise's DevOps with its from-the-front-lines fictionalized case study with human drama to spare. And, of course, it is never easy, whether you are trying to convince management to back you or your team to implement DevOps — or if you are Maxine in “The Unicorn Project.” In the the first third of the book, Maxine is stranded on an island” and “everything requires a ticket — not one ticket but like 30 tickets,” Kim said. “She's having to pester people to get even license keys or environments,” Kim said.

Gene Kim is out with a new book - The Unicorn Project! Richard chats with Gene about his latest book - a fictionalized story of an organization struggling to build software that is critical to the survival of the company. The conversation explores a core aspect of The Unicorn Project known as the Five Ideals. Think of these ideals as a Maslow's Hierarchy of Needs when it comes to teams building software - this is how you do it!

Maciej Wyrodek joins the 343 podcast to talk about his experiences with modern testing, The Unicorn Project, and various rants about the state of software testing. Follow Maciej On twitter – @maciejwyrodek His blog – The Broken Test Also mentioned: The Modern Testing Principles mindmap Polish article on the state of testing --- Support this podcast: https://anchor.fm/abtesting/support

Can you imagine the worst possible business environment for a team of top technological talent? Well, veteran CTO and novelist Gene Kim has embraced this vision in his blunder-laden “The Unicorn Project” in which every business SANFU and stumbling block heaps upon our heroine Maxine.  Host Bart Jackson brings Gene aboard to discuss the real life wall that so destructively separates managers from technological professionals, to the detriment of all.  With wit and insight, Gene poses solid solutions for removing the barriers of suspicion, communication gaps and faulty structures.  And the outcome of Gene's allegorical tale?  Fear not.  The unsinkable Maxine, with the aid of a shadowy guru brings the Five Comppany-Saving Ideals into play, that – no surprise – hold true equally in the tech room and the C-suite.  Tune in and learn ‘em.