You ever get the feeling that the way most companies are set up doesn’t really make sense?

That the passion you have for coding and tech gets sucked out when you do it for a business, instead of it being amplified?

Matt K. Parker had that realization… hard.

A third-generation programmer, Matt’s epiphany that there was something wrong with the way the majority of the world sets up its teams and workplaces led him on a journey to explore the way the world’s best companies operate.

After diving into case studies, academic research and leveraging his own professional experience, Matt concluded that the most productive companies all had one thing in common: They were radical.

Radical in how they structure their employees. Radical in how they treat their employees. Radical in how they empower their employees.

Fortunately for us, Matt stopped by Dev Interrupted to share some conclusions from his new book “A Radical Enterprise: Pioneering the Future of High-Performing Organizations.”

One of our favorite recordings to date, this is your ticket if you’re looking for some inspiration on how to increase productivity while decreasing BS.

Episode Highlights Include:

  • (1:23) Programming with punch cards
  • (8:26) Reducing people to human machines
  • (13:07) Knowledge work has an endless number of problems to solve
  • (17:34) 9 out of 10 employees would be willing to donate 24% of their lifetime earnings to have more meaning in their work
  • (24:01) Matt’s Four Imperatives
  • (36:13) Feature factories vs outcome factories
  • (41:57) What is good for people is good for business

Transcription:

Dan Lines: Host

Matt K. Parker: Author of A Radical Enterprise: Pioneering the Future of High-Performing Organizations

---

[Music playing]

Matt: [00:00-00:16] So much of the pain that we feel in the world of software development with processes like Waterfall are really an attempt to take a paradigm of mass production and apply it to a world of knowledge work that it was never meant for and can't possibly satisfy.

Sponsor: [00:17-00:36] This episode is sponsored by LinearB. Accelerate your development pipeline with data-driven engineering metrics, continuous improvement automation, and project visibility and more cutting your software development cycle time in half. Sign up for your free demo at linearb.io and mention the Dev Interrupted podcast discount for a one month free when you sign up for an annual pro membership.

Dan: [00:37-01:08] Hey, what's up everyone? Welcome to dev interrupted, I'm your host, Dan Lines. And today I'm joined by Matt Parker, author of the book a radical enterprise, pioneering the future of high performing organizations. It takes a scientific look at how the fastest growing and most competitive organizations in the world have no bureaucracies, no bosses and no bullshit, which is why I wanted to have them on the pod the moment that this book crossed my desk. So Matt, thank you so much for joining us.

Matt: [01:09-01:12] Yeah, thanks for having me. Dan, I really appreciate being here.

Dan: [01:13-01:40] I'm super excited to talk to you about the book. But of course, you know, let's start out by giving our audience an opportunity to get to know you a little bit better. I know you are a third-generation programmer. So that's quite the lineage there. I don't know if I know anyone whose grandmother or grin father was a programmer. So man, it's just like in your, in your blood. Tell me about that.

Matt: [01:40-03:08] Yeah, yeah. So my dad's a programmer, or was anyways, and his dad was also a programmer. Yeah, you know, my grandfather, after coming back from the fighting in the Korean War in the 50s, wound his way into an insurance company, which was one of the largest in Texas, and also one of the first sort of companies buying those newfangled machines called computers and putting out open calls into the workforce, like, who wants to learn how to do something with this, right. And my grandfather was very interested in the idea and raised his hand and really dove into it, and, you know, became among those first groups of programmers out there in the world. And then my father sort of followed in his footsteps. And then I've sort of followed in both their footsteps and you know, so I grew up doing, you know, in sort of immersed in this world of computers, I didn't actually start programming until I was in high school, but I was always sort of around it knew about it, my grandfather would show me his old, the punch card programs that he had kept just for the soldier, and tell any funny stories about you know, taking 500 punch cards to the operator, but dropping them on the way there and, like scattering them, you know, like horrible horror stories like that. So, yeah, it just sort of grew up in that world. And I sort of idolized it, too. And I know, we'll get into it. But certainly, the idea I had of that world didn't match the reality of that world after I started actually doing work in industry.

Dan: [03:09-03:14] It actually-I was gonna ask you what programming language did your grandfather code in?

Matt: [03:15-03:43] [Laughing] Yeah, yeah, yeah, no, I, you know, I-I know at some point, it was Fortran. And then eventually, you know, later in the late 70s, and 80s. And into the 90s. He did nothing but COBOL for like, three decades. But yeah, in the very early days, you know, even those first computers, what language even was it? I don't know. And I didn't ask him before he died. And I don't know if we would even recognize it, right? Like, what programming language that was. But yeah, at some point, it became Fortran and then COBOL.

Dan: [03:44-04:13] My mother is visiting this week, and we went out to dinner. She was also a programmer. And she was programming in COBOL. So, I guess that was totally a popular language. And I've heard right now COBOL developers are actually in high demand, you can get some high paying jobs because there's all these older systems that nobody knows that need updating. So, it's like, “Yeah, Mom, you got to get back into the industry, now's the time.”

Matt: [04:14-04:30] And that was even true two or three decades ago, like the last decade, my grandfather spent programming. He programmed for about four months out of the year as a consultant, got paid top dollar to do it, right diving into these nasty old COBOL systems, and then spent the rest of the months living on a lake and fishing.

Dan: [04:31-04:49] That's awesome. That's-that is the life. Now, you've said that the inspiration for your book was when you realized the old way of coding was doomed to fail. Let's talk a bit about how you came to, you know, this type of realization.

