PurePerformance - The Unicorn Project, The Five Ideals and how DevOps evolved with Gene Kim

Episode Date: November 11, 2019

In 2013 the Phoenix Project by Gene Kim, Kevin Bahr and George Spafford sparked the next phase of DevOps transformations. 6 years later Gene Kim (@RealGeneKim) is back with The Unicorn Project, A Novel about Developers, Digital Disruption, and Thriving in the Age of Data.Developer Productivity is a key focus point of the story in the book and is what Gene has learned from different companies in the last years about. Good engineering companies put their best resources in developer productivity as it benefits every developer and allows them to use their best energy to provide business value instead of solving puzzles. Gene lets us in on his day at Etsy as well as the story from Nokia and the reason they moved away from Symbian – both stories that touch on developer productivity!If you want to learn more and read about the Five Ideals then download the excerpts from The Unicorn Project.https://itrevolution.com/the-unicorn-project/https://twitter.com/RealGeneKim

It's time for Pure Performance! Get your stopwatches ready, it's time of Pure Performance, episode 99. My name is Brian Wilson and as always Andy Grabner, my co-host. Andy, how are you doing today on our 99th episode? I'm just shocked. 99. Look at that. Yes. Has it been that long? 99? It has.

It's been about three years. And if we think back to our first year, we had, you know, we got lucky. We had some really, really cool guests in our first year. Gorenko Biedoff, right? We had some guy named Gene Kim, right? Gene who? Gene who? Gene Kim? I'm not sure.

It's someone. But anyway, we're coming back full circle, right? And I know I'm jumping right into it, but I'm just really excited to get to our guest. So sorry, before we jump into the guest, how are you doing, Andy? I'm pretty good. And I'm just as excited as you having actually Gene back on the call. So let's get straight to him because I think there's nothing else I can say to make this more exciting. Gene, is it really you that the real Gene Kim? Hey, great to be with you, Andy and Brian, and congratulations on episode 99. Thank you. Thank you very much. Thank you.

Hey, Gene, it's been, I think we talked about this prior. We met each other a couple of years ago at one of our Dynatrace conferences back in Orlando. So that must have been at least three years, I believe. Yeah, exactly. In fact, I remember that. I even remember the hallway we were in. Wow. In the track. That was awesome.

And, you know, we had you on the podcast. I think we actually back then recorded three podcasts because we had so much to talk about. And if people want to learn more about it or kind of re-listen to it, right, we'll probably put the links up there as well. Back then, it was all about the Phoenix Project, which was, I think, a game changer for the DevOps industry or for organizations that wanted to transform and actually understand what DevOps really means from a cultural perspective, what organizations need to do to change, to get rid of waste. And now there's a new thing, right? What's the next big thing you're working on? Oh, you know, for the last three years, I've been working on something called the Unicorn Project, and that's coming out on November 26. And, you know, what really motivated me to write is that

this problem still remains. You could do everything, you know, described in the Phoenix Project, but studying the DevOps Enterprise community, it's still so clear that there's at least four big problems I think that stand out. One is that there's all these invisible structures that are required for developers to be productive. And the problem is that they're invisible. And most organizations, they have decades of technical debt that make, you know, doing even simple things almost impossible. I think, too, is I think there's often a very much a will to do DevOps. But I think it's not quite clear, you know, what exactly we need from leadership. You know, what behaviors do they need to model?

What things do they do that help and which things they do that hurt? I think I've also been fascinated by the fact that, you know, I think the DevOps movement was incredibly crucial for spotting that this problem of like, we can't get code to where it needs to go, right? In other words, we can't get it into production. And it turns out there's this other parallel universe that's almost exactly the same but it has to do not with code but data so how do we get data into the hands of you know the frontline developers but it's often stuck in the systems of record you know these data warehouses and it takes six to nine months

uh to uh to get data to where it needs to go or to make you know schema changes or to make data available so yeah that was a real eye-opener to me and then i think uh fourth was uh uh you know this this notion of uh uh you know this thing about digital disruptions on every board agenda right so i think it's being kind of weaponized and cutting causing all sorts of strange things to happen. And so I actually do believe that there's a – especially in retail, the retail apocalypse is decimating certain parts of the economy. And I think that is happening in every industry vertical. So just being able to be able to connect the dots from like what do executives care about to the daily work of developers. I think those are the things that really I want to explore in addition to functional programming. So,

you know, those are the sort of my aspirations around the unicorn project. Yeah. And I, I think this one is, this book is really great because it walks through, you know, again,

it's a, it's presented like the Phoenix project as a story and it walks you through how these teams overcame all the challenges in front of them in order to implement this. And the reason I bring this up specifically is you mentioned the fact that everyone is aware of these things, but they're having trouble implementing them. And that's what I see all the time. So I deal with a lot of customers and prospects in my job. I shouldn't say deal with, I engage with. You get great delight and satisfaction out of it. Right. But usually when we have a new prospect, we're trying to sell our software into them. And I'll ask them,

