Finding Our Way

Show Notes

Peter and Jesse are joined by organization designer Clay Parker Jones, author of Hidden Patterns: A Playbook for More Human Workplaces, who has led organization design work at Airbnb, Undercurrent, R/GA, and August. The conversation covers why roles persist, the importance of indexing on trust over role clarity, the difference between psychological and structural safety, organizational rule of law, and why demonstrating better teams beats trying to convince skeptics.
Clay Parker Jones: https://cpj.fyi, Hidden Patterns book

Jesse James Garrett: https://jessejamesgarrett.com/

Peter Merholz: https://petermerholz.com/

Transcript

Jesse: I’m Jesse James Garrett.

Peter: And I’m Peter Merholz.

Jesse: And we’re

Peter: finding our way. Navigating the opportunities- And challenges- Of design and design leadership.

Jesse: On today’s show we’re joined by organization designer Clay Parker Jones And author of the book Hidden Patterns: A Playbook for More Human Workplaces. We’ll get into the untapped value that is unlocked through organization design, why teams might be better off indexing on trust rather than clarity, and strategies for overcoming organizational resistance to change.

Peter: Clay, thank you for joining us.

Clay: Happy to be here.

Peter: You’re probably a little less standard of a guest- … on Finding Our Way, in that you’re not a UX design type. So for our audience who might not be familiar with you, how do you introduce yourself?

Clay: Well, firstly, when I was young, I did want to become a UX designer.

And I very much looked up to the both of you and the work that Adaptive Path did. So not being a good enough designer, I think, led me to be an organization designer.

Peter: Which is something I, I now share myself.

Clay: Hey, life brings us many changes. Okay. So how do I introduce myself? I’m an organization designer.

I am now an author. I’m now also a dad. I live here in Brooklyn, New York, with my wife and son and cat, Ian. I’m a former bicycle mechanic.

Defining Organization Designer

Peter: Organization designer is one of those roles that I think people have heard but don’t really know what they do. Yes. What would you say an organization designer does?

Clay: Like, the formal answer or the way that if I was trying to explain it to someone who’s going to be paying me would be something around the structuring of units to help people achieve a goal, or the reforming of an organization in its various constituent parts in order to deliver some improved outcome for stakeholders.

That’s, like, a real nerdy example or a real nerdy way to talk about it. I think the way that I think about it personally is waking up with a mission of the people that you’re working with being able to get more and better work done today than they did yesterday, and continuing to do that over and over again.

The idea of design is useful because it introduces, like, a category boundary. But I, I think so much of this work is actually just in… It’s in the margins. It’s in the meeting that goes well or goes poorly. It’s in the role that is well-described or poorly described. It’s in the team that knows that the other teams around them are gonna keep doing the things that they said that they were going to do and not always, or maybe increasingly so, not infringe on their territory or step on their toes.

It’s in people feeling really excited about their work. And whatever mechanisms we might use in order to get there, it might be a PowerPoint deck containing a org chart. It might be a piece of software. It might be a prompt that somebody gets or a prompt that somebody gives to a intelligence. It’s all kinds of things.

But it gets pretty narrowed into this idea of, oh, we’re making a deck for a senior leader that follows, like, this diagnose, design, deliver kind of pattern. And I think that’s increasingly unuseful or even unhelpful in the way that we define the field.

Jesse: What are some of the other tools that you’d like to see come into play in how organization design is done?

Clay: I think it’s more about the distribution of the knobs or the levers or, like, the palettes that we might paint with to more and more people. And I don’t mean that through terms or ideas like self-management necessarily. That may be something that happens, but mostly just that more teams are able to have more of an impact on the way that they are themselves designed, the way that they have agreed with each other that they’re going to work, and that more people are doing it more frequently at a higher and higher level over time.

So it’s less about, like, the tooling exactly, and more about, like, more people adopting whatever tooling it might be.

Peter: Mm-hmm. Correct me if I’m wrong, but org design, at least the way you practice it, is more defined by its outcomes of an improved org. Whereas while that had been the goal of UX design when Jesse and I were doing this 20-some years ago, UX design, over the last decade-plus, has been defined by its artifacts and its process and what it creates, less by its impact.

And I’m wondering, well, one, an opportunity, I think, right now for UX design is to be less defined by its tools and process and artifacts, and more by its impact. And I guess with org design, I’m wondering, have you seen it defined by its stuff, or has it been able to stay a bit truer to an orientation on impact?

Clay: I think that there’s, like, roughly two portions of the field.

There’s this kind of like structuralist portion that gets paid for doing organization design, and that is seen by stakeholders as org designers. And those people are typically at one of the big consultancies, less so like an August, less so like The Ready, and more so like McKinsey or Kates Kesler, now part of Accenture.

And they’re defined by outcomes, but they’re also very much defined by the actual artifact. There is a perceptible feel to one of their documents, that where even if it has the company logo at the bottom, you know who wrote this thing. And the outcomes are far, so far in the distance. They’re gonna come to us five, 10 years from now when we finally bring together all these operating units that have been operating on their own, with their own intention and with their own structure, and now we’re bringing them together and we’re gonna achieve some efficiencies. That’s gonna happen way far in the distance, and the outcome is not really even part of the conversation. It’s the output. It’s the thing that we all agree is, like, gonna be the effective transfer of power.