Matt: [04:50-07:07] Yeah, so as I said, I certainly had this ideal image of what it would be like to work in information technology, you know, growing up and even from my very first internship, right, reality didn't match that idea. I remember at my first internship, which was for a major hospital system in Dallas, and when I showed up on my first day, the manager met me in the lobby, he took me to the elevator, I thought we'd be going up to, you know, program. And instead, he took me down, he took me down deep underneath the hospital into the basement area. And we sort of wound our way through this maze of, you know, cinderblock corridors and eventually came to an unmarked door, which he opened and inside of there was this really dim cubicle farm, right? Very quiet, very disturbing and dystopian, almost. And, and that's where I spent, you know, that entire summer, right? Slaving away with a bunch of other people trying to figure out what's going on and wondering why everyone's so stressed and afraid to even talk about it. You know, I didn't-I think-it took me a long time to understand what-what's so wrong with that way of working. But the visceral experience of it is sort of immediate, right? Like to walk into an environment like that you can sense the vibe. And so very quickly, I became convinced of three things; that this way of working is bad for business. This way of working is bad for people, right? The actual people doing it, and that was obvious to me as I experienced it. And I also thought, this way of working is a choice, right? Like nothing about this seemed necessary, right? I knew in my heart that we could actually have a great time making software, that it doesn't have to be a miserable experience. And I just couldn't figure out why. It seems like no matter where I went, in my whole first decade of, of programming in industry, I seem to be going to places in which they-it’s as if somebody had sat down and thought, “What is the most miserable way we could make the experience of making software?” Right? How can we make it so stressful and impossible and demoralizing, right, and non-collaborative? How can we reduce the creativity from it and turn programmers into mindless order takers, right? Like, it's, it's-nobody actually sat down and said those things and yet, that's what I saw everywhere I went, and I couldn't stand it.

Dan: [07:08-08:38] Oh, my God. Yeah, that's actually so odd and true and kind of funny, because when you're a developer, at least, when I started coding, I was doing projects on my own. And it was super fun. And it was like, a great experience, it was a creative experience. I felt “I’m getting these, like, dopamine rushes of I'm accomplishing something and solving some problems.” And these were projects that I was doing on my own! So, I felt almost like a builder or creator, like an inventor. And it's very odd then to come and be excited. “Okay, I got a job in this industry. Now, people are going to actually pay me money to do this thing that I really liked doing this is going to be awesome.” And then sitting down and be like, “Wait, what just-What just happened here?” You probably know, I'm not sure why that happens. Because you would think if you were “Okay, now I'm gonna get money to do this. And we're paying people to do this. It's gonna be even more creative. We have funding to be more creative. We have-” But it-but it's not the case often times, and I know that you've dabbled with like extreme programming and like some of the broken things like Waterfall but yeah, I mean, high level Matt, why do you think it is? I don't know if it's money getting involved, or like, where is the disconnect from me doing something amazing on my own to, I guess corporate environment?

Matt: [08:39-11:50] Yeah. Okay. Well, this is a complex answer, right? It's not any one certain thing. But I do point out certain things in my book, for instance, right in the beginning, all right. The way of working especially the Waterfall way of working within the world of software development, really is a holdover from ideas that began long before computers really even existed, right? The Industrial Revolution gave birth to a whole way of thinking about organizing people to accomplish something called scientific management, or called Taylorism, named after Frederick Taylor, or there are other names you'll see for it. And then they're often synonymous with other forms of corporate organization like command-and-control structures, etc. But it's really an attempt to say, okay, in the world of industrial manufacturing, and mass production, people were saying, “Okay, we're going to try and build a million of a certain thing. And that thing has to come out the exact same every single time. And we know it takes these fixed quantities and we can think about that whole process and then just repeat it indefinitely. How can we do that as cheap as possible, as fast as possible, while still maintaining enough quality that people buy it?” Right? And, like they had those kind of things that they were thinking about, and that led them to create a dehumanizing form of production in which people were sort of reduced to like sort of human machines like okay, we're gonna put people at certain spots within this production line, we're going to have them do the same task eight-thousand times a day, we're going to measure them on how long it takes, right? But the-and there will be smart people at the top optimizing this whole sort of vast biological machine. That sort of way of thinking about building stuff carried directly over into the world of software development, because no one else had thought of anything else, right? Like, there wasn't really much of an attempt to say, “Well, how do we need to think about this differently with software?” And there wasn't much of an understanding of what software even really was, right? But what we know now-what we know to be true now about the world of software development is that it is fundamentally different from anything that we encounter in the world of mass production. Software development exists in the world of knowledge work, right? And knowledge work deals with things-that you're dealing inherently with the unknowns, right? Sometimes you're trying to build for a population of users that are dynamic, right? They don't-they're not static, right? And you're trying to meet needs of people who you're honestly most of the time guessing at and waiting for feedback to figure out, okay, we got it, right, we got it wrong. Those users don't live in a vacuum. They're living in a world that is rapidly changing this whole in, in everything you're building, right, the whole technological infrastructure that you're building within is also rapidly changing, right? And so, what is most important in the world of knowledge work in software development, is creativity, is intuition, is experimentation, is rapid learning, right? And not vast planning, right? And biological machine optimization, right? These are two fundamentally different things. And so, so much of the pain that we feel, in the world of software development with processes like waterfall, are really an attempt to take a paradigm of mass production and apply it to a world of knowledge work that it was never meant for and can't possibly satisfy.

Dan: [11:51-13:13] Yeah, I mean, I think it's part of just human evolution, we do kind of take things that we know or maybe things that work and try to apply them to the future. Sometimes they work well. And sometimes it's not the right thing to apply. I actually worked on an assembly line, by the way, in high school, building computer. I was on an assembly line, screwing in motherboards and CPU chips, and what I-it's not that fun. It's not that fun of a work. But the-while you were talking there, the interesting thing about I guess, software, is there are some components of it that can be, I guess, reused or are not the area for creativity. Like, there's areas that you don't necessarily want to think about, there are repeatable things. But then it's the same time it's almost like a, a Michelangelo, or like a great creator, an artist, where you really are inventing something, you're doing something new, it can't be just mechanically copied over and over again. And I've been kind of thinking about it more recently, it's like, how do we blend these two things together? That's a concept to run by you, man. What do you think about like, some things can be repeatable, but other things like cannot be at all?

