More and more organizations are adopting a "Radically Collaborative" approach to business. Matt K. Parker, author of the new book A Radical Enterprise joins me to discuss what this means, why it's desirable, and how to begin adopting these practices in our own organizations.

In this episode

• What is "Radical Collaboration"?
• What does radical collaboration mean for the business bottom line?
• The four imperatives of radical collaboration: Team Autonomy, Managerial Devolution, Deficiency Gratification, Candid Vulnerability
• How do Agile Software Development and the DevOps movement relate to the idea of radical collaboration?
• How are OKRs similar to or different from the radical collaboration model?
• The "Advice Process", and how decisions are made without designated managers.
• What recourse do these organizations have against potential "bad actors"?
• How do self-selected salaries work?
• How does this book fit into the landscape of recent books such as Reinventing Organizations and Team of Teams on new ways of management?
• Do companies ever fail in their attempts to become radically collaborative, and why?
• What can a lone individual do to begin a transformation toward radical collaboration?
• When is the best time in a company's life cycle to begin a radical collaboration transformation?
• What can a solo founder or entrepreneur do to begin laying the foundation for radical collaboration when they make their first hire?
• How long does it take to transform to a radically collaborative organization?

Resources

• Book: A Radical Enterprise by Matt K. Parker
• HOW report
• Book: High Output Management by Andrew Grove
• Book: Reinventing Organizations by Frederic Laloux
• Book: Team of Teams by Gen. Stanley McChrystal
• Book: Corporate Rebels by Joost Minnaar
• Blog post: How to Run A Radically Collaborative Meeting In 3 Easy Steps by Matt K. Parker
• Book: Turn the Ship Around by L. David Marquet
• Book: Humanocracy by Gary Hamel & Michele Zanini
• Book: The No-Limits Enterprise by Doug Kirkpatrick
• Book: Holacracy by Brian J. Robertson
• Corporate Rebels web site
• MattKParker.com to join the Slack community

Guest
Matt K. Parker
Web site: MattKParker.com
Email: matt@mattkparker.com

Transcript

Narrator: Ladies and gentlemen, The Tiny DevOps Guy.

[music]

Jonathan Hall: Hi, everybody. Thanks for joining me again for another episode of The Tiny DevOps podcast. I'm your host Jonathan Hall. On this show, we like to talk about solving big problems with small teams. Today, I'm really happy to have with me, Matt Parker. Now, if you are a math nerd, like I am, you might be thinking of Matt Parker from Stand-up Maths YouTube channel, that's not who's on today. This is Matt K Parker, author of the book, A Radical Enterprise. Thank you so much for coming on, Matt. I'm excited to talk about your book. Would you give us a brief introduction about your background, tell us who you are?

Matt Parker: Sure. Well, thanks for having me. I am now an author, but in the past, I've been in engineering. Actually, I've grown up in that world because my dad and my dad's dad were both programmers. I've been around programming for a long time and got into the industry myself and spent maybe my first decade in it, not being very happy, working for both startups and enterprises, but feeling like, "This isn't a great experience. Why are people so miserable making software together?"

Then, I was lucky enough to get a call from a company called Pivotal Labs at the time. They were a small consulting company back then in 2011. I knew they did things like extreme programming. Not that I really knew anything about them, but I thought it was worth a try. I'm really glad I took the chance because it was a life-changing experience. I got the job and I became immersed in the world of extreme programming, lean product development, and human center design.

I got to experience that from many different angles, both as a engineer, working on teams and pair programming and trying to help others learn how to do all of it, but also as a director, trying to set up teams for access so that they could be autonomous and self-organizing and really have all the liberating constraints that they needed to succeed. That whole experience, by the way, is what led me to write the book because I thought, "Wow, there's really something to this. We're having so much fun together and we're having really great outcomes."

Maybe those two things go hand in hand, maybe if you find ways of working together that are really open and collaborative and help everyone leverage their intrinsic motivation and passion, that will end up doing great things for our organizations, our customers, our businesses. That led me into research around this book. Who else is doing stuff like this? How far does it go? What size and shape does it take, and if they're successful, what can we really they accounts for that success? There you have it. That's how I came up with this book, A Radical Enterprise.

Jonathan: Nice. Are you still involved in software development these days then or what are you doing now?

Matt: Now, I'm doing independent consulting. Really, around the topics that you can read about in my book. I'm trying to help organizations become more radically collaborative, more self-managing, how do they actually set up teams for success, how do they leverage ideas, like team autonomy and managerial evolution, candid vulnerability, and all this stuff to achieve great outcomes. I could say my day-to-day right now looks like a lot of leadership coaching at the moment and that's what I focus on now. No, I don't write a lot of code anymore and some days, I miss it but I also feel good about what I'm doing now too.

Jonathan: Definitely, I hope so. One question I want to ask right off the top, before we even really dive into the topics of the book and this is because of the audience on this channel, since we focus on DevOps for small teams, the title of your book is A Radical Enterprise and I want to ask, are the topics relevant to small organizations too or do they only work in large enterprises?

Matt: Yes, totally. Well, absolutely, it's going to be relevant. I should say you can take the title two different ways. A Radical Enterprise could be referring to enterprise organizations. It can also be taken as an enterprise as an a thing we set out to do and enterprise in that sense as well. I meant it to be taken in both ways. The organizations I profile, 13 different organizations I profile in the book range in size from actually, I think the smallest is about a 25 person Internet of Things company you can find in San Francisco to the largest is an 80,000 person appliance manufacturer. That's really spread around the globe and headquartered in China.

