#114 - A Radical Enterprise & Radical Collaboration - Matt K. Parker

[00:01:18] Episode Introduction

Henry Suryawirawan: Hello, my friends. Welcome to the Tech Lead Journal podcast, the show where you can learn about technical leadership and excellence from my conversations with great thought leaders in the tech industry. If this is your first time listening to Tech Lead Journal, don’t forget to subscribe and follow the show on your podcast app and on LinkedIn, Twitter and Instagram. And if you’d like to support my journey creating this podcast, subscribe as a patron at techleadjournal.dev/patron.

My guest for today’s episode is Matt K. Parker. Matt is the author of “A Radical Enterprise”. In this episode, Matt started by sharing his views on the underlying causes of the great resignation trend, which includes the dominator hierarchies. Matt then explained in-depth about the four key imperatives mentioned in his book that organizations must practice for establishing radical collaboration, which are team autonomy, managerial devolution, deficiency gratification, and candid vulnerability. Matt also touched on several other interesting concepts, such as how to establish autonomy while minimizing chaos, the concept of a dynamic and contextual leadership, and a few alternatives for structuring the salary and compensation in a devolved organizations.

I enjoyed my conversation with Matt, learning a few radical collaboration practices, which actually have been practiced by a number of growing organizations in the world. Matt’s book even provides more examples on how these organizations thrive with those practices. So for those of you who would like to learn more about these practices, make sure to also check out the book.

And if you find this episode useful, please help share it with your friends and colleagues who can also benefit from listening to this episode. I always appreciate your support in sharing and spreading this podcast and the knowledge to more people. Let’s go to the conversation with Matt after hearing some words from our sponsors.

[00:04:35] Introduction

Henry Suryawirawan: Hello, everyone. Welcome back to a new episode of the Tech Lead Journal podcast. Today, I have with me a guest named Matt K. Parker. He’s the author of a book titled “A Radical Enterprise: Pioneering the Future of High-Performing Organizations”. It is one of the books published by IT Revolution. So if you follow the DevOps world, IT Revolution is one of the top publishers, I would say, publishing all these cool DevOps books. Today, I’m really looking forward for this conversation because the topic sounds really radical for me, because I come from traditional background. So we’ll be talking a lot about radical collaboration. So Matt, I’m really looking forward for this conversation. Thank you for your time.

Matt K. Parker: Yeah, thanks for having me. I’m excited to be here.

[00:05:14] Career Journey

Henry Suryawirawan: So Matt, I always love to start my conversation by asking the guests first to tell us more about yourself. Maybe your career highlights or turning points.

Matt K. Parker: Yeah. Well, I maybe am sort of among a rare group of people who have ancestors who were programmers. My dad was a programmer. And my dad’s dad was a programmer. Sort of among some of the first in the late fifties, early sixties. So I sort of just grew up as part of this lineage of programming and was interested in it from a young age. Although I didn’t really start programming in earnest until I was in like the ninth grade or something. It was part of my world growing up and hearing all kinds of funny stories, especially from my grandpa, about what it was like to carry a big stack of punch cards to the operator and accidentally drop them along the way, or to hand your cards to the operator and then have it all run overnight and come back the next day, and for the operator to tell you your program doesn’t work. And that’s the end of it. They just tell you it doesn’t work. Like that’s your debug statement. So, I just sort of had this image of how fun and wild programming was going to be. And, of course, I got into it as well and I studied it in college as well and got a job.

My actual experience of programming in industry didn’t quite match the, I think, idealistic image I had of it. Cause I think my dad and my grandpa, they mostly told me about the good stuff, but I didn’t have a very good sense of the bad stuff. And so, I quickly discovered that our industry can be a real pressure cooker. You can be in very high-stress situations building software in which you’re given very unreasonable deadlines or in which you’re told so much about what to do and how to do it, that you feel like you have no creativity left in how you approach it or anything. I was on projects where we would slog away at it for over a year only to see it scrapped and never see the light of day. So experiences like that really caused me to question, should I even stay in this industry? I think the one sort of thing that kept me sane for a while was doing open source programming in my own time on the nights and weekends.

Luckily, there was a company called Pivotal Labs that ran across some of my open source work and invited me in for an interview. This was in 2011. I had used Pivotal Tracker on some side projects. So I had this very sort of vague understanding of what Pivotal Labs might be. And I thought their Tracker project was really cool, and I enjoyed using it. But I didn’t exactly quite understand it. However, one of my coworkers who I confided in, I said, “Oh, I think I’m going to go do an interview over there.” He grabbed me and he said, “Don’t do it. Don’t you know they pair program? It’s insane. You have to share a computer with another programmer. It’s like the worst thing in the world. I don’t know why anyone does it. Don’t do it. Don’t even bother.” I was miserable though at the time, in my current job, so I thought I had nothing to lose and I tried it and it turns out I really loved it.

My very first experiences there were just so eye-opening and it really gave me the belief that programming and building software could be a truly joyful experience, a creative experience. One in which we got to use sort of all of our brain power both as individuals and as collectives. In which we could be really innovative and try stuff even though it might fail and take risks. All of that sort of came back to me and it reminded me of my first experiences with programming. The excitement of starting with a blank screen and having so much possibility. And so, I stayed at Labs for the next decade. For the rest of that decade anyway, and I think it was a life-changing experience. It’s where I got to experience what I now call radical collaboration, which, by the way, isn’t my term. It’s sort of a term you can see floating around in academia and literature and in industry. But, the first real experience I’ve had of being on autonomous self-organizing teams that are sort of empowered to achieve an outcome and experiencing sort of the power of aligned autonomy within an organization.

So, after doing that for many, many years, I began to wonder. What makes this experience so good? You know, I knew it from an experiential standpoint, but not necessarily from an intellectual or theoretical standpoint. And so, I began to do some research and look around and discover that not only are there plenty of other companies doing this kind of thing, but they’re doing it outside of software as well. Like, it’s not just a thing that you can find in the world of software. You can find it in manufacturing and research and development and hospitality and healthcare. Like, it’s not unique. Although it can look and take many different forms and many different industries around the world, I think the underlying sort of spirit of it is there in all these sorts of different manifestations.

So I ended up writing a book about all of that. It is not the first book in the world about sort of this growing field of radically collaborative companies, but it is one of the first books out there that ties what we’re seeing out there in industry with what we’re seeing in the world of software together. Most of the books out there don’t really look much at software companies. So, that was part of my contribution to it. And I also just tried to step back from all of it and say, what makes these successful? And we can talk about it, but I eventually arrived at these four imperatives of radical collaboration.

So, yeah. So that’s sort of my journey in a nutshell.