And then there’s, like, this, I refer to as, like, a mutualist side of the practice, which is more about helping people define their work together and giving them the tools and the technologies and the language to actually be able to do that.

And that is almost entirely outcome driven, and it gets paid a lot more reasonably than do, like, the structuralist org designers, right?

And I think there’s a little bit of the mission kind of getting in the way there to a certain extent, if all we’re trying to do is get paid.

But, at very least, there’s like these two sides. One is called org design, one is usually called, like, culture work or ways of working work, but it is org design. It’s changing the way that the organization is structured, intentionally, for good, usually, or that’s the intent or the hope.

And then the other side is we’re trying to, we’re trying to hack it, and sometimes we get called in, sometimes we get brought in after the big consultancies get called in, and that is entirely always going to be sold.

We always did at August, sell it in terms of the things that are, that our clients are going to be able to observe in the organization, not something that they’re gonna be able to hold onto, which maybe is a bad consulting strategy.

Peter: Mm-hmm. Mm-hmm.

Jesse: Some would say.

Clay: Sure.

The End of Role Clarity

Peter: The impetus to have you join us on our podcast was something that you published in February called The End of Role Clarity, which I ended up responding to in a newsletter article of my own.

But before we get into a dialogue, I think it would be good, for those who haven’t had a chance to read it, if you could just share the thesis. It’s a long enough article, so I’m sure you’re gonna have to elide some details, but what is your high order thesis when you were writing The End of Role Clarity?

Clay: Yeah. In large organizations, so much of the conversation ends up being about, “Oh, well, we don’t have role clarity.” And it’s something people say when they are trying not exactly to avoid taking action, but it often allows people to do that. We’re not going to take advantage of this opportunity because we don’t have role clarity, because I’m not sure if that person over there is supposed to be doing that thing that they’re doing that I think I should be doing, and it’s getting in the way of us being able to make a good decision.

And I wanted to offer with that piece this alternative view, which I think is more and more plausible or possible with, or maybe even required or will be forced upon us by the introduction of new technologies that allow more people to do things that they didn’t know how to do before. Whether or not they know if the output is good or not is sort of beside the point, but it is going to allow more people to be designers, be musicians. It’s going to allow people to do more things.

So that means that individual roles as we have defined them today, like an engineer or a product manager or a designer, become less useful or interesting distinctions between roles because teams are able to just say, “All right, yeah, I can kind of be a software engineer if I’m a designer with an interest in artificial intelligence and figuring out, like wading through the process of like getting Terminal working for me and being able to work in the command line. Oh, I can actually be useful, and I can make a prototype with the design sense that I have.”

Or if I’m a product manager, I can actually do some of the design work using some tokens that I’m pulling from a library that’s been well architected by actual designers. And that means that the more useful thing to be focused on is less, like, are they perfectly defined, and do they have no overlap between the two individual roles, or do they know how to work very well as a team because they have a clear team purpose, they have a clear sense of our focus areas, they have a clear understanding of how we’re going to be measured. They know where we’re going to work, they know and they’ve made an agreement together about how they intend to work.

That’s much more useful than this idea of role clarity, which feels antiquated and stuck in this idea of the org chart being defined by the employment agreement, which I think, again, is going to be less and less interesting over time for the people who, I don’t want to say the people with the most talent exactly, but the people who are like really leaning into trying new tools and building with AI.

Like they’re gonna want to be doing more, and that’ll change the way that we think about the team, and in ways that are in the near term probably not always so good and feel a little bit like, “Ooh, am I losing some of my identity in this?”

So that was the piece. I think I’ve stepped away from the computer for a while to raise my now 12-week-old son. So hopefully that is mostly what I tried to say. And I know, Peter, you disagreed with me to a certain extent, and you emailed me right after I posted it. “We need to talk about this.” Which I knew then that I had done something good for the world in introducing something that people may find disagreeable, if not a little bit useful.

Peter: The, the heart of your thesis is something that I think I tried to reflect on when I wrote Org Design for Design Orgs and in my own design leadership practice. And Jesse and I have talked about recently, even when we were back at Adaptive Path, where we tried to have just one role: You’re an experience designer.

And in that role, there could be a range of skills, and different people with the same title might have different skills, and that’s okay. Because we wanted to kind of support what you’re talking about. It’s less about you being tightly defined in this way and someone else being tightly defined in that way, and more this group of people is joining together to solve some problem.

As I’ve gone in-house, and then even after leaving, going in-house and becoming my own flavor of org designer, I found myself defining roles.

But, like, when I create career architectures, I always start with skills and not roles, where when you see, like, how most people create career architectures, they start with roles and not skills. But I start with skills.

I’m like, that’s the most important atom of effort, and then we can build a career architecture around that.

And so I largely agree with you. I also thought it was funny that something I’m seeing is that AI, and I put AI in quotes, is enabling many of us to dust off things that we were saying 10 to 20 years ago, and be like, “Maybe now. Is there… if we… Will you listen now? Because it was true before, but it’s actually even truer now.”

