Episode 104: Gamifying Product Creation to Meet Customer Needs with Luke Hohmann

Brian Dawson: Hello. Thank you for joining us for another episode of DevOps Radio. I'm Brian Dawson, and today with me I have Luke Hohmann, the founder and CEO of FirstRoot, Inc., author of Innovation Games, and man of many other credits. But I'll leave that for Luke to cover throughout our conversation. Hello, Luke. How are you doing today? 

Luke Hohmann: I'm doing well. Hello, Brian, and hello, listeners. We're really happy to be here.

Brian Dawson: Alright. This is exciting. And I'll let you know, like many of my other guests I know Luke outside of DevOps Radio. I've had the opportunity to have many interesting conversations with him, and I'm excited, Luke, for you and I to be able to have a conversation with our listeners being privy. You know, I gave a short introduction, so let's take a moment to give our listeners a chance to learn a little bit more about you. 

If we could start with giving them an overview of what you're doing today. We notice you're the CEO of FirstRoot, and I believe that that's your primary focus today. Can you tell us a bit about it and/or what else is going on with you?

Luke Hohmann: Yeah. That's an exciting way to start, because FirstRoot is doing some really exciting things. FirstRoot is a public benefit corporation with the stated public charter of improving financial literacy and economic equality for people around the world. We do this, we accomplish this goal, by using a technique known as participatory budgeting in schools. Participatory budgeting is a process endorsed by the United Nations in which we go to a school and we give the kids money to invest in that school and we support them as they learn how to manage money and they learn how to make real change happen in their school.

It is a fantastic process. It's a structured process, because you don't want to just walk up to the kids and hand them money and say good luck. You want to guide them through how to make decisions. And in the process we get to integrate not only financial literacy, but we get to talk about civics and positive civic relationships and design thinking throughout this process. It's a very exciting company, it's a very exciting opportunity, and the market is absolutely substantial. 

Brian Dawson: And so I'm going to want to go into your background, but first I have to dig into a few things there. Let me start with just the why. Why is FirstRoot necessary? Why did you build FirstRoot?

Luke Hohmann: Yeah, I'm thankful that you did that. There's a framework from Simon Sinek, "start with why." And I've been a fan of Simon Sinek's work for a while, and I love the fact that he talks about you've got to know the why. Well for me the why is extremely profound. If you look at the research – and I'm going to reference the book called The Spirit Level, which studied the effect of economic inequality around the world.

And what the authors found was that the more economically unequal a society is the worse it performs on every known health and social dimension. So let me give you an example. The United States is the world's most unequal society and the United States scores the worst on the following areas. We have the highest level of obesity, the highest level of homicides, the highest level of incarceration, the lowest level of trust.

We have horrific infant mortality compared to other Western democracies. We have the highest levels of opiate and drug addiction. And what the kicker is, is that when we talk about an economically unequal society, rich or affluent people like to fool themselves into saying well that's a poor person's problem. But the data shows that it's everyone's problem, meaning an affluent person in America is less likely to be healthy in these dimensions than a poor person in more equal countries.

So this is something that cross cuts every segment of society. And frankly, we don't need pills to cure some of these problems. We need a deeper analysis of what the root cause of the problem is. I'm an engineer, and eventually we're going to talk about DevOps and we're going to talk about mean time to failure and recovery from failure, and every person listening to this podcast knows if you're an engineer and you have a production outage you've got to do a root cause analysis. 

The problem is that we're not going root cause analysis of societal problems. We're looking at the surface. We're looking at the manifestation of some of these issues, not doing the root cause analysis. The second part of the why for me – so the first part of the why is this massive problem that is affecting our society from health and social index. And this is literally wasting billions of dollars of money that could be spent on far better things.

The second thing is that because we have become so distrustful, that distrust has extended to our civic engagement. We no longer trust our governments. We're better with our local governments, like our cities, but our trust in the effectiveness and the ability of the federal government to take positive action is at an all-time low. Brian, 24 percent of Millennials say that it is a bad idea to run a country using a democracy or a representational democracy.

Brian Dawson: Wow.

Luke Hohmann: So we see what's happening right now, right? And so what we want to do, the why is I want to change economic equality and positive civic engagement, the how is through a technique known as participatory budgeting, and the what of FirstRoot is we provide a gorgeous, easy-to-use platform to support all stakeholders in implementing and delivering participatory budgeting solutions in schools at scale. 

Brian Dawson: Phenomenal, phenomenal. So much there I want to dig into, but the one I'll pull on is so you're diagnosing, for one of the better words. And forgive me, I'll take a broad swath. I'll get some of this wrong, but forgive me, right? We look at where we have gaps or deficiencies as a modern Western society, and you're identifying that in the capitalistic democracy that we're in for there to be equity people need to have a level of financial literacy, financial understanding and empowerment, but they also have to have a sense of civic engagement. 

They have to engage with the democracy. And if we can manifest these things, bring about equity with financial and democratic participation, it could address some of what you found at the root cause of much of this, right? And interrupt or correct me if I'm wrong, but then where I want to go to, and you started to hit upon it, is okay, look, you're an engineer. I mean, you're an engineer. I've talked to you enough to know at your heart you're an engineer. 

Why is a tech guy getting involved in this? Or let me put it a different way. What's the role of technology in tackling the challenges that FirstRoot has taken on?

Luke Hohmann: I am a big optimist. People who know me actually will remark – and they've worked with me and they're like, dude, how can you come into work every day with a smile on your face?

Brian Dawson: Yes. [Laughs]

Luke Hohmann: You've worked with me. Like how could you just come in? And for the listeners, even Brian has seen me wither criticism about like what is this idea that you want to do? Right? And you're laughing but it's true. And it's because – I'm an optimist because I do believe that technology can create profound positive impact in the world. 