Matt: [13:14-14:22] Yeah, I mean, I think that rings true with my own experience in software development, sometimes you're doing something that you've done before, right? Like, oh, you pick up a user story off the top of the backlog. Oh, I'm going to create a login form. I've actually done that a lot. Like, and at some point, I don't want to do that again, right? Or I want-I want a way to be able to do that without doing all the work again and putting together all the plumbing again. And that leads us to create things like abstractions and frameworks and libraries, right? Because part of what we are-the way we spend-our best use of our time and our brainpower is to focus on novel problems. And there are an endless number of them within the world of knowledge work, right? Knowledge work is ultimately the process of sense making. So, getting the sort of repeatable things out of the way, or being able to do those with as much ease as possible so that we can focus on the new and the novel is, I think part of what you see in organizations that become really successful at software, they don't spend all of their time doing the things that they could have automated away. They automate those things away and focus on all the stuff that can't be automated, or they don't know how to or that they don't have any patterns for yet.

Dan: [14:23-15:03] No when I started my professional development career, this was already the era of Agile so like no one was talking Waterfall. We learned about Waterfall a little bit in school. But when I came into the industry, it was like yeah, we work at Agile, whatever that means. Do you think some of these methodologies of working so you know, like extreme programming, there's Scrum or Kanban? There are these different flavors, I know-I'm sure you know better than me. Have they advanced us in-on the creative aspects or is this something different? Has this taken us to a better place or not?

Matt: [15:04-16:19] I don't know. And so let me let me say why I can say I'm not entirely sure. I'm not convinced it has. But I don't think that's for fault of trying, right? Like, many people have tried to come up with new, better ways of thinking together, working together and collaborating together. And yet, I think many people have had the experience in industry in which the ideal that they heard about this Agile way of working or whatever it is, right, that was being put in front of them didn't match up with the reality, right? They're like, “Yeah, but, actually nothing’s really changed. We're still getting, you know, twenty orders a day from the boss to go do something, and to have it done yesterday, right? And you're saying we can be autonomous and self-organizing, and yet, we also have to accomplish these hundred things at the same time that no one has-none of us had any say about or don't even understand why we would do them.” Right? Like, it's that sort of conflict and clash of paradigms that I think many people run into that leaves them with a bad taste in their mouth when anybody says something like Agile or Scrum or Kanban, or extreme programming, or anything along those lines. So yeah, I think the jury's out on that. And I think the-the reasons for that, though, are nuanced. And that's a very sort of interesting area to contemplate.

Dan: [16:20-17:29] Yeah, I've seen again, even when I came into the field, like professionally, people, were already kind of cynical about some of these Agile practices, probably the I'm guessing. And I'm kind of like reading through their cynicism. Like, yeah, kind of, like upper management says, everything's good now, because we're Agile, like all-all the problems are solved. And I think, you know, most developers are saying, “Okay, like, maybe this way of working is a little bit better. Like, okay, this is better, but it's not solving, like some of these root problems that we're experiencing as developers.” And you kind of I already know made, as you said, like a realization that when you came into the professional field, it's not, you know, what you were looking for the way that you thought it was going to be. And you began to study companies thinking about things in a kind of a different way. And you found some pretty incredible statistics that I have a note here about. Can you talk about some of these things that you've discovered are the stats that you found out when you started studying?

Matt: [17:30-20:14] Yeah, well, if I could back up from that slightly before I tell you some stats, or actually, let me do it this way. There's two stats that I'll start with. And these are stats about something that's been growing and building and that we can point to as reasons for their great resignation that we're all experiencing today. Over the past several decades, the level of disengagement, the number-the percentage of workers that are disengaged at work has grown dramatically. Right? To the point that in 2018, I believe it was, Gartner had measured disengagement at work globally at 84%. Right? So, 84% of workers were disengaged, right? That means uninterested, uninspired, dispassionate. And in fact, some significant, a non-trivial minority of those disengaged workers are what they call actively [dis]engaged, right? So, people who are not only just depressed and apathetic and not happy that they're, they're at work but are actively undermining the workplace and creating toxic situations for others, because they are so disengaged. Right? So, this is like a crisis that has been growing and growing for decades. Another crisis that's been growing for decades is really a crisis of meaning. Right? In-and highly correlated with this growth and disengagement is a growth and people finding their jobs meaningless, right? And it turns out meaning is important. In fact, a great study from 2018, called Meaning and Purpose at work found that nine out of ten employees would be willing to donate 24% of their future lifetime earnings to just have more meaning at work to have more meaning in their jobs. Right? They would give up 24% of their entire future lifetime earnings, which by the way, is more than most workers spend on a house in their lifetime. Right? And so, they are saying it's even more important for me to have meaning that it is for me to buy a house. Right? That is-that is an amazing and astounding statistic that should have given everyone significant pause, especially people in leadership, right? Because the combination of these two things, this massive growth and disengagement and this math is massive growth in meaninglessness. And by the way, there's other stats that go right along with it, including a massive growth in mistrust, right? 50% of work, 6% of workers globally mistrust their CEOs and their senior leadership, right? So, the combination of all these three things should have given every leader pause, but it didn't. And so what do you have today, you have people saying, “I have had enough! I am quitting. I am not going to take it anymore. There must be something better than this. Right? There must be a better way of doing stuff out there.” Okay? So those are some of the stats that I am recently become privy to, that, in hindsight really helped me sort of make sense of everything that's happening in the world but [Crosstalk 20:13] when it comes to-