where are you on, let's say, your pipeline in automation? And so many times, even now, years and years later, it's, oh yeah, we're really trying to get there. We really want to get there, but we really haven't had a lot of time to put much effort into it. Or we have part of the pipeline built, but it's still manual. You know, because we fit into that stuff. But you still hear that the progress isn't as far as we would have thought. A lot of people know about it. A lot of people want to be there. But what I like about this book is it's really showing you some of the common things that we probably have taken

from all the stories you've heard that people encounter and how to overcome them so that you actually do get to these places. Yeah. In fact, I mean, I think the, I'm actually going through the audio book, just, you know, spotting mispronunciations, acronyms that were mispronounced, et cetera. And I'm just having a lot of fun listening to it. And it just kind of reinforces for me that really this is a book about contrast. Maxine, our hero, she's looking around. She knows what great looks like. She embodies creating great teams, great technical practices.

And she's blamed for the payroll outage unfairly. You know, thrown into the Phoenix project as a four-month punishment. You know, that's terrible. But all around her, she sees people who can't get things done, right? They're not doing builds, right? The builds are always breaking. You know, there's no automated testing. And so, you know, her job in the story is really to kind of recoil from this and to be horrified by it.

You know, she sees a merge, a three-day merge process and is like physically sickened by it. So, yeah, I think the goal is really to try to convey, you know, just how awesome and great, great feels like when you have right architectures, when you have right technical practices, when you have the right cultural norms and just paint in vivid detail, just how awful and sickening it is like when you can't do it. So really Maxine, she chooses her mission, right, is to rescue developers, you know, liberate them so that they can, you know, feel that sense of incredible joy that I think brought us into coding, right? That sense of incredible creativity and productivity where we even lose sense of time or even sense

of self, right? This is the... And it gets into the flow, right? I mean, that's... Flow, right. It's a second idea called that call that focus flow and joy and flow is really in that uh spirit of uh dr uh mahali cheeks and mihai right who wrote this amazing book called flow and gave this amazing ted talk that describes you know that transcendent state we achieve when we do the things we love you know without impediments and obstacles and

hardship right the the other thing I wanted to mention too with this is ourselves at Dynatrace, we've had the luxury and the good fortune of having an endorsement from the top down to do this journey ourselves. So contrasting

with the book where there's the Rebel Alliance in the book who are kind of subversively trying to do this. Some people are lucky and they work in an organization where maybe CTO or someone very high up says, we need to make this change. I understand, or we understand that we're not going to survive if we don't go through this transformation and it's all hands on deck, they get full support. But I think what is probably, and you can maybe tell me what you see, what's more common is you might not always have that support. So the book almost can be used as a loose blueprint of how to go the DIY route, maybe, and start your own little rebel alliance and how to, you know,

pick something small, get a team of people you really think can work on this stuff and start small and try to prove out some of these things. And then you'll pull in more allies as you go along. And that's another thing that I really liked about it. Cause it's, you know, not everybody has luxury of full on support in the beginning. Yeah. Right. Um, yeah, it was a great point. And by the way, uh, and this is what I remember so vividly from our conversation is your description of like, you know, this was, uh, our transformation was driven from the top, from the beginning, the flagship product. And that really made an impression on me.

And in the Unicorn project, it's been my observation studying the DevOps enterprise community. This is a community that I've just gotten so much delight and it's been an honor to study for the last five years, seeing how these things are being incorporated in large complex organizations where you don't have that top-down support. Really, you have this incredibly courageous leader who's, you know, in many cases, putting themselves into incredible personal jeopardy, trying to push the organization to where they have, you know, moral conviction that, you know, where they need to go. They're hiding capacity. They're doing things on the side. organization to where they have, you know, moral conviction that, you know, where they need to go.

Yeah. They're hiding capacity. They're doing things on the side. They're kind of, as you put, kind of putting together this loose coalition and alliances really so that they can show a success and then build a billion and show, show it, right? This is not a belief. This is something we built. And, you know, that's what drives a more business, a business case and allows the more conservative, more risk averse people to eventually get on board. And so that, this community has really inspired the Unicorn Project. And it's, so in the book, you know, Maxine couldn't do it alone, right? It's like in the movie Robinson Crusoe or the movie Lost. You know, she's like stranded on this island, right?

Supported by nobody and is approached by this mysterious group of people who recruit her into the Robo Alliance. And so it's really Maxine in partnership with Kurt, this kind of savvy leader who just knows kind of how to bend the rules and stay underneath the radar screen that really allows

them to take all of Maxine's ideas of like how things should be done and really bring them into reality, take advantage of opportunities to show that this is a better way of working. So to your point, one of my hopes with the book is that people have internal book clubs like they do with the Phoenix Project and be able to say, is our leadership more like Kurt? Who's really kind of has the best long-term interest organization at heart? Or is it like Chris, the VP of R&D, who is actually kind of a very weak character who wants things kind of the way they are and is almost afraid of change. So I'm hoping that might bring up some interesting and maybe courageous conversations. Does that resonate with you, Brian? Oh, yeah, absolutely.

