Abi Noda: Gene, so great to have you on the show. Also, here with Laura today. We’re so excited for this conversation. Really appreciate your time.
Gene Kim: Oh, I’m so delighted to be here. And Abi, I mentioned to you, I’m a fan of your work, and that was so great to meet you guys last year. And so delighted to be here. Long time coming. Thank you.
Abi Noda: We really enjoyed both of our times at ETLS. So thanks for all your efforts there and putting on a great event and great community.
Gene Kim: Oh, looking forward to many fun adventures ahead, including this interview.
Abi Noda: So Gene, we want to dive right in, you’ve had a storied career helping organizations with DevOps and now developer experience and helping organizations really apply these principles to transform how they work. And I want to ask you, I think some organizations view developer experience as sort of a next chapter in their transformation journey. I’m curious, how do you see it? How do you see developer experience fitting into this journey we’re all on?
Gene Kim: Yeah, it’s great with the way that you put it, is many organizations see developer experience, developer platforms as their next chapter. I really like that. And I think there’s a reason for that. And before we started recording, we were talking about looking back all the way to the Phoenix Project, DevOps handbook, the state of DevOps research, the work I got to do with Dr. Nicole Forsgren. The topics like modularity and architecture and developer platforms, are they just sort of a random set of practices that they have nothing in common, or are they all incomplete expressions of a far greater whole and there’s a reason why these things emerge and why it should be no surprise that is the next chapter? And I think it’s definitely the second. And so to me, what is a developer platform?
Why is it important? We know from the Phoenix Project is that when to get anything done, you have to open up tickets with 30 different people and pester them for weeks just to even get the smallest things done. This is terrible. And we spread that across every developer in the organization, across potentially scores or hundreds of teams, you basically have a system that is locked up where no one can get anything done. And so what I learned from working with Dr. Steven Spear, is he wrote the most widely downloaded Harvard Business Review article of all time called Decoding the DNA of the Toyota Production System. And we worked on a book called Wiring the Winning Organization that came out about a year and a half ago. And I cannot tell you how much I learned from that. It was just the most intellectually challenging thing I ever got to do, but also the most rewarding because so many things that I kind of viewed as separate before, now are obviously the same thing.
And so our quest was what’s in common between agile DevOps, Toyota production system lean, resilience engineering, platform engineering, and so forth? And our conclusion is that they’re all incomplete expressions of far greater whole.
And if I can just end with one other point, is that the other sort of key learning for me over the years, especially working with Dr. Steven Spear, was that the big problem now that we’re all trying to solve, regardless of functional specialty domain ,is the ever-growing number of functional specialties. And so what I found so amazing is that what I learned in the book is that one of the top examples that we use is healthcare systems, especially emergency departments, which is just notoriously dangerous.
You risk getting injured at a rate higher than skydiving or even base jumping in an emergency department. And so the big surprise to me was that it wasn’t always that way. In the 1950s, emergency departments were relatively safe. And the hypothesis is that it was because you had very few functional specialties. You had doctors and nurses, very little technology. You had X-ray machines, and that’s not terribly complex. And so you could get away with what we call a simpler social circuitry at what we’ll call layer three, technology at layer two, patients at layer one. But fast-forward 50 years, and now you have scores of clinicians. Just among doctors, you have nurses, supply chain, pharmacy transport. At layer two, you have technology, you have not just X-ray machines, you have imaging, MRI machines, CAT scanners, technology everywhere. And then, let’s say you need a very, very sophisticated layer three wiring to coordinate all their efforts.
And it doesn’t do it very well, unfortunately. And so the same thing is happening in our world. We have an ever-increasing number of functional specialties. Laura, you had mentioned that you’re going to KubeCon, right? Okay, can your average developer use rattle off Kubernetes commands to restart a cluster pods? I know I can’t. You need functional experts. And so how do you avail yourself to all these amazing technologies without having to make everyone a Kubernetes expert without creating silos that make everyone wait?
Laura Tacho: I like the way you just described social circuitry. We talked before we started recording about solving these organizational problems with math. And one of the math concepts that I often bring into my own conversations with organizations is just simply graph theory.
And the more nodes that you have, the more complex everything gets. So a team of three, we’re having this nice conversation, as soon as we add a fourth person, it doesn’t just get 25% more complex, it gets a lot more complex because we have all of these other relationships to manage as well.
Gene Kim: I think we were talking beforehand about how much certain formulas really we love, because it just shows that these are kind of facts of life that you can’t argue away, no matter how gifted you are in rhetoric. And another one is that, so why are cues so dangerous, is that it puts you into an NP-hard scheduling problem. And I actually had to prove it to myself that if you have a job shop, so I guess the academic term is the job shop. You have work centers, you have routings, and in order for work to get complete, you have to pass through certain work centers. You are above polynomial time. And I didn’t actually believe it.
So I wrote a little simulator of you have two silos of movers and painters, and is it really that difficult to find the optimal solution for where N equals 20? And what I learned is like, “Oh yeah, you are in combinatorial space where you don’t have to get very complicated before you are at hours of scheduling time for trivial problems.” So I also learned that logging is really difficult when you are in combinatorial space. You print out something at every step in combinatorial space, you spend all your time logging and not computing.
Laura Tacho: Yeah, interesting. Yeah, I think queuing and approaching infinity wait time when you’re scheduling at near capacity is something I think we feel that every day. Right? And when I think about the slowification, simplification, amplification themes that you brought up in Wiring the Winning Organization, a lot of it is just cut down on the number of nodes, don’t schedule at 100% capacity, make things flow with less friction through the system, kind of optimize the system for performance. And that just means cutting down on a lot of the moving parts.
Gene Kim: Yeah. So I’ll give you a concrete example. This is another one of those aha moments for me. So I think the great technology leaders that I admire, one of them, her name is Amy Willard, she’s Director of Technology at John Deere. And so she’s part of the program committee for Enterprise Technology Leadership Summit. She’s shared her experience reports over the years. And she and so many others evoked this, what I learned from Dr. Ron Westrum, he introduced me to the term the socio-technical maestro, high energy, high standards, great in large, great in the small, and they love walking the floor.
And she talked about how she loves shared services, she loves centralizing the best people so they can make sure that their expertise can be available to the people who need it most, regardless of where they are in the organization. But there are certain places where shared services can be very dangerous, where if it’s work that every organization has to do and they all have to get in queue and wait, that doesn’t lead to great outcomes.
And so there are places where she had a specific situation where groups needed the specific expertise, and they were spending a lot of time waiting, like a lot of time waiting. And she said, “I love shared services. I love expertise, but not there.” And so she basically broke up that group, put them in the business units, and suddenly all the problems disappeared, because the scheduling, there was no shared resource. Each business unit got one, and it could just be naturally used however they saw fit within those groups. And for me, the big aha moment was it takes that kind of a leader who understands, “Oh, maybe we’ve wired our organization wrong.” That could be software architecture. It could be just how teams communicate and coordinate or schedule. And just by making this small change that entire category of problems disappeared.
Abi Noda: And sticking on this math theme, you were also telling us about option value theory, something you’ve been getting into in setting. So tell us and listeners more about that. What is option value theory? How is it relevant to developer experience, platform engineering, DevOps? How can listeners understand and apply that?
Gene Kim: Yeah. Oh my goodness, yeah. In fact, I’ve been meant to write a blog post on it this week, so I’ll do my best. So I’ve been working with the amazing, Steve Yegge
And we’ve been exploring how does gen AI help developers. And kind of the conclusion, well, there’s really five things. It helps us do work faster.
I think so many of us have experienced that. We can be more ambitious about the things we can build. This incredible one is that we can do things alone that otherwise would’ve required a team of people. We can have more fun doing it. And we can have more swings at bat. And as we were talking about it, this familiar term from the past started appearing. It seemed like this concept around option value.
And so I learned, so Dr. Carliss Baldwin was a student of Dr. Robert Merton, who won the Nobel Prize for economics for the work that he did around option theory. And so he won that with Black and Scholes, which basically created a pricing, a way to price options. And so an option is the right, but not the obligation to take an action. And I learned about this formula that I guess was in Carlos’s book, that despite reading it five times I never picked up on. And the formula is NK divided by T, and then there’s ambient value of sigma. So N is a number of modules. So obviously probably higher is better. K is a number of parallel experiments you can run at any time. So again, higher is better.
T is the duration it takes to actually perform an experiment. So you want T to be smaller to make the value go up. And then sigma is something that captures the shape of the risk reward space. And so when sigma is one, basically it says that you have perfect knowledge and there you don’t need option value. So what Dr. Bob Merton said was as risk increases, the value of having options increases. In other words, you want the ability to defer your decision to when you have more information. So A-B testing is great, you have the right to test your A and B options, but you are not obligated to take either one of them. You can take A, B, or none. And so when sigma is very high, that means you don’t know where the treasure is buried. The higher the sigma is, the more valuable that treasure is.
And so you want to become more valuable to explore the space of options.
Laura Tacho: I think we have both equal amounts of enthusiasm or maybe you definitely have more enthusiasm and more knowledge about this. But when we can solve organizational problems with math, it’s just very fascinating because the physics of these things of how organizations just fundamentally work in the market, it doesn’t vary so much. There’s just some laws that we always have to respect that just show their faces in different ways. And I think it’s very fascinating. And just reflecting back what you’ve shared so far with us, in order to be able to run those experiments at such a high throughput of experimentation, we do need the independence of action.
We can’t have people submitting 30 tickets and waiting in a queue. And there’s something you said earlier, all of these things to support that independence of action like architecture, DevOps, and DevEx, platform engineering, these are all just incomplete expressions of a far greater whole. And I wonder, how would you describe that whole? What is it that we’re actually trying to get to with all of these formulas that we can apply to organizations in different ways of working that are enabling us to unleash the greatness of our organization? What’s the whole that we’re aiming for?
Gene Kim: Yeah. And what we are trying to express in the book was that there’s really maybe two concepts that leaders at all levels need to understand that in my mind kind of make up what is it that these socio-technical maestros are intuiting and used to lead so well. Just to be concrete, that lead to the incredible performance multiples that you see in the state of DevOps research that, let’s see here, one, two orders of magnitude difference in performance across the five tuple of deployment, frequency, lead time, change success rate, and meantime to repair, I’m using the old older language. And in the case of meantime repair, that’s three orders of magnitude, better performance, which is just shows how much better you can be when you create the right wiring at layer three. So what intuitions are they using? And so I think the first one is understanding the notion fully of coupling.
And we use the metaphor in the wiring the winning organization book of two people moving a couch. And I love this because I have tried for 20 years to understand great software architectures. I’ve interviewed, in fact the whole ideal cast I used to run, that was 20 plus interviews just to try to concretize this elusive property of great architecture. And so here’s what our treatment of it is that imagine two people moving a couch, Steve and Gene. And so you might think that this is all brawn work, no brain work needed.
But it turns out there’s all this non-obvious problems they need to solve. Where exactly is the center of gravity. To get through a narrow doorway around which axis do you rotate? To get through a narrow winding set of stairs, who should go first? Should they face forwards or backwards? And what’s amazing is that you don’t need focus groups, you don’t need consultants, Steve and Gene, just by picking up the couch, trial and error, fast feedback experimentation, we have some confidence that they will achieve the mission. But there’s all these things that leaders can do to make it more difficult or even impossible for them to achieve their goal. We can turn off all the lights and suddenly the nature of the work hasn’t changed. But boy, the work will take longer. It’ll be more dangerous. They might damage themselves or the environment around them. But what’s interesting is that there’s another dimension of difficulty that leaders can introduce, which is you can introduce a lot of background noise or like a loud siren, loud music.
And again, we’re not changing the problem, but suddenly Steve and Gene can’t communicate and coordinate as well. And so as leaders, we can even put in an intermediary that prevents Steve and Gene from talking directly with each other. And so suddenly you can put in a product owner or a lawyer or an account manager, or you can put in a Jira ticketing system so that everything has to be put into well-ordered forms. And what’s astonishing is that we have now set up a scenario where Steve and Gene might not achieve their goal. And I think this is what happened with DevOps 15 years ago, where suddenly the deployment became so complicated. And because Dev and Ops weren’t allowed to speak directly with each other, no matter how many fields you put into that Jira ticket, you could not achieve the mission. The information flow so far exceeded the bandwidth given to them.
And so essentially they could not work as a team. And so the couch is really a metaphor for joint cognition, joint co-creation. And so there you want things to be coupled in order to create a single coherent system. So there’s some things like you want developers directly interacting with customers. You want a customer observation, you want certain functional specialties embedded with the developer groups because you don’t want those to go through tickets because we want that coupling to be there. But for the vast majority of things, we want decoupling. We want independence of action because the interfaces are known and you don’t want anything between them actually degrades independence of action. So I love this because it’s understandable, wish I had known this 10 years ago. And then Laura, to your other point, what’s the other missing piece? Is that you had mentioned the three mechanisms of performance, slowification. There are some problems, the most consequential problems you don’t want to solve in production, you want to solve them in planning and practice.
And then the second one is about simplification. You divide up and partition problems so they’re smaller so they can be simpler, easier, and fast to solve and safer. Modularization is a great example of that. And then you want amplification. You want to create a system where weak signal of failure is not suppressed or extinguished. You want them to be amplified so that problems can be better detected and corrected or better yet even prevented. And I think those three mechanisms really are pretty complete description of what all the things that we about in DevOps, lean, Toyota production system. So I find it very parsimonious and very satisfying.
Abi Noda: So I want to ask you in regards to these coordination problems that we’re discussing here, earlier you talked about how platform engineering, developer experience these concepts are partly aimed at this idea of self-service and faster feedback loops. One thing we see a lot of leaders grappling with is how many of these problems are truly solvable through tooling as opposed to changing culture, changing organizational behavior. How do you think about that bifurcation and the best ways of tackling these problems in organizations?
Gene Kim: Yeah, that’s a great question. And I think I have two primary responses. So what I gained a lot of confidence in working with Dr. Steven Spear was the notion is that layer three is a difference maker. And so in our community, we know about the joint venture between Toyota and General Motors that the famous NUMMI plant was previously the site of the worst performing auto plant, not just in North America, but probably around the globe in Fremont, California. And the remarkable story is that that same plant, when it was a GM plant in this joint venture within a year became one of the best performing plants on par with the best parts in Japan. And so what changed? It was the same people, same floor space, same capital equipment. The only thing that changed was all in layer three. In other words, same people at layer one, same tools and technology at layer two.
The only thing that changed was the management system at layer three. And so I think the reason why this resonates so much with us in technology is that we’ve seen the same thing where the same phenomena happens in technology as well. But I think that’s an incomplete answer because something also changed in DevOps, which is that we actually had these radical breakthroughs in layer two, tools and technologies. We had CICD systems, we had cloud, we had enabled self-service, which actually the reason why we call it DevOps is that it actually changed, blew up layer three, in what ways has how Dev and QA and operations and InfoSec, what hasn’t changed once you go from before and after. And so I think it’s really, we know how important leadership is. We know that transformational leadership is such a cool finding. I think it was in organizations that didn’t have these transformational leadership qualities, you’re only one-fifths is likely to be a high performer, which just shows like, oh man, that’s a wild finding that says leadership does matter.
We know that architecture matter, right? So that’s that layer three. But we also know that technical practices matter, is that you need automated builds, tests, deployments, telemetry, all these things to make sure that we can do our work safely and quickly with fast feedback and so forth. So I think leadership absolutely matters, but sometimes there are these amazing inventions like CIC, cloud that so radically change the work structures that it should blow up layer three and create these different ways of working. And certainly, I think gen AI is one of those, it’s maybe even bigger. If you can radically improve productivity and group productivity, how does that not change how layer three works?
Abi Noda: Gene, you brought up fast feedback loops and being able to work frictionlessly, and these are concepts, of course, that are part of DevOps and also developer experience. I want to ask you your take on just even the name developer experience that folks are talking about because one thing I’ve seen, Gene, is that it’s not uncommon for especially business leaders to react negatively when they hear the phrase developer experience. One leader I spoke to recently said, “Developer experience sounds like please coddle me.” Like, “Please coddle the developers.” So I want to get your take on this. First of all, how would you frame developer experience to a leader and the importance of it? And also, is developer experience just a poor name for these concepts?
Gene Kim: And to this mythical person, I would say, let’s explore what not having it looks like. And I think that was really the thought experiment that was a unicorn project, is the notion that you can take the best engineer in the organization, Maxine, and strand them in the desolate wasteland of the Phoenix project. It has years of technical debt and the best engineer can’t build, can’t test, can’t deploy, can’t get logs, can’t get license keys, can’t do anything despite the fact that she’s the smartest person in the organization, right? That doesn’t sound very good. It sounds terrible. And so if development is where the value creation happens, you want those people to do their work easily and well. I think that was one of the key takeaways of the wanting in your organization book leaders enable people in their organization do their work easily and well.
And if developer experience means helping the hundreds or thousands of people that drive the majority of value creation in the technology value stream, not that platforms are important and not that Kubernetes is important, but the value creation is no doubt in ideation, research, design and development. And a critical prerequisite for that is that they need to be able to get quick feedback on the work, requires so much of what platforms need to deliver. And so all those things that we talked about naturally belong to platforms about logging, CI/CD, environment creation, getting a dev environment, right? Those things you don’t want developers to have to do by themselves because they’re not going to do it very well, which is why you need world-class experts in these areas.
And just to share a story, I mean, oh my gosh, if my most frustrated times is grappling with configuring CI/CD pipelines, my build image went out of date and I was so proud that I actually got to implement this feature. It turns out for 10 years, every button that I’ve done in JavaScript is wrong. The hitbox is the text, not the button. And finally I was like, “Oh, that’s why it’s so hard to click.” So I fixed that in seven minutes and then it took me four and a half hours to deploy because my Node.js build image was without a date and I didn’t know how to make a new one. I mean, I have so many stories where I just wanted to do one thing and then it got caught in the barbed wire of the environment. I’m sure I’m not the only person to have run into that problem anyway, so that’s why DevEx and Dev Productivity are so important.
Laura Tacho: Yeah, definitely not the only person to run into that problem. And then when you think about those interactions that every developer has and you multiply it across entire organizations, I mean, I think the positioning of DevEx. Abi, has the anecdote of like, “Please coddle me.” And I like your take of, let’s imagine a world without developer experience. I often talk about it as a ping-pong and beer problem. It’s seen as a vitamin when really what we should be talking about is like, “Can you believe that one of your most talented developers who has the capability to build theoretically anything is sitting there for four and a half hours trying to futz with a Docker image to update the version of…”
How much money is that costing? Not just money, but time and innovation. These are real problems. It’s a painkiller. It’s not a vitamin. And I think that’s as soon as we can start to quantify and build a better business case, educate leaders on how to talk about things like developer experience using language that appeals to the whole business and not just to our section of engineering, I think the better off we all are because these are so important. These topics are so important.
Gene Kim: Yeah. By the way, just to riff with you, I had a friend, he owned that part of the system for a large bank and he said, “We opened up a Silicon Valley branch. We hired the best developers from the Facebook, Amazon, Netflix, and Googles. We found that most quit within the first 30 days because they were still waiting on laptops. They were still waiting on environments and taking compliance training.” And that was just this big problem that people were forced to face, right? It’s like, “Okay, we can’t even hang on to the best people we hired because of exactly those reasons.”
Laura Tacho: Yeah, it’s a real problem. I want to switch gears a little bit, Gene, and I’m thinking about being in the room at ETLS in Las Vegas this past August, and I think this was your introduction to Steve Yegge’s talk about the death of the junior developer, and you’re very bullish on AI, and I remember the introduction to that talk of saying AI is just fundamentally changing the way that software teams are going to be composed. And then getting into this idea of the death of the junior developer because we have AI tools to kind of augment skills of developers and the shape of our organizations are going to change fundamentally.
And I remember thinking, “Wow, that is a really…” It felt very bold at the time, and I just want to kind of get your take or ask you to expound on that a little bit because I know you’ve written about it on LinkedIn and other places and have done some webinars. And Abi and I mentioned we’ve been sort of following your explorations, but if you could just for our audience and the listeners sort of share your position on fundamentally how you think AI is changing the makeup of software engineering organizations, we’d really love to hear it.
Gene Kim: Yeah, okay, first off I’ll say, I’m having more fun now than I’ve had in a long time. Maybe it’s been 12, 13 years from the early DevOps days, but I think I’m having much more fun now, and I think it’s because I’m having more fun coding. So in 2016 I learned about, it was actually Mike Nygard, the author of Release It. He was then the SVP of Platform Engineering. Oh, isn’t that interesting? At Sabre, the famous travel platform company, and we had just finished a DevOps handbook, and I was looking for something really hard to do, and I thought now’s the time to learn this crazy programming language called Clojure, this functional programming language that runs on a JVM. And oh my gosh, it was the hardest thing I’ve ever done just because how do you program when you can’t change variables, right?
This is specifically disallowed, and I’ve never written Java before, so I didn’t really understand class paths or JVM, but I have to tell you, it changed my life because it reintroduced the joy of coding back to me.
So that’s in 2016 to 2020, but the whole GenAI thing has sort of dumped gasoline on the fire, right? On a whim, I haven’t done graphics programming or graphics manipulation in probably 20 years. I just said, “Write in Clojure and I’m going to give you an image, march up the left-hand side of the screen, find the red pixel, and then march to the right and complete the percentage complete in the video.”
And again, this is one of those life-changing moments where it just did it. And there’s just no way I could have done that without a ton of reading, right? I mean, the last time I did anything like that was probably 20 years ago in Microsoft C++ in Visual Studio, right? And it did it essentially in one shot. I don’t know how you can have an experience like that and not just sort of have it change your life and just have that open up new horizons.
So I think I just have moral certainty that these are ways that these help not just individual, but will help teams, and brings up the door of finding from this last year that had this very weird anomaly in it that said, “The more AI you use, the worse stability you got and the worse throughput got.” It’s like, “Okay, that can’t be right.” I mean, I’m not saying it’s wrong because they found what they found, but boy, wouldn’t it be great to actually test some theories that says, “Under certain conditions, you will not always reduce throughput and reduce stability. You can actually massively increase throughput and not sacrifice stability and get all these other dimensions of value that we talked about.”
Laura Tacho: So Gene, I kind of want to get really specific about this phrase, the death of the junior developer, because I think it is, it’s kind of sensational, right? But what I’m hearing from you is AI makes coding fun again, and you can do more experiments. You can be more productive as an individual. You can do a lot of things on your own that you might have… more productive as an individual, you can do a lot of things on your own that you might’ve relied on the hive mind of your development community to do before. And so I wonder when we read Death of the Junior Developer, we think organizations don’t have to hire junior developers anymore. I wonder if that’s part of it, but also that junior developers aren’t going to be junior for as long anymore because their learning is just so accelerated. Can you get a little bit more specific about what you mean really with the death of the junior developer?
Gene Kim: Yeah. In fact, Steve came up with a follow-up post I thought was great. He called it the Death of the Stubborn Developer. Maybe it’s not the junior part, but I think there’s three things that you touched on. One is that I do think that, and we’re hoping to test that people’s hiring habits are changing, people’s hiring is changing. And I think a great anecdotal example comes from Steve Yegge. He had a head of data that built a data experimentation platform in an afternoon. But what’s remarkable is that in the previous year, this would’ve been a summer intern project for a college student. So great for the head of data, but bad for that summer intern who could have had this amazing project to work on that could have his or her career.
The second thing is something that Dr. Matt Bean, actually after Steve’s post came out, he reached out to me and said, “We have got to talk.” Because it turns out he’s been studying what he calls the novice’s optional problem. And so for 15 years he’s been studying surgeons. And so for centuries, maybe more, surgery has always required three hands. And so this is a very natural place for a senior surgeon and a junior surgeon to work together. Good for the senior, it can get the work done. Great for the junior for all sorts of reasons. But with the advent of surgical robots now, the senior surgeon has the third hand.
And what’s happened, and this happens across so many domains, is that the novices become optional. And because they take 10 times longer, they actually have more accidents. Any operational-minded person will say, “Don’t let the junior get time on the surgical robot because time is money and we don’t want lawsuits.” And so this actually starves the path for juniors to become seniors. And so without someone with a longer-term view, their route has basically been, has evaporated. And then the third thing is the notion that just like DevOps with CICD and Cloud forced, that layer two caused layer three to get reconfigured. I think we’re going to see similar things. I don’t know what we’ll look like, but no… I think it’s impossible to argue that when I think there are so many technology leaders who are actually going back into IC roles. And so when I say a whole bunch, I’ve learned of almost 10 examples where technology leaders say, “I want to actually get close to the keyboard.”
Steve Yegge was one of them, where essentially it sounds like my tour of duty is over. I want to get, want to get back to the real value creating work. I’m sorry, the fun part of value creating work as opposed to approving expense reports, performance reviews and so forth. Not that those aren’t important, Abi, we know those are important, but I think it causes the shape of the role to change. And so we know from history that when the role changes, layer three will also change. So just so excited to explore what that might look like and super interested in any reactions you have to any or all of those.
Abi Noda: Yeah. I think the insight around the path to becoming a senior developer being complicated and potentially more difficult with the advent of AI is a really interesting one. And what are the longer term implications of that in terms of do you then end up with a workforce that is fundamentally, do you have less surgeons, senior surgeons? I think that’s the implications of that are interesting and profound. I can’t really fully wrap my mind around it here on the spot, but curious what you think, Gene. What does that mean longer term?
Gene Kim: Oh, yeah. Yeah. And the reason why I brought up the Mike Nygaard thing is that for the junior, what’s the benefit? It’s for people who don’t feel like bugging Mike Nygaard, which includes me, to have an AI as your infinitely patient teacher and coach who won’t get mad when you say, “I don’t understand. I still don’t understand.” How can that not dramatically change the life of juniors? No doubt. But two is to your point, I think this is where the socio-technical maestro comes in, is that for the vast majority of vocations, let’s take lawyers. Lawyers do not become profitable until they’re, in fact, the only people who make partners are the ones who are economically profitable. So you can be technically good at your work, but without the ability to earn client trust, build your book of business, you’re not going to make partner because you’re still losing money for the firm.
And I think those dynamics are probably there for engineering organizations as well. And so the need, as you said, for a pipeline of great senior technologists, and I think to make it very concrete, is that Steve introduced me to the notion of the task tree. For any given thing that you want to do, you create a hierarchical tree of tasks and you give your summer interns and the AI, the leaf node tasks, and that’s getting higher and higher. But who actually makes the task tree? Who actually creates the architecture that enables ideally independent action and the right decomposition of problems? It’s the seniors. And so I think AI can help with both of them.
Abi Noda: Yeah. Gene, where is your exploration around GenAI headed next? You mentioned potentially a new book you’re working on. Tell us more. What’s coming? Where’s your research taking you… on this topic?
Gene Kim: So for me, I just have so much enthusiasm about revisiting Dora and seeing if we can actually change the instruments so that we can find the signal that we know has got to be there to help developers, both the individual developer, and get some hints on what it does to the layer three of everything around developers. So super excited about that.
Two is, I can’t believe I’m working on another book. I hope that, I think for some of us, after you finish a book, it would take something really interesting to get you to write another book. That actually happened to me talking with Steve Yegge. He said he wanted to write, I’ll write a book on the CHOP Handbook, how to use chat oriented programming to help developers do what they want to do. And when I heard about that against all my expectations, I said, “Oh my gosh, can I help?” So yeah, we’re on a crash course to try to get our first draft done in a week, in a couple weeks, and it’s just been so fun because here’s two guys who love using GenAI for developers, for doing development work, trying to explore how much can you get away with with writing in a way that makes you do better work, get it done faster, have more fun doing it, be more ambitious of what can be built, and be very proud to put your name on it? And so the parallels between CHOP, chat oriented programming and CHOW, chat oriented writing and maybe STAR, chat oriented dot star has been super interesting in sort of the meta learnings around what are the common underlying principles of how you use LMs is, it’s been really, really fun and wild. Like I said, I’m having more fun now than I’ve had maybe in my entire life.
Laura Tacho: Gene, we’ve really enjoyed having you on the podcast as a guest. Abi and I are looking, so we met you in person at ETLS in Vegas, and we’re looking forward to meeting you again in person at ETLS in September. One of the things we both admire a lot about you, not only for your storied career and pioneering work in DevOps, is you’re just a magnet for community and assembling fantastic, wonderful people all in the same room. Can you tell us a little bit about ETLS, formerly known as the DevOps Enterprise Summit, for those of you who have followed along, and if someone listening to this doesn’t have experience with this community, what might they expect to learn from the people and the content that’s shared in that forum?
Gene Kim: Oh, yeah. Great. Yeah, so this will be the 11th year of the conference. So we’ve had 24 conferences, and it is the community of people that I admire most. These are people who are changing ways of working. And upon some reflection, I mean, it just really occurred to me, and I apologize, I’m so late in understanding this, but in some ways it was like the Dora users group. These are the leaders who said, “Hey, we are all interested in a methodical, scientifically grounded way of increasing our ways of delivering value that involves measurement.” And so yeah, there’s actually, as Amy Willard, who I mentioned before, there’s no technology leader, there’s no senior technologist who’s not working with AI. It’s just amazing. It’s not just at the strategic levels, but we’re all thinking about how do we use this amazing new technology to win?
So last year we had this, day two was the ultimate GenAI learning day for leaders. It was so much fun. I just met so many interesting people doing amazing things. And so we’re going to expand that program by 50%, and we actually changed the logo. So it’s like the Tech plus AI leaders and the plus AI is sort of in pencil. It’s sort of like a joke, but it’s not a joke. I don’t think it’s… Sometimes I get a little bit sensitive, is this a fad? If you think this is a fad, right, you might be making it like a big mistake. And I just love this further validation that says across every organization, and it’s not concentrated in the startups, it’s everywhere. It’s experimenting with how do we use this technology to help developers help our specific, any project, help these new initiatives create incredible value for our organizations? And I think there’ll be definitely a focus on dev productivity, specifically around GenAI.
And we’re looking for as many experienced reports about what’s working, what’s not working, which was a pattern that we very much are following from the DevOps Enterprise Summit days. And I just would say, I think the reason why it’s fun, for me, fun collapses at least three dimensions. For me, it’s high learning, it’s kind of high networking, meaning you’re hanging out with the best in the game, and it feels like something really impactful. So if something is missing one of those dimensions or maybe all of those dimensions, I can promise you it’s not fun. It’s boring, it’s a waste of time. And so I just thought the goal is really to create that magic where everyone is learning something super, super important, impactful. You’re hanging out with the best in the game, and everyone knows it’s good for them as a person, as leaders, for the teams, for their careers, and also great for their organizations as well.
Abi Noda: Well, Gene, echoing what Laura said, thank you so much for all that you’ve done for the community and the industry, and thank you so much for your generosity and spending time on our show today and sharing your perspectives and insights. This is really valuable conversation, and again, really appreciated your time.
Gene Kim: Oh my gosh, it’s so great to do this with you finally. And I really want to thank both of you. It was great meeting you. It was amazing. And Laura, thank you for getting your amazing clients to DevOps Summit. The two talks from Pfizer were absolutely fantastic and a testament not just to them, but also your amazing work. So again, thank you.