Dan: [20:13-20:16] Alarming-alarming statistics. [Laughing]

Matt: [20:17-22:28] They, yeah no, they are alarming! But, you know, when it comes to finding a better way to work, and better companies, really pioneering a better way of working, I didn't find them at first, they found me. I was very fortunate back in 2011, to have a company called-a little company called Pivotal Labs, reach out to me and say, “Hey, would you like to come interview with us? We saw some of your open-source work, we think you might be a good fit here. Right? It seems like you're doing things like test driven development, etc.” And I didn't know much about Pivotal Labs at the time, but actually, one of my co-workers grabbed me and he said, “Hey, don't do it. Don't go interview there. Don't you know, they're doing pair programming? You have to write code with other people at the same time, you share a computer with another programmer! It's insane, don't do it don't even interview!” And of course, I was miserable. I was, at that time, working at an enterprise, which, you know, I just spent 18 months and a process to define a process for software development, like it was the most draconian, demoralizing place I'd ever worked at. And I said, I don't-I have nothing to lose, I'm gonna go try this. And I have to tell you even just stepping into that office, for the first time, it was life changing, right? Like just seeing an-a sea of programmers on a large open floor to programmers for every computer doing pair programming simultaneously, right? A hundred people on the floor doing this all at once, the noise of it, right, the sound of it, seeing all the people sitting around debating, writing code together passionately, right, and laughing and arguing at the same time. And smiling, even just the experience of seeing so many people smiling at the same time, I experienced that as uncanny! Right? I had been so long working in environments in which no one even smiled, most of the time that just seeing people smiling in mass was just mind blowing. And that I was lucky to get a job there and spent the next several years there working in an extreme programming environment. And it really opened my eyes, it made me believe that there really is a better way of working. And that's what led me to start to say, “Okay, who else is doing stuff like this? Is it just technology? Does this go beyond technology? What does all this really mean? How does it work?” And that's eventually what led me to write my book.

Dan: [22:29-22:41] That is an amazing story. They were following the extreme programming practices or just doing the pair programming, or how did it work at Pivotal, like their full methodology?

Matt: [22:42-23:50] Yeah, it was, it was XP. And then as-when I started, it was, I would say, really just XP, like our understanding of product and understanding of design was still maybe-maybe more advanced than you would see in a lot of places, but less advanced than it became over time. Because eventually, we would say that we do XP, Lean, and UCD, and really fully embraced all those things into a balanced team concept. And so, that whole experience and being part of that evolution was-was amazing too, right? And seeing not only how good it was for all of us inside a team working in those ways, right? How much fun that was, how inspiring it was, how collaborative it was, but also how good we were at creating great outcomes for the organizations we were working with, right? Pivotal Labs was a consulting company. So, they're teaching other clients how to do Lean, UCD, and XP, by just building products with them saying, “Come into our labs, and we're going to build something real with you, or we're going to take over something you're already building and help you write it.” You know, like, whatever it is. But we're going to do this through autonomous and self-organizing teams that really are that and by using Lean, UCD and XP methodologies. And you know-

Dan: [23:50-24:20] That’s awesome. Well, we owe a thank you to Pivotal for inspiring you to kind of-or setting you on a path to write your book, which I really want to dive into. I know there's kind of a few central themes of your book, what you call the four imperatives. So, let's run through those. The first one that I have on my list here is Team Autonomy. What's up with Team Autonomy? What does that mean?

Matt: [24:20-28:34] Okay, so what did I-let me-let me start by saying when I-when I began to do research for this book, I very quickly discovered that there is a whole world of pioneering organizations, not just in technology and manufacturing and healthcare, all over the place, that are working in really what I described as radically collaborative ways. And that is, in fact, one of the technical terms you can find in literature for this way of working but it's not the only one, self-managing organizations, non-hierarchical organizations, some specifically are referred to as like “holacratic”, or “sociocratic”. There's just a whole wide spectrum of organizations that in some way, shape, or form are broadly speaking doing something called radical collaboration. And really, this is a form of working together, which is at a high level, and in fact, on the back of my book, I say it's what stands out to you immediately is that there's no bosses, no bureaucracies, and no bullshit. And by the mean, like no level of corporate bullshit that you find in so many hierarchical organizations, in which you constantly feel like people are lying to you or hiding stuff from you, right? These organizations were radically transparent from within. And so anyways, there-when I stepped back and said, Okay, well, how not only what are all these organizations doing, but if I synthesize and sort of group these things together, what's happening within them, and what-what is necessary to make this work? And there-there were four imperatives that it boiled down to two of them were structural, two of them were cultural, I would say, or socio-cultural. And the first one that you mentioned, Team Autonomy is one thing that just stands out immediately within all of these companies. Let me start by explaining, let me-let me illustrate what Team Autonomy looks like at a very vast level. There's a company called Haier. If you're in America, maybe you've never heard of Haier, or maybe you've only sort of seen them. If you've been looking at some appliances, maybe you notice their brand name, but you may not know much about them. Well, what you don't know is that they're the number one appliance manufacturer in the world by sales volume. In fact, they are such a big and successful company that they are the parent company of GE Appliances, they bought GE Appliances back in, like 2014, I think it was. Right? So that's how big they are. What else is amazing about Haier is that over the last forty years, they went from a command-and-control manufacturing organization that really just made shitty refrigerators. And everyone knew it, like don't buy-don't buy their fridges, because they suck right, to being the one of the most prestigious manufacturing organizations on the planet and they did that by moving from command-and-control to radical collaboration. And they have created I think, sort of the poster child for the power of Team Autonomy, they took an organization of eighty-thousand people, instead of running that, like some kind of centrally controlled mini economy, right, with people at the top pulling all the strings. They said actually what we want to be is like a radically collaborative swarm of startups, right? So how can-how can we take sort of the best of what we see in the power of free markets to coordinate and cooperate and compete at scale to do amazing things for the world and how can we boil those down into our company? And they took those eighty-thousand people and they’ve broken them up into what they call micro-enterprises, thousands and thousands of micro enterprises of ten to fifteen people each, and that's Team Autonomy, because each of these micro enterprises or teams are really like entrepreneurial units within the company focused on achieving some kind of outcome, focus on providing some kind of service, they could be just providing a service internal to other micro enterprises, or they could be entirely you know, user facing, customer facing, right. And this is how they actually have reorganized the company, each of these micro enterprises, they don't have a boss or anything, right, they start products on the market on their internal market without the control or guidance of any leaders, right. And they use market-based dynamics to sort things out over time. They own their own profit and loss statements, right, their-their actual pay is derived from the value that they generate as a micro enterprise. So, profit sharing is part of it. Right? And they have supercharged their organization, and over the last eleven years now have been number one appliance manufacturer in the world. So, at a high level, just so you know, this is this is not some pie in the sky concept. This is actually what is supercharging innovation and at scale, right, in in the world of manufacturing.