Henry Suryawirawan: Thanks for sharing your journey. I could relate to some of your experience, actually. So I’ve been in a project, you know, spanned maybe about a year, and then it got scraped, and even they changed the team to an offshore. I also moved to ThoughtWorks, so I could really relate to the experience of really changing radically the way you work. I think it’s really interesting. And the way your journey afterwards, right? You tried to summarize what really happened when you spent your time in Pivotal Labs.

[00:10:51] Great Resignation

Henry Suryawirawan: Before we actually go into your four imperatives, which I find really radical. You started the book by talking about great resignation and how it relates to why this radical collaboration is important these days. So can you tell us about this great resignation? Why you actually started the book by talking about that? What kind of problems and relationship between them that you can probably relate to the radical collaboration?

Matt K. Parker: Yeah. So when I wrote the manuscript that turned into the book, it was sort of at the height of the pandemic. The final few months before we had any vaccines out or any available. But there was this also emerging phenomenon. People quitting their jobs. And I think if you peel back the layers on why that happened, you can see something that probably could have easily been predicted because it’s something that had built up and just finally came to a head during the pandemic. And it’s sort of these two parallel movements.

There is, on the one hand, over the past, let’s say half century, there’s been sort of these long-term longitudinal studies looking at disengagement at work, mistrust in the world, and a desire for meaning and a complete lack of meaning as well in the world of work. So, if you look at, for instance, disengagement. It’s been growing and growing for decades. In the book, I quote, I think the 2018 study, which was at like 84% and now it’s at like 86%. So 86% of workers today feel disengaged from their jobs. And that’s anywhere from passive disengagement, just like, “Whatever. I’ll get through the day”, to active disengagement, which is much more toxic, right? I think we’ve probably all experienced people that can have a very toxic effect on the workplace and destructive effect. So disengagement is a real problem, and it’s been growing for decades.

Mistrust is a real problem. It’s true in the world of work and in the world of society, government, institutions, etc. Just more and more people mistrust so many of the foundations of the way our world works today. In the world of work, this includes like I think it’s around 56% of people mistrust their CEO. Don’t believe their CEO has their best interests at heart. Don’t believe their CEO tells the truth. It’s a pretty startling number.

And lastly, meaninglessness. A lot of people have increasingly found that they have an expectation that they should have some sort of meaning and purpose through their work. The reality is most people feel like they’re not getting it here in America. 9 out of 10 people would be willing to give up 23% of their future lifetime earnings just to have more meaning in their job. To have a meaningful work experience. One in which they derive a sense of purpose and fulfillment from it. By the way, that’s more than most people will spend on housing in their lifetime. So, there’s this realization that meaning, the sort of global realization and awareness and awakening to the fact that we are, as human beings, meaning seeking beings, meaning is important to us. Fulfillment, purpose, etc.

So all of these things really came together in the great resignation. And I think it was a great way to start the book because it sort of speaks to something that we can all see and experience and read about happening around the world. But it touches on all these themes that also are part of explaining why radically collaborative companies are growing in the world. So companies that have really issued dominator hierarchies, companies that have a non-hierarchical structure, companies that make autonomy and self-organizations sort of first class organizing principles within the company. Why this type of company is growing around the world? Just over the last decade, they’ve more than doubled in number and currently are comprising somewhere between 7% and 8% of companies around the world. So that’s, important to understand too and I think it’s part and parcel of this trend that we’ve seen over the last several decades in this sort of emergence of a phenomenon like the Great Resignation. It’s all tied together.

Henry Suryawirawan: Wow. Those are pretty staggering statistics that you quoted just now. So the three things that you mentioned just now: disengagements, mistrust, and meaninglessness. So I think it was probably much more prominent in the western world. In Asian, we do see some of this great resignation trend, although it’s not as severe in the Western or US. But I think everyone during the pandemic felt something. Maybe enlightened or something throughout these hard times, I guess, where they could see probably the work is less meaningful than maybe the other parts of their lives. So I think, yeah, this is actually a trend that I feel myself as well, in my daily life. During pandemic, everyone works from home. And you try to question, okay, does this work actually worth it? You spend so much time to actually work, but then you didn’t spend much time on the other stuff.

[00:15:26] Dominator Hierarchies

Henry Suryawirawan: And you mentioned this thing about dominator hierarchies, right? So it could be one of the reasons why people are disengaged, people has a lot of mistrust and less meaning in their work. So can you tell us more? What is this dominant hierarchies? Maybe for those listeners who haven’t read your book.

Matt K. Parker: Yeah, totally. So the term hierarchy itself can be used in many different contexts. And some of those contexts we wouldn’t think it’s positive or negative or it’s just a description, right? Like you can think about like a taxonomy of animals. They’re organized in a hierarchy and how we break things down. So that’s one way to think about hierarchy.

There’s a very specific type of hierarchy, though, that we can see in many organizations around the world that’s referred to in sociology as a dominator hierarchy. That’s definitely meant in a much more pejorative sense. And what we’re really looking at is a hierarchy in which privilege, power, resources are sort of unevenly distributed and concentrated at the top. So it’s the way of putting together an organization based on ranking in which the higher you are in the ranks, the more powers of coercion you have over people beneath you. It’s part and parcel of sort of a misunderstanding of human behavior that flourished in the early 20th century called behaviorism. It was, basically, pioneered by scientists like BF Skinner. As it’s turned out, it’s been just debunked in so many different ways that human behavior is much more complex than the behaviorist lens.

At the outset of the 20th century, basically, the idea was that human behavior boiled down to carrots and sticks. People will be incentivized by carrots and dis-incentivized by sticks. And the only reason people would work and produce and perform at high levels is through some combination, some careful sort of scientific management of those carrots and sticks on your workforce. That’s had a lot of disastrous effects. It was first pioneered in the field of manufacturing. But it was very quickly taken into knowledge work fields, like software development. And it just turns out that organizing work that way turns out to be growth inhibiting. It reduces people’s motivation, intrinsic motivation, I mean. It reduces the sense of passion, meaning, fulfillment that they get from their work. It reduces their sense of autonomy. Even if you just look at autonomy itself, that alone can account for so much success. The more meaningful decisions people get to make in pursuit of an outcome, the more likely they are to succeed at the outcome. The more you take away their ability to actually make meaningful choices in pursuit of an outcome, the less likely they are to care about the success of the outcome. So, yeah, there’s just all this sort of fascinating stuff that comes together around this.

So dominator hierarchies themselves are just a manifestation of a misunderstanding of human behavior that I think is slowly being corrected. The industry, the business world, it always is lagging behind the science world. The psychological sort of understanding of human beings, sociological understanding of human beings. And so, I think today we’re just seeing the world of business start to catch up to insights that were gained 50 years ago in the world of science.