I actually give a talk to high school students every now and then where I'm trying to promote STEM careers, and specifically computer science careers and software development careers. Now I want to kind of give you some of the reasons why I'm so excited. Software to me is the most honorable profession when practiced well. In the 1950's, the biggest supermarket had about 7,000 items for sale because that was the actual limit of human record-keeping relative to food and food safety.

Brian Dawson: Oh, wow.

Luke Hohmann: Now the average supermarket has over 160,000 items, and we have 7,000 kinds of salsa and ketchup and mustard, because a software engineer wrote the inventory control system. We have the world's highest skyscrapers in Dubai because a software engineer wrote the mechanical analysis code to determine the stresses and the construction. We have anti-locking brakes that save lives in cars because a software engineer wrote an embedded control system. We have pizza on demand from food delivery because a software engineer harnessed geolocation services on a phone and made it easy for us to get pizza while we're watching our game.

All of these are manifestations of this amazing opportunity, that we have safer planes, we have communication systems that were unimaginable 30 years ago because software – you know, and I joke, I'm like, yeah, yeah, those hardware people, they helped out too. [Laughter]

Brian Dawson: Yes. They have a bit of a role here, right?

Luke Hohmann: Yeah. You know, those chip guys, you know, fine, we'll give them a little credit. No, I'm kidding. [Laughs] And yet this is why – why am I doing FirstRoot? Because the other thing that just breaks my heart is we have social media companies creating solutions that tear at the fabric of human relationship. There was a study published last year in Harvard Business Review, which was really remarkable, that as advertising increases social happiness decreases. 

Because you're just reinforcing what you don't have in a way that is playing to the worst kind of human emotions. We have kids who are – and we're going to get philosophical for a moment, Brian.

Brian Dawson: Yeah, I love it, I love it.

Luke Hohmann: So the question becomes what is really wrong with some of the social media that's out there? And then I can talk about how FirstRoot is designed to help ameliorate and address some of that. But human societies function well when the institutions we create have positive self-correcting mechanisms. So let me give you a couple of fundamental institutions that have corrective mechanisms. One is law.

As laws have been developed we sometimes make bad laws, but the curious thing about law is that law evolves, law changes. Laws that are bad eventually get removed and they get replaced or updated with laws that are better. Now social activists who see the future faster than the rest of us will be unhappy with the pace of change, and I get that. Of course there are laws in our books right now that are still horrific. 

I have a transgender son, and we've got laws being passed in certain Southern states that are taking away their rights, and it's frightening when my son says, "Dad, can I literally travel through that state safely?" And my response is, "You know, I don't know. I don't know. And frankly, now we've got a class of our citizenry who have to worry about traveling across state lines because of poorly constructed laws.

But I have faith that our society will address that because over time we have seen the legal system get updated. So the notion of self-correction exists in law. It exists in capitalism. Capitalism creates offerings that meet the needs of our customers. When those needs are not being met or when those needs are no longer required, the products and services that are offered change. 

Again, now one aspect of capitalism that you can be rightfully critical is when capitalism is framed as constant growth it can become cancerous and it can become exhaustive of physical and planetary resources. So now you're seeing capitalism evolve. You're seeing capitalism move into the circular economy, the doughnut economy, conscious capitalism. You're seeing people move from pure financial investing to impact investing.

So you're seeing again the response to society to help society become successful. The challenge that I have with, in a sense, the internet writ large, but social media for sure, is there's no corrective mechanism. People can spew flat-out lies with no corrective mechanism, and therefore the structure of how humans interact with each other and how we evolve is broken and damaged.

Brian Dawson: Well there's really a couple of threads, interesting thing to pull on there where we talk about technology as both an enabler but then also such an accelerator it can be dangerous. So your examples of being self-correcting, of law being self-correcting, we'll have to call out that the correction can be delayed or skewed when there's a level of corruption introduced into the system and that at the end of the day those systems are not entirely self-correcting, meaning they need some level of human observation and interaction, right?

Luke Hohmann: Right.

Brian Dawson: So take this to something I've been saying over the past few episodes and translate it into software. At the end of the day software is developed by humans for humans. Now when we talk about social media – so we talk about technology applied for good. If you look at FirstRoot, the ability to develop a platform to bring FirstRoot's benefit to bear at scale is amazing. For you to travel the country without modern technology and do this would be difficult. 

But on the flipside, I think when we look at something like the damaging elements of social media, this is again something that moves so much faster than law. It moves so much faster than capitalism. I say this and it sounds dramatic, Luke, but the damage it can wrought, you can bring about, can occur so fast that it's difficult for that human element to come in and correct it. And so when we talk about technology and you talk about this philosophical concept that you just covered, is it fair to say that the acceleration that technology provides can cut both ways?

Luke Hohmann: Oh, of course. It has to, right? I'll give you another kind of philosophical point. And I've had some really interesting disagreements with friends on this point. So this one I'm going to present is – so the ones I just talked about, this notion of self-correcting mechanisms helping society evolve to be a better society, people don't generally disagree with that but let me give you one that people have some valid disagreements with. One of the things that I bring to the table is I am an engineer but I'm also a cognitive psychologist and an organizational behaviorist.

So I look at how do we think and how do we solve problems? And when I say we, I mean individually cognitive psychology problem-solving, and we collectively, individual team and groups of teams and teams of teams problem-solving, right? So how do we solve problems and how do we engage in that activity? So when we're looking at how we solve problems, one of the things – and this goes back to something that the listeners, when we were getting warmed up for the podcast I was sharing a story about how I try to be good at forgetting bad things in my life.

Because there's so much good that if you allow yourself to forget the bad – now that sounds trivial or trite or whatever, but in reality it's quite profound because forgiveness, genuine forgiveness of a transgression, requires an act of allowing yourself to forget that transgression. And when we have media that can record every action we've ever done, we can no longer forget. And so we're now faced with a construct in humanity that we've never had, which is far outpacing our human evolution, our biological evolution, which is relationships are sustained when we forgive, to forgive we must forget, and yet we have technology that makes sure that we never forget.