Dan: [28:35-29:04] That is great. It almost sounds like it's like the no bosses, part of it is like a heaven or like almost too good to be true. Like you-do have anyone ever say that you're like, I know you gave an example it is possible but man, if-if my company did that, it would be like pure chaos or something like that. I can't imagine that working. Do you think like for some companies that would turn to pure chaos, or can everybody do this?

Matt: [29:04-35:19] Yeah. Okay, so the reason that there's four imperatives and not just one is because any one of these things would fail on its own. So, Team Autonomy would absolutely fail on its own, it would turn into chaos, right, or worse, it would turn into sort of what I would describe as petty tyrannies. And in fact, some organizations that have attempted to, right, become nonhierarchical and structureless, etc. have discovered that it's not enough just to say, we're not going to have bosses anymore, right? Because in the absence of a formal structure of hierarchy, if you eliminate all formal structures, all you're left with is the informal structure. And that's actually a term in organizational science, informal structure refers to the ways that work gets done on a day-to-day basis based on the relationships people have and the influence they exert over each other. So, the danger is, if you get this wrong, you can end up with some pretty toxic work situations and I won't name names, but there are actually some pretty well-known companies out there that have had articles and very high-profile publications written about them about the-the risk you run right if you get this wrong. So that's why there's the second imperative-structural imperative that I call Managerial Devolution, and devolution is an odd sounding word. And in fact, in the colloquial sense, it even has some certain negative connotations, right? If somebody says, “This has devolved.” Right? You think that means something bad, however, in the world of organizational science, and also political science, for what it's worth, and sociology, devolution is a technical term for the decentralization of power out of the hands of what is referred to as a dominator hierarchy into the hands of what is referred to as a heterarchy, self-organizing, self-linking network of teams, right? So as power becomes distributed, and as governance of the organization becomes distributed and decentralized, right, that is a process of devolution, and the degree to which a company succeeds at decentralizing governance and management within the organization, out of the sort of old tried and true command-and-control structures and corporate hierarchies into a decentralized distributed world. Right, that's to the extent that they control the chaos or that they eliminate the potential for toxic dysfunction based on informal structures, etc. And so, what does that actually look like? Well, the good news is, it looks like lots of different things actually. There's many different ways these radically collaborative organizations, whether they're the eighty-thousand-person organization Haier down to, you know, the hundred person company, Civic Actions, which I talk about in my book, and everything in between, right? There's lots of different approaches people are taking to distributing authority within the organization and making it possible for the organization to evolve its formal structure without a command-and-control hierarchy. Right? And I think that's an important step-an important point to emphasize, the fact that you don't have bosses doesn't and shouldn't mean you don't have formal structure, right? structure should not be synonymous with hierarchy, right? structure is possible without the sort of dominator hierarchies in which rank and privilege and resources are distributed unequally and concentrated at the top, it's possible to create structure on a paradigm of partnership and equality. And so, you see things like ad hoc leadership teams within these organizations in which basically anyone who says I see a tension within the organization, maybe it's a tension between two roles, maybe it's the tension in the way the corporate dividend is getting distributed. Maybe it's as simple as PTO, whatever the tension is, anybody in the organization can say, there's a problem, I see it, who wants to come solve this with me in these ad hoc leadership teams form and have full authority to make changes. Right? There's a great company that-called Nearsoft, now called Encora that I profiled in the book, they tell the story of basically redesigning how they distribute the corporate dividend and basically do profit sharing as a company, when somebody just a rank-and-file person on the floor said, I think this is wrong. I think this is unfair, I think it's opaque. I think we could do way better at this. And I don't think I'm the only one is anyone else with me. And it turns out a ton of people in the company were with them. And they treated it as a what's called a below the waterline decision, which if you get it wrong means you're sinking the ship. So, they were very thoughtful, very careful about it consulted outside experts, came up with a new profit-sharing mechanism for the company. And they did all of this without the participation of the CEO or the rest of the C suite that founded the company. Right? And so that's just one example. There's other things like holacratic governance, which I don't want to get into what is and isn't holacracy because it's sort of complicated. But at in a nutshell, it's a preexisting sort of rules-based approach to doing things like governance and decentralized coordination at scale. And the holacratic governance process is basically a set of rules that any company can adopt to say, here's how we sense and respond to tensions within our organizational structure and resolve them very quickly. Another approach is called the advice process, which is going to sound crazy when I say it, this-this advice process was pioneered at a powerplant company-an international powerplant company called AES, who was doing everything from coal fired power plants, even up to nuclear power plants. And the founders of that company said, what is important to us is that everyone experienced joy in work. And the best way to do that is to make it possible for everyone to make meaningful decisions. And so, we are going to allow anyone to stand up and say, I want to make a change within this company and to make a decision about it, so long as they conform to what's called the advice process, which is I have to solicit the advice of anyone and everyone that is going to be affected by whatever kind of decision I'm thinking about making, whatever kind of problem I'm trying to solve. And this led to a sort of radical redistribution of authority within AES in which somebody who might in the morning be slinging coal off a barge right, to bring to the power plant might in the afternoon, be calling up Chase Manhattan to say, you know, how much money-what kind of return can you give me on a $10 million investment? Right. And that's not a hypothetical, that's actually something they began to do. Right? So those are three forms of sort of managerial governance, or devolved sort of governance that became prevalent in many of these companies and is prevalent in many of these companies today.