Henry Suryawirawan: So when you mention about this, of course, like for many of us, we could relate because this is like common practice in many companies, traditional or just normal companies. And I think some people refer to it like command-and-control, bureaucracy, and Taylorism. I think the situation in which you have some kind of ranking and a power as the higher you are, the more power that you have, and thus you think that you can control the people below you. So I think that also is probably one of the reasons why people are disengaged. Especially if the bosses or the managers are not considered a good boss, right? So people might have different opinions, but they just do whatever they’re told. And I think that’s probably one of the source of this disengagement, mistrust, and meaninglessness.

[00:19:12] 4 Imperatives

Henry Suryawirawan: Which brings us to your radical collaboration concept. So you mentioned about four imperatives. Maybe you can briefly mention what are the four imperatives? And maybe we can dive deep into each of them afterwards.

Matt K. Parker: Yeah, totally. So just at a high level, there are these sorts of four pillars. In the book, what I’m doing is looking a lot at case studies at different companies. Like Haier in manufacturing and W. L. Gore, or companies like Buurtzorg, or all these different companies and all these different industries and a number of software companies too, like Nearsoft Encora, CivicActions, etc. What I’m trying to do though is not only tell their stories, which we can learn a lot from in and of themselves, but pull back the curtain on why are these companies succeeding? And when I did that, four things really stood out to me.

The first was in all of these companies, team autonomy seems to play a really central role. Whether it’s micro enterprises at Haier, right? They took their company of 80,000 people and broke it up into thousands and thousands of micro enterprise. Each of which are autonomous and self-organizing. Each of which develop their own profit-sharing schemes. Each of which is starting their own product on the market. That’s a manifestation of team autonomy and the powers of it, and I believe in the powers of it. And so you see that sort of in all these different companies. They all have embraced this idea that there is a lot of power to having autonomous groups of people within the company being able to self-organize, cooperate, and sometimes even compete against each other. And that actually turns out to be a more powerful way to organize a company than to divide it into some kind of elaborate command-and-control structure in which everything is controlled at the top. As if somebody at the top could be all seeing and all knowing. So, yeah. I think that stood out to me.

The next thing that stood out to me was what’s called managerial devolution. Devolution is a technical term for the decentralization of power. So when you take sort of power out of the hands of a static dominator hierarchy and you disperse it into the hands of sort of the self-organizing hierarchy of teams, it’s a process that’s called managerial devolution. That was clear in all these radically collaborative companies that they were all engaged to some level in that sort of process. There’re many different ways it manifested in these companies. So it’s not just one thing. But there are elements of it in all of these companies. In all these companies, it also seemed to be an ongoing evolution as well, which I found fascinating.

By the way, one thing I’ll say just before I move on to the next imperative is that many people, the first sort of fear they have when you say, “Well, it’s a non-hierarchical organization”, their assumption is that it must be either chaos, like anything goes chaos or it must be death by consensus. “Oh, they must not get anything done because they won’t be able to do anything unless everyone agrees”. What’s fascinating is these companies are highly structured, yet non-hierarchical, so they’re not chaotic. But none of them, except among very small groups of two or three, for instance, none of them relied on consensus. They all had ways of making decisions that did not require everyone to agree. So I find all that quite fascinating.

The third imperative is all about human needs. So it’s called deficiency gratification, which is really a technical term borrowed from the field of psychology. Really, quite simply, it’s just about the fact that humans are different from other animals. We have psychological needs. We need security, autonomy, fairness, esteem, trust, respect, meaning, fulfillment, purpose, etc. All of these things are things that human needs to really thrive to be able to grow, to be able to take risks, etc. And these companies have seemed to figure that out. They’ve said like, “Actually, we will be better as a company if we create environments that are rich and meet satisfaction. If we are creating environments in which people derive security, autonomy, fairness, etc, from it, they will be much more likely to perform at very high levels, to take risks, to trust each other. That ends up having a very multiplicative effect on performance.

I mean, trust alone, one of the many different human needs. For instance, high trust workplace environments lead to 32 times the amount of positive risk taking. So teams trying something, even though it might fail, and if it fails, learning from it and trying again. That’s an example of positive risk taking. So it leads to 32 times the amount of positive risk taking, which then leads to 11 times the amount of innovation and 6 times the amount of economic performance at the end of the day. So creating these sorts of environments rich in human needs turns out to be a great way to supercharge your organization.

The last imperative really is all about showing up and being able to say things to each other even though it’s uncomfortable and even though it’s scary. So it’s called candid vulnerability. The ability to be candid, which is saying what you believe and what you think we should do, but the ability to be vulnerable. Not only saying what you think should be done but also saying why you think it. I think a lot of us, myself included, are really good at being candid. I’m never afraid to tell people what I think. I am afraid to tell people why I think it, because if I tell people why I think it, if I show them the hidden chain of inferences, assumptions, biases, beliefs, etc, behind what I think, it’s likely to be invalidated, right? They’re likely to be like, “Well, what about X?” And I’ll be like, “Oh, crap. You’re right. I am wrong about something. Oh, and now I had to rethink it.” So being vulnerable can be pretty scary for most of us. These organizations recognize, though, that if you create environments in which people are not just candid but vulnerable, you supercharge collective critical thinking, collective innovation. You get teams to recognize problems much faster, errors in their approach much faster, and to correct for them much faster. That being said, it’s not easy. And so they’ve all sort of realized that to get there, they have to actually practice it. And so, you know, in the book, I show some stories of some things that they do to actually try to practice candid vulnerability.

So anyway, those are the four imperatives in a nutshell. And it seems like if you want to really succeed at stepping out of a dominator hierarchy into some sort of radically collaborative configuration or just even moving down that path, which, by the way, isn’t one thing, right? It’s a whole spectrum, and there’s just all kinds of room to move down it. But if you actually want to take steps towards it, I think you’re going to have to consider and, at some point, really embrace, in some way shape or form, all four of those imperatives. It doesn’t seem like success is possible without them.

Henry Suryawirawan: So those things that you mentioned, I think there are many studies already mentioned about this, but putting them together, as kind of like characteristics or traits that an organization should think about, like merging them together, I think it’s really exciting. So you mentioned about autonomy. You mentioned about the human needs, psychological needs, and being vulnerable. So I think there are many researchers, authors who are talking these different concepts in a parallel, right? But I think putting it together, putting as a one giant characteristics of a radical enterprise, I think it’s something that I want to dive deeper in the next conversation.

[00:26:14] Imperative 1: Team Autonomy