Everything in between, you can find as well. I would say also the reason that you're going to find my book relevant to the topic of this podcast is because so many of these organizations have realized the power of small teams to such an extent that they've created organizations centered around the idea, the power of small groups of people achieving amazing outcomes, and being able to do so with autonomy with also alignment, even in a very large organization.

Jonathan: Let's talk now about the book and the core thesis. Of course, I have read the book and I find it really enlightening, but in your own words and just a minute or two, you already started to talk about your history at pivotal, which is how the book starts, what was it about that experience and others that led you to your core thesis? What is that thesis and how does this book address it?

Matt: The book is about, broadly speaking, you could say it's about the topic of radical collaboration. Why my own experiences are relevant to that is because I experienced radical collaboration before I ever understood it. That term, I should maybe break down a little bit too what is radical collaboration and why do you say radical in it. Radical can mean different things to different people in different contexts. Let's break that apart a little bit.

My experience collaborating with other people up until I worked for Pivotal Labs, so my first decade in industry, was not only not fun, it was ultimately a demoralizing experience because collaboration was stuff that was dictated by others. You two worked together to achieve X. You put this together and throw over a wall to someone else, and that's what they call collaboration. None of us understood why we were doing it or how we were going to succeed or anything like that in the first place. There was also a lot of anti-collaboration going on in the places I worked.

In fact, at the enterprise I worked at before I joined Pivotal Labs, I was privy and part of an 18th-month-long process to define a software development process. The process map that we created at the end of that 18th months was so complicated, has so many steps in it that ultimately, you could say, all it was doing was institutionalizing both incompetence and a desire for everyone to be able to play CYA, cover their ass, in case anything went wrong and be able to point the blame somewhere else.

I feel like that's all we ended up accomplishing and what a demoralizing experience that really was. When I say radical collaboration, what I mean is that when I went to Pivotal Labs and I began to experience their programming and working on small teams that were empowered to achieve an outcome and empowered to figure out the best way to get there and to learn as they go and to have really tight learning loops with their customers, that they're delivering the software into the hands of. That, ultimately, was radical in the etiological sense of the word.

It was radical because it changed the ground of collaboration. It changed the nature of my relationships to my peers around me. It was no longer a hierarchy. It was a heterarchy. It was a group of people, peers, each with different experiences, each capable of leading in certain situations and following in others, everyone able to really leverage both their own experiences and their intrinsic motivations and passion to be able to geek out together and do really fun stuff together as software engineers and designers and product managers, that was such a beautiful experience.

It gave me hope that a better world really is possible that it's not a foreground conclusion that software has to be a miserable experience or, ultimately, experience that leads nowhere and leads you to throw away years worth of work because somebody decides to scrap it at the end. There is a better way out there and that's what I ended up discovering. The other thing I'll say about radical collaboration in the book is I'm really referring to a process in which people are collaborating as partners, as equals, as peers on a basis of voluntary commitment and responsibility to each other.

There's a complete lack of coercion within these environments and it's not a coerced form of collaboration. It's very much a partnership form of collaboration. That's a lot of what underlies the experience and ultimately the success of a lot of these ways of working. It's a paradigm of partnership and equality that you can see at play in these companies.

Jonathan: Amazing. I think that really fits with the DevOps mindset of collaboration. I always say that DevOps is just another word for collaboration or cooperation. I think that there's a really strong tie between these concepts. We'll talk a bit more about that, I hope in a moment. Before though, what you've described sounds super nice.

I can imagine that working in such a place would be fun and fulfilling, but what do you say to someone who says, "If I want fun and fulfilling, I'm going to move to a commune and I'm going to sit around a campfire and sing Kumbaya," what's the business impact? How does we have to make money too? How does that concern fit into this concept of radical collaboration?

Matt: Well, obviously, it's an important question. For better or worse, every company that's out there playing on the market, live or dies on that market. They have to be able to actually succeed economically. For a long time, throughout the whole 20th century, a lot of people hypothesized that, what would be good for people would also be good for the organization. Abraham Maslow, Carl Rogers, many other psychologists, and organizational scientists had this belief that there would be a great deal of synergy between individual and organizational success.

There wasn't a lot of evidence and really it's only in the past couple of decades that we've gained an increasing amount of empirical evidence to say, these two things really are tightly correlated. When you create an organization in which people feel they get meaning and fulfillment out of the job in which they feel passionate, they have autonomy, they are engaged, you actually end up with some really outsized economic outcomes. There's a great report that was run successfully, like a longitudinal report about this idea, what's good for people is good for organizations.

It's called the HOW report. You can read about it in the book as well. It really breaks down organizations in the three fundamental archetypes. One of which is radically collaborative. In over last 10 years, we can see that the number of radically collaborative organizations has grown from 3% to 8% and that their economic outcomes that are vastly superior to their much more traditional and hierarchical competitors. The outcomes also for individuals within the organizations are superior. You can see that type correlation at play.

I would also add that if you want just another sound bite there around, is this really economically successful? There are three or four different organizations I can point to in the book. You can read about yourself all over the inner webs, Haier, which is the number one appliance manufacturer in the world and 80,000 person enterprise has for the last 40 years transformed from a very traditional command and control hierarchy to a very radically collaborative structure that they refer to as micro-enterprises.

They're now the number one appliance manufacturer in the world and they've really gotten there over the last decade and a half as they've really pioneered a whole new way of working based on a quality partnership and radical collaboration. They're a great success story. If you want to see at a very massive scale, these ideas and how they can play out, and how successful they can be for a company, check out Haier. Another organization you can read about in the book is Morning Star, which is the number one tomato processor in the world and they're based in California.