Dan: [35:20-36:04] Thanks, Matt, for all of the information and the detail there. And while you're talking, I was thinking to myself, what would this mean for a developer or, you know, traditionally, very conventionally, let's call it or even old school, I'm a developer, I joined an organization, I get my tasks from a product owner, and I'm measured by how quickly I achieve them and quality is also a component and then I get sent my next task. So, in a situation with Team Autonomy, or managerial devolution, how is my life different as a developer?

Matt: [36:04-38:14] Yeah, great question. So, I think what you can see from a development standpoint, and in the companies that I looked at, anyways, that are doing significant amounts of software, one of the primary differences, you know, what you just described is what I think, generally we refer to as a feature factory, right? Basically, people at the top saying, like build X, build Y, do it by this date, you know, or whatever, right? Like just an unending list of tasks to be done, right? Pummeled down to you from up top and often provided, you know, given-accompanied by unrealistic dates and expectations, so and you're constantly like trying to fight that. Okay, so that's a feature factory, I would say, at a high level, what you can see in these radically collaborative organizations is that instead of being feature factories, they're outcome factories, right? You see balanced teams spun up to autonomously achieve an outcome, right? Maybe the outcome is, we want to increase shopping cart conversion by 5%, right, or we want to increase basket size by 5%, or something like that, right? That would be an example of an outcome. You know, it's-it's a statement of where we want to get to, it's not a statement of how we should get there. And in fact, who is best suited to figure out how to achieve an outcome. It's the people on the ground doing the work day-to-day, right, they're the ones that actually are best set up to achieve an outcome because they are closest to the actual problem. And they are learning every day, more and more about what it takes to get there. They're able to pivot from one strategy to the next as they learn etc. etc. And by creating sort of these autonomous self-organizing teams centered around outcomes, you actually unleash and liberate a lot of innovation within the organization, a lot of learning and ultimately a lot of autonomous decision-making power, right? Because you're saying, one of the things one of the dimensions of autonomy, a team like that has its autonomy and autonomy of backlog, right? They themselves are responsible for filling their backlogs with user stories, prioritizing their backlog, right, deciding what is the next most important thing to do at any given moment. What is the next most important hypothesis to test or experiment to run? Whatever it is, right? That's the I think fundamental paradigm shift that I see. Inside these technology organizations that become radically collaborative.

Dan: [38:15-36:36] Totally makes sense to me, you mentioned that you had a wonderful experience at Pivotal. Are there other well-known software companies, even ones that listeners could maybe go look up or see if there's a career opportunity for them that are more known for Team Autonomy and freedom with the backlog?

Matt: [38:37-41:10] Yeah. So, I think the good news here is that these ideas are really taking fire all across our industry. And so there, I think what you'll discover, at least in our industry, in the world of software, is that there are many organizations who might be at many different places along this journey towards radical collaboration towards sort of this future of work. But many of them have caught on to the idea that knowledge work actually works best when people get to make decisions, when people doing the work are actually-and have the information have the authority to act on that information. And so you can see this outcome, paradigm outcome team paradigm at play in all kinds of places, even places like the US Air Force, right, there was a lot of work done between Pivotal in the US Air Force over the past several years through an organization developed inside the air force called Kessel Run, which was based on this entire concept and methodology that we need-need to empower teams to autonomously achieve outcomes, right. And it's a place that maybe a lot of people wouldn't expect it at. But I think that shows the power of these ideas, and also the success of these ideas, right? They wouldn't, they wouldn't keep taking root in places unless they weren't achieving better economic outcomes and better organizational outcomes than otherwise. So, places like the Air Force are happening. Now there's many software companies that I mentioned in my book, which I can mention some right now, cLabs which is the creator of the cryptocurrency called Celo or “cello” maybe is a better way to pronounce it. They are a radical collaborative cryptocurrency company based in San Francisco, I'm gonna get some of these wrongs. They're basically they have three sort of primary locations around the world as well as a distributed workforce. And they are a radically collaborative software organization. And you could read many stories about how they work within the book. When I was doing interviews with them, they were already at a couple hundred people and still rapidly growing, and seeing a lot of success too, and doing a lot of really good things in the world right. They’re a mission driven company. Nearsoft or Encora, which I've already mentioned, is a consulting company that's been doing this for the last fifteen years and really been pioneering a lot of this. And how for you Mantis, which is another organization I profiled in the book, which has its own fascinating story from moving from sort of Dominator Hierarchy to workplace democracy to radical collaboration and self-management. Right? So, a fascinating evolution with a lot of, I think, critical lessons to learn along the way, which I tried to give you in the book, there another great organization to check out. And they're really at the forefront of creating collaboration software. So, there's others I can mention, too, but maybe that starts to give you a sense of some of them.