And what's more important is with – I asserted to a friend that – it was around to me 1996 or 1997 that it became cheaper to retain information forever than to put in place the policies and practices needed to delete it. That's a sociological change that we haven't yet fully resolved.

Brian Dawson: Yeah, yeah. So interesting analogy then question on that. We will eventually get to your background. We've got to stay on this for a bit and Agile and SAFe and then ultimately how you arrive here. But it's an interesting anecdote. I just started. I'm probably late, way beyond the times in scouring Netflix for shows to watch. I just started watching Humans. And for those that haven't watched Humans, it's a society where we now have synthetic humans.

They're highly intelligent, yet by default they lack consciousness. The plotline goes to the original designer has figured out how to introduce consciousness into synthetic machines. But where it relates here is that the creator's son, Leo, is kind of a cyborg, right? He's half machine. He's brought him back to life, and I believe he has some sort of memory system. 

But part of the plotline was that with his memory system he's human with human emotions, human consciousness, but he can't forget. So he remembers every bad thing that has happened to him in his life. And they called out a sort of interesting philosophical point in line with what you've said that this very kind of medium-budget show got me thinking about, is how important it is for the human psyche, and to a certain extent I'd even just loosely argue for human progress to be able to – you know, that our memory prioritizes improvements. So anyway, you just jogged that.

For people that haven't seen Humans, check it out. It aligns with what you talked about, Luke, where we are in society. What happens when you can't forget? That's a lot of burden to carry. So let's transition a bit off of this though and talk about so what does this mean, right? Us as software engineers, what are our responsibilities? This gets into the space of ethics and ethical technology. 

But what do our listeners, our DevOps engineers and leaders and people actually bringing this technology to bear in your opinion need to be thinking about to take on kind of this new time, this new challenge?

Luke Hohmann: Yeah. And I think maybe one of the things I should also mention to make sure it's stated is when we're venturing into the field of things like ethics and ethical choices, I want the listeners to know that I'm not claiming I'm a perfect person by any means. You know, I joke that I have a lot of flaws, and if you need any help finding them talk to my family. [Laughs]

Brian Dawson: Exactly. I second that, yeah. Not for you, for me, by the way.

Luke Hohmann: Yeah, yeah. No, no. Oh, yeah.

[Laughter]

But I think it's worthy to look at the notion of an ethical construct and decide what am I working on, what is ethical, and what is the potential outcome of what work I'm doing? And we talk about that a lot at FirstRoot. For example, one of the items on our backlog is – and I rejected it, but one of the members of the team said, "Hey, Luke, you know, when we give schools the budget it's coming from the principal or the PTA and it's usually a few thousand dollars." You want enough budget that the kids can do something meaningful with the money, but you don't want so much budget that the parents are going to get involved and remove the ability of student control.

So if I went to a high school and I said, "Hey, the high school –" and I'm going to pick a moderately-sized high school. Let's say there's maybe 800 kids in the high school. And we said the high school has $10,000. You know, that's a little more than $10.00 a kid, and I don't think any parent would be freaked out about the kids controlling $10,000 to invest in their school and make it better and have this great learning-by-doing experience. But if I walked up to the school and said, "The kids have $10 million," well now for sure you know the parents would be stepping all over the kids and taking control.

Brian Dawson: Yeah. Right, right.

Luke Hohmann: So now we have an ethical choice, because one of the members of our team said, "Wait a minute, Luke. What if the kids have a really good idea that is $2,400? And we could construct a system where someone could just fund the idea without going through the student voting process, right? They could just fund it on their own." I'm like, okay. I said, "That actually is going to reinforce structural inequity, because now we've moved from we are working on this problem together as a school where everyone's vote is equal to my idea is better than yours, and because I'm more affluent I can buy and do whatever I want."

Now I'm not asserting that an affluent person is going to make a choice that's not a healthy choice or an uplifting choice or it's somehow rude or negative. My point is that the philosophical and structural underpinning do not align with our stated mission of creating a positive civic engagement, and therefore we're going to reject that feature. And I don't know what goes on in other companies. I naively sometimes hope that people are sitting around at the table and doing questions like this.

And even from the concept of DevOps, the DevSecOps. I'll give you an example, and this is something that's a definite Luke-ism that I talk about in my classes. And Brian, I don't think you and I have talked about this yet, but have I talked to you about the difference between a success failure and a failure-failure?

Brian Dawson: No, no. I'd love to hear it. No.

Luke Hohmann: Yes. Success failures are some of my favorite concepts, right? So let's say I'm building an online transaction processing system and I'm in engineering, and product management comes to me and says, "You know, we've done some market sizing, market analysis, and market adoption. We think that our initial system needs to be able to support 30 transactions a second." And I'm an engineer, so I'm thinking, you know, I love those marketing guys but I don't really trust them. So I'm going to make my transaction system have enough head room to support 50 transactions a second.

And I'm not really going to worry about it. I'll just add a little bit and everyone's happy, right? So we turn the system on and then boom, it's massively successful. Growth massively exceeds everyone's reasonable projections. VCs are happy, the president's happy, investors are happy, everyone's happy, except our customer because now my system's failing. It's not handling the load.

I maximized it for 50 transactions per second, I'm seeing 95 transactions per second, and the system is creaking. In my world, and my Dev teams have seen this, I've celebrated that as a success. It's a success failure. It's failed – and then you've got to pick up the pieces and move on. Now I like to distinguish between success failures and failure failures. I'll give you an example of a failure-failure, and I'm going to actually name a company by name, partly because they're famous and partly because it's such a well-known story.

A few years ago Facebook had a leak of user IDs and passwords where 4 million accounts were compromised, and the passwords were stored in plain text.

Brian Dawson: Yeah. [Laughs] Yes.

Luke Hohmann: Do you remember that?

Brian Dawson: Yes, I do, I do.