They have such an amazing radical process. They start every year as equals without titles and they write something called Colleague Letter of Understanding. It's really the negotiated commitments that they're making to each other that year about how they're going to take that year's tomato crop and turn it into puree and diced tomatoes and everything else for all of their clients like Heinz Ketchup, everything else. They're another example of radical collaboration at play in that partnership and equality are more competitive than domination and coercion.

WL Gore. If you've ever bought a raincoat, you've probably worn Gore-Tex waterproof fabric. If you ever flossed your teeth, you've probably used Glide dental floss. The company behind all these products is WL Gore and they're an innovation factory. They're an amazingly innovative organization and they are also one of the longest-lived experiments in radical collaboration on the planet. They started in the late '50s with the completely radically collaborative structure and it was just four people in a basement. Now, they are 10,000 people spread around the globe innovating at a global scale using these same ideas.

I'll stop there. There's more in the book you can read about, but hopefully, that gives you a sense, there is really something to this and there's some very significant economic stories that we can point to related to these ways of working.

Jonathan: Yes, that's great. I remember reading those examples too and thinking it's not just that this does work as a business model, but it's actually a superior business model, at least in many cases. That's encouraging if you're worried about meeting the budget using radical collaboration, I don't think you probably need to really be worried about that. I think you can do it anyway. Would you mind taking us through the four imperatives that you've identified? Just briefly a high-level overview and then we can talk about some of those in more detail.

Matt: Yes, absolutely. In the book, I'm not only trying to show a bunch of companies doing working in radically collaborative way, I'm asking the question, why do they succeed? What stands out the foundation of their success? The other companies interested in doing these things will have a sense of what's it going to take. It's probably not just one or two things that you're going to have to think about or cherry-pick from other companies, there's something deeper and more holistic here that you need to be aware of and I broke it down into what I call the four imperatives of radical collaboration.

All of these companies at some level are exhibiting four imperative things that I think are stand up the base of their success. That's, one, team autonomy. Two, managerial devolution. Three, deficiency need gratification, and four, candid vulnerability. Team autonomy is probably a concept that your listeners are already familiar with. All of these different companies, you can see a strong sense of empowered teams being able to achieve an outcome, but figuring out day-to-day how they're getting there. What is their backlog? How are they working together as a team? What practices are they using? When are they working? Where are they working? Are they distributed, co-located, et cetera?

These elements are really left up to the team and it's not surprising, right? There's a great deal of neuroscience research actually over the last 20 years that's developed that points to a strong correlation between individual success and individual autonomy team success and team autonomy. Individuals and team successful, by and large, to the extent that they believe in what they're doing and one of the best ways for them to believe in what they're doing is to figure it out themselves, to come to their own ideas and conclusions, right?

Maybe as an organization, you say like, "Oh, we need to increase consumption of this product by 5% this year," but a team getting together and saying, "How are we going to do that? How should we get 5% growth in our customer base this year?" "Oh, I have an idea, you have an idea, we're coming up with ideas, we're trying things out, we're experimenting." That's at base of what is going on with team autonomy. The second thing, managerial evolution. That really points to a process from hierarchy to heterarchy.

Now, heterarchy is a technical term, if you're not familiar with it, you could just think of it as a network of self-organizing self-linking teams. These organizations are, by and large, moving from a traditional command and control pyramid structure to a structure in which it is much more like a network. Part of that is creating sophisticated ways to do governance at scale. How do we iterate on our structure as an organization without people at the top, dictating everyone?

With us being able all to send some respond tensions within the organization and respond to tensions within the organization, resolve them together, do that in a decentralized and distributed way. When you see an organization like Haier, for instance, which is composed of thousands of micro-enterprises each consisting of 10 to 15 people and you can see all kinds of fundamental changes in the way those micro-enterprises are relating to each other, the roles within them, the networks of them, collaborating together or not as they see fit, you can see that growing and changing very quickly and rapidly over time and responding to changes in the market very rapidly.

I think that's a lot of what points to their success, right? Being able to iterate on your organization. In the same way that you would iterate on a software product, but doing at an organizational or metalevel is a really powerful thing. Being able to leverage the mind share of your whole organization to do that. Being able to respond and all can kinds of different ways to different things happening in the market in an ecosystem. That's where I think a lot of their success, nimbleness, and agility comes from. The third thing, the third imperative was deficiency need gratification. That's a term I borrowed from the field of positive psychology.

Deficiency needs are really needs that all humans have and are motivated to rectify if they become deficient in them. These are needs that are over and above animals. Humans don't just need food, water, and shelter. We need security, autonomy, fairness, esteem, trust, belonging, love, meaning, purpose, fulfillment. We have these higher-level human needs that we also need to satisfy to be full and complete human beings to be at our best.

These organizations have realized like, "Oh, if we create an environment in which people feel they're really getting that out of all this, then we have some really amazing outcomes as an organization," because no one's walking around disengaged, no one's walking around being toxic or anything like that because they are already getting their sense of security autonomy, fairness, esteem from the nature of their interpersonal interactions with each other and the nature of the organization itself. There's different stories I point to in the book around all of that and how they accomplished deficiency need gratification.

Lastly, candid vulnerability. That's really about a beautiful thing you can see happening inside these radically collaborative organizations at points of the nature of collaboration within them. It's the ability for people in these companies to say very courageously what they think, but even more courageously why they think it. They don't hide their hidden world of inferences, agendas, assumptions, biases, et cetera, from each other, they make all that vulnerable to critique, exploration, examination, et cetera. In doing so, they end up collaborating in ways in which they can all surface ideas together and also untether those ideas from the egos that they came from.