Dan: [41:11-41:56] No, thank you so much for sharing that. And I know that you're legit, because we had one of the change agents at Kessel Run, Adam Furtado on our pod, and that's one of our most popular episodes around the transformation that they did there. So of course, anyone listening, you know, keep your ears open to what Matt was just saying some really nice opportunities there. I do want to move us on just a bit here. There's two other imperatives that I would love for you to touch on here for us. And hopefully I get this right, Deficiency Need Gratification is the next one that I have on the list. Could you talk to us about that?

Matt: [41:57-46:31] Yeah, absolutely. So yeah, so the next two imperatives are-really speak to sort of the cultural, the personal, sort of the actual relationship and collaboration aspect of making all of this work at scale. And the first is called Deficiency Need Gratification. It's a term from the field of positive psychology. So, if it's like new to you or anything like that don't feel bad, because it is actually a technical term. However, I think the concept everyone's familiar with, even if they haven't heard that term before, for instance, I'm sure all of your listeners are familiar with a disease called scurvy. Right? Scurvy is a deficiency illness. It's a physiological deficiency illness, right? It's the illness that you get when you don't get enough vitamin C. Right? It was the one-time scourge of the British Navy. But it turns out, there's a really simple fix, vitamin C, right? Like, go eat some oranges, right? Or whatever it is, or take your vitamins, right? If you're suffering from scurvy, you can actually gratify your deficiency, quite simply by consuming things that have vitamin C in them. And once you do your symptoms, all the physiological symptoms that you experienced with that disease, go away. Okay, so we've known about physiological deficiencies for at least three-hundred years, right? And in a scientific sense, right? We've known about them. But it's only in the last really seventy-five years that we've understood that that same process works for humans with psychological needs, not just physiological needs, right. And I think this is one of the most pivotal discoveries of the 20th century. It almost sounds weird to say it now. But the truth, the thing that was discovered in the 20th century, which shocked a lot of people, believe it or not, was that humans are different from other animals, and have psychological needs over and above physiological needs that other animals don't have. Right? And those are needs like security, autonomy, fairness, esteem, trust, belongingness, meaning, purpose, fulfillment, love, right? We need all of those things to be full and complete human beings. And when we are deprived of those things, when somebody deprives us of our security, or our autonomy, or treats us unfairly, or disrespects us or doesn't give us esteem, right, we begin to exhibit certain psychological illness symptoms, right? And we begin to act out in certain ways. But we also become motivated to rectify our deficiencies. If we find ourselves every day, day after day in an environment which drains us of our psychological needs, we become very interested in finding a way to find a different environment, an environment which would make us feel like a good human being again, right make us feel safe and respected, trusted, like we belong. And so, 20th century psychologists like Abraham Maslow and Carl Rogers and others sort of pioneered this sort of breakthrough and they had a hypothesis at the time. They said, “We believe that what is good for people will also be good for organizations.” So, organizations that focus on creating environments that are psychologically healthy, for the people within them will actually have really outsized and fantastic organizational results for the customers, right, et cetera. And that was just a hypothesis that they had. They had reasons to believe it, but they had no empirical evidence. And the good news is, over the last twenty, thirty years, there's been a great deal of organizational science that has validated that hypothesis. It's not a hypothesis anymore, right. Just take one of those needs that I mentioned, trust, right trust is an underlying psychological deficiency need. And if we become deficient in it, we don't perform well, right? But if we experience work in a high trust environment, it turns out fascinating things have been found to happen inside the organization, there's a really great acronym called TRIP: T, trust, R risk taking, I innovation, P performance, high trust environments lead to thirty-two times the amount of risk taking in those environments, like positive organizational experiments, etc., right? And that risk taking translates into eleven times the amount of performance over a normal organization! Which then turns into eleven times the amount of innovation, which turns into six times the amount of performance. So, T.R.I.P. TRIP is just an example of how satisfying an underlying deficiency need has outsized economic impact. So yeah, I think that's one of the central messages of my book that what is good for people is good for business. And it's not just a belief, it's a fact.

Dan: [46:32-46:49] Do you think it can work in a world-or at least a lot in the US that's about deadlines, money, you know, because some of those things that you're saying are kind of just like the opposite of-love, hard deadlines and, you know, capitalism, can it work?

Matt: [46:50-49:22] Not only can it work it-it works better than all of that, right? And that's, that's the other point I make in my book, right? Like, I point to like various empirical studies that are looking at organizations in mass and saying, “Okay, if we break down the different organizational archetypes and pit them against each other, economically, and then correlate that with what we're seeing in terms of the interpersonal dynamics within the companies, what do we see?” Well, we see that companies that satisfy deficiency needs, outperform other organizations, more traditional hierarchical organizations that are just focused on the bottom line, they outperform those companies on practically every meaningful financial measure, whether it's market share, whether it's growth in market share customer satisfaction, or revenue, growth, etc. etc. Right? So, I'm not surprised that we're seeing the number one appliance manufacturer who has this-all these elements that I'm talking about within their company, that that we're seeing that in the-the number one appliance manufacturer in the world. Same thing with the number one tomato processor in the world, Morningstar, everybody's probably got a can of, you know, tomato sauce in their pantry. And it's probably been processed by a company called Morningstar, even if it has a Heinz label slapped on it or something. And that company is radically collaborative, too. And they are the number one tomato processor in the world and the experience of working there as deficiency gratifying, right? The same for WL Gore, which is one of the longest-lived experiments and radical collaboration in the world, right? They were started in the late 50s, everyone on the planet probably has Gore-Tex fabric sitting in their closet, right? The Gore-Tex is the waterproof fabric that practically all raincoats are made out of today, right? Or Glide dental floss was created by Gore-Tex along with, you know, like Elixir guitar strings. Like all of these things, all these innovations have come out of this innovation factory, WL Gore, which underneath the hood has a great deal of deficiency gratification going on within it. So, it's not-it does maybe strike some people, especially in places like America as touchy feely, but they-they would be foolish to stop there and not sort of get over that initial reaction. Because when you-if-if all you care about is the bottom line, you should care about this, right? Like that's the end of it. Like that's, even if you don't care about this stuff, if you just care about the bottom line, you still need to look at all this stuff, because you're dead in the water without it. And these companies, these radically collaborative companies, right. have gone from 1% to 3% to a 8% of corporations around the world over the last, like, fifteen years. Right? So, it's-it's a rapidly growing cohort. And they aren't-they aren't just going to sit around and play nice, right? They're going to out compete every traditional company on the planet before long.