I think that's always the question. And I think, too, when you have the people like Kurt or when you have the people like Chris, Sarah, Shannon, Cranky Dave. I love Cranky Dave's nickname. But these are all characters if you've been working in anywhere in IT for probably even a year or maybe even six months, you can identify them in your organization. You know exactly who's who. So they're very archetypal characters. Oh, and Brent. Oh, Brent, of course. And Brent's't just even mean, oh, Brent, of course.

Brent's back, right? Brent's back, yeah. But, you know, and I don't even mean in like the archetypal Star Wars way. I mean archetypal even in just in the IT world, right? So you can point to every single person in your organization who are these characters. So I think it is critical, as you say, to have those conversations and identify who's who so that you know where to go, maybe where to sneak past, you know, keep your head down, which Maxine didn't do a very good job at doing, right? Yeah, it's one of the things I'd learned doing the Unicorn Project is there's a, you know, famous Tom Cotter who wrote the, you know, seminal book

on organizational change, right? The eight, the urgent, the burning platform, right? That came from Cotter. But he also wrote a book called Accelerate. He talks about what he calls the second operating system. The first operating system is the official hierarchy, you know, is the org chart. And, you know, he suggests that, you know, to really get great things done, you know, to act faster, get better decisions, you really need the second operating system that you overlay on top of that, which is all about relationships. And it's these informal networks that you create to get things done. And I think really that rebellion in the Unicorn Project is meant to embody that, right? You know, find the other greatest engineers in the company who all are supremely dissatisfied

with status quo. And, you know, as they state, their mission is to overthrow the ancient powerful order because they know there's a better way to work. So, yeah, I think there's a lot of literature to suggest that, you know, these are the way that we create new, better ways of working that are better, safer, happier. Hey, Gene, so now looking back, I mean, you've been, as you said, in the enterprise DevOps community for that many years. I think you're hosting at least two DevOps Enterprise Summits every year. Is it even more?

Is it two or three? Yeah, it is. We have one in Las Vegas that's coming up next week. And that's end of October. And then we have one in London that's around June. And so what's great about that is that it gives us opportunities to study

organizations that are really global. And I would say it's really the largest brands across every industry vertical. And what they all have in common is they have hundreds or even thousands or tens of thousands of developers, just like Google had not so long ago. So it just shows that every company is becoming a software company and they need to be adopting DevOps permissibles and practices.

So if you think back, I'm pretty sure people always ask you, so Gene, what's your definition of DevOps? What does it really mean i would assume that definition also has changed over the years or has it or has it not or has it expanded has it evolved so my question to you would be you know if somebody approaches you and i'm sure they do all the time what was the what was the answer maybe a couple of years ago when you started on that mission? And how has it changed? And how do you now explain what DevOps really means and what it means for an organization? Yeah, great question.

So in the DevOps handbook that came out in 2016, we came up with this. Here's the definition technical practices and cultural norms that allow organizations to deliver applications and services quickly and safely which allows experimentation and innovation allows the fastest delivery of value to our customers while ensuring world-class reliability security and stability so that we can win in the marketplace or even survive in the marketplace so i like that because it doesn't actually say what DevOps is, right? It says what the outcomes are, which I love. But I actually love this definition more now, which actually came from John Smart, who for so many years, he was the head of ways of working at Barclays. And he said, it's better value, sooner, safer, happier. It's so great. And I think in the Phoenix project, I mean,

we use the instruments of the three ways and the four types of work to kind of explore kind of, you know, how does it impact our daily work? And in the Unicorn project, I use the instrument of the five ideals to really just show, in my mind, kind of experientially what is required to create greatness. And so the first ideal is locality and simplicity. So sort of the opposite of technical debt. The second ideal is focus, flow, and joy, right? That feeling of fun that we're talking about versus toil. The third ideal is improvement of daily work. So like the Andon Chord, we have to prioritize improvement of daily work, even over daily work itself. The fourth ideal is psychological safety.

So the opposite of the desolation and the cultural tones that the Phoenix Project are creating, where people are getting fired left and right for failures. And the fifth ideal is customer focus, really putting this unflinching search at what things do our customers really value that they are willing to pay for, which create lasting, durable business advantage versus things that are only of importance to our functional silos. So those are the things that I meant to explore,

kind of these other dimensions of DevOps before and after. First of all, thanks for that answer. The question that I have now, I have to admit to the audience now, to the world, that you sent us the parts to read the book, and I only made it right now as of the time of the recording to uh half of part two so i don't know all of it but i do want to mention that i finished it but i'm not but i'm also not i get the points i'm also not running around you're on vacation and andy runs around like a maniac i sit at my desk all day no but i have a question for you because you know when when when we talk with our customers and they also like to hear our story and then what we are now basically promoting and pushing to them is what we call autonomous cloud management or autonomous cloud enablement, which means we want to help them how their organizations can use cloud technology so that they can enable their development teams to become more autonomous when using that technology.