You end up with this world in which innovation is a collaborative exercise. You're not just waiting for Steve Jobs to come and say, "I have a brilliant idea. Everyone, go execute it." You're actually coming up with brilliant ideas together, ideas that no one individual could come up with on their own because you actually need to put a lot of really smart minds together to do it. That's what these companies excel at as well. I think that's part of why they're so successful.

Jonathan: You started off with team autonomy and mentioned the audience you're probably familiar with that because we come from largely an agile software manifesto style background, where that's one of the core tenants of agile movement and DevOps grew out of that. What relationship do you see between agile and maybe DevOps and this radical collaboration? Are they along a spectrum of the same spectrum? Are they different? How do they relate?

Matt: I think what we're seeing in spaces like self-management, radical collaboration, self-governance, et cetera is really an extension of a lot of the ideas that drove the agile movement in the first place. Ultimately, in DevOps, Scrum, Agile, XP, et cetera, all of these different streams have come together with the idea that collaboration is important, empowerment is important. Team's being able to iterate and learn as they go, that's all important. I think we've also seen this idea fail a lot within the industry.

Organizations tried to implement it and discovered their teams still struggled, their teams still just focus on execution without understanding value, their teams still exhibit a lot of the symptoms that they started with. I think a lot of that has to do with the fact that agility isn't just something a team does. It's something an organization has to do as well. It is hard to be agile in a command-and-control structure.

With everything you want to do, you have to pretty please your boss for it and see it run up the flagpole to higher and higher levels of your organizational hierarchy before anybody decides anything can get done, you discover a lot of teams feel like their hands are tied behind their back. They don't actually have agency, empowerment, and autonomy. They can't really decide what they're doing day over day to figure out how to achieve an outcome.

They're just being given a set of tasks still at the end of the day and being measured on whether or not they completed them irrespective of the value of those tasks may actually have. I see radical collaboration and self-management very much as an extension of the whole agile movement and DevOps movement.

Jonathan: There have been other attempts, of course, to try to codify some of the things you've talked about. One simple example that comes to mind is the concept of OKRs, which I'm sure you're familiar with. Andrew Grove, I think, made them popular or introduced them to the world in his book High Output Management. He was the former CEO of Intel. The basic idea is that management decides what we're going to do or decides the objectives we want to reach, but then lets the teams decide how to achieve them.

What is your thought on this approach? It's some of the autonomy you're talking about, but not all of it. Is that good or bad or again, is it along the spectrum?

Matt: It is absolutely a spectrum. There's no real litmus test that says you are or you aren't self-managing, self-governing, radically collaborative, et cetera. I think the trick is, in a world in which people not only deciding, for instance, a high-level set of portfolio level outcomes to achieve as a business but also having hire and fire, and performance review power over everyone who's been tasked with achieving some kind of outcome, you end up with a lot of weird dynamics at play in those organizations. Even with something like OKRs, people actually still really struggle. That's where I see those things failing.

What I find really beautiful about a lot of these companies, there's this, I think, knee-jerk reaction a lot of people have to non-hierarchical organizations, self-governing organizations to say like, "Oh," but it almost just be chaos, it must just be unstructured madness where either nothing gets done or the loudest voice wins or something like that. There is still got to be some kind of power structure there at the end of the day.

Well, in reality, I think what these organizations have figured out is that their ability to succeed as an organization depends largely under the degree to which people are clear about what their role is, what success for that role is, and what is their domain of authority within that role. In these radically collaborative organizations, you can see people having a role like Portfolio Manager or something where they are deciding at a very high level, "Here's an outcome we're going to try to achieve like 5% growth in margins," or something like that or 5% headcount or customer base growth or something like that.

You can see people in these organizations doing that, but that's not a hierarchical position of authority, it's literally like there are people whose job it is to figure that stuff out at a high level and to liberate teams to go achieve outcomes because what those people don't have the power to do is to tell a team how to get there. They don't have the power to say like, "Okay, you not only have to achieve this outcome but here's the 10 tasks you're going to do to achieve it, and here's the five technologies you get to play with," et cetera. That's not happening in these companies.

If you look at a classic balanced extreme programming team, you could see really three primary roles. Product manager, designer, and engineer. So much of what that makes that team succeed is the clarity they have run whose job it is to decide what. A product manager has a domain of authority at the end of the day. That domain of authority is the prioritized backlog. On a classic XP team, they have the authority to say, "This is the next most important thing for us to work on as a team. I prioritize this story at the top of a backlog and not this story."

Engineers then pull from the top of the backlog because they honor that priority and they honor the team's ability to make that decision. Now, the designer has a domain of authority around the user experience and user interfaces reflected in those stories. No one else gets to tell them what user interface or what user experience is reflected by these stories. It's their job to decide. We can all give them advice and thoughts but they make the call at the end of the day. The engineers have domain authority over the code.

It's this clarity that they have around their roles I think that it can point to so much of their ability to move very quickly as a team to iterate to experiment to not get too hung up on like, is this the right thing to be doing? Because they know they're just going to keep learning as they go no matter what and no decision is ever going to be perfect. That same idea of these self-managing radically collaborative organizations, they've taken that idea from the team level and said, "What if we created that same level of clarity within the organization as a whole?"

That's such a powerful concept. It's so clarifying and so empowering to everybody in the organization to have that form of clarity.

Jonathan: The book talks about something called the advice process. I know this wasn't your invention but would you tell me what that is? Then, I have a question about some of its implications.