Henry Suryawirawan: Let’s start with team autonomy. Many people have talked about autonomous teams, self-organizing team, and you mentioned about intrinsic motivation. So tell us more. How can we become more autonomous? There are these six core dimensions that you mentioned about being autonomous. So maybe can start from there. Like how can a team become more autonomous?

Matt K. Parker: Yeah. So there’s all these different ways in which autonomy can manifest. In some organizations, all six were present and some subset of them were. But it’s really about autonomy and how we work. What are the actual practices we’re using as a team? So if you think about a software team. Are we pairing? Are we doing TDD? Are we doing continuous integration continuous deployment? What are we doing as a team day over day, week over week? What are the practices we agree on?

Autonomy of practice really is all about the how. Actually, in all of the organizations that I profile in the book, autonomy of practice was common to all of them. It sort of seemed like table stakes form of autonomy, that if you don’t give the team any say over how they work together and what practices they use, you don’t actually achieve fundamental engagement. That doesn’t mean some of these organizations didn’t have significant alignment on practices. Like in some of them, there was just a sense that all teams do a certain number of things, and that’s just part of who we are in our culture. But outside of that, we’re always experimenting and trying stuff. But in other organizations, there was no common set of practices. It was literally like the teams are up to figuring that out themselves, figuring out what work with each other.

Another way autonomy manifested was sort of autonomy of schedule. Are we co-located or are we distributed? Are we synchronous or are we asynchronous? Like, you could imagine that you put different groups of people together, different individuals together with different life circumstances, maybe different locations around the world, right? You’re probably going to end up with different teams gravitating towards different modalities. Some are going to want to be co-located cause they’re all in the same city together and it’s a lot of fun to work together in person. Others are going to want to be or even have to be distributed because they’re not all together. Others are going to want to be synchronous. We all agree that we start work at 9:00 AM and end at 5:00 PM, and others are going to say, “No, let’s be asynchronous. Let’s let the night owls be night owls and the larks be larks”. Whatever makes sense for us, we can do that. I think in our industry you can run into a lot of evangelists for one way, one specific way. Like you must be co-located. You must pair program in person. You must blah, blah, blah. If you step back and really start investigating all these different companies, you can see that there are lots of teams succeeding with wildly different modalities of presence, of synchronicity, etc. So yeah, that was pretty eye-opening to me.

Also, there’re things like autonomy of role. So maybe you go join a team. What role do you play on that team? Are you the product manager? Are you doing engineering? Are you focused more on data science? Are you doing some amount of design and user research? I think that is something that a lot of these organizations take seriously, that we shouldn’t shoehorn people into doing one thing and one thing only. If people have a serious interest in moving into other disciplines or developing and expanding their skill sets to be multidisciplinary, then we should like honor that and make that happen. Because when people feel like they’re doing things that are meaningful to them, and that progress their career, they’re more likely to stay. They’re more likely to be able to do more and more things within the organization and for the organization. So it’s a win-win in many ways.

Anyway, so there’s just this sort of rich world of autonomy at the team level that is expressed in all these different companies. It was eye opening to me. Now, despite all of this sort of differentiation in autonomy, there were some very clear trends that stood out at the team level in the world of software companies that I profile in my book.

One is that almost all of these companies gravitated towards something called the outcome team paradigm, which I think makes a lot of sense given where these companies are coming from. The outcome team paradigm is, the team is aligned around achieving a specific outcome. Say, you’re some kind of e-commerce company. Then you might put together a team whose outcome is increasing shopping cart conversion. Our entire reason for being is getting shopping cart conversion increased by 500 basis points or something. So they set out to figure out how do we do that? No one tells the team how to do it. Because no one other than the team is going to be an expert in figuring it out. The organization itself said this is an outcome that’s important to us. We need to put together a team that focuses on this outcome.

So, the interesting thing about outcome teams is that they tend to be radically decoupled from specific code bases. So, unlike in a traditional organization, which typically is modeled around something called a component team paradigm in which teams are tightly wedded to controlling specific code bases, but not others. Therefore, if something needs to happen in that code base, you have to go to that team and convince them to do it and beg and plead to get on their backlog. That’s the typical approach. In an outcome team organization, teams increasingly are decoupled from specific code bases. Meaning that to deliver on that outcome, say of increasing shopping cart conversion, they might contribute to all kinds of different code bases in the company that they didn’t create and they don’t normally maintain or steward. And so, it’s really embracing that sort of open source spirit of which any developer can come along to an open source project and make a contribution to it that could be really meaningful and important to the project itself. It’s taking that same spirit and bringing within the company.

The other sort of clear trend that I saw in all these companies was an emphasis on human centered design. The idea that we make great software not only by making software that is for users, but involving users in this process in a non-trivial way. The smallest, the lowest level of human-centered design is probably we build something and put it in the hands of users and very quickly get feedback from them. Even higher levels is that these user bases become more and more ingrained in some way in that development process, in which we’re sort of thinking together about the evolution of the product. Yeah. So anyway, that’s team autonomy.

[00:32:25] Autonomy Without Chaos

Henry Suryawirawan: There are so many insights there, team autonomy. For people who came from traditional background, I’m certain that some of the questions will pop up. Like you mentioned in the beginning, how do you maintain sanity among different team members so that it doesn’t become a total chaos? Because by having an autonomous team, it is assumed that they’re just given a problem, but they will go solve it. But how can they align? Align with the company’s objectives, align with the other teams. Are there sort of like probably cultural things or principles that must be there so that they are all aligned? So how do you maintain autonomous without being insane in terms of chaos?

Matt K. Parker: Yeah. There’s two fundamental flavors that I’ve seen that address, sort of, how do you make this not chaotic. And I think both are quite fascinating. So the first flavor, I’ll call the free market flavor. And you can see it in companies like Haier and W. L. Gore. In those companies, anyone in the company can basically say, “Here’s a thing I think we should go after and I’m going to start a team to do it.” And then other people could say, I want to create a team that supports your team or creates a platform for your team, or is part of this team’s ecosystem.

Companies like Haier have looked at sort of the power of the free market in the world to really supercharge economic growth, innovation, etc, in which these sorts of autonomous agents are freely either collaborating or competing against each other. And they said, could that work within our company? What if our company was structured sort of like a free market? What if anybody in our company could start a new product or service within our existing ecosystem? What would that do and how would that work? Could we use sort of the same pressures that you see in the free market? Economic pressures that cause things to fail or cause things to succeed? Could we bring those same market-based dynamics within the company? Zappos is another company that’s gravitated towards this, that’s gone through a whole journey of radical collaboration and today has embraced something that they call market based dynamics. But in reality, it looks a lot like micro enterprises at Haier because it’s based on the same sort of mirroring of free market ideas within a company.