And I suspect that’s something of what you’ve got going on with what you’re writing.

Why Roles Persist

Peter: But the part that I wanted… that maybe I disagree is strong, but where I’m like, the hard part of it is, I think, there’s these three qualities of roles that are really hard to get over.

Roles are human shaped, and I think as an anthropologist, I think we process the world, right, through heuristics, and one of the heuristics is things that are human shaped make sense to us. So a role makes sense to us in a way that a pile of skills doesn’t, and so we start there. It’s a human shaped thing.

Thing two is, roles are, to use Seeing Like A State language, they’re legible by the bureaucracy, right? The bureaucracy loves roles. It knows how to post a job with the role title. It knows how to put you in an org chart. It knows what to pay you, right? There’s just something about roles that get taken up easily by these systems, that again, a pile of skills or, like, five people on a team doing a thing, whatever that is, what do we call them?How do we pay them? What do we… how do we reward them? How do they grow in that career or whatever?

And then thing three is something you touched on, which is identity. This is something Jesse and I have been talking about, well, for 25 years, and pretty much since the start of the podcast, is designers…

Like our industry, our colleagues, many of them went to design school. They’ve had design in their title. They see themselves as designers first and whatever else second, employees second, an employee at a particular company second or whatever. There’s something around design that has this connection or affiliation with identity that’s so strong.

So my question to you, and this is a big one, but I’m curious your thoughts, like, how do we overcome these three kind of, obstacles isn’t quite right, but just, like, realities of role-ishness in order to achieve the nirvana of a post-role team-oriented future?

Clay: Yeah. That’s, it’s a very good question, and I’m happy that you… It’s okay to disagree with a thing too. I appreciate that it sparked this, ’cause it is worth debating and it’s worth digging into. I think in the three things that you identified, two of them are really good and worth maintaining as we redesign a thing.

Or if we move from where we are today to where maybe we hope to get, or where I hope to get with more of a team-oriented networked future for work, I think that’ll be better for more people more of the time.

So human-shaped heuristic for understanding the work that’s happening in a team, that’s great. I wouldn’t change that.

The identity thing I think can be, can be good for some people and limiting for others. Being constrained by the way that an organization sees you coming in, or by the way that the field has defined what you wanna do. In the case of organization design, we get defined by what big consulting says organization design is going to look like. And we have to, like, figure out our way around that.

So it’s good and bad, but it is part of who we are. Like, I wouldn’t wanna build a future that, like, sullies the things that make us human, right? We don’t want that.

Legibility to bureaucracy is the thing that I think is most worth figuring out in this. What do we make legible? How do you make an organization understandable to humans, understandable to machines, understandable to other organizations? You can put machines and other organizations maybe in, like, a bucket together because they’re only able to, like, piece together what they know about the organization by, like, sending a request.

But making, like, the organization and the work visible to each other, being able to see a system so that we can change a system, I think that’s really valuable, and it’s a slippery slope to creating something that feels like a surveillance state within an organization.

Jesse: Right.

Clay: So we have all of this exhaust coming out of the work that we’re doing.

Like, we know that the three of us were on this call together today. we could instrument that. It would be actually relatively easy for us to understand that we were on this call together, that we had these emails that preceded it, that I had read some of the work that you all had done, and maybe if we had all seeing memory of what we had been doing, it might be able to help us, like, make this better and make this more interesting.

But it would also mean that the organization would know all of that about us, and I think that’s a challenging bit of this. It’s like we have this ability, to your point, Peter, around, like, these ideas that we had a while ago that we knew were good ideas then but now have become relevant because the computer can actually do the things that would be necessary for us to actually bring that thing to life.

Okay, fantastic, and it has this kind of scary side effect. I’m not sure what to do about that, but I do feel like it’s something that we have to contend with in helping organizations find their way toward better structures that put teams at the center instead of saying, “Manager is a person,” versus, “Management is a valuable thing that we do, and many people need to be good at it.”

Even at the very top of the organization, they are managers. Almost to the bottom of the organization, there are managers. And everybody needs to be good at that. Leaders need to be everywhere. Subject matter experts need to be everywhere. So it’s, I think, just a better matching of reality to what we’re able to write down.

Handling Scale

Jesse: Peter touched on our experiences wrestling with some of this stuff at Adaptive Path. And one of the things about that experience was, honestly, it pretty much worked. We had some challenges. We had some challenges with people who, going back to the identity thing, their identity wasn’t just designer, it was like, “Well, I’m not an experience designer, I’m an interaction designer,” and, “I’m not an interaction designer, I’m a service designer,” and on and on and on, where we had these sort of increasingly fragmented identities.

But in terms of how the work got done, it mostly worked. The people who were routing the work to the team knew the skills of the team and were able to manage that effectively and were able to assemble teams that could get a job done. That was at a scale when we were 30 people, 40 people maybe, and everybody knew everybody else. Everybody had worked with everybody else. There was a lot of the, kind of the intangible personal knowledge that was a part of our processes and how we made those decisions and how we made those choices.