Luke Hohmann: You remember that, right? And we're like – you're awkwardly laughing because what you're really saying is how could a member of my profession sit down and actually write code that stored passwords in plain text? They didn't even bother salting them, they didn't do an MD5 hash. They literally ignored the most common, basic sense of how to do something. Now there's a couple of potential reasons this happened, right? One reason might be the developers were so junior and so inexperienced that they were being asked to do a task that was inappropriate.

Well, that's a management failure, and that's a failure-failure of a management team. The developers knew what to do, but they were under so much pressure to get features out the door that they just cut corners left and right. Again, that's a management failure. And it's not a success failure. It's just a failure. It's a failure-failure.

Or the developers knew exactly what to do and they spontaneously chose amongst themselves to implement it improperly, which is maybe in some cases the least likely, but it's still an option. But in all cases that's a failure-failure.

Brian Dawson: So agree with the concept, and it's an important differentiation. How do we leverage the concept of success failures versus failure failures to do better?

Luke Hohmann: To do better. Well the first is management and engineering, when they're doing their root cause analysis, sometimes it's good to know is it a success failure or a failure-failure? And the failure-failure is the harder one in your retrospective to really get to the root cause and deal with it. The success failure is to remove the blame from the environment so that people can realize that the reason you in air quotes – I'm doing air quotes and no one can see me – but the reason you failed was because you actually succeeded, and rather than being upset, celebrate and then go back and redesign the system to a new capacity that's appropriate for the new context. 

Brian Dawson: Right. Okay. And when we look at, for instance, social media or we look at under this umbrella of ethical technology or ethics in technology, it's we are going to run into success failures where we are so successful that we've exposed another problem or created another problem. Correct me if I'm wrong. It's not so much that we can prevent that. And in fact, when we talk about an Agile approach, an iterative and evolutionary approach, that's going to happen but we need to take our success failures, celebrate the success, identify where the failure was and then iterate against it. Is that fair?

Luke Hohmann: Yeah, absolutely. But even more importantly, I would say that we want to look at this in part of that culture – and I'm going to bring this back, because we are here to talk a little bit about DevOps, is to bring that into that DevOps world, right? In the DevOps world you start to see successes and successes and successes, and so the organization becomes so comfortable with the benefits of DevSecOps, which is so profound in so many ways. Later on I'm going to talk about why I think DevOps is a competitive advantage in people management. I think it's a profound advantage in people management.

I don't think that's talked about enough at all. I'll come back to that. But I think that this notion of success failures is important because no matter how good you are, we are going to have our mistakes, and that's when we want to really understand was this a failure-failure, and that's a harder retrospective and root cause analysis, or is this just a success failure that means we want to redesign our system and celebrate that redesign? But nonetheless we need to redesign.

Brian Dawson: Okay, okay. Now actually, let's start to lead towards DevOps and culture by getting back to you or a second. People can look you up on Twitter, look you up on LinkedIn, look you up under FirstRoot. There's probably a number of people that are familiar with some of the texts you've created. And just to get a bit into your background, you are a formally trained computer engineer, a graduate degree in computer science. You have been all of a leader, educator, and entrepreneur at multiple points in your career. Am I correct in describing you in that way, Luke?

Luke Hohmann: Yeah, yeah. I am a proud and unashamed geek [laughs] and an engineer. But I've also been blessed to work with many wonderful people. You know, Brian, I think that if you're intellectually honest with yourself you find so many opportunities to recognize others for the help that you've been given.

Brian Dawson: Oh, yeah.

Luke Hohmann: And I've had some remarkable people in my entire career. They have helped me and they continue to help me. They continue to provide guidance and support. Sometimes I need a two-by-four to the head. Sometimes I need a kick in the butt. Sometimes I need a hug.

You know, whatever it is you've got this community of people, and of course the Agile community and the DevOps community similarly, it's a warm set of community. It's a warm group of people who are united in many common values and common practices and common desires. But going back to my background, yes, I have a bachelor's in computer engineering, which is kind of half between electrical engineering and computer science, and then I have a master's degree in computer science and engineering both from the University of Michigan. 

Brian Dawson: Wow.

Luke Hohmann: And I've got 13 patents and four books.

Brian Dawson: Yeah, and there's one of those I want to talk about provided we have time, and in case we don't I'll call out we were talking and we connected around the Journey of a Software Professional, sort of a psychological, sociological view of software development. But we'll get back to that. Now in this journey, somewhere you shifted into an Agile leadership role. And in fact, you previously worked at SAFe, with the scaled Agile framework organization as a contributor and principle consultant. I'm going to conflate two questions together as I always do, but what I'm curious, how did that come about and what did you teach or learn through that process that could benefit our audience here? 

Well, and let me split them for the sake of you. I always do this to people. But how did you end up as what I'll arguably lazily call an Agilist? 

Luke Hohmann: Yeah. Let me start by saying –

Brian Dawson: Redirect? Okay. [Laughs]

Luke Hohmann: Yeah, let me start by saying that the story of my career is much more humble [laughs] than people might realize. You know how you get a lot of people who say I worked my way from the ground up? Which I think is admirable.

Brian Dawson: Yes.

Luke Hohmann: One of my very first jobs ever in the field of technology was working for Electronic Data Systems, and Brian, I was a floor grub, meaning my first job was crawling underneath raised floor in datacenters cabling computers. And I'm going to speak in ways that most of the listeners will have no idea what I'm saying. So right now everyone knows the internet and many people know the underlying structure of the internet is TCP/IP and all that kind of stuff. When I was working for EDS I was pulling bus and tag and cabling 3720s and 3090s. 

Brian Dawson: Oh, wow.

Luke Hohmann: I was cabling coaxial frontend controllers. I was doing X.25 and ISDN. So kind of my super geeky background was I was a networking guy and I loved network protocols and Token Ring and Metropolitan Area Networks and fiber and all sorts of crazy stuff, right? So I worked my way from beneath the ground up into tech support.