So, but I think, I mean, we have kind of a prescriptive blueprint on how to get there but now kind of circling back what i read in the first part of your book where maxine is really struggling with getting the development environment up and running right and actually getting access to it um is this i mean from my perspective and i think this is is what kind of people, what I answer them, I think you need to have something like a developer productivity team or something in your organization to get started with, right? Where you basically provide development self-service models. Like you basically need to deliver to your developer an app, a mobile app like experience to get started with the task. So on my mobile phone, I can download an app that does a certain job pretty well.

And so I think as an organization, I need to provide the same app like experience, a great user experience to my developers as well so that they are not slowed down by figuring out how these things work in this company, but just getting started. So basically, I don't know, development environment as a self-service or a, I don't know what you call it, but so I would be interested. Everything is a service. Everything is a service, right?

I mean, that's what it is. Yeah. In fact, one of my favorite lines in the book comes from Eric, right? Now who we know from the Phoenix Project, you know, he says, you know, in the tech giants, Facebook, Amazon, Netflix, Google, Microsoft, right, they put their best engineers on developer productivity. I think Google has over 1,000 developers on dev productivity. By their numbers, that's a billion dollars a year. Microsoft probably has 3,000 developers on dev productivity. Whereas in most organizations, the people who they put on dev productivity and builds and CICD and telemetry platforms are the summer interns. Or the developer is not good enough to work on features. contrast of the the contrast of how highly the tech giants prioritize it versus uh how much um

in you know traditional organizations they don't value it and uh it is no doubt in my mind that developer productivity is one of the most uh important uh priorities for any organization in fact such a nadella, CEO of Microsoft, he said, if a developer ever has to choose between a feature or improving dev productivity, choose dev productivity because we will reap the benefits forever. So I think that's, I can't be overstated.

In fact, Eric also talks about this amazing story of Nokia, right? The chairman of Nokia, right? The chairman of Nokia, when he realized in 2010 that the Symbian OS build times were two days, that there was no hope of catching up with Apple, right? They switched to Windows Mobile because he said, if a developer takes, it takes two days for a developer to learn whether their change worked or would have to be redone then all our hopes on near-term profitability and long-term viability is a mirage it was an illusion right so i just for the chairman of a company to be able to say that i mean it just shows that this is something i think in 10 20 years every uh business leader will also

be able to do but in the meantime it's really up to us to be able to convey how important dev productivity is. I think it's funny because that was one of the notes I had put was that one about the people at the top and the bottom. So I'm glad you brought that one up for me. But I think that also goes to address, right, if we think about, you know, the title of the book, The Unicorn Project, right? Everyone looks at the Googles and the Facebooks and all these as unicorns, but then you even beautifully mentioned in the book that a unicorn is just a horse with a horn on it, right? So you have all these horses that you can turn into a unicorn by sticking a horn on it, right? But, and you address it in the book where, you know, developers can't get anything done. You

have all these developers sitting around and can't even build an environment. But at these, the quote unquote unicorns, in the first day or the first hour, even sometimes, you're supposed to deploy code, which you can't do unless you can't just spin up your own environment. But I think the idea, right, the idea, what you're saying though, with all this is like, you don't have to be Google. You don't have to be Facebook to be able to give the developer, to enable them, asy's saying with the developer enablement team or whatever to enable your developers to come in spin up an environment and try something right that's not a unicorn idea which is the title is almost it's i mean the prod the the title the book the title of the team is almost a misnomer right because the whole idea is you don't have to be one of these unicorns to do this. Right. And by the way, you know, when I'm laughing, it's not because it's

funny. It's because it's sad and tragic and all we can do is laugh. I mean, it's maddening, right? But it was 2011, 2012. And one of my biggest aha moments was when I got to spend a day at Etsy. And this is when John Ospaugh was, maybe it was 2013. And I got to spend a day at Etsy. And this is when John Ospaugh was there. Maybe it was 2013. And I got to watch a deploy. And it was just amazing, right? The fact that every new engineer at Etsy will do a deploy by the end of the first day. And so, yeah, they're only pushing their picture to the site. But still, it's a deploy. There's blogs about their board members doing deploys.

It even says even dogs do deploys. At Facebook, you go through a boot camp and you're doing a deploy within the first couple of days. And in most organizations, some of these applications, they're so complex, they require, they're so tightly coupled to everything. You can't do a deploy.

You can't even get, the only place it will run is an integrated test environment, which there's never enough of. They're never cleaned up. It's just – it's one of those things that some things are just so obvious when you put them in contrast next to each other. And to your point, Brian, I think your point is right on. Maxine's saying that they are taking the same DevOps and principles and patterns that were pioneered by the tech giants, but must be adopted by every technology organization. And it's not that small beats big. It's fast beats slow.