And some of the things that I hear you talking about in terms of what do we do about the potential for these surveillance systems to shape this work, it seems to me that some of that is an artifact of scale, that you have to be able to architect these systems at a scale at which you’re evaluating the performance and evaluating the contribution of people who may be many layers removed from the people who are actually making kind of the big decisions.

And I wonder about how scaling can work when everybody is a pile of skills and every sort of interdepartmental or interpersonal contract is bespoke, so to speak.

Clay: Yeah. Great question. The prevailing answer in the scholarship and in the examples out there in the world is don’t. Just keep the elements small and knit them together with their own contracting and have something that feels more fractal in the way that it operates and the things that humans touch about it.

Like I’m with my seven people that I’m on a team with. I know them. I know them really well. I know that Peter’s really good at this, and Jesse’s really good at that.

And then there’s these other teams that I’m kind of like in a neighborhood with, and I know that they do that, and we do this, and this other team does that. And sometimes we do things together, and sometimes we do things apart, and they get value from us, and we are continually like negotiating that.

And then maybe outside of that group of 150, then there’s like, okay, that might be an organization. There’s maybe a bunch of teams within that or a few neighborhoods within that. And that way you don’t have to scale anything really, scale the human experience, but you’re able to build an organization that works well together because it can be knit together with something relatively simple, like a contract between a consulting client and Adaptive Path, or same thing with Undercurrent or August.

It’s through the contract, it’s through making something smaller, and it’s probably through building something that feels like a, like using consent in a different way than I normally would in org design. Like a consent-driven approach to like what’s disclosed by the individuals, what is gathered by the organization, and what remains like true to the person. What can they pull out of the organization? What can they determine they grant to the organization in terms of the information that they’re allowed to know about the way that we work, the kinds of things that we do?

And that networked approach that would shrink the interface, I think that might be the way out. I’m not sure. Yeah. I don’t think you can just try to import this stuff onto the top of a 50,000-person traditional command-and-control bureaucracy and have it work because people will want, “I need this thing defined. I’m here for a tour of duty.” The handshake is not between me and the company that I necessarily look up to and believe in the way that it would’ve been for Adaptive Path that makes things a little bit easier when people are coming in and more open to adopting a role that has like less clear definition.

Same thing with August, same thing with Undercurrent, et cetera. I’m not sure that it’s gonna work if we like have the same priors and try to import a system on top of it.

Jesse: Yeah. It’s interesting to think about the way in which if you kind of take down the level of clarity in the roles themselves, it has the potential to make the entire organization more nimble because people aren’t locked into a particular set of expectations.

I’ve been working with teams on their AI transformation initiatives for a little while now, and one of the things I’ve been saying to leaders is that this is a process of embracing the unknown, and in a team environment, it’s very difficult to do that if you don’t have a high level of competency across the team and a high level of trust across the team.

And the pressure on leaders now is to figure out how to create these high-competency, high-trust environments in which teams can rely on each other in the face of no contract at all, potentially, right?

Clay: Yeah. Completely agree. Completely agree. And I, I’ve ranted about this in a few different other posts and places, but it’s relevant to bring in here, too.

Trust and The Importance of Good “Teaming”

Clay: The trust thing, like leaders creating an organization that is high trust or that has a high degree of trust, means that there is trustworthiness between the organization and the individual. We have to say, “We trust you to try some things that are likely to be harmful to the organization, but we are interested in that because we are learning about how this new technology works. We have no idea. Anybody that does is wrong or lying or incentivized.”

And we don’t know where, like, where the motor in the example with the steam engines and electric motors, we don’t know where the motors are gonna go yet. We know that they’re gonna go in different places than we put the steam engines, but we don’t know where they’re gonna go.

And we have to dig into that by trusting our people and believing that they are more competent than we have believed they are in the past. I find all the time when I work with teams, that you give me 10 relatively junior people that the organization doesn’t think are all that great, and let’s put them in a team and do the things that we know to do to make them a team, to help them become a team, and they will achieve amazing things.

They’ll be seen as rock stars within the organization, if even if six months ago they were kind of like the cast-asides. Because people are capable. People are really good.

Peter: Just thinking of The Bad News Bears here.

Clay: Yes. I mean, it’s a sticky story. It happens over and over again because it’s real.

And I’ve seen it over and over again that just give me anybody. Doesn’t need to be the most talented people or the high potential people that the organization has determined are the ones who will rise up. Let’s see what happens. If we make them a team, they’re gonna do amazing things. It always happens.

It never doesn’t. It’s crazy. It’s not crazy. It’s super obvious.

Peter: So I have your book in front of me, Hidden Patterns, available wherever books are sold. And…

Clay: Thank you …

Peter: …you have as one of your foundational elements, something that I neglected in Org Design, but has since become core to my teaming practice, which is psychological safety.

And as you’re saying what you’re saying, right, there was the research that came out of Google a decade ago, maybe more now, Project Aristotle, where Google, a company built on high performers, right? Everyone is a rock star. Everyone has a PhD. Everyone is the best at what they do. And so there was assumption that the most effective teams would be those that had the best people on them as assessed by the system, and it turned out that was not the case. In fact, those were some of the worst teams.