Brian Dawson: Literally.

Luke Hohmann: And then I just got a couple of lucky breaks from people who believed in me at EDS. I've had five amazing bosses in my career, and the first and some ways most profoundly amazing boss I ever had was a guy named Vern Olson at EDS who just gave me a break and believed in me and supported me. And he was amazing. Now at the time I hadn't had a degree, so I'm doing all this work at EDS and I didn't have a degree. I did –

Brian Dawson: Now is this high school or young adult or –

Luke Hohmann: Oh, no, no, no. So there's a background here that's even curious. You may not even know this yet. So when I was in high school I was actually a figure skater. I was a pairs figure skater.

Brian Dawson: Oh, right. Yes.

Luke Hohmann: And I wanted – I had a scholarship to go to college and I had been doing a little bit of computer programing and I really loved it, because they had a computer programming class in my high school.

Brian Dawson: Oh, okay.

Luke Hohmann: But I remember going to my mom and saying, "Mom, I know I got this opportunity to go to school but I can only skate when I'm young." So she and I cut a deal. [Laughs] I went to a two-year associate's degree while I was skating, and in that two years I actually got decent enough that I wanted to make skating my full-time thing. So I moved to Michigan from Buffalo with $300.00 in my pocket, everything I owned in the front seat of a used Ford Pinto, [laughs] and I was going to –

Brian Dawson: Some people are like, "What is a Pinto?" A Ford Pinto, classic. A used Ford Pinto. Funny. 

Luke Hohmann: Yeah, a used Ford – yeah. Think of it as the car that would explode when rear ended.

Brian Dawson: Right.

[Laughter]

Luke Hohmann: So I'm working part time for EDS and skating full time. And I didn't have a fancy degree, and the guy who gave me the job – Lewis Mattson was his name – he gave me a job on a flier, right? He gave me a break. So then I finished skating and I started working for EDS full time, and I got a lucky break. I actually worked with – he became my best friend – Dan O'Leary – and we built at EDS in 1985 the first production expert system when AI was having its first heyday, in EDS to help automate the processing of transactions in a big EDS mainframe system.

Brian Dawson: Oh, wow.

Luke Hohmann: Huge success. Now Dan is one of these – his prowess in architecture skills are pretty much legendary. Dan is one of those guys who's worth six people. He's that good, right? 

Brian Dawson: Okay, right. Prolific, yeah.

Luke Hohmann: But just right, like smart and scalable and – like everything you want in an architect, right? But Dan's got a degree and he's working in the EDS R&D lab, and here I am, I don't have a degree. I just got a break. I'm like, I want to go back to school. And I'm telling a very thorough story, and my point in sharing this story is it's really not about me as much as it sounds like it's about me. For the leaders who are listening to this story and for the people who are emerging in their leadership skills, my story is about other people giving me opportunities, and I really, really believe that it's our responsibility as leaders to pay those opportunities forward.

I try to create those opportunities for other people by hiring interns, giving them good work, giving them experiences. And so when I talk about my story I don't want it to sound like, oh, isn't Luke great, 'cause it's not about Luke being great. It's about how kind and how wonderful and how great other people were.

Brian Dawson: Well I'll tell you what I think – and not to throw you off, I'll give it back. But no, it's important and it's perfectly in line with what I love to bring forth in the conversations here and really putting it generically. Computer science is a discipline for everybody that impacts everybody. And we take very different paths. And Luke, you are seasoned, you are well credentialed, you are well educated, and there's an aspect that's maybe not the management aspect, but calling out what your journey was, which some may call a nonstandard journey. 

It also very much reflects with me. You're triggering in my own memory the multiple times in my career that people took a flier on me, and I had a very nonstandard path. So aside from the value of support that managers could provide and how important that is, I think there's a lot more that I'm getting out of your story as well. 

Luke Hohmann: So let's continue.

Brian Dawson: So no explanation necessary. Yeah, go ahead.

Luke Hohmann: Let's continue because it gets interesting. So I go to my leaders and I say, "Look, I really want to get my degree and I'm going to quit EDS." And my boss Vern is like, "What? You can't quit. You just built this great expert system." And I'm like, "Well, I really want to get a degree." He goes, "Well, what are you going to get a degree in?" I'm like, "Well, I'm going to go get a degree in physical therapy because it's the only degree I can afford and I know how to do that because of skating," because I had so much body work.

Brian Dawson: Now real quick, I'm going to interrupt. Were you an Olympic candidate? There's Olympics somewhere in your figure skating.

Luke Hohmann: Yeah, yeah. So I was the United States National Junior Pairs champion, and then I moved up into the senior ranking and I got as high as eighth in the US Seniors. So I was the eighth best pair skater in America. I actually don't think I was good enough to eventually get into the top three to make it to the Olympics, but I would say I was world class. So what you see in –

Brian Dawson: Phenomenal.

Luke Hohmann: Yeah, yeah. Well, if you're gonna do something, Brian, do it as best you can, man. [Laughs]

Brian Dawson: Yeah, yeah, yeah. See, there's no way we can't explore the nooks and crannies of your story. Okay. I wanted to hit that. Back over – so you're going to go get a PT degree.

Luke Hohmann: Yeah. And my boss Vern is like, "Okay, you're an engineer." I'm like, "Yeah, I guess I am and I love it but I can't afford it. I don't know what to do and I really want to get a degree." So I kid you not, he comes back and he goes, "Give me two weeks." Vern goes to the board of management at EDS, and Jeff Heller was at the time the president, and he gets the board to cut a deal with me that says the following: we'll pay for your degree under the following three conditions.

We get to pick the school, we get to pick the degree, and for every year we pay you give us a year of employment. And I'm like, are you kidding? Sure. Where am I going to school and what degree am I going to get?

[Laughter]