So big and fast. Well, decimate big and slow and small and small, right? So I think that's what's so exciting about the, you know, quote, enterprise is that it's like the sleeping giant awakening. Once they fully embrace, you know, these new modes of production, new modes of thinking that were pioneered by the tech giants, the economic value they'll create will eclipse that that was been created already by the tech giants, the economic value they'll create will eclipse that that was been created already by the tech giants.

And I know that's trillions of dollars, but that is, in my mind, it is obvious that when you take those same practices, put them in the organizations of which 98% of developers reside, make them as productive as if they were at a unicorn, a tech giant, you know, that will create trillions of dollars of economic value per year. So, yeah, it's fast beats slow. And big and fast will decimate everybody else. Hey, Gene, coming to the responsibilities of a dev productivity team or, I mean, what you've seen out there, can you give the audience that may now realize, hey, we work in a company, we don't even have a dev productivity team

or we have one and we only see the interns there. Can you, and I don't want to say interns are bad, right? But basically coming back to your argument earlier, Can you roughly explain what you have seen in the organizations you work with, what the dev productivity responsibilities are, and also what type of people they have in there? I'm especially interested in, is this just the tools? Is it also them giving architectural, let's say, are they giving help on architecture?

Because obviously you need to have the right architecture for your apps in order, for instance, to bring build times down and things like that. So what's the scope of a dev productivity team? What kind of people do you see being part of the team in organizations that are successful? MARK MANDELMANN- Yeah, I kind of have a very broad view

of it. It's like, you know, I think platform teams probably fit into that. You know, the kind of the SRE competencies might be coming from here. But yeah, I think the broadest goal is like help developers use their best energies to solve the business problems at hand, right?

And not have to deal with infrastructure, things that they shouldn't need to know. They shouldn't all be experts in telemetry. They shouldn't all be experts in security. They shouldn't all be experts in telemetry. They shouldn't all be experts in security. They shouldn't all be experts in operating systems. So the goal is to embody that knowledge into platforms that developers can use and, you know, quickly inherit the best known ways to solve problems so they can use their best energies to, you know, solve the most important business problems as opposed to solving puzzles all day

and Googling things and stack overflowing things. And so things that obviously in my mind fit in there is like environment creation, right? Everyone should be able to get a production-like environment and be able to run it on a laptop or run it in a cluster somewhere or run it in the cloud. They should be able to have some opinionated patterns they can use for deployment and architecture, right?

Like the 12-factor app pattern or container Kubernetes, whatever, right? God help us if they all have to learn Kubernetes, right? It's just so hard, right? Telemetry, right? It's like, oh, we want someone to say, here's how we do logging in production and here's how we do metrics. And we'll give you these APIs. You can just use them and, you know, they'll just show up, you know, in a way that you want so that developers aren't have to learn about cardinality rules and, you know, which ones will break the telemetry cluster. Right.

So these are things that, you know, these are things that we want to liberate developers from. And there's no doubt in my mind that there's so much value. And so these dev productivity teams, they're also probably responsible for onboarding new teams into any of these platforms. Like, do you want to use Kubernetes or Mesos or whatever, right? Hey, we'll support these, but not these. And if you really want to go it alone, you can. But that's kind of like not on the menu. So you're really on your own.

But I think there's a tremendous value in being able to provide that for developers. I would put databases in there, too. Despite 30 years of experience, I still can't write fast database queries and I probably have too many indexes and my queries are still slow.

Right? So, like, having help on that. Does that resonate with you? Yeah, not completely.

And I think that's also what we are seeing. And I guess the, you're right, I mean, there's a lot of different roles that kind

of fit in. And you mentioned some of them in the beginning, the platform teams, the SRE teams, the performance engineers, there's a lot of, a lot of different roles, but in the end, I like what you said in the end. And if I kind of get this, you, you want to build, you want to provide a self service model where developers can really focus on what they need to do, which is using, and I like this, the best energy to solve business problems and not having to think about every other problem because it's been fully automated into the platform, into the tools that they use, and the Dev Productivity team is also there to onboard them, or to onboard new platforms, but also onboard these teams and enabling them

to actually use these platforms in a, and I call it, as what I said earlier, in an app-like experience. Like I wanna, you know, I just wanna download a new app. Hey, I wanna deploy an app on Kubernetes. So actually I don't care if it's Kubernetes, I wanna deploy it in a two-stage pipeline, and I don't want to write YAML files.

I mean, that's... And I really like that because now a little bit of the stuff that we are doing, we've been also focusing on how can we make, for instance, monitoring available as a self-service. So we always say we have a lot of data, but the most important thing is how can we get easily the right data to the right people or tools at the right time to make the right next decision without them having to learn how does this monitoring tool, in our case, Dynatrace, work? The data has to be easily available, either through a Slack bot or an integration with Jira because they're using Jira or whatever else they're using, right?

I mean, that's one thing. And the other thing that I want to say, I really like you use the word opinionated. I think you said opinionated delivery and and I like that, too, because currently we are we're working on an open source project called Captain and Captain has also it's an event driven but very opinionated operator or orchestrator that is basically doing continuous delivery and automated operations for cloud-native applications.