Psychological safety

Peter: But the best teams were those that had high degrees of psychological safety. So I’d love for you to actually talk a little bit about your experience with psychological safety, creating psychological safety, and I think it touches on matters of trust.

Our audience is a bunch of leaders who are probably trying to make a psychologically safe space in their organizations. We hope so. And one of the challenges I hear all the time when I teach my masterclass, we talk about psychological safety, and they’re like, “Yeah, so I can try to do that for my team, but we’re operating in a much broader context that just has none, totally lacks psychological safety. So what do I do then?”

So I’m curious kinda how you encourage, foment, enable psychological safety for those that you’re supporting.

Clay: Yeah. It’s really hard, and it’s poorly understood, and the tools that leaders are often given, I think, are relatively dissatisfying. I went to a workshop for HR leaders six months ago, and we were there with some of the psychological safety and design thinking luminaries.

They were teaching…

Peter: Did you ever think that you were just an HR leader? Did, did, in your wildest dreams 20 years ago, you’re like- … “My aspiration is to be an HR leader.”

Clay: No, and that is something that I deal with every day.

Peter: Sorry for the interruption. I couldn’t let that phrase go, though.

Clay: No. Speaking to the identity point it’s not something that I had envisioned for myself, but it’s been very interesting.

And one of the things that we were taught as a practice, which I love, it’s an amazing practice. I’d never done it before exactly. It’s a team kickoff thing where you get groups of three together, and the instruction for the group of three is for one minute, one person must say to the other people things that they love.

“I love Post-Its. I love this little fan that cools off my son when he’s in his carrier. I love going on podcasts.” Like that. And it’s really hard for people, very frequently, to get to the end of a minute and continue to have things that they love. But there’s also a lot of, like, commonalities that the facilitator will inevitably pull out.

Did people mention their spouse? Did people mention their child? Did people mention their career? Da, da, da. Did you have any similarities? And this is one of the things that we’re supposed to do to increase psychological safety, and it feels so rudimentary. It’s good. It’s good. I don’t think it’s bad. It just is one of those things where you’re like, “Okay. If we’re gonna create psychological safety, one of the things that I need to do as a leader is ask better questions.”

Okay. Is that the whole book? Is that everything? Well, kind of, and absolutely not, right? There’s lots of other things that we need to be able to do. We have to have, yes, good team kickoffs. We need to ask good questions. We need to model, as leaders, vulnerability.

Structural Safety

Clay: We also need to address the structural parts. So if we’re able to, if we’re able to, as organization designers, get the keys to the top, the final boss, and actually do the deep structural work here. We need to address the lack of structural safety within an organization because you’ll have leaders within an organization that want to build psychological safety on their team, but they are not able to because that team could be deleted at the drop of a hat.

Peter: So that’s what you mean by structural safety as a distinction from psychological safety.

Clay: And we need both. We need both. And one of the things that we did and didn’t fully express in the way that I wanted to at August was set up a business where people have a very clear understanding of what will get in their way or what will cause them to be exited from the organization.

It’s by breaking these contractual boundaries that we have set up, and we all agree to them when we get started. They’re clearly written. We amend them only when we have the rights or the incredible data to change that constitution effectively. And that kind of thing, to me, is one of the reasons why August is still around 10 plus years on, right?

It’s an organization that has some durability to it because I think it’s spurred on even after founders like myself leave, because people feel structurally safe. So knowing what’s gonna get you kicked off the bus and actually knowing that that’s not like, “Oh, you did your expenses wrong,” but it’s like, “Oh, you weren’t trustworthy,” or, “You didn’t trust your teammates enough.”

Not that you spent too much money on this thing, or you made a bad decision, or the campaign didn’t work, or a client left, but that we couldn’t really believe in you as a member of this team, and people often found their way to leave on their own, right? So that structural safety that’s encoded into the organization, that is something that we need to establish.

Most organizations have nothing of the kind, right? You have all these things that you sign when you join that are, like, rudimentary guidelines about what’s gonna get you kicked out of any organization. Don’t do anything unethical. Those are important, but we forget about those. We don’t have anything that’s about the things that we actually care about.

So getting those things on paper, saying that we believe in them, actually believing them, and using them as the boundaries for membership, and then doing all the things that we need to do within a team, right? Have good clarity for what the thing is that we’re trying to do, what the rules of the road are within our team, how we meet, the way that we operate, asking good questions as a leader, kicking off meetings the way that we should.

There’s all these gigantic things and these really small things, too. So it’s hard, but it is the challenge, and great organizations and leaders who lead organizations that they believe in, I think, kind of do some of this naturally. It’s like, oh, we should have a skills framework for the way that we help people up level, but it’s not there to prevent you from up leveling.

We want you to use it. We want you to go, like, level up, become better. Those are the things that we know are powerful, and we just kind of neglect them. Sorry, that was a bummer.

Balancing Solidity and Rigidity

Jesse: Yeah. Well, I’m maybe about to make it even more of one. When you talk about structural safety, it’s interesting because when I think about organizational resistance to change, it often is because of kind of the dark side of structural safety, which is that you have functions or business units or departments or other elements of the business that are sacrosanct, that can’t be altered in any way, that have been sort of calcified.