Matt: The advice process, it's one of many different forms of decentralized governance that you can find in radically collaborative organizations. It's probably one of the older ones and its origins are in a place you would never expect. Let me first describe what it is and then let me tell you where it started. The advice process is the idea that anyone in the organization can make any decision so long as they consult. Everybody that's going to be affected by the decision, solicit their advice while also making their own ideas, beliefs, positions, perspectives, et cetera open to examination, critique, et cetera, by all the people that would be affected.

That's a pretty wild idea because it sounds like you're giving everyone the power to do anything and oh, bad actors, what would happen? As crazy as that sounds, it gets even crazier because this idea started at a company called AES, which I think was like Advanced Energy Services, I forget the exact, what those acronyms are. I'd have to look it up now. Anyways, they were a power company, building coal-fired power plants, et cetera, generating electricity. I think even nuclear power plants they had purview over. They had power plants all over the globe.

The founders were very much motivated by the idea that there's no point in going through life creating miserable experiences for everyone. If we're going to go make our own power plant company, how can we do it in such a way that everyone enjoys their job and finds meaning purpose, and fulfillment in it? They came to the conclusion that people only enjoy their jobs to the extent that they actually get to make meaningful decisions day over day, which is ultimately what autonomy means. Autonomy means having choices, being able to make choices and run with them, and not have them second-guessed by everyone else or overridden by everyone else.

They've pioneered this idea called the advice process to really fantastic effect within their company and there's all kinds of-- I even point to some stories in the book about this, not only about the founders in their own experience doing this but the experience of people within the company like going from pulling coal off a boat to calling up Chase Bank in Manhattan and asking can they get a $10 million loan?

People doing those two things, you wouldn't normally assume the same person could do both but it turns out they can and they enjoy their lives so much more when they're able to leverage their own intrinsic interest for the good of the organization. Anyways, that same idea has been taken and adapted by many organizations, including some in the book. It's only one of many different forms of, I would say, radically collaborative governance you can see at play. It's not the only one out there but it's a pretty fascinating one.

Jonathan: You brought up the topic that I'm interested in drilling in on and that is bad actors. You make it sound like it's not really a concern. It's probably true, but what if, just on some off chance, somebody decides that they are going to give themselves a $5 million pay raise or they're going to buy a fleet of corporate jets that they can't afford or something ridiculous, what's the recourse in place to prevent these bad actors from acting bad?

Matt: Well, in some of these companies, ultimately, the ultimate recourse is of course getting fired, getting kicked out. We all know how that works in a traditional organization who has hire and fire power. Well, it's people within the hierarchy. The higher up you go, the more hire and fire power they have. Within these radically collaborative organizations, often what you see is that hire and fire power is left to the teams themselves.

They all have, not only the ability to bring new people into the organization, they also have the ability to remove people from the organization if they believe those people don't belong, if they believe that they are bad actors, or have done something that there's no forgiveness for. I tell some stories about that in the book. For instance, at a organization, it was called Nearsoft I was doing research. It's now called Encora, but anyways, it's a software company. They basically had the rule that any team could fire any team member at any time.

However, if they do it, they then have to go before the whole company, and tell everyone what they did and be transparent about it, answer any questions, criticisms, concerns anyone has, and believe it or not, they haven't had to do it very much. I think they can point to three instances of actually doing this in their last 15 years of existence. They also have this feeling that is both ultimately a very fair way of doing it, and maybe the only right way to do it. That's how they try to account for. The small group of people of bad actors.

You can see many companies creating very convoluted sort of handcuffs for everybody in the organization out of fear that a bad actor or a bad apple will spoil a bunch. These organizations don't have that same fear, or at least they don't have the same response to it. Maybe they still are concerned like one day, somebody could walk in and do something bad, but their approach to managing is it to say everyone is on guard for it. Everyone has the power to see it, call it out, and remove it from the organization.

Jonathan: Nice. It's what I imagine, of course, if I were to fire you unjustly and I go in front of the whole company and explain that, then somebody might fire me. In that case, probably justly, right? [chuckles]

Matt: Totally. Yes, absolutely.

Jonathan: Sort of natural check and balance system. That's good. I want to ask another question, the flip side of this. Later in the book, you talk about different ways of addressing salary. One of the ways that you mentioned some of these companies do salary is by self-assigning salary through the advice system. I remember you saying that in the companies that do this, the average salary increased by 10%, it wasn't outrageous, people weren't doubling their own salaries and stuff like that.

I'm concerned though, in the same way, that we hear that unlimited vacation time often means people take less vacation. Do you have any evidence or reason to think that if we're all given the freedom to accept a salary that we end up working for less than we would otherwise?

Matt: I don't have any evidence to think that, but I do have the same background you do that leads me to ask that question. Absolutely. It's a question you'd have to ask and always want to watch out for. I didn't find any examples of it in these companies that particular thing is going on in fact, to the opposite as you point out. Salaries, in general, tend to go up. The other thing that's going up in these companies at the same time is retention.

People leave jobs for many different reasons and it's complicated, but one reason, everyone that we can always point to is that some people leave job because they don't feel like they're being compensated appropriately. That particular aspect of it seems to be going away in these companies that have moved to a self-managing salary process. The fact that these companies that do it that their salaries are in effect transparent within the organization and that when anyone wants to change their salary, they are telling their peers about it and they're being transparent about it and even soliciting their advice about it.