So that’s one way in which chaos gets managed. It gets managed through a sort of set of economic pressures and abilities that cause some things to thrive and other things to clearly fail and stop. You can contrast with other companies that, for instance, are creating a very specific product. Like they have something very specific that they are trying to do. Just imagine, sort of like a retail organization. Retail company has a very specific thing. Maybe they’re a clothes company and so they sell clothes and they have stores. The name of the game is, really, how do we make that business more and more successful? How do we optimize it? How do we solve problems in it? How do we get the right products to the right people at the right time? How do we upsell? All that kind of stuff. But in reality, if you’re in that business, you’ll quickly discover, wow, there’s almost like an infinite number of things that we could try to make our business better, to expand our business, to grow our business, to shore it up, whatever. But we have a finite number of people, a finite number of money. And so, if you were trying to be a radically collaborative organization, but you have a very specific product you’re building, you are going to run into the prioritization challenge, right? We have to, as a company, prioritize from the infinite number of things that we could possibly do down to a very specific number of things that we think are the most important things to do.

So instead of using market-based dynamics, what I find is that most companies that have a very specific product use spheres of support, spheres of domain of authority. Within these companies, you’ll have autonomous teams trying to achieve outcomes. But where do those outcomes come from? Well, they come from people outside the teams that are looking across a portfolio. A business portfolio of ideas, of possibilities, of challenges, of tensions, opportunities. And they’re saying, okay, of this entire mix of ideas, which of these things are quickest to execute on and highest value, for instance? Okay, let’s prioritize those things. That means we went from 800 different things that we could do in this side of the business down to 80. And now, I’m going to align each of those 80 outcomes to these 80 different teams or something. That idea, it’s really about how do we prioritize in the company in a very fractal way.

Teams themselves are constantly prioritizing day over day in pursuit of an outcome. They’re saying, “What’s the next most important thing we could do to try and achieve our outcome of increasing shopping cart conversion or whatever it is.” And then, outside of that, you have fractal prioritization happening. Of all the things we could be doing in the side of the business, what are the smaller number of things that feel most important to do right now? At higher and higher levels, you would have different versions of that happening. So that’s the two sorts of ways that I’ve seen, anyway, in which the chaos is being managed.

[00:37:15] Imperative 2: Managerial Devolution

Henry Suryawirawan: Very exciting concept. So I’m more used to the second one, not the first one, where you have free markets. I think it will be very interesting if I’ve experienced that. But, let’s say, you have outcome based, maybe decided by a certain kind of like committee or something like that, or board of directors, and you give it to specific teams. So let’s go to the second imperative where you mentioned about managerial devolution, in which that probably you don’t have hierarchies within the team. The normal practice that happens in many organizations is that, yeah, we have outcome, maybe it’s related to OKR, team or companies OKR, and you assign to a team, but you assign it to a manager for them to run it. Now you mentioned about this second imperative where we probably don’t need a manager. So maybe tell us more why having a manager is not good in this sense?

Matt K. Parker: If you put a manager on a team who has hire-and-fire and compensation power over the people on the team, and that manager is also charged with delivering an outcome and making sure the team delivers an outcome, you actually create a perverse incentive. The team is dis-incentivized from telling the manager what they think if they fear that what they think is not what the manager thinks, if the manager disagrees. You end up just creating this world in which a manager, even if they didn’t want it, ends up with this weird coercive power over people on the team that gets the team to do what the manager wants, and not necessarily what is the best thing to do, the right thing to do. It inhibits the ability for the team to think critically, openly, transparently, and safely to take risk, to try things.

And so, that’s primarily the reason why they’ve assumed line managers within these companies and said, okay, what if we design roles in such a way that it’s very clear what a role gets to make decisions about, but we don’t include within these domains of authority, course of powers over others? So if you think about a sort of classic extreme programming team. You would have product manager, product designer, a number of engineers. What’s amazing about that is that this team can move very quickly with very clear domains of authority about each of those three roles, and without requiring just consensus for everything.

So the product manager on the team has a very clear domain of authority over the backlog. They get to decide what is the priority of user stories in the backlog. Everyone on the team can give their thoughts and advice, but at the end of the day, you all know the product manager decides it. They decide which is the next most important story at the top of the backlog, and you as the engineer honor it. You as the engineers, you pick up the next priority story on the top of the backlog. Designers have a domain of authority over the user experience. So they may not get to write the user story themselves, but they get to say, what is the experience expressed in that story? How does this actually play out for the user from an experiential standpoint? That’s their domain of authority. And again, everyone on the team can give the designers advice and thoughts, but the designers have to make the call. A pair of engineers on the team has domain of authority over their code base. Everyone on the team has commit rights to main or master or trunk or whatever the team calls it, and they all have the ability to push code directly onto that branch and to deploy it. That’s their domain of authority.

Actually, it turns out to be a really powerful way to help teams embrace an experimental mindset, to trust each other, to make decisions and to move forward with things. Even if not everyone’s sure it’s going to work out. Because, even if it doesn’t work out, you as a team are going to be open about it not working out, and you’re going to try something different next time. No one has to believe that they have to be a hundred percent right before you do anything. So you can see that there’s a real power in that approach. And if you take those same sort of principles. Creating roles that have very clear goals and very clear domains of authority, and you begin to apply it throughout the company, you can end up with all these sorts of spheres of support around these frontline teams that are creating value for the company. So, again, outside of the teams themselves, you may have a role called like portfolio manager or something whose job it is to look across the portfolio of ideas, challenges, opportunities, insights, etc, and to say, “Let’s focus on these outcomes and not these.” Okay, so I’ve now got six outcomes and I’m going to give it to six teams, and that’s how you create aligned autonomy.

The concept of aligned autonomy is so important, because the way you keep the organization from going off the rails is to make sure everyone is aligned around what outcome are we trying to achieve, but in which the teams going about achieving it have complete autonomy in how they get there, to make meaningful decisions in how they get there. That’s at the end of the day, I think, where managerial devolution really takes off, at least in the world of these software companies.

[00:41:46] Dynamic & Contextual Leadership

Henry Suryawirawan: Yeah. When you mention about this concept, the team is given the “what”, right? The “what” is the outcome that they have to achieve. But the “how” is independent. So they are free to try different methods, different strategies to achieve that “what” outcome. So I think that’s a very fascinating concept for some of us who came from traditional background. In this concept, managerial devolution, you have this one thing that I pick up really interesting as well. You mentioned that leadership is dynamic and contextual. Which means that anyone can be a leader at any point in time, depending on the situation, depending on the trust from the peers and things like that. So tell us more about this concept. Why leadership can be dynamic and contextual?