And he goes, "You're gonna go to Michigan and you're gonna get a computer engineering degree." And I'm like, okay. [Laughs]

Brian Dawson: Wow.

Luke Hohmann: So they helped me set that up and get into the school. Meet Elliot Soloway. That's the next super big person in this journey. Elliot's a professor of computer science and artificial intelligence. He had just come in from Yale. He's studying how programmers program – cognitive psychology. So I start working for Elliot instead of taking goofy stuff. 

I'm in the research lab because it's a research university. That gives me my cognitive psychology background. Then I'm still pretty poor, right? I'm not still making bank here by any imagination, so I need some extra money. So I start working programming the research software used in the School of Organizational Behavior. 

So I started working with these organizational behaviorists in the business school. So instead of getting a business school degree I'm just writing the code. So one of my claims to fame, Brian, that's not well known is one of the world's first 360 assessment systems was called the Competing Values Skills Assessment System, and it was created by Bob Quinn and Dan Denison, and I wrote all of the software for that system to work.

Brian Dawson: Oh, wow, wow.

Luke Hohmann: So I wrote the world's first 360 assessment tool, or at least one of them. And it was pretty amazing. That managerial line of thinking is still going strong today. And now we're progressing, we're progressing. I finish my degree, working for EDS, and I get bit by personal computers at Michigan. So I go back to EDS and I basically put together a pitch that said I really want to do personal tech; can we create something here?

And it wasn't a fit for EDS at the time, so I left EDS and I joined a small company in Dallas called Object Space, which did at the time object-oriented training and mentoring. C++ was hot, Smalltalk was hot. The early Agile methods. So now you're wondering how did I get to Agile. Well the precursors to Agile were in the OO and patterns community, and in some of the earlier methods, known as the Gang of Three – Booch, Jacobson, and Rumbaugh and OMT, Booch – and those methods merged into UML.

And now we're starting to see two things that are kind of leading us into the Agile movement. We're seeing better practices in system design with OO, we're seeing patterns which are reifying and creating reasonable knowledge chunks, and we're seeing unification of methods that are designed to improve communication. So most people think that stuff like UML or whatever is this heavy method, but what they forget is if you and I are going to communicate as engineers then we need notations and mechanisms that allow us to be precise in our language, just like music has notations. I don't know how to read it.

One of my sons is a good musician. My wife is a good musician. And so to communicate music precisely they have their own language, right? 

Brian Dawson: Yeah. Right.

Luke Hohmann: Well, we need that too as engineers, right? 

Brian Dawson: I'm going to jump in on your story a bit just to – so first, it's interesting to explore this lineage, that connection, because I was not aware of that association or didn't actually see it. But just to be a bit of devil's advocate, if we look at kind of UML, which is very precise – and yes, you'll find me and many others borrowing from UML, but not, for instance, in that is a pattern, applying the pattern dogmatically – but if we flash forward and you have a relationship to the original Agile Manifesto or some of the authors of that, that seems to shy away from or deprioritize precise, well-defined communication to substitute it with less-structured human interaction. That's strong there, but to challenge you a bit and give you a window to correct me. Please do.

Luke Hohmann: Well, I don't think you're wrong, so I don't think you need correcting. I think that you want to be clear though about what we're arguing or what we've debating. The most structured communication that we have as engineers in software is the actual code we write. [Laughs] There's no ambiguity. The compilers –

Brian Dawson: That's the contract, right.

Luke Hohmann: Right. The compiler is going to compile what we give it, and we have languages designed to help us express ourselves. We have Scala, we have Erlang, we have C, we have C++. There's more than 10,000 languages out there. And so those languages have different purposes and different mechanisms and they're incredibly precise. But humans aren't computers and so we do need communication, but the nature of our communication is different.

Sometimes we need highly imprecise and unstructured mechanisms of communication as part of sense-making and building knowledge and shared insight and understanding, and sometimes we need more precise mechanisms. Because if you and I are communicating about a data model many times cardinality really is important in the data model and the proper – I don't want to say correct, but the proper use of a notation that includes cardinality improves our ability to communicate about our intention and to be clear and allows us to reduce the likelihood that we're going to create mistakes in understanding or mistakes in group behavior. Now all of this leads into the Agile movement.

I am not an original signature of the Agile Manifesto. It's a different group of people. Many of them are – I think all of them are my friends – but I was a member of the group that created the first Agile conference in 2003. I have served on the board of the Agile Alliance, previously in collaboration with the Scrum Alliance. I ran the world's largest webinar on collaboration called the Collaboration at Scale webinar for about 2½ years, and that was a labor of love. I also wrote the book Innovation Games: Creating Breakthrough Products Through Collaborative Play.

Brian Dawson: Well let's go back. I'm going to jump in.

Luke Hohmann: Oh, let's go back.

Brian Dawson: Before we go to Innovation Games, let's quickly hit on Agile. I have a list of about 30 questions I need to get in in the next 15 minutes.

Luke Hohmann: Okay, I'll try and answer them.

Brian Dawson: Ready for this speed round?

Luke Hohmann: Yeah, we'll do a speed round and I'll stop pontificating and get off the soapbox, but yeah.

Brian Dawson: No, your pontificating is valuable, don't worry.

Luke Hohmann: [Laughs]

Brian Dawson: But let's talk about Agile. As again, having a relationship with some of the authors of the original Agile Manifesto, personal and likely professional relationship as well as being on the board of that first Agile conference, when we flash forward from 2003 to eight years later, 2021, you see – and I want to say it was in 2008 or 2009 that one of the original authors – I don't recall the name – wrote a blog Agile is Dead. Being there early stage, also working with SAFe, are a particularly interesting person to answer this question. Is Agile still viable? What role does it have in modern software development today?

Luke Hohmann: Yeah. And to be super clear, I didn't join SAFe until SAFe was very mature. I joined SAFe many years after it was started.

Brian Dawson: But you're probably aware of some Agile purists, SAFe has its detractors, right?

