{{announcement.body}}
{{announcement.title}}

Author Spotlight: Gene Kim

DZone 's Guide to

Author Spotlight: Gene Kim

This month, we highlight DevOps leader and Unicorn Project book author Gene Kim as they embark on their first all virtual DevOps Enterprise Summit.

· DevOps Zone ·
Free Resource

Gene Kim

In our latest in-depth DZone interview, DZone regular Gene Kim speaks on the DevOps Enterprise Summit community and his most recent book The Unicorn Project. This week Gene Kim embarks on his first-ever virtual conference in the DevOps Enterprise Summit - London (which he previewed on DZone). 


How would you set up and tell developers about your latest must-read book The Unicorn Project?
I think the Unicorn Project will be of interest to almost every developer just because we all want to be productive and we want to work in a system where it's easy to get done what needs to get done easily, quickly, reliably, and securely.

I love the three domains. The first level is the features or the app. Anyone can get funding for that. For the backend systems integration and APIs, that's tougher because, you know, you can't see it. You only see the app. The lowest levels are the systems that the developer uses in their daily work. And that's what I found in almost every organization that’s very difficult to get funded. So, at Facebook Amazon, Google, Microsoft, they put their best engineers at that lowest level on the system that their developers use. Google has 1,500 developers on dev productivity that's over 1.5 billion a year.

Microsoft has like three to 5,000 developers. Most organizations put summer interns there or the developers who aren't good enough to work on features. This shows what leads to technical debt and architecture problems. That shows to what degree we must lift up architecture.

The second thing is, I hope the Unicorn Project will not only show how important developers are but also the systems that support developers. And it's not just definitely activity but also data right how do we get data to where it needs to be which is in the hands of developers so they can use it in their daily work. And I guess the last thing is, I think it starts with the trajectory of great developers is it doesn't have to be turned into a manager. It could be like what Maxine where, you know, she's really being elevated in her role is as an individual contributor, and her job is really to create greatness throughout the organization.

unicorn project

So many companies get lost in going from the formalization to the implementation side of their DevOps journey. Developers are often frustrated and knowing there is a better way. If they had this book as a North Star was to walk them through it and speak to what success looks like and in giving them the five ideals as that framework for success.

To answer that, let me talk about the construction of the book and specifically the first third of the book.

The mental model for me was, like the movie cast away with Tom Hanks, and crew so you have this kick-butt developer stranded on an island and she (Maxine) can't do anything right. She's in the middle of the most important project but can't get builds done and can't get the tools she needs. It was too busy to onboard her. She ends up being the top engineer in the company, yet still can't do anything. And I feel like and I don't think it's overstated to say that, this represents the way of life and the condition that most developers operate in.

Even if they can do builds, like to implement this simple feature takes, you know, eight teams.

When the amount of communication and coordination required is missing it feels like you're completely stranded. So, then, then you get it done, and then you're totally reliant on an external testing group and an external security group. I actually did have a lot of delight in writing that while laughing. It's so sad and tragic and funny all at the same time.

And like one of the claims I'll make and I am actually quoting someone else I don't recall who told me that every executive needs to read the Unicorn Project. I challenged him and was like no this is a book for developers, the redshirts. He goes, “I'm the furthest thing there is from a red shirt, I don't know my ass from my elbow. But what every CEO who is embarked on digital transformation needs to know is that the most important people in their organization, are those redshirt developers."

That's a heck of a statement. 

So, anyway, this is my long way of saying, I'm delighted to hear you say that just because, you know, only time will tell whether people will connect to it, but it's something I do believe.

Gene Kim quote 

With software running the world right now, it is important for C-Suite executives to be able to more easily see the world through the developer's eyes. A story like Maxine's helps any executive to get their and level up their understanding.

There were a couple of little passages that I really loved. The part where, Steve, the CEO says you know the technical debt is like the spreadsheet, you know, they’ve become so complex over the years that you can't change it without blowing the calculation. And that was really specifically designed to explain that most executives have lived in spreadsheets. Like with sales commissions, "How do we end up in the quarter?" And we've all been in situations where we came up, and we had a spreadsheet where we're just so scared to make any changes to it because we don't trust the results.

I use a metaphor in just trying to explain what technical debt feels like and then also describing that here's the desolation you feel when you're stuck in this tundra of technical debt built up over, in this case only years but in some cases decades.

My fondest hope is that the type of leader who really cares about this will be like, "How can I help enable frontline workers to do their daily work?" Whether they're in a retail store or on the assembly line or developers, you know, in the code editor right, I'm hoping that will trigger some discussions and some sorts that we haven't seen yet, so that would be very exciting to me.

How did the DevOps Enterprise Summit attendees and community at large help shape the Unicorn Project?

The simple answer is if you listen to every one of the DevOps Enterprise Summits feedback reports as I have, I've been blown away by the courageousness and bravery and innovativeness and savviness, and technical skill and leadership that came out of it. Really that's what the whole rebellion is really modeled after.

Just to be able to merge all of the central figures in the DevOps enterprise community to reinforce that everyone is represented. The rebellion really is the embodiment of that, the best of. The mental model for that was like the combination between the A-Team, the TV show Hogan's Heroes, and the movie Brazil where the number one fugitive is the rogue air conditioner repairman who breaks into people's apartments and fixes their air conditioning because central services won't do it for them. They’re like the number one person wanted by the state.

This is not to exaggerate the DevOps enterprise achievements as I wanted to put a more heroic frame on it. The story told was really kind of what I've observed over the last six years of studying and being a part of this community.

You mention in the book that if your dad helped push you and inspire you for The Unicorn Project.