And I guess I wonder about how you manage that tension between wanting to create the correct amount of safety without encouraging this kind of rigidity structurally that prevents an organization from evolving and adapting in the ways it sounds like you were able to build in at August.

Clay: Well, it doesn’t work all that often, sadly.

You know?

Jesse: Hmm.

Clay: This is one of those things where I think those of us who turn our eye toward organization design tend to be really disappointed and feel like, “Oh my God, I didn’t actually want to do this.” This is not the way that I want to spend my time thinking about what to do with that calcified organization over there, and the people who are resisting change, and maybe rightfully so.

They might have some wisdom that tells us that we should keep it the way that it is, and the leaders around them that perpetuate that. Like, that’s… It’s ugly. Organization design is often dealing with the basest human desires and some of the things that we don’t like to express about the way that work works or doesn’t work for people.

And when it works, though, it’s by creating a movement toward positivity. I had this rule for… I still have this rule. I maintain this. Don’t convince people. Don’t try. Just offer the thing, offer the better way of doing something, offer the better design, offer the better practice, and if they don’t wanna do it, they probably have a good reason, and trying to trick them into doing it is not worth your time.

Instead, what’s better, a better plan, is to go find teams that really want to get something done. Lavish your time and attention and tooling on them, and then show the organization what they’re able to do. “Wow, this team over here was able to re-architect our backend. It would normally take a year. It took us 11 weeks.” “Fantastic. How’d they do that?” “Oh, well, they used AI in a different way.” “Oh, it was an actual team.” “Oh, they had a designer on the team.” “Oh, the PM was not just a PM. They actually had some, like, engineering chops.” “Wow, fantastic. Amazing.” And they added some more clarity to their team, and they’re able to agree how they’re going to operate together.

And then building up those stories, it becomes more and more of a communications thing, and I think that’s where we’re at with this movement toward better ways of organizing and better ways of working, is that we have to have more and more of those, and do less of the thing that I see in corners of this work, which is purity tests around the way that we’re working or the way that we’re thinking about it or the framework that we’re using.

Mm-hmm. And instead, just keep pushing for teams that are working better and showing that they’re working better so that we can get more leaders on the side for this. ‘Cause the thing that I see most frequently is that when you introduce some of these ideas to mid-level, like it’s usually not the top of the organization, it’s usually not the bottom of the organization.

The middle of the organization, someone in that room will look at you a particular way when you’re talking about, “Okay, we’re gonna create some clarity on this team. Management isn’t just gonna be a role. It’s going to be a practice that’s going to be distributed across the team, and you, all you people who have great skills, you’re gonna get to do those skills again more than you were in the past.”

One person at least will be like, “Uh, this is… I don’t like this. You’re changing the handshake that I made with the organization. I like what I do. I like doing it the way that I do it. I do not want to give up the management authority that I have earned over many… many years, and I don’t want to do SME work anymore. I don’t know how to do that. I don’t like doing it. These people do, and I’m a good manager of them, or I think I’m a good manager of them.”

And they’re right in that. They’re right in that. So letting them, like, have a graceful off-ramp from that or just not trying to trick everybody into doing the thing that you want to do because it sounds nice or it gets more done, that’s one of the hardest challenges in this work.

Creating a Pattern Language

Jesse: Earlier, Peter touched on your book, Hidden Patterns, and this is a little bit of an unusual kind of a book. I wonder if you can tell us a bit about what inspired it and, yeah, some of the ideas behind it.

Clay: Sure. So it started in 2013 as an obsession with trying to break down problems of business strategy or corporate strategy or digital strategy or whatever it might be, into recomposable parts. So trying to understand the problem more accurately and then trying to resolve portions of the problem by finding solutions that were better fit to the form around it or the shape that we were trying to create.

That obviously touched on the work of, or was inspired by the work of Christopher Alexander, and I know that’s probably a big thing in your world as well.

And it was just rapturous for us to see problems in this new way. And we kept playing with that. It kind of became the root of the work that we did at August. When we got started with August and we started with one of our first clients, we wrote down all of the things that were working with our previous client work at Undercurrent, and we tried to make them as small as we possibly could so they could be recomposed into something that we could go deliver.

So we then rocked up to our big client and we were like, “Here’s our 50 things. We would like to go try these 50 things with some of your teams.” And they said, “Absolutely, fantastic.” It was our first client. We were so excited. And we got to, like, nine or so things that really worked. And I think August is still implementing roughly the same ideas.

So it’s this thing that has gone for me through multiple companies, has been a thing for me to try to take ways of working and break them down into not best practices, but patterns that preserve the context and tell you why you should be using those things and when they break and why you should modify them and, like, how they could fit together.

I had this idea that I’d been sitting on for a long time, and I feverishly wrote it and … ’cause I had all this material for it that was kind of like…

Jesse: Mm. Mm-hmm …

Clay: …poorly composed and things I’d half written or completely written and written seven different times. And I was able to, like, bring that into one thing and finally make the thing that I wanted to make that I would have wanted many years ago when I was getting started.