Luke Hohmann: Yeah. Well, okay that's bull crap.

Brian Dawson: I think that plays in here.

Luke Hohmann: I'll just point out that most of that's bull crap, right? Let's not also be unaware that there are baser level motivations at work in any industry, right?

Brian Dawson: Yeah.

Luke Hohmann: So you've got to ask yourself, interest goes where money flows, and when people get really riled up about a method or a tool, as we know they do, I ask a simple question. What's the economic benefit for them to be taking that stance?

Brian Dawson: Yeah. Right. Okay.

Luke Hohmann: Many times we see consultants – and by the way, the economic benefit doesn't have to be just money. It could be what's the psychological benefit, what's the ego, what's the id.

Brian Dawson: Right.

Luke Hohmann: So think about it. Methodologists tend to fight about methods because that's what they love to do. They want to be a methodologist. When I go to the clients that I've worked with in the past, the BMWs, the United Technologies Aerospace Systems, the Verifones, the eBays, you know, Verifone doesn't want to be arguing about software methodology. They want to build great payment terminals.

Brian Dawson: Yes. Right. Well said.

Luke Hohmann: United Technologies Aerospace Systems, if you don't know what they do it's kind of curious. They're this massive company that has very few customers. They build the landing gear assemblies for planes.

Brian Dawson: Oh, wow.

Luke Hohmann: So if you're landing a 747, the wheels when they go down and they go down, they build that, right? Do you really think that those people want to argue about their software method or you think they want to build really good, safe equipment so that a plane lands and takes off safely?

Brian Dawson: Right, right.

Luke Hohmann: And I kind of cringe when our community has this kind of debate about the merits of any given particular method. This isn't Agile or this is Agile or this is that or this isn't that. Because many times they're missing the point so completely that it's almost comical, right? And even the people who are CloudBees customers, right? We all care about DevOps and we want to have efficient pipelines and we want to know our DORA metrics and we want to manage that stuff. 

Brian Dawson: Well that's all an ends to a means. Right.

Luke Hohmann: That's right. It's all an ends to a means, and we want to build better products and services –

Brian Dawson: Or means to an end.

Luke Hohmann: Yeah. That's all a means to an end, right? And so there are purists in the Agile community, and I love them. They keep us honest in consumer behavior. My wife laughs. When I go to the store and I get food, I don't know what I paid for it. 

She's like, "Hey, you know, honey, how much did you pay for that?" I don't know. Here's the receipt. I just bought it, right? [Laughs]

Brian Dawson: Right. I had a need. [Laughs] I had _____.

Luke Hohmann: Right. And then every now and then she'll say, "Do you even know what a pound of apples should cost?" I'm like, no. But of course she does. And there's the function that people like my wife serve in a society, which is really important, which is you need a certain percentage, between 5 and 15 percent of the society who does care about that to keep the rest of everyone on their toes. 

So while at times I get a little like why are the methodologists fighting – really? Come on, people – the value that they bring is they kind of keep the practitioners on our toes. And I consider myself more of a practitioner than a theorist.

Brian Dawson: Right. I love that you hit that. And again, we could easily get deeply philosophical, but what you just called out applies in a lot of spaces. It can be frustrating, it can be dogma versus an appropriate level of pragmatism, but you need a certain amount of tension. So the theorists keep the practitioners honest. The practitioners actually bring the theory to bear and action it, and there's a yin and yang there, again to hit a bit of philosophy.

But let me ask – so today, and you can really look at a lot of DevOps principles, right? I kind of do a very gross lineage of DevOps, this visual diagram, and as many would agree I highlighted it really starting with Agile principles. And a lot of the way we seek to iterate a focus on feedback loops is couched in Agile principles. That said – and I'll ask it in a pretty wide berth – what is the role of Agile today in software delivery and in particular Agile today in enterprise software delivery?

Luke Hohmann: Well, let's remember what Agile is. I give a talk called The Distinction Between Agile Being and Doing, and it's an important talk and it gets again into philosophy. When I ask people to ascribe words of – I ask people in my talk, I say, "Take the word manager and tell me the kinds of attributes or activities or behaviors you would ascribe to a manager," and they do that. And then I say, "Take the word leader and give me the attributes and activities and behaviors you would ascribe to leader."

And what you'll find is in management it's about the domain of doing – I make budgets, I make plans, I check things. And leadership tends to be about the domain of being, and so I'm visionary, I'm supportive, I am inspirational. And then to really show what the problem with the word manager and leader right now is that it perpetuates that mental model. So to break this up – and I'm going to do this real time, everyone – so let's put Brian on the spot. Brian.

Brian Dawson: Uh-oh. Yes.

Luke Hohmann: Can you change the tire of a bike if one of your kids gets a flat?

Brian Dawson: I can.

Luke Hohmann: You can. And Brian, if one of your kids comes home from a sporting event or a date where they lost the game in the sporting event or they just had a crush and it didn't work out and they're really sad, they might even be crying, can you give them a hug?

Brian Dawson: I can.

Luke Hohmann: So wait a minute, are you saying that you were both in the domain of being and doing?

Brian Dawson: Yes. In this particular case, yes I am in both domains.

Luke Hohmann: Because we have the right label for you. It's called father, and father is a label that we do not distinguish between the being and the doing, and we don't distinguish that label with mother. Mother can change a flat bike tire just as well as father. Mother can give a hug on a broken heart to show affection just as well as father. 

So now we have two distinguishing labels for entities that have unique relationships to other humans, right? Father and mother is a unique relationship. So I've actually been over the years trying to gently promote the idea that an Agilist is distinguished from the other terms because they're in the domain of both being and doing. And when you think about an Agilist from the domain of doing, I'm an Agilist. Okay, what's your role?