It is also, I guess, a check and balance against things getting out of control, people taking too much. It does seem universal that salaries go up when companies do this. [chuckles] A conservative estimate is that it costs twice a knowledge worker's annual salary to replace them. That's just the average knowledge worker. It could be even much more expensive to replace somebody that maybe is more integral to an organization. It is important that we be doing things to increase retention because although salaries may have risen by 10% if retention has also gone way up, they're actually saving money in the end.

Jonathan: I can also imagine that when you couple this with a candid vulnerability, if I'm underpaying myself, my colleagues may start to call me out on that and say, "Jonathan, you haven't taken a pay raise in three years, it's time you should consider that." I can imagine a conversation like that happening when people are open and honest with each other. Your book comes out. I don't know, in my mind, it's one in a series of books on similar topics.

I'm thinking of books like Reinventing Organizations, Team of Teams. One I haven't read yet, Corporate Rebels, is along the same vein, I think you mentioned that in your book. For people who have read some of these books, what does this book add to the conversation in your mind? Where does it fit on that landscape of these books about new ways of organizing?

Matt: I think my book offers two things that should hopefully be complementary to this whole genre. One is a focus on technology organizations. I don't look only at technology organizations, I've already mentioned several that aren't purely technology organizations, but there are also many software organizations profiled in this book. I'm also triangulating on technology-specific ways of working that I see coming up in these organizations, which leads me to talk about things like the outcome team paradigm, human-centered design, and some other stuff that you can see being expressed through agile practices, like Scrums, forms of autonomy of practice, and autonomy of allocation, autonomy of schedule.

Anyways that's part of, I think, what you'll get out of my book that will be new if you've already read all the other books in the genre. The other bit too is the imperatives that you can read about in my book that synthesize from these different organizations and see as sort of integral to their success. To my mind, and I'm pretty well-read in this space, it's not anywhere else within the literature. I think it'll add a new dimension to your thinking when it comes to understanding why these organizations succeed and it's multidisciplinary.

I'm pulling together both organizational science, sociology, psychology, and economics to try and explain what stands at the root of their success.

Jonathan: One critique I hear frequently about these types of books, and many other especially books in the business genres more broadly speaking is that they tend to focus only on the successes and maybe you little bit of a selection bias. Now, you've mentioned already in our conversation today that some companies have tried some of these radically collaborative ideas and failed.

What's been your sense, what percentage maybe fail, or maybe you don't have the percentage, but just give us a sense? You've given us a nice profile in the book of the ones that have not failed, that they're succeeding. What's your sense of the other side of that story and what leads to that if you have insights?

Matt: This sort of dovetails with the topic of transformation and what we're seeing succeed and what we're seeing fail with respect to organizations transforming, moving down the spectrum. In some sense, there is at least a very nascent, radically collaborative angle to any sort of agile transformation that you see going on in companies and certainly some more than others. We've seen plenty of those fail which I think is what I mentioned earlier. There are sort of three empirically validated transformation strategies that seem to be succeeding. That's a bottom-up transformation strategy, a top-down plus bottom-up transformation strategy.

For lack of a better word, I'll call it a democratic transformation strategy. There's a number of success stories that we can point to, to say, "Empirically, these strategies seem to work. It probably for these reasons." The one that seems to always fail is the top-down transformation strategy. You can often end up in an organization in which you discover there's some enlightened leader that thinks that for the good of the organization, they're going to transform it. They're trying to create an organization in which people are more empowered, autonomous, self-organizing, self-managing, self-governing, trying to eliminate a hierarchy, domination, and coercion.

They end up going about it in a very hierarchical top-down command and control way. That is such a oxymoron. You can't achieve autonomy by reducing people's autonomy. [chuckles] These two things don't really go together. I think that's what you see in a lot of agile transformations, even if we just take it at that level. You can see a lot of inflicted help, people saying, "This is going to get us there," and telling other people what to do. People just say, "Oh, my boss tells me I got to do this now." Not understanding it, not believing it, not feeling they have any choice in it.

Of course, it fails. The most successful transformations are the ones in which people are doing the transformation work themselves, owning that journey, deciding moment-to-moment and day-to-day. What's the next step they're taking down this path? If you get a bunch of people together and they're all united around the belief that there is a better way of working, collaborating together, one that is based on partnership and equality, not domination and coercion, that we can actually all adult together in a much more reasonable way in which gives us more meaningful fulfillment.

Then, they can actually also take that journey together. You don't have to have somebody come in and tell you what to do at that point. The best thing you can do is leverage the sort of natural success you have when you start making choices because you own them, because you learn from them, because you take the next step, and doing that together as a group. In fact, one of the technology organizations in my book, TIM Group, I tell their transformation story. It really is that story. There wasn't enlightened leader, but he was enlightened enough to know that there would be no point in just dictating the new way of working to everyone.

Instead, he brought everyone together to talk about, "How can we manage this organization together? What's the state of the art of doing that? What's on the cutting edge of that?" They all began to research together. They all took little by little steps together. He just had the authority to support them along the way until he, eventually, created a whole new organizational structure, which devolved many of his own authorities into the organization at large. The organization was more powerful because of it.

I don't know. Those are some of my high-level thoughts on it. I definitely don't have a percentage on how many fail and how many succeed. I do want to say, it's a complex journey. It should not be undertaken lightly. It should definitely be undertaken, but don't go into it with naivety. It takes a lot of work and a lot of diligence to take it step by step. You're not just going to pick one thing and say, "Oh, team autonomy, we got it. We don't need to think about any of these other imperatives." That's not going to work.

Jonathan: Well, that's a great segue into my last series of questions here. The first one is, let me start small. Is it possible for an individual, maybe somebody sitting on a team, and they read that your book and they think this would be great, but nobody else on their team or the company may be knows about it or cares about it? What can they do with that or does it really require a bigger groundswell of support before this transformation can start going? I hope that question makes sense.