So it’s got, I don’t know, like, a intro that you can read in 30 minutes, and then 75 individual patterns that you can make your own, that you can remix, and that also are really interesting to play with with LLMs. You can use the stuff in the book, and I was intentional about putting it online for all people who have bought it and just tell me that they bought it, I give them access to the full text online.

Copy and paste it into your system of choice and use it to diagnose your problems. It’s cool to have something that feels like software instead of just a book of a framework that tells you the ways that you’re doing it wrong. So yeah, it was just kind of like a labor of love. It was, like, more of an art project than a business book, and when I was writing it, I had nothing to sell exactly.

So at the end of the book, it’s like, “Go work with my friends,” which I was very happy to do. So yeah, it’s a weird book. I love it, and it breaks things down from the biggest possible things like true purpose, structural and psychological safety, this weird thing that we encounter more and more every day, unfortunately, the idea of the importance of rule of law within the organization, and th- things all the way down to the physical space.

Thinking about the way that Valve puts all their desks on casters to let people move around to re-team with each other, and they couple that with the ability to actually dissolve the things that you’re working on and find the things that are most appropriate. So whiteboards everywhere and rule of law all in the same place, and everything in between.

Peter: Whiteboards everywhere. Very Christopher Alexander.

Clay: Yeah. Whiteboards every- ri- actually, it’s not whiteboards everywhere. It’s whiteboards at intersections. That’s the pattern, and I believe in that, and you notice the whiteboards that get used are in spots where people gather, and you end up seeing interesting ideas on them, and that’s the cool shit.

The Rule of Law

Peter: I’m curious of… You mentioned the 75 patterns, and you’ve identified a few. You highlighted rule of law, and that’s one, as I was looking at it, I’m– I’ve got my own project that I’m noodling on that I’ve realized is kind of adjacent to what you’re doing. I’m … I’m looking at a challenge that many who are listening to this will face is, and a question that often comes up is around, how do I make the company I’m part of more human-centered, right?

Jesse: Hmm.

Peter: Mm-hmm. And one of my missions in the work I do is enabling humanism within organizations. And so similarly-ish, I’ve been noting, like, what are maybe less patterns, kind of like criteria, components, elements, kind of these core operating aspects that either lean in towards humanism or lean away from it.

And been jotting those down, and then I’m between contracts, so I’ve been hanging out with Claude, throwing these ideas back and forth. But as I was getting ready for our conversation, I opened the book, I was flipping through it, and you have rule of law in there, which isn’t something that I had generated.

Like, the purpose stuff I’ve thought about, the psychological safety… some of the other things you’ve mentioned. But I’m curious, talk a little bit about rule of law, why it’s foundational. And you mentioned it feels hotter button right now to talk about it. Yeah. What is that?

Clay: Take a hypothetical organization Where there are different rules for different people.

Peter: Right.

Clay: And whether that’s a function that is better liked than another and is able to spend more lavishly on a conference that they want to go to, or a dinner that they wanna go out to, or that salesperson over there sells more than everybody else, so they get to do things that other people don’t get to do.

And this pattern, this idea of rule of law in the organizational sense, is just that we are going to live by the rules that we have written down, and we are going to adjust them when we have cause to adjust them. But we’re going to hold ourselves, regardless of the seat that we happen to be in, we’re gonna hold ourselves accountable to them through some mechanism.

Doesn’t need to be like a draconian mechanism, like, “Oh, if you break this rule, you’re gonna be out all the time.” It can just be, “Look, we’re gonna hold you accountable, and however we’re gonna do that, we’re gonna do that.” Might be a conflict management process, might be something else. And implied in there is that we are going to have a set of rules of the road that we actually think about, that are not handed to us by bureaucracy or by tradition.

So to me, it’s just holding ourselves accountable, everybody, to the same rules. Or if that salesperson over there does get unique privileges, write those privileges down somewhere and agree to them- Codify … so that other people can understand them. Once the rules are visible, people can challenge them.

That’s much more useful than making everyone guess which rules count. But Jesse, to your point a- around, like, fixing that ossified thing, fixing it starts with naming it and being able to address it, so there’s a few things that kind of like bleed out from the idea of rule of law, but that’s the…

Peter: all right, Wittgenstein.

Clay: …the idea. Sure.

“Design slows us down”

Peter: No, I, I, you know, I wrote my whole book on org design because I realized you needed to define these things. And we tend not to recognize the importance of agreed-upon terminology, and then we end up talking past each other and then wonder why no one knows what’s going on.

I’m curious, though, as you were talking about writing it down, I wonder if you get the same kind of pushback that design has often got, uh, UX design has often got, which is you’re slowing things down. If we do, if we wanna do things your way, it’s gonna make us slower by following these rules and programs and processes of documentation or whatever, and we don’t have time for that.

And if so, if that is a common pushback, how you’ve addressed that?

Clay: Very common pushback. Yes. Why don’t we just get started? Why don’t we just do the work?

Peter: Yeah. Why do we need a charter? We know what we’re doing, right?

Clay: Yeah, yeah. I will usually have basically a contest. You take one of your teams, and you keep doing your thing.