Well I'm an Agilist on a development team. I'm writing code – that's doing – I'm making an estimate – that's doing – I'm being a good collaborator in a meeting by being supportive and listening to the point of view of my fellow team members – well now I'm in the being domain. So the question of is Agile dead, I don't think Agile can die because properly stated Agile is the domain of being through a set of values. The methods that we use, like the SAFe or the Scrum or other methods, those are in the domain of doing.

Brian Dawson: I love it. I got it, right.

Luke Hohmann: I kind of can't accept structurally that Agile could be dead because Agile is a domain of being. If that being is no longer needed, okay, fine, then we shouldn't have that domain. But I think the being of Agile is pretty durable. 

Brian Dawson: Yeah, and the principles of Agile are pretty durable. Right. I think the doing is where we end up debating are daily standups valuable, should we practice Scrum, should Scrum be two weeks, et cetera, et cetera, the endless sort of levels of terminology, practices and ceremonies that are doing part of implementing the principles. Those can change. And again, I invite you to adjust me or correct me, but that's in the doing space and that may change.

But the principles, we really go back to the original Agile Manifesto outlined there that you are contending that those won't die. Those shouldn't die. They can't die.

Luke Hohmann: I think some of them do evolve a bit. So if you think about the hierarchy of change and kind of what are the more durable and what are the less durable, the values are the most durable of all. When we say we value individuals and interactions over processes and tools –

Brian Dawson: The one I always think of, right.

Luke Hohmann: Right. And I think of customer collaboration over contract negotiating or just collaboration. Those values are very, very durable, right?

Brian Dawson: Yes.

Luke Hohmann: When you look at the 12 principles of software development, those I think have changed a little bit over time. They're still very valuable, but for example one of them is at regular intervals the team reflects on how to become more effective and then tunes and adjusts its behavior accordingly. I buy into that principle, but I actually don't use its kind of common application. That promotes retrospectives. But most Agile methods require a retrospective at the end of every sprint.

We don't do that at FirstRoot. We don't think that that's the powerful mechanism to really create durable retrospectives. And I've given a separate talk on this. What you see in retrospectives in most organizations is the same complaint issued every couple of weeks, and then what happens is the team becomes immune to the problem because they're tired of complaining about it. So what most organizations need to do is fewer retrospectives that are broad-based. 

So I call them enterprise retrospectives, where every team does a retrospective and then you analyze the results across the entire organization, and then you have fewer change items that have more profound impact. And that's one of those times where I think the Agile Manifesto is more correct in the being and the Agile methods are often less correct in the Agile doing.

Brian Dawson: Right. Makes perfect sense. Well, so I'm going to have to be like United Technology Assembly Systems and put the landing gear out.

Luke Hohmann: [Laughs]

Brian Dawson: So in that – and there's so much I want to talk to you about, but unfortunately I know your time's limited and my time's limited – so I want to move forward just to two final questions. First, I'd like to ask is there a book, a podcast, or a resource that you would absolutely recommend to our audience? And that can be technical, nontechnical, but what is something that has been very meaningful to you and formative to you that you think would serve the same purpose for our DevOps Radio listeners?

Luke Hohmann: Oh my gosh. That is such a hard question for me because I have a phrase that my team hears all the time, right? Leaders are readers. And so I read constantly. I read five magazines a month minimum, I read three book as month minimum. I am – 

Brian Dawson: That is a voracious –

Luke Hohmann: I read all the time, right? I'm voracious. But I'm going to give one of my go-to books for everyone. It's called Understanding Comics by Scott McCloud. And he was one of the authors when the X-Men were cool when I was growing up, and I have found that that book is profoundly useful in helping people think about communication, about system design, about philosophy. It is not what you would expect.

It is a fantastic book. And I'm also recommending it because it's so easy for me and other hosts to recommend something associated with technology in our field that was profound, and there's plenty of profound books, right? But I want to give something that is really fun and really – I just find it super valuable. So I would recommend the book Understanding Comics by Scott McCloud. 

Brian Dawson: Okay, that's awesome. I'm going to buy that now. And I love – I mean, we get a bunch of awesome technical references. Actually one of my favorite parts of DevOps Radio interviews and the conversations with guests are what they read and share. This is extremely unique. I love it.

I'm going to buy it now and we'll give it a read. Before we let you go, before I begrudgingly let you go, Luke, any final thoughts for the listeners?

Luke Hohmann: Yeah. I believe in something called the strategy of small wins. I studied under Karl Weick, which is an organizational behaviorist at Michigan, and he talks about the fact that when you're looking at massive social problems and you want to create profound social change, it's easy to become overwhelmed with the scope of your vision. Our visit is to get $1,000 into 1 million schools and watch what happens when kids around the world have more than $1 billion in capital.

Now as you know from system design, that is a massive architecture, that's a massive DevOps opportunity. It's a big dream. And it's so big that some people could become discouraged, disheartened about how big it is. But I want to point out that the strategy of small wins says that if you can find a way to decompose the problem and do a sequence of small wins then you can have the wins accumulate. And so I don't need to have every school in the world today.

I just need the school that the listener of DevOps Radio is willing to help us work with. So every listener of his show has been to a school, went through a university or went through an elementary, middle, and a high school. They might have children in school. So my request of them is to help us create a profoundly useful impact in the world, not by worrying about something else but just by working on one thing with us. The school your child goes to or the school you went to. If we just do that we can create the change that we need in the world at scale.

Brian Dawson: Awesome. Will do. And I have that on my list. Luke Hohmann, it's been fantastic talking to you. I tell you, you are an extremely vibrant and multifaceted person who I could talk to for hours. Thank you for taking time today to share your thoughts and your experience with us, and I look forward to the next time I get a chance to talk to you.

Luke Hohmann: Thank you Brian so much, and thank you everyone for listening.

Brian Dawson: Thank you all for listening to this episode of DevOps Radio. Do make sure to hit the subscribe button so you don't miss our upcoming episodes with other phenomenal guests. Thank you, Luke. Thank you, listeners.