But I like that you used the word opinionated because that's also the way I explain it. Captain has an opinion about how cloud-native applications should be deployed, tested, evaluated, and promoted. And that's what we're doing. And I think that's why I like the meditation a little bit at least. I love it. And just to what is the context, right? I mean, when I'm Googling for something about how to build a Kubernetes whatever,

I don't have an opinion, right? My opinion is whatever is the first answer I find on Stack Overflow, right? I'm not that good at it. I don't deserve to have an opinion. So I like to have an opinion so like to have a strongly opinionated way like here's kind of what experienced people say is the best way we're going to do things or you know here's some choices i think it's great and i love the idea of like solving business problems versus solving puzzles uh for me my uh not so recent

past i was trying to figure out how to escape spaces and file names inside of make files and yeah i i couldn't figure it out like after a day and and this uh buddy told me oh that's the double dollar sign in uh make files and i got really really angry because i knew that 30 years ago and now i resent it it's like i don't care i i don't want to deal with that stuff anymore. So there's certain things that I value in terms of learning. And there's other types of things like double dollar signs and make files that have really no value to me whatsoever. It's like I learn it and I'll throw it away because it has no long term. I don't want to use up space in my brain for stuff like that.

Right. I think this all ties into, Andy, if you go back to when we spoke briefly with Josh McKinty at the end of Perform a few years ago, and we were asking him, you know, what his thoughts on, I think, I think we asked about, you know, internet 3.0, because I think we're in 2.0 at this point, but he jumped ahead to 4.0. The whole idea, I want an internet where I don't even have to be aware of the internet. And that always tied back to me, the idea of, to put thatem software, disable your call waiting, you know, make your connection, sit through it, and then you have your slow connection. And with this whole idea of like, now it's just there and I don't really have to think about my connection unless I have to put in a password for a new, you know, hotspot. Same thing with the developer ideas. Like the developer shouldn't have to think about any of the other stuff.

All they should really have to concentrate on is pushing their code. Right, solving the business problem. Right, and if they're spending any time on things outside of that, it's not set up right for them, at least as ideally as it could be. Right, right, right.

And I think that's where it needs to be. The developer should just walk in, plop down, here's my code, and push it out, right? Yeah, and maybe it out, right? Yeah. And maybe just to resonate with that, Brian, so I wrote this blog post, my love letter to Clojure. It's the hardest thing I've learned. It's a functional programming language. It's a Lisp.

And functional programming is, for me, it's made like 95% of my errors just disappear. I mean, it's kind of an astonishing claim, but I wrote 9,000 words on trying to substantiate why I believe that. And, you know, it's because it takes away certain things that are just very dangerous, like your ability to change variables, right? They're immutable. You know, it's forced to kind of discipline around side effects, right? All input outputs happen at the beginning and end end and everything in the middle is pure functions. And I just love the purity and beauty of that. And kind of one of the weird things

that I've now self-identified as a developer. So, you know, for 20 years, I self-identified as an ops person despite getting my graduate degree in compiler design. Because I just loved operations and infrastructure. But now, like three years ago, it sort of flipped. I just love coding and just how much you can get done and being able to build all these things. And kind of this weird side effect is that I really detest infrastructure

now. And it's not that I don't value it. It's just that I'm terrible at it. I told my make file story, right? I don't want to do Kubernetes deployment files. I don't want to, like me writing a Kubernetes YAML file is like a disaster. I'm terrible at databases. I just want to be in my little universe. And I think, you know, maybe I'm exaggerating just a little bit, but I really do believe that, you know, if you can, I would love to be surrounded by world-class infrastructure people who just have done all the work for me and do exactly like you said. I don't have to solve puzzles these days, right? I just use what they wrote,

build the platforms they built, and suddenly, like, my database queries and storage, it works, right? You know, my deployments work, my telemetry shows up in a way that not only works, but could be leveraged by the rest of the organization and feed into data warehouses and, like, dashboards.

I mean, those are amazing things. Right. And I think it really affords a specialization that is very good. Right. It allows us to solve business problems and leverage expertise in a way that we just couldn't do before. Right. Before we'd have to have meetings and open up tickets and have people do work for us. And you were saying the self-service platform. I think that dynamic is so great because now anyone who uses the platform is genuinely using the best known methods of how we think we should be solving problems. And I think it's magical for the developer. It means that there's developers saying thank you to all these people. Yeah. Gene, looking back,

so it was the Phoenix project. Now it's the Unicom project. What's next? I have no idea. My planning horizon these days is measured in minutes, maybe hours. I must say there is something that really riveted me, and that was the Nokia story, the story told by Risto Salasma, the chairman of Nokia. And when I first heard about it, my first reaction was, what can we possibly learn from a board

member who oversaw the 95% destruction of the market cap of Nokia? But it was just a really astonishing book, right? That line of how at the highest level of the company, he knew that 48-hour build times was basically a death knell for them. And Windows Mobile didn't work out so great, but it was a calculated bet. It was like, we're not going to get there through Symbian OS, right? So it was just an astonishing book. And I think I would just love to explore further that I think we all have this common narrative