If anything, my dad helped me get the book done. Before he passed away, I remember that he spent like five hours one December day just watching me kind of mark up the manuscript and tear my hair out like, “Oh this is terrible!”

I like to think that he actually got a lot of delight in just watching me work so that's the context.

If you could talk about the five ideals that you outlined in the book.

I would go in order. The first is to look around and just have an honest and unflinching assessment, and I don't mean a formal assessment, but they'll just assess themselves.

To what degree can we actually get our daily work done without having to deal with tons of other teams. And that really does say. I think I've mentioned that in the opening, it's like, what are all the invisible structures required to make developers productive and the dirty word is called the architecture. Over the years and decades really turned into something we're all a little bit cynical about it being visual diagrams and the pretty picture doesn't know what it was. To what degree can we, you know, work without being coupled to everything in ways that we don't want to be coupled. That requires simplification. To really fully understand how much did that prevent us from getting work done, right, that was one of the top predictors of performance in the State of DevOps report was architecture.

The second of those focused on joyWhat I didn't really fully appreciate until I learned and started spending so much time programming in Clojure. By the way, DZone is awesome and I'm so grateful to them for posting the love letter to Clojure.

That sense of having so much fun that you lose the sense of time and even lose a sense of self at times right that's like, I think that's what really marks when we're in a state of flow as framed by Dr. Mihaly Csikszentmihalyi. So, I think we've all in technology gravitated towards it because there's something really fun about building things and I think we know what that sense of flow feels like. 

Just so you know, I think a lot of programmers still know what it feels like because of all their hobby projects. But just like Maxine in her open-source project. She knows what flow feels like and then they go to work and this is terrible, a system where they can't. So, how do they demand that it should be equally easier to work on small projects as a hobby, as well as projects that a company is willing to spend hundreds of millions of dollars to make happen because they're that important.

Thanks to a third of the improvement of daily work, all right, how did you get from here to there? Well, we have to prove our systems will work. 

Speaking just technical debt reduction I love the Nokia story…“Nokia died because of technical debt,” as framed by Risto Siilasmaa. I was looking for a smoking gun quote like that for almost three and a half years. I finally found it in his book.

And then fourth, psychological safety, trying to create the linkage between like safety culture and accord, and psychological safety as we think about the DevOps movement, and then focus on the customer. And one person wondered is it an accident that focuses on the customer comes last? I thought that was a very provocative question because I think it was very deliberate. And then the person said, “good because we have no business folks and the customer until we can get our own act in order.” We don't deserve a seat at the table if we can't first get our own work done. That was just a profound comment.

And then for companies they can't just be internally focused, they also have to be customer-focused.

It’s peculiar right? Because it should really be customer-focused first because until we can fulfill promises, why bother folks? We don’t want to make more promises. We have got to fix how we do work so we can fulfill the promises that we already made.

We've got to solve the problems. Instead of creating more problems.

Yeah, and this one of the other things that were kind of interesting to me it was like, even though Maxine was a developer, the way that it's written it's like you kind of feel like there's a little bit of Maxine and all of us, and almost like there's a little bit of a dip, even if we're not all developers, you kind of, it's a little bit evergreen in the way that a character that you normally wouldn't think you can relate to, you know, now you can actually relate to you mentioned like cast away a lot of us haven't been stranded on an island but through the power of story. We have got to be in their world and so that's what was really interesting about Maxine, you not only get that and don't have to completely read the full book yet to do so. It's like you feel that you can relate to it and that there was a part of a developer in you that you didn't know was there.

Maxine serves a couple of roles in the story right, she knows what greatness looks like and when she gets thrown into the Phoenix Project, everywhere she looks is like the opposite of greatness. Secondly, I think she also represents technical excellence right which is not just a domain of developers it's infrastructure, databases, and security.

She knows, like her role in the story is to institutionalize greatness. And it's kind of interesting that she's like the greatest engineer in the company, but without the right systems or systems that support around her, there’s now no way to exploit that greatness. Regardless of where we sit in the ecosystem, we need to be able to exploit that greatness and Maxine knows how to do that.

I'll bring up that you might be amused by is that one of the reviewers noted, Maxine is chaotic good, right, like she'll always make her own bagel. I laughed when I heard that because yes Maxine is lawful good, but she had to partner with Kurt is chaotic good. 

Kurt will find a loophole to figure out how to spend you know to get to a per diem of $5,000 a day. And it's a really both of them right, she knew what to do, and Kurt was wanting to figure out the how in exploiting every loophole every relationship, every favor.

I love that you are constantly bringing out new voices across the DevOps and developer landscape at your conferences.

I'm almost starting to think of them as core cohorts, when did you enter the industry as a cohort and what cohort did you enter with. And, you know, I'm constantly looking for like who are the people doing the most innovative things and so I want to especially find right now who the emerging leaders are and having them come on board as the latest cohort. We're spending a lot of ways to try to find kind of who those people are and make sure that everyone realizes that.

Burnout has been a big theme at recent tradeshows and conferences.

Yeah, it's just, great that we have such an ambitious community that you know we're all seeking to understand what we need to understand so we don't burn out.

One of my favorite sessions was the CFO CEO panel where they actually talk to people on the bridge crew, how they speak, and so forth. So, I'm proud of the fact that we’ve talked about burnout in the last few years and have some of the best experts to have shared their experiences on that.

Effectively, burnout was kind of at the core of my book The Phoenix Project, to me it was, you know, what happens when you have a system is preordained to fail. That can't help but lead to cynicism and fatigue and ineffectiveness. Those are the five by Dr. Christina Maslach, those are the three most obvious symptoms of burnout.

Gene Kim on burnout

Topics:
devops, gene kim, interview, unicorn project

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}