Matt: I think it does. Yes, absolutely. What can I do, me, today? I'm still sitting in an organization, I've had the AHA moment. Maybe no one else around me has had that moment. Should I just leave and find someone else that already gets it? Should I try and convince others around me? Well, I do believe that radical collaboration, first and foremost, it's a mindset shift. It is something that is possible for anybody to do at some scale, any moment, every day. They can always treat other people around them with security, autonomy, fairness, esteem, and trust.

There is nothing stopping anyone from doing that at any moment during the day. It doesn't matter how draconian your organization is. They don't control your ability to be a good human being towards other people. At the very least, that is a start that you can make. It really does actually begin to make a difference because, as you begin to model deficiency need gratification and candid vulnerability, you begin to see your relationships change with people. You begin to create spaces for more trust. Now, you can take that a step further.

Just set a team level, maybe you're like, "Outside of this team, I don't think I can accomplish anything right now." In my team, I think there's space for me to say, "Hey, what if we did this meeting that we're about to do in a very collaborative way, instead of just waiting for the boss to come in and tell us all what to do? What if we had an idea together on our own about--? How can we work through this problem ourselves? What stands in our way from achieving success?"

Whatever it is you're trying to accomplish as a team, there's all kinds of great radically collaborative meeting techniques out there. Some of which I just wrote about, it was published on my publisher's blog, which I'll share the link with you afterwards. You can take small little steps like that to begin to create more and more space for radical collaboration. I had to say, based on my own experience, those ways of working are addictive. Once you experience it, you want to experience it again because you get something out of it. You don't just succeed more as a team, you also feel better as a person.

You feel closer to the people around you. You feel like you actually do have-- Maybe you're on a team in which you feel like it's very disharmonious and people are always debating and arguing with each other. When you begin to experience collaboration, you realize that under the surface of that, there is a lot of shared humanity, shared goals, shared interests, shared concerns, even if the ideas that you'll have on the surface appeared very different. Once you discover that common base from which to work from, radical collaboration begins to proceed very naturally and very powerfully because you begin to put your heads together and really do some amazing stuff.

I think that's another great step to take. I really like that TIM Group story I mentioned earlier because it starts with a reading group, which is something a lot of people will probably have the space to do within their own companies, to start a reading group. It doesn't have to be around my book. It could just be around maybe an article that you find on Harvard Business Review or something like that. Let's read some of these things and just start there, which is what they did at TIM Group and they went really long way with that.

Just with that co-exploration together was really inspiring for a lot of people. I think there's space for anyone to take this. At the same time, I don't think if somebody feels like they're in a truly toxic workplace, I would never tell somebody, "Oh, but you have to stick it out. You have to be the hero and you have to transform." I don't think that's the right thing to do. I would never tell somebody to do that. If somebody wants to do that, great, but I'm not saying that. I just want to be clear.

Jonathan: That's a good answer from the standpoint of an individual. From the standpoint of an organization, is there an ideal time in an organization's lifestyle? Let's think of maybe a typical startup. You start pre-funding, and then you build a product, and you hopefully get some VC funding and you're growing rapidly. Is there a particular point along the way where it makes sense to start focusing on this? Is it the very beginning, or do you need a certain critical mass before it makes sense or something else I'm thinking of?

Matt: The earlier, the better. That is my own belief. The longer you go, the more and more you entrenched a hierarchical way of working based on domination and coercion, the more and more damage you do, the more and more opportunities you miss, the more and more productivity you lose as a consequence, as people become more and more disengaged over time, as the hierarchy becomes bigger and bigger, and the bureaucracy behind it becomes slower and slower. So many people walk into enterprises these days and just experience glacial movement within the company.

It feels like nothing is changing at any time. Nothing could change. Everything feels so rigid, so unable to accommodate any change. The earlier, the better. I think regardless, there's no better time than now, I guess, is another way of putting that. Even if you are right down the road and you feel like you have a ton of problems, don't wait any longer. Start today. Don't start big, don't boil the whole ocean at once. You can actually always launch into this. It is possible, I think. I've seen this. I've seen radical collaboration, at least from an experiential standpoint.

Even from an organizational and authority standpoint, I've seen this take fire in organizations you might never expect it like the US military, for instance. I think everyone has this idea that the military would be a very command and control place. I'm sure it often is or is in many places, and yet, I've seen it take off from a software engineering standpoint in the military. I've also read about it taking off in places like the Navy, maybe many of your listeners are familiar with the book, Turn the Ship Around. Well, ultimately, what David Marquet is talking about in that book is radical collaboration.

He's pushing information to authority. That's one of the central tenets in that book. That's also a central tenet behind radical collaboration. Being able to empower people to sense and respond to the situation on the ground at that moment without having to wait and let someone else think for them but being able to put their heads together with the information they have in their hands and make decisions together. That's a very powerful thing. We see it even happening in places like the military. I think it's possible anywhere, don't lose hope.

Jonathan: Great. Supposing that somebody is listening, maybe a solo founder, or maybe imagine that you're starting your own company, as a solo founder, what foundations can you-- When you're by yourself when-- maybe, there's some collaboration you can do, but it doesn't seem intuitive, what groundwork can you start to lay before you make that first hire or you find your co-founder or whatever? Are there things you could be doing already, by yourself to lay the groundwork?