Matt K. Parker: Okay. Well, I think it’s funny that this doesn’t seem intuitive to most of us in the world of business, because dynamic, contextual, emergent leadership is what we see every day over day out in the world, outside of our corporate office. Imagine, say, there was some kind of natural disaster in your neighborhood. A dam broke, and it flooded. People have homes and flooding and stuff going on. What happens in that situation? Dynamic contextual leadership tends to emerge, right? Some people will step up and start to organize activities. Okay, we’re going to do this and we’re going to do that. We’re going to put sandbags over here to try and get the water to stop flooding in this area. Whatever it is.

Leadership is granted by the trust of peers. It’s not like this person suddenly is anointed as the leader once and for all of other people who get to tell everyone what to do, and, actually, just emerge in a situation. And in that situation, some people followed, other people took the lead, and they trusted each other and they actually collaborated in that way. That’s really dynamic contextual leadership. I think these companies recognize that the leadership in most traditional organizations is sort of a joke. It’s sort of like an illusion. Just because such-and-such person has a certain title doesn’t mean that they have the best idea in every situation. It doesn’t mean that everyone should always follow them. That’s sort of the spirit that they’re embracing within these companies.

Now, what’s amazing too is that these companies, I think, do a much better job and create much more clarity around roles within the company. It’s sort of almost like this paradoxical situation in which these radically collaborative companies have created a great deal of clarity around who gets to decide what. And yet the same time, are completely open to, in any given situation, following someone’s lead. Even though on paper their roles don’t say they get to play that role, or take that lead. And I think all of that goes back to trust. These companies have created a great deal of emphasis on creating high trust environments. When trust is in the room, anything becomes possible. Groups can do amazing things so long as they’re doing it on a basis of mutual trust and respect.

[00:44:30] Salary & Compensation

Henry Suryawirawan: Mutual trust, respect, and equality. I think you mentioned all these characteristics. The other thing that I find really fascinating. I think for some people, this might be even totally radical, right? You mentioned in the beginning if the manager has the power to decide the compensation, the salary, or the pay, I think that can give a perverse incentive. In this concept, managerial devolution, you have a few radical thoughts of how people should be compensated. So tell us more about this part. Because at the end of the day, we work for some salary or some compensation. So how does a radical team actually get to decide their compensation?

Matt K. Parker: Yeah. Well, these aren’t so much my thoughts on how it should be done, but sort of my observation of how it is being done in these companies. Like Haier, for instance, one day laid off 12,000 managers when they said, this is not how we’re going to work anymore. It’s not how we’re going to decide compensation and performance, etc, etc, etc. Okay, well then, what did you do? Instead, if you don’t have a bunch of managers going around deciding you get this and you get this, and you get put on a PIP, and you get a raise and you get a bonus. If that’s not what’s going on, then what is going on? Well, it turns out there’s just quite a few different ways that things like compensation are happening within the company, within these radically collaborative companies.

One approach is pioneered by the company W. L. Gore, and you can also see it in a company like Morningstar. It’s the idea of peer-based compensation decision making. So instead of a boss coming along and deciding what you make, your peers decide what you make, just like you decide what they make. And so, you have these peer committees that are doing, basically, compensation adjustments for each other. That’s one approach.

Another approach is called the sort of self-management of salary. So self-managing compensation. It is as it sounds, where everyone decides on their own salary and everyone revisits it whenever they want. It’s typically combined with a transparency around it, though, where no one’s salary is a secret, and if anyone changes their salary, that’s also not a secret. And in third, it’s also typically combined with something I haven’t talked about called the advice process, in which any decision that gets made within the company must first be solicited advice from the people who would be impacted by that decision. So anyway, those three things come together.

Another approach is called fractal compensation. And so you can see this in companies that are using market-based dynamics, typically. Like Haier or like Matt Black Systems, another company I showed in the book. Fractal compensation and its most sort of crystallized form basically devolves the company into a world in which everyone within the company is a virtual company of one. It’s almost like everyone in the company becomes a one person business with their own profit-and-loss statement, their own balance sheet, in which their pay is a derivative of those things. And so, in Matt Black Systems, for instance, a manufacturing organization, that’s how far they went with it. The sort of combination of activities throughout a supply chain in their manufacturing organizations becomes manifested in the profit-and-loss statements and balance sheets of everyone within that supply chain.

So there’re other versions of that, actually. Don’t go down to the individual level, but stay at the team level, which you can see, for instance, at Haier, where every team develops their own profit-sharing scheme. If they start their own business, their own product or service on their own internal market, they also start by deciding on what is the profit sharing mechanism behind their work. Which means they are carrying around things like P&Ls and balance sheets as well to figure out how much profit they’re actually making, and therefore, how much money each of them makes as they develop this product or service within their internal market. So that’s another way compensation is happening.

In all of this, I think the question often comes to, okay, what do you do about bad actors? What do you do about people that need to be fired? If there aren’t managers running around saying, “You’re fired!”, then how do you get rid of bad people? This is sometimes also referred to as like the sociopath problem. You have a great organization, but you accidentally let a sociopath into your midst. What do you do? How do you get them out? And there’s no one answer here, right? One of the companies NearSoft Encora that I profiled in the book devolved hiring and firing power down to the team level. So teams themselves could come together, like, say, somebody on the team is constantly shirking their duties, not performing, not being responsible, not showing up to work, etc. The team could get together in that person’s absence and say, “We agree. By consensus, we are firing this person”. And if they did it, that person would be fired. And then that team would go before the entire company to say what they did and why they did it. Keep in mind. Now that they’re going before the entire company and saying what they’re doing and why they’re doing it, other people could get together and fire them. So there’s a real check and balance of power in that scenario. You can’t just fire with impunity because remember, other people could come after you as well. So it’s something they do with, I think, a great deal of thoughtfulness and consideration.

That’s not the only approach either, right? Like in a world in which you are very clear about domains of authority, there’s nothing stopping a radically collaborative organization from saying, we’re going to create people within the company whose job it is to find bad actors and fire them, and that’s their role and that’s their domain of authority, and we’re all going to trust them to do that. There’s nothing wrong with that. That’s another approach to dealing with this that, certainly, at least warrants an experiment. And if it doesn’t work out, you can always try something else later.

So anyway, I just think it’s sometimes hard when all you’ve ever experienced are very traditional organizations, both I think in school, in church, in work and everything else, to imagine the possibilities of how you could solve for the same sorts of problems in a world in which you would not organize by a dominator hierarchy. But it turns out, we can think creatively about these things. All these different companies out there are showing us all the different ways that we could go about doing these same sorts of things without some of the negative consequences associated with the growth inhibiting consequences associated with a system of domination and coercion.