Dan: [49:23-49:29] I have a few Elixir guitar strings at home. So great product, probably amazing company. Your last, or I guess the fourth imperative is titled Candid Vulnerability. Tell us about that before we wrap up here.

Matt: [49:40-51:36] Yeah, totally. So, the other thing, and a lot of what is behind the level of innovation within these companies. It starts with that high trust environment that I mentioned, but there's another component to it that really supercharges innovation within these companies, and it's called Candid Vulnerability. Okay, what does that mean? Well, had a high level that simply means people within these companies are remarkably candid, and remarkably vulnerable. Meaning they don't just say what they think they actually are vulnerable by saying why they think it, what is the underlying hidden chain of inferences, observations, experiences, biases, beliefs, etc. that they have, that leads them to say what they think, right? They have all kinds of facilitation techniques for bringing this out but ultimately what this means is that within groups, instead of fighting for one idea over another, they untether ideas from the individual egos that they came from, and they're able as a group to collectively examine-examine a whole host of ideas with a far greater degree of sort of objectivity, collective intuition, collective exploration, and create new ideas as well that were only possible by doing that. Right? That other teams that can't collaborate in that way, would never even have dreamed of. And so, this aspect is, it's sort of a startling aspect and almost like a scary aspect when you walk into these companies, because you hear people say things that in normal organizations, people never say, because they're too afraid, because they self-censor. But you also hear people be incredibly vulnerable at the same time. And you see facilitation techniques within these companies that allow this all to come out and ultimately create a whole experience that is, what psychologists refer to anyways, as psychologically successful. In other words, the experience of candor and vulnerability doesn't diminish your sense of worth or anything like that, it actually makes you feel better. And therefore, it gives you more energy next time to do it again and again. And so, it has this flywheel effect, it's autocatalytic.

Dan: [51:37-52:19] That totally makes sense for me, especially for development organizations, when you're inventing something or innovating mistakes are going to be made, teams that I have seen that kind of have that candid vulnerability, they're able to say, “Yeah, this is what happened, or the failure or the problem that I created. Here's how I'm going to do it better. Or what does everybody think?” The innovation, also like a flywheel starts happening faster and faster. So, I can totally relate to that. We are coming up on time here, Matt, this has been an amazing conversation. Thank you so much for sharing all of this, I would call maybe enlightenment on our podcast today.

Matt: [52:20-52:22] Thank you so much for having me. I really appreciate the opportunity.

Dan: [52:23-52:41] Now your book A Radical Enterprise, I assume it's available on all the normal places, maybe it's not, but like Amazon, and so on and so forth. But what I really want to ask you about it is, who do you think should be purchasing and reading this book? Who do you think it's best suited for?

Matt: [52:42-54:56] Yeah, so I've-alright, this isn't the only book that exists in the world about this topic, right? There's a whole sort of host of books about self-managing organizations and radically collaborative organizations. What's unique about my book is two things. One, I-having a background in technology, I am specifically looking at a certain set of technology organizations, in addition to the other organizations I mentioned, as well. Right? And so I'm trying to understand not only what are we-what does this look like all around the world in many different industries, but specifically, how does it express itself within technology organizations, so that's something you can get out of my book that you wouldn't otherwise find. The other thing is the four imperatives that I've come up with, although you probably see all those same ideas appear in different forms in different books, right, I pulled them all together, I think in such a way that is new and unique and I hope to be a helpful contribution to this whole field. Now, who is this best suited for? I think it's best suited for first and foremost, technologists. That being said, you don't have to ever have programmed a line of code in your life to read this book, you don't even have to work on software to read this book, there may be just a few paragraphs that you would skip over at most, if you thought, like I'm not quite sure what they're talking about there. Because by and large, the book is focused on things that everyone in any organization ultimately cares about, which is either the organizational structure aspects of this, or the cultural aspects of it. So, I think leaders also especially would get a lot out of reading this book, and they would all-they would get it for two reasons. One, I think these concepts should be on every leader’s radar, especially because if their company doesn't already understand these things, they're going to have their lunch eaten by some other radically collaborative organization soon enough. But the other reason I think that leaders have to really understand these things is because-and look at the stories within this book is because this book tells transformation stories about how leaders and individual contributors work together to go through this transformation, right, to distribute power and authority throughout the organization in a way that doesn't diminish or dilute power, it actually enhances the power of the whole organization to be able to sense and respond to economic conditions etc. and to innovate at scale much more effectively than otherwise.

[Music fades in]

Dan: [54:57-55:14] Awesome. Well, totally makes sense to me, anyone, you know, developers or team leaders, VPs if you're looking to make a change within your organization and how your team operates, definitely check out Matt's book. And Matt, thank you again for coming on the show today.

Matt: [55:15-55:17] Thanks so much for having me. I hope to see you again.

[Music fades out]