of why did Apple beat Nokia or why did Google beat Yahoo in the display ad and the search space? And it's all because they typically sound like, oh, because Apple was so smart and Google was so smart. They had the best people. They had the best technology. And I think there's a narrative that says, you know what? Nokia also had really great people. And Yahoo also had great people. In fact, Hadoop was built at Yahoo. I think the answer of why they were beaten has a lot more to do with architecture, technical platforms, how they prioritize infrastructure, how they made or didn't enable developers to be productive.

And I would just love to explore that more fully. I don't know what to do with it yet, but that's something that I've been interested in for years. And working on the Unicorn Project only makes me even more interested because this is not just a technology concern. This is a business concern. This is not technical debt. It's like complexity debt, business debt. I mean, there's nothing technical about it. This is a choice made by all leaders. So that's something I just, I think kind of when I look ahead, that's where I'd love to be spending more time educating myself on. So basically, I mean, again, I didn't read all the stories, but I would assume that the one that is being more flexible,

that actually coming to your point of the data, right? That one that can actually react on data faster and then being flexible enough to change, if they see basically that something is not going in the right direction and but if you're inflexible if it takes you two days to build then obviously you are not very agile and you cannot change as fast as you need in order to avoid a big mistake i think that's yeah and i think uh i think that's definitely a part of it and i think the five ideals really came from being able to try to even more concretize that. Like one is, you know, to really react in the marketplace, you have to be able to be able to make changes quickly and deploy them.

And it can't be scattered across 35 different teams. And, you know, that requires an architecture. You know, second ideal is focus, flow, and joy, right? You have to have employee engagement. You have to have people happy doing their work. You know, third ideal is improving the daily work. Are we really prioritizing improvement, you know, especially when it comes to technical debt reduction, right? Are we prioritizing architecture and debt productivity in the way that we should be?

Psychological safety. Google spent years studying what made great teams great in their project rework, project oxygen. And psychological safety was always at the top of, you know what team supported as being the most important and they they defined it as to what extent do members on a team feel free to share what they think um say what they uh to express ideas without fear of castigation or blame or ridicule um the fifth idea is customer focus um so yeah i just uh i think those kind of i think the answer kind of lies in there somewhere hey i want to i want to throw a quote out at you and i want to get your opinion so this quote now um comes actually from from anita angler that she actually was leading the initial transformation

or part of that team that was actually the initial DevOps team, what we would now maybe call a platform team. And she said a quote, she had a quote earlier this year because we asked her about her thoughts on when we talk with customers about they have to have these many environments and automated pipelines and automated testing. And then she made a comment and she said, for her, the maturity of a company is indirect proportional to the number of environments

that lead up to production. That's great. I love that. And so the result basically, if you do the math, that means if you only have production, you are the most mature company because you don't need anything else. And then people sometimes probably say, well, how is it possible? Because you obviously have modern deployment models where you can do canaries or, you know, you can deploy through feature flags. But I was, I wondered, I wanted to throw it out at you and see what your reaction is. Yeah, I love that quote.

Because, right, in the most, I would say in the kind of the most dangerous environments, you have no testing environment, no staging environment, no place safe to make changes. So that means like you're making all your mistakes in production, right? No integration environment. Yeah, I think so. As you get better, right, you have lots of integration test environments. And that's good, right? No integration environment. Yeah, I think so. As you get better, right, you have lots of integration test environments, and that's good, right?

And those are often not valued. So that definitely resonates with me. But if you look at how these world-class organizations work, I mean, one talk that really blew me away was Spotify. He said, you know, we were getting good enough. This was a dev manager at DockerCon 2013, 2014. He said, you know, we were getting good enough. This was a dev manager at DockerCon 2013, 2014. He said, you know, we were catching all the errors we could catch in unit testing, but now the errors are really happening between the components.

So that means we need an integration environment. And so that's when they made the decision to basically have every developer not just write and run the unit tests on the laptop. They said, we need to write and run integration tests on our laptop. And that's when they created basically kind of this mini Spotify environment inside of Docker that has every component in it that developers are expected to run every test in. And it just shows how much you can shift left on that.

And to do that, right, you end up with orders of magnitudes, more pre-production environments than production environments. Instead of just one pre-production environment, you have hundreds or maybe even thousands. So that, quote, definitely resonates with me, and I think it's just another great difference between what great

organizations do and what not-so-great organizations do. Very cool. Yeah, I mean, Gene, is there anything else if you, you know, what, what kind of to, to, to wrap it up or kind of come to the end, but if, if somebody asks you, what is the biggest takeaway from the last couple of years that you, that you spend, you know, in writing the book and interviewing companies, what is the top thing that people need to do, that organizations need to do, the biggest takeaway? Yeah, I think it is this importance of dev productivity, right?