Matt: When you're growing an organization, especially in the very beginning, it's because you can't do it all. You need help. You need a partner. Often, people in the very beginning, they do have, at least in some sense, a partnership mindset but their first hire's like, "Wow, this thing could be really cool, but there's no way I'm going to do it on my own. It's too much. I'm killing myself. Can I find some other cool people to come do this with me?"

One way you can make that succeed is not only having a partnership mindset with those first hires but also being pretty clear about who's deciding what, at any given moment. Maybe you have a role that's related to product strategy, maybe you're hiring somebody else, and you need them to have a role that's related to selling strategy or something like that.

Well, each of those roles are going to be successful to the extent that they have a very clear domain of authority or another way to put that is a very clear autonomous decision-making rights. As someone who's designing product strategy or in a role responsible for it, I get to make decisions about X, Y, and Z. As somebody in charge of sales, you're making decisions about A, B, and C. I can't override your decisions even though I hired you and you can't override my decisions. That's the idea behind autonomous roles that you have something about which you can make a decision about and no one in the organization, whether the CEO or the janitor can say otherwise. That's the clarity you need.

I think you can actually leapfrog a lot of dysfunction that results from ambiguity and many organizations by creating clarity early and often. There's never a bad moment to create more clarity about what success is for a particular role, what it's held to account for, and what its domain of authority is. There's another way in which you can supercharge collaboration from the get-go. When you're hiring your first people in and bringing them in, you can take a collaborative approach to decision-making as opposed to what's known as an adjudicative approach.

Most people in the west are raised to operate within a very adjudicative model, almost like a legal model of decision making in which people are debating ideas and positions as if one is right and the other is wrong or as if they're dichotomous. A collaborative approach steps back from the initial perspectives people have in positions, people have to identify underlying concerns, needs, goals, wants, desires, et cetera and to use that as a basis for generating ideas together, collaborating together on a shared solution mindset, et cetera.

There are many things in an organization, even when an organization has a great deal of clarity on roles in which you still are bringing together a number of people to look at something from many different perspectives, put their heads together, and come out of it with something, say like, "Oh, we're going to do X now and we're going to try it and we're going to learn from it." There's a collaborative way of doing that that is not based on, "Let's all get into a room and yell at each other until somebody wins."

In people's loudest voice wins that's instead based on a much more partnership model and collaborative model of decision making. Anyways, that's something I think people have to get their minds around early on.

Jonathan: Really good advice. My last question which I'm sure doesn't have an answer, but I have to ask it because everybody's thinking it, how long does this transformation take?

Matt: It depends.

[laughter]

I'm thinking now in the book. Of the 13 organizations I profiled, one went through a, let's say, 40-year transformation. They had already been a company for 80 years and they spent the next 40 years slowly evolving and they had a lot of success along the way, too. They didn't have to wait until the end to reap all the benefits. Let me be clear, but they did spend a full 40 years transforming until they really pioneered a whole new way of working. There's also stories in which organizations transformed much faster, but they were smaller.

I can point to one that transformed over the course of about five years, step by step incremental like changed by change until they arrived at a really radically collaborative way of working. I think another way to say that though is, I don't think people should see transformation as an activity or a project which you do, and then once you're done, you get all the benefit.

Transformation in my mind-- Okay, these radically collaborative organizations, I don't think they ever stop transforming because they have devolved decision making and organizational governance and evolution to the point that the organization is always ready to transform as it encounters new situations that the organization as it's currently designed isn't prepared for. I think that's why they're having such great economic success because they didn't see it as an activity that would stop.

They say we're going to get to a state in which we can always adjust, adapt, evolve, and be agile and nimble, not just as teens within an organization, but as an organization as a whole. I would encourage people to think about it that way as well.

Jonathan: Sounds really good. Matt, if people are interested in learning more, of course, they should buy your book. What other resources can you point to us to if this is something we're trying to learn about and in effect in our own organizations?

Matt: Well, as you've already said, my book is one of a number of books on this topic. Corporate Rebels, Humanocracy, The No-Limits Enterprise, reinventing organizations. These are all fantastic books to go out, check out, and explore. Beyond that, oh, the Holacracy book as well about Brian Robertson. That's another great one. Beyond books, the Corporate Rebels website, and their newsletter, I highly recommend subscribing to. You'll just get weekly nuggets that you'll probably eat up as you're into this stuff. I do, I get it every week and love it.

I also started a Slack Community for my book. If you go to my website, mattkparker.com, you'll be able to join the Slack Community. Anybody can join. You don't even have to have bought the book or anything like that, it's meant to be a place for people that are interested in these ideas to be able to come together with others interested in the ideas to share stories, to talk about it, to get advice, et cetera, and to just explore together. If you want to join a small but growing community of people doing that, just go to my website, mattkparker.com.

Jonathan: Great. The book is available in paperback, Kindle, I assume audiobook. Any format is fine. There is no special scratches and sniffs or any features that would diminish the experience in any format. Is that correct?

Matt: That's correct. It's basically all the same content everywhere.

Jonathan: All right. Great. Well, thank you so much for coming on, Matt. It's been an educational, entertaining conversation. I'm really excited to have read your book. I'm glad it's out there. I hope other listeners will get some value from it as well as from this conversation. Anything else you'd like to add before we sign off today?

Matt: Well, first let me say thank you and I hope your listeners got something out of this. I also wanted to say that on my website, I have my email directly there on the website. It’s matt@mattkparker.com. If any hearing this and they just want to ask me something directly without like joining the Slack Community or something like that, feel free, I'm always open and looking forward to talking to people, meeting people, and sharing thoughts.

Jonathan: That's good. Thanks so much. Until next time, everybody.

[music]