Henry Suryawirawan: Wow! Thanks for sharing all these exciting strategies and techniques. I’m still trying to wrap my head around some of these ideas because I’ve never experienced it. For those listeners who are interested, I think I suggest you to read the book and maybe from there, you can go to few different references so that you can actually understand how it is actually being done. So there are no like a hundred percent answer to some of these concepts. Sometimes, it depends on the context and the situation. Maybe you can choose the things that might work for you.

[00:50:49] Imperative 3: Deficiency Gratification

Henry Suryawirawan: So let’s go to the third imperative, which is deficiency gratification. So you mentioned this is related to the psychological needs of human. Why is it important to satisfy the human psychological needs? Tell us more about this imperative.

Matt K. Parker: All right. So I think, you know, at the beginning of this, I talked about how there was sort of sea of change in understanding of human motivation and behavior. What really happened throughout the 20th century was they discovered that humans aren’t like rats. That may sound weird to say. But in reality, the dominant sort of understanding of human motivation and behavior in the early to mid-20th century was based on a study of rat behavior and then extrapolating from rats to humans. It sounds crazy when I say it, but that’s true. That’s how we came to this kind of crazy conclusions about carrots and sticks for humans and how that’s the end all, be all of getting people to do what you want them to do or getting people to perform.

So, actually, what we discovered throughout the 20th century is that human motivation is much more interesting, rich, complex, and in some ways much more powerful, and in other ways a little more fragile than we thought. Intrinsic motivation turns out to be a great predictor of success. When people are doing things that they feel intrinsically motivated to do, that they are doing because they believe it’s what they want, because they believe it’s what is right or what’s important, they tend to be much more successful. That correlates with other human needs like autonomy, which I’ve already mentioned. It correlates with other human needs too, like trust and our trust in each other to be able to pursue activities together.

The psychologist that sort of pioneered the field of positive psychology, which looks at sort of motivation and personality and all these psychological needs, they had this hypothesis in the mid-20th century. Their hypothesis was, if we take what is good for humans and extrapolate from that, we believe that what is good for the individual human will also be good for the organization of humans. In other words, if you create environments in which the humans within them are getting all the security, autonomy, fairness, esteem, trust, belongingness, etc, that they need from their environment, they will actually perform better as an organization of people.

But those mid-20th century psychologists when they first began to say, this is our belief, this is our hypothesis, they had no empirical evidence to stand on to say that’s actually true. It’s really only the last, maybe three decades that we’ve developed just this growing body of research into the relationship between individual human psychological needs, satisfaction and group level performance. And what I mentioned earlier about, like the multiplicative effects of trust, the strong correlation between success and autonomy, etc, are all based on these studies over the last 30 years that have looked at the relationship between performance and outcomes and efficacy and underlying needs. That’s really what this boils down to. And so in the companies that I profiled in the book, I show a number of ways in which these companies cultivate a culture of mutual need gratification.

Henry Suryawirawan: As you mentioned about rats, you kind of like reminded me every time I read a book, there’s always this experiment with rats, right? I think maybe that’s the reason why some of these actually came from that experiment. We always test against rats first. That’s why there’s this term called rat lab and things like that. So that’s really funny when you mentioned that.

So yeah, I think it makes sense. We all have our human needs. So if you refer to the Maslow’s hierarchy, beyond a certain point where you have the basic needs and things like that, people crave for meaning, for self-actualization, self-esteem, trust, and things like that. So the higher you go, especially when now the world has evolved so much, I think people crave more towards the top hierarchy in the Maslow’s hierarchy. Thanks for sharing that.

[00:54:23] Imperative 4: Candid Vulnerability

Henry Suryawirawan: So let’s go to the last concept. The last imperative called candid vulnerability. I think there are so many research done about vulnerability, right? Leaders are also expected to become more vulnerable. So tell us why vulnerability is also one of the ingredients for radical collaboration in a team?

Matt K. Parker: Most teams are dysfunctional in the world. You put a group of people together, you tend to witness a certain set of dysfunctions within that team that are shockingly consistent between different teams, right? They tend to be dysfunctional in the same sorts of ways. The question is, why? Why is that happen? The answer is, or at least one theory around it was developed originally back in the eighties, and since then it has sort of grown. It’s a theory of sort of tasks and psychological routines that many people have learned in early childhood that end up making their work with others, typically dysfunctional. Those routines are winning and not losing, maintaining unilateral control, suppressing negative emotions both in themselves and in others. While doing all this, appearing to behave rationally in appearances, probably the key word, right? That’s called defensive reasoning.

And so, when you have a number of people working together as a team that don’t all agree on what to do, you typically see them manifest defensive reasoning. Instead of getting to the truth, they each try to win. Instead of discovering what is the best approach, they each try to campaign for their one approach, regardless of whether or not it’s the best. They don’t even sometimes realize, I mean, I say, I’ve done this so much in my life, right? We don’t even realize we’re doing it when we do it, typically. Like these underlying sort of routines that lead us to be dysfunctional are tacit.

The opposite of that is called productive reasoning. Productive reasoning is what I call candid vulnerability, because it really does boil down to not only getting people to say what they think should be done, but why they think it should be done. Exposing the hidden chain of inferences, assumptions, beliefs, biases, observations, etc, to others to be able to actually explore it and sometimes invalidate it in pursuit of getting to what is the right thing to do. That candid vulnerability does not come naturally to us. Most of us have not learned to do that from an early age. So we had to practice it.

And there are some interesting ways that I found that these companies were practicing it. They included things like doing two column exercises. Let’s say, Henry, you and I were working together, and we were in a meeting and we had gotten to a big argument, and we both sort of left feeling not good about it. One thing you and I could do separately is to take a piece of paper, draw a line straight down the middle. On the right side in the right column, we could write down maybe some of the key things that we said. You said, I said, you said, I said. In the left column, we could write down what we were thinking as we were saying these things.

If you just stop there, what you typically discover is that what we say, and what we think are radically different. What is said versus what is thought tends to expose a tremendous amount of defensive reasoning. Having done this myself, I can say it can be humbling and frankly a little horrifying when you step back and are honest with yourself about the delta between those two columns. But you can also then rewrite the conversation. What if I had been more honest, more candid? But what if I had also been more vulnerable? What if I had demonstrated vulnerability to the person I was arguing with, and I had demonstrated curiosity in what they were saying instead of assuming I knew everything about them and assuming I knew everything about why they were saying it? And so, that’s one way that these companies have began to develop the skill of candid vulnerability.