Everyone sees features, and so that's the ones that get funding, right? My app, my feature, my API, right? Does this underneath that are all the systems records, the APIs below that and so forth, right? Those are tougher to get funding for, but in general, no one is funding these dev productivity teams, these platform teams.

And I think that is actually one of the most important. And I'm hoping the Unicorn Project does sort of help people see why it's so important and enables conversations within the organization. And I generally hope that, you know, people can use that to confront some issues, whether it's

their productivity or psychological safety or what do we want from our leadership. And I'm hoping that, you know, causes some productive conversation, maybe even uncomfortable. And I think it really does suggest that, you know, people's intuitions of what is needed is absolutely right. And I'm hoping that they can use a book as ammo to help really kind of push that agenda forward. Andy, did you want to go ahead then and summarize? I know you've got a train to catch.

Don't miss the train. Yeah. Well, the the thing is it is really it is really challenging for me to summarize all the stuff that that gene actually you know all the all the stuff that you that we talked about i think there's a book that summarizes it you know read the book uh we'll make sure to put links out there on the conference proceedings so people can find it. But I think it's very easy to find. But for me, the biggest thing that I've –

a couple of notes that I made to myself is when I asked you about how have you defined DevOps and how would you define it now, I think there's a little evolved over the years. But I think you said John Smart gave a quote saying, better value, sooner, safer, and happier. I think that's a great way. And in the end, it really comes down to making sure that the people that actually create the value for the business, which are the developers, can use their best energy to actually solve these business problems and not puzzles in the fast, most efficient way. And therefore, organizations need to put the right people into the dev productivity teams

because this is a multiplier. If you put the right people there, you're building systems that enable developers to become self-serviced in standing up to environments, pushing code through an opinionated library, opinionated delivery pipeline, not having to deal and care and learn about how many dollar signs do I need to escape? How does this YAML thing work? And I think this has to be just part of it. So I think developer productivity is key, and I cannot agree more with it. And also one thing that I take home, two things I take home for me as a homework,

A, I obviously want to finish the book and B, I'm also very interested in that Nokia story, what we can learn from that. Great. Thank you, Andy. And the one thing I wanted to mention, the only other quote that I had highlighted, now there was a ton of stuff in here that I wanted to highlight, but I have so much to learn before we're experts at this. And then to me, that's one of the keys in all of this is that you're going to learn, you're going to start doing things, but there's always going to just be so much more to tackle.

And this concept, if I had, I think, you know, the five ideals, they're all very, very important, right? You can't get through all this without maybe all five of them. But if I were forced to pick one of the most important ones, I would almost say the fourth ideal, psychological safety, to me, I believe, is one of the most important ones because you have to have the ability to make mistakes. You have to have the ability to learn from the mistakes, to make errors, and then build better pipelines,

better automation, better everything around those mistakes so that they're not made in the future and that everyone's enabled without placing blame on everybody. And we had that in our own system where Bernd, our CTO, said, yeah, I know you're going to take down production. That's going to happen.

I'll cover for you. Make sure whenever those things happen, you build a resilient system that takes care of that and you try to predict all the different things. You use chaos engineering to figure out what could go wrong. How do we build more resilient apps? But the idea is, yeah, it's not going to come overnight. You're going to be learning so much over and over and over again.

And it's a work in progress almost always until you get to some really elevated state. But every once in a while, we just see, I think Azure just this week had issues with their, what do you call that? Their VPN access, right? We couldn't log into VPN. Everyone's still making mistakes, right? So it's okay. Anyway, that's what really struck with me. Anyway, I love the book, Gene.

Thank you for writing it. I think it's a great learning tool. And again, in story format, it makes it so much more enjoyable to learn this kind of stuff. Thank you so much. In fact, we are making excerpts, I think 60% of the book available for free.

And so those are all available for download. And those are in a couple of, in a week or two, we're going to have the audio book excerpts available as well. And so those are all available for everyone to enjoy. And yeah, I hope everyone does enjoy it.

And you know, I would love to get any feedback on what you all think. Is Mark Hamill doing the audio book? That was really fun to interview. You can listen to the, the audition tapes. It was really kind of very fun to sort of pick one and kind of

give some extra stage direction of that was something I've never really done like that before. So that was great. Awesome. Well, thank you for coming on.

Anybody wants to reach out to Gene or follow you, you're just at Gene Kim or do you have, were you able to? Yeah, Gene K at ITRevolution.com and on Twitter,

Real Gene Kim. Real Gene Kim. And if you have any questions you able to? Yeah, genek at itrevolution.com and on Twitter, realgenekim. Okay, realgenekim. And if you have any questions or comments for us, you can send them to pure underscore DT on Twitter or send an email to pureperformance.donatrace.com. Thank you, Gene. Andy, as always, thanks for doing this with me. We'll see everyone back for episode 100 next time.

Thank you so much, and congratulations again on hitting 99. Thank you. Thank you. Thanks, Gene. Talk hitting 99. Thank you. Thank you. Thanks, Dean. Talk to you soon. Bye-bye.