Give me another team, and let me show you what they can do. And the numbers are… They tend to be outlandish. We talk about, oh, AI is going to be, like, this enabler of super performance for teams. We already have it. It’s just a good team. A good team is super intelligent. We’ve all experienced, in the best teams that we’ve worked on, this feeling of a hive mind.

That’s what we’re going for here, so let, let’s just do that. Let’s just do that more, more frequently. And what I find is, over and over, the teams that actually spend a bit of time getting their shit together up front, they end up delivering. Whether that getting their shit together is writing it down or whether it’s going to a mountaintop and becoming one with one another through time and place, I don’t care.

It could be either one of those or somewhere in between. But just do that and see what comes out of it. And they get… Again, the numbers are crazy. It’s, “Oh, we had a 4,000% improvement.” It’s like, “What? Clay, that, that can’t be true.” Well, it- … it’s very true. Here’s a project that we’ve done before. We did it Clay’s way.

It was so much faster, and everybody was thrilled, and everybody stayed, and they hired their friends. It’s just, it’s… Everything about it is better, and it is free. Teaming is free.

Peter: I’m curious then, actually ’cause I agree, and, and I think org designers can be a bit like Cassandras. We’re just shouting truth that no one is hearing.

But I’m wondering what you make of the resistance to it, right? In a world that claims to be data-driven or evidence-driven, why so many decisions are being made that actively thwart the stated desired outcome? And, like, how, just through your observations, what do you make of this contradiction between, you have evidence that a different way works better, and yet most organizations are behaving in ways that are antithetical to their own success?

Clay: I mean, I have dumb answers to that mostly, and they’re like, look at the world around us. You have to believe in state capacity and institutions and people and the fundamental goodness of people, and you have to believe that people want to get more done. You know, you have to believe that the road is publicly funded, and having a grocery store that’s publicly funded is also fine.

The world is not in our favor when it comes to this stuff. I think it is also just, it’s hard. It’s hard to do this. Building a team within an organization that wants to operate in a particular way, and the rest of the organization operates differently. Dealing with that dissonance, that’s hard on its own.

And then helping people get over, this is a thing we experienced at August, is nobody expects you to be true to what you believe when you believe the things that I think we do. When you’re like, “Every role in this team is going to hold equal stature regardless of their seniority,” people are like, “Yeah, okay. I’ve heard that before. We know this, how this is actually going to go, and I’m not gonna trust your word on this.”

And people, like, getting over their well-earned baggage around the way that organizations work, the way that people are asked to lead, that’s hard, too. It’s just hard. It’s harder. But it’s better, and I’m okay with that.

Jesse: But maybe just a touch of optimism can get people through.

Clay: Thank you. I… Funny thing was the first person who read my manuscript, he’s like, “It’s kind of, if you read it all the way through, it’s kind of a bummer, because every single chapter starts with, ‘This is why the usual way you do this is broken and terrible. Here’s a better way of doing it.” And I’m like, “Uh, it’s a little late to change that.” And it’s true, though. I do believe that, it’s a window into my, into my soul, I guess.

Peter: Though it’s also, I mean, another way to take the book is that it is utopian.

Clay: Oh, yeah.

I

Jesse: think so. Yeah.

Clay: Yeah.

Jesse: Yeah. Yeah. I think so. And I do think that implicit in it is the idea that if we believe it’s possible, then it can be.

Clay: Yes. Great podcast title, by the way.

Jesse: Clay, thank you so much for being with us.

Clay: Thank you, guys. I really appreciate it. And seriously, as a super fan- … it’s so cool to be here.

Jesse: Thank you so much.

Clay: I cared about intranets so much when I was young, in ways that, like… yeah. Anyway. Yeah. So anyway, thank you for doing the work that you’ve done.

Peter: Oh, thank you.

Clay: Yeah.

Peter: It’s been great to have you- Yeah … on the show. Thank you for not just Hidden Patterns, but the commentary generally on… Well, we usually ask, so let’s ask. Clay, how can people find you on the internet?

Clay: Most places, if you just search for Clay Parker Jones, you’ll find me. Current website, because I’m bad at managing domains, is cpj.fyi.

And with the help of my friend Claude, I was able to get all of the back history on the back issues off of Wayback Machine onto the current version of the site, which means you can go back to 2006 and read some really dog writing from me. Terrible. So, but it’s there.

Peter: Awesome.

Jesse: Thank you so much.

Peter: Yeah. Well, thank you for, for what you’ve contributed as well.

Clay: Thanks.

Jesse: For more Finding Our Way, visit findingourway.design for past episodes and transcripts, or follow the show on LinkedIn. Visit petermerholz.com to find Peter’s newsletter, The Merholz Agenda, as well as Design Org Dimensions, featuring his latest thinking and the actual tools he uses with clients. If you’re looking for help with AI transformation or you just need a private advisor to help you solve your hardest leadership problems, visit my website at jessejamesgarrett.com to book your free one-hour consultation.

If you found value in something you’ve heard today, we hope you’ll pass this episode along to someone else who can use it. Thanks for everything you do for others, and thanks so much for listening.