One other way is practicing clean language, with something developed, again, in the field of psychology. It’s a way of asking questions in which you are removing your own individual assumptions and biases from the question itself to try and better actually model what the other person is trying to say. So much conversations go off the rails because we don’t bother to confirm whether what we think they said is what they actually meant. If you do go through this process of actually diving into what do they mean, you discover that you are often wrong. You had them totally wrong. What you thought they were saying is not what they were saying at all. Sometimes you discover it is what they were saying. But regardless, going through a process in which you really dive into their own reasoning brings you closer to the other person. Makes you more trusting of each other. So anyway, clean language is another way. It’s a set of questions that you can ask and use in different ways to be very curious about what the other person is saying and begin to systemically model how they think and why they think that way. So that’s just a couple of ideas. But yeah, there’re some others in the book too.

Henry Suryawirawan: As you mentioned about defensive reasoning. Yeah. I think I must admit myself as well, right? We all have this defensive reasoning. We want to win. We want to bring our own agenda to the front instead of listening to others. Or maybe assuming we know what others think and we make decisions on their behalf. So some of these definitely are anti-pattern, so to speak, right? And I think this candid vulnerability is based on the concept of openness and always be transparent. You explain also what is your thought process, not just the what and the result, the conclusion of what you think. And this exercise of thinking versus saying, I think it’s really interesting. I haven’t done it before. But I think for those people who want to analyze why they have an argument or a clash between certain team members, I think maybe you can try this reflective practice of thinking versus saying, and maybe there’s something that you can take out of that practice. So thanks for sharing that.

[00:59:54] Applying Radical Collaboration

Henry Suryawirawan: With all these imperatives, there’s one question that I want to ask. Does this only work for certain types of people, or can we all try to practice this radical collaboration?

Matt K. Parker: I don’t know. That’s my honest answer. I really don’t know. And I have wrestled with this too. The answer I’m going to give you is standing on the shoulders of real scientists and researchers who are delving into similar sort of kinds of questions. I think what I have learned from all of that is that human intrinsic motivation is fragile in some sense. It’s not as resilient as I assumed it was. We can get into situations in which we are so routinely subjected to carrots and sticks. We are so routinely deprived of meaningful decision making, etc, that we can not only lose any intrinsic motivation that we had in the beginning, but we can often lose the will to regain it.

This is sometimes referred to as Theory X or the end result of Theory X, anyway. Theory X is a pictorial pneumonic, actually. If you imagine a worker holding their hands up in an X shape in front of them. It’s this theory that workers won’t perform, won’t do anything unless you force them to, unless you dangle carrots in front of them or whip them with sticks or whatever. It turns out theory X is a self-fulfilling prophecy. If you routinely subject them to coercive environments, a lot of people do become that employee. They do become the people that hold up the X in front of them and don’t do crap unless you make them do crap. And it’s a coping mechanism, honestly. The problem is that can really damage the long-term ability of these people to be effective in the organizations.

So I think this is the fundamental challenge that many organizations are going to have to wrestle with. As more and more organizations decide to transform, you may have to wrestle with the fact that you have a lot of people in the company that have no interest in transforming, have no motivation to transform, don’t want to make decisions, just want to show up, get told what to do, get a paycheck, and go home and live their lives. I don’t want to sit here and judge people that are in that state. I’ve been in that state myself, and I think if somebody had come to me and said, “No. You can’t be like that anymore. And you have to do radical collaboration,” I would be like, “F you. I don’t want to do radical collaboration. Just don’t make me work at this. Don’t make me think about it.” And that’s, I think, a reality that a lot of us are really going to have to wrestle with as more and more companies begin to embrace a new way of thinking about work.

Henry Suryawirawan: So that’s an honest answer as well. So I think there’s no a hundred percent answer here. As you explain about this theory X, kind of like related to the psychological safety that people crave these days. I think it’s kind of like a key theme these days. People talking about psychological safety. So I think if you don’t have this psychological safety, I guess, yeah, people tend to be the one that you mentioned, right? The theory X. They shut down and they don’t want to perform beyond what they are probably being told.

[01:02:42] 3 Tech Lead Wisdom

Henry Suryawirawan: So, Matt, it’s been a really exciting conversation. I think we kind of like over time a little bit. But I have one last question that I want to ask you. It’s called the three technical leadership wisdom. I always ask this with all my guests. So would you be able to share your version of three technical leadership wisdom?

Matt K. Parker: Yeah, absolutely. Let me preface this by saying I’ve been a tech leader by title, and I’ve also been a tech leader without a title. What I can say I’ve learned from all of my experiences and also from my research in other organizations is, first, leadership doesn’t come from an org chart. And in my own experience, authentic technical leadership, the kind in which people genuinely seek out your advice and follow your lead, is inversely proportional to your title. The higher your title is, the less of a leader in practice you become. I think that’s something we have to wrestle with.

Okay, two. My second bit of advice is if you are a technical leader and yet you don’t look back on your previous years' code with disdain, then that’s a signal that you’ve stopped learning and stop challenging yourself. And complacency like that is the death of technical leadership. So if you are in that situation and think like, “I did it, I’m the best. My code last year is still great”. I haven’t learned anything new to change my mind. You probably are deluding yourself. So think about that.

Lastly, my third bit of advice. Technical leadership, and really all leadership, requires you to listen to what’s not being said. What are the topics people are dancing around but afraid to confront, afraid to admit, afraid to wrestle with? Find those and surface them. And if you are getting good at doing that and doing it empathetically, openly and candidly, you will be an amazing leader.

Henry Suryawirawan: Wow! I think beautifully said. I like the second one. So if you are not cringing looking at your code or your contribution, probably you’re not improving yourself, right? I think that’s kind of like a good reminder for all technical leaders out there.

So, Matt, for people who love this conversation, they want to find out more from you or connect with you online. Is there a place where they can reach out to you?

Matt K. Parker: Yeah. Well, for starters, my email is matt@mattkparker.com. So just feel free to email me. You can also go to my website, mattkparker.com. There’re links on there for Twitter. I’m realMattKParker on Twitter. Links to my LinkedIn as well, where I try to post. That’s where you can find me.

Henry Suryawirawan: And make sure to get the book as well. So, if you want to be kind of like mind twisted with all these radical concepts, I think the book is really good to give you summary and also practical examples from companies who have done it. So I think it’s not just theoretical, but it’s also practical in a sense that they are real companies examples inside the book.

So Matt, it’s been a pleasure talking to you. Thanks so much for your time. I really learn a lot today. My mind is still twisted for some of the concepts. But I hope that you enjoy this conversation as well.

Matt K. Parker: Oh, I loved it. Thank you so much for having me.

– End –