Richard Banfield, Advisor & Recovering CEO
Transcript
Chris Strahl:
Hi and welcome to the Design Systems Podcast. This podcast is about the place where design and development overlap. We talk with experts to get their point of view about trends in design, code and how it relates to the world around us. As always, this podcast is brought to you by Knapsack. Check us out at knapsack.cloud. If you want to get in touch with the show, ask some questions or generally tell us what you think, go ahead and tweet us at @TheDSPod. We'd love to hear from you.
Hey, everybody. This is Chris Strahl with the Design Systems Podcast. Today I'm here with Richard Banfield. Richard is a recovering CEO, artist, mentor, advisor. He actually advises Knapsack. And we wanted to get him on here to just talk because we always end up having really interesting conversations. So I'm sure I missed something in that introduction, but Richard, welcome to the program.
Richard Banfiel:
Thank you so much, Chris.
Chris Strahl:
So tell us what you're up to these days. Let's start there.
Richard Banfiel:
Yeah. So I have a dual life. I spend some of my time advising, both for-profit and nonprofits, and I spend a lot of time doing creative work, which is artwork. I'm also a writer. I'm working on my fifth book. And I'm also working on treatment for a movie as well, so I've done two documentaries when I was at InVision, along with Ben Goldman and Dan Cohen, and so doing a treatment for a future movie as well.
Chris Strahl:
Yeah. I think the first time that we met was when you were at InVision and the company that would become Knapsack was doing some consulting work for you all, and that was our first conversation ever. And I remember being struck by your point of view on design and work and how we all think about this. When we were initially talking before the show, there's this idea that you have that design systems are actually this really interesting Trojan horse for organizational change. So maybe let's start there.
Richard Banfiel:
Yeah. You and I have discussed this in the past, and that is that work as a function of how we get together and do stuff every day is not working. So work is not working. And we are very often lulled into a false sense of security by the structures and organizational, let's say, hangovers that exist within the business world. So things that look and feel like they're supportive, like the structures, like the hierarchies, like the titles often are the things that are most likely to cause friction as well. And where I see design systems being a really, really interesting part of that conversation is that when you introduce the idea of creating a design system, you're actually introducing the idea of working together.
And that might sound oversimplified, but think about it. How many people do you know, know how to work with others in an almost guaranteed positive way? It's very, very rare. So when you introduce the idea of a design system, you're not saying the design system is going to solve our problems. What you're saying is the conversations about how we work together, that is going to bring us closer, that's going to tighten the relationships, it's going to allow us to relate to each other, that relationship that we build with each other is going to create additional or maybe in some cases even start trust, and that trust is going to create confidence in each other. That reliability cycle that's going to be created through questions and answers and trust flywheels, that's going to lead to a better organization.
So the reason why I think it's a Trojan horse is because very often, people think about design systems as being functional. They're not functional at all. What they're doing is helping people understand who they're working with. If I'm a designer, I suddenly now need to know who I'm working with on the other side of the table, developer, engineer, product person, marketer, etc. I'm going to have to have conversations with those people that maybe I don't normally have conversations with, and I'm going to be forced to relate to their work, create empathy and understanding about what they're challenged by too before I can create a great design system. So that's why I think it's a great starting point for teaching people how to work with each other.
Chris Strahl:
So the causal loop in your mind is really this is about a way of working that is different because it's empowered by systems. And so that design systems tool or hard system that exists inside of this framework is really about how do we change a lot more about our fundamental way of working together where we go from these old models that are broken? You talk about the hangover. I wish I was there for the party sometimes. The idea of these faux supportive things that we all do inside of modern corporate structures that ultimately represent conflict. And that's like fiefdoms and interpersonal scrutiny and internal competition that exists and the climbing the corporate ladder, is that what you mean by all this stuff?
Richard Banfiel:
Yeah, it's like Conway's Law and the reverse of Conway's Law. So Conway's Law is suggesting that the way that we communicate with each other ultimately determines how we're going to design our systems, but the reverse can also be true. The way that we design our systems will ultimately determine how we communicate with each other. So if we're building a system based on age-old military and factory models, like hierarchies, titles, managers, the idea of just that I need a manager to tell me what to do is the most archaic thing and so condescending. It's so weird to think there are people that have knowledge and there are people that don't have knowledge. Even that term knowledge worker suggests that somebody doesn't have knowledge.
So we are creating systems based on models that even the military gave up on. I was in the military, and I can tell you that the military has evolved far more than businesses have. We've thrown out some of those old models where it was a top-down hierarchy of decisions. Can you imagine trying to manage a war where you've got people on the ground and there's somebody sitting in an office 5,000 miles away making decisions? Well, that doesn't work. You've got to return authority to the people on the frontline. But in business, we're still using even the vocabulary of military. We're still using sports analogies. We're still using factory analogies. We haven't evolved to the point where we're giving people the authority to make decisions.
And that's where this design system conversation becomes so powerful because suddenly, you can have conversations about, well, how do we make decisions? How do we come to an agreement? How do we solve conflict? Oh, we haven't decided any of those things. Great. Let's have those conversations. And that then leads to a change in the way that we work with each other. So it's not the design system that's fundamentally improving the organization. It's the conversation around the design system that's improving the organization.
Chris Strahl:
When you think about these ideas, these theories behind the way we've structured hierarchy in companies, the two apparent conflicts that come to mind was the old adage that shit rolls downhill but praise always goes upward, always floats upward. And then the second side of it is you can't advance in your career unless you become a manager. I think that both of those two things are really interesting. When you think about the idea of how does gratitude and praise in an organization work and how does credit and then also blame work inside of a company.
And so when you think about those things, the hierarchical models are still fundamentally what we use there. There's very little to suggest that we're in a situation where those aren't the preeminent ways of thinking in most of corporate America. Likewise, this idea that your career ends if you have no more IC advancement to go, and thankfully we're starting to fix this. We're starting to get this idea that people that are really good engineers or really good designers probably should still write code and design things. There's now some career pathways in some organizations that are laid out for them that aren't about all of a sudden managing other people.
And I think that probably the best place for this is, ironically enough, our education system where you have an administrative track, which is completely independent from what the educators do, it's different degrees, it's different training, it's all that stuff. In corporate America, it's totally normal for somebody to have been a designer working in production design, working in product design, working in any number of design disciplines, that is all of a sudden like a VP of design at a company with the exact same education, the exact same career track as another designer that goes on to be a creative director or another designer that goes on to be a CMO or something like that. But that's weird if you think about it because none of those people-
Richard Banfiel:
[inaudible 00:08:57]
Chris Strahl:
Those are very different skill sets, and none of those people are actually doing the design work that much anymore.
Richard Banfiel:
Yeah. So think about it like this. We'll use product managers because they tend to be the ones that end up in these positions coming from lots of different angles.
Chris Strahl:
This is great because we don't pick on product near enough in this podcast.
Richard Banfiel:
And if you think about how you get to product, very often, it's a mistake. You saw it as an engineer. You saw it as a designer. Maybe even in marketing or you're just a program manager. You were really good at project managing, and then suddenly you said, "Hey, I've got this idea. You should be a product manager." And so because the word product precedes the word manager, the assumption is I'm going to manage the product. Same is true of design manager or engineering manager. I'm going to manage the design. I'm going to manage the engineering. That is a fundamental flaw in the way that we're setting up these communication structures because what we're doing is undermining the work that actually happens.
The product manager or the engineering manager or the design manager isn't managing the product. They're managing the team that makes the product. Their skillset is people. Their skillset is ideally how to assemble and maintain a group of people in a healthy way. God help us, Chris. We have not taught anybody how to do that. We're saying, "Oh, you're really good at pushing pixels around. You must also be good at managing people." This assignment of skills. We're just going to pass the skillset onto that or the assumptiveness of that. That's like saying, "Oh, you're really good at piloting airplanes. I bet you'd be really good at piloting submarines as well."
Chris Strahl:
Right. Or even better, you're really good at adding fuel to a jet engine. You could totally fly the plane too.
Richard Banfiel:
Oh yeah, yeah, exactly. Yeah, just get in the cockpit and go and do it. So I think what we've got to do is, and this is what design systems are really doing, they're asking really, really interesting questions. When you at Knapsack or your teams are introducing design systems, you're not asking people to adopt technology. You're asking them to ask interesting questions about how people work. And when you're asking questions about how people work, they start to wake up and go, "Huh. We're basing a lot of the work that we're doing on assumptions. We're basing a lot of our skills required for the job on the associated skills, not the skills themselves. Oh, you're a good designer. You must be able to manage designers." No.
That doesn't mean you're a good psychologist or a good therapist. And that's half the work. The half work is, "Hey, this person needs help. This person is not in a healthy state of mind because of whatever is going on in their life. I need to help them. I need to give them guidance. I need to provide the necessary personalized structures around them so that they can be the best that they can be." That's not design. That's something else.
Chris Strahl:
Totally. I'm also annoyed that we oftentimes are really reductive about this, and we talk about it as like, "Oh, they're good at soft skills." And the reality is that managing people is not necessarily a soft skill. Maybe being charismatic is or something like that. But it's such a hard skill. It is absolutely something that can be taught. It can be learned. And you can get much better at managing people.
I think about before being a CEO and then now being a CEO and the difference in the tack I take with trying to get work done is really fascinating because now, most of it is, like you said, how do you ask the right question in the right moment? And oftentimes, that takes a high degree of humility and a willingness to feel pretty stupid. And then the second side of it is how do you put the right people in the right place and then give them the tools they need to be successful? Because as CEO, there's a lot of things I could do on my own, but I'm probably not the best person to do them. And so how do I go find that person that is the best person to do it and then empower them in the right moment by asking the right questions and putting the right structure in place to make sure that person is successful? And man, had you asked me that six, seven years ago, I would've had no idea what you were talking about.
Richard Banfiel:
Yeah. So the reason why design systems get me excited is because the fundamental parts of a working system require answers. So think about that for a second. If I'm trying to build a system and I don't have answers, I cannot complete the project. So it's the quality of the questions that I'm coming to in the design system conversation that are going to lead to a better outcome. And the questions are very often, how do you work together with the other people on the team, with your designers, with your engineers, with your developers, with your marketers, with your senior leaders, with your customers? Those questions aren't basic questions. They're hard questions. They require detailed thought. They require a conversation.
Chris Strahl:
My favorite probably microcosm or example of that is naming. When people talk about naming, they talk about naming things being hard. Naming things is absolutely hard. Giving something a moniker is really challenging, but the depth of that challenge isn't really apparent until you try to get other people to use that same name and also understand what you meant in the context of that name. I think that when you think about naming things being hard, you're not just talking about naming it for yourself, you're talking about naming it for designers and engineers and product and content people, all these other folks inside of a design system because they all touch it.
This is actually fundamental to one of the tenets of Knapsack, is that the two things that we really cared about when we were creating Knapsack is that it innately has to be cross-functional and that it has to rely on some structure, like some structured data. The information in it needs to have a structure to it. And so that is all about the two things we've been talking about, this idea of, okay, so how do your communication structures support what you're actually trying to do, which is get work done? And then secondly, how do you make sure that those are meaningful and varied to all the different types of people that need to interact with that system?
We've been really, really hard on the idea of if you don't have designers, engineers, product people, content people, even marketers and brand people all using the same basic system as a foundation for knowledge, you don't have an effective design system.
Richard Banfiel:
Right. When I was at InVision, one of the team was this amazing woman called Emily Campbell.
Chris Strahl:
She's been on the podcast before.
Richard Banfiel:
Yeah. And she used to talk about how words matter. They really, really matter. Vocabulary really matters. Names really matter. And as an artist, one of the things that it reminds me of is Claude Monet used to say, "To see, we must forget the name of the thing we're looking at because in the word, in the description, in the name, we are putting our own perceptions, our point of views, our biases in the name." So just by naming it, we're changing the nature of the thing. It's like quantum mechanics. Once we have observed it and put our perspective on it, our will around it, we've changed it. And that requires a conversation. And that's the kind of conversations that are worth having in an organization. What are we going to name this? Why? Why is that important? What biases are we leading? What are we going to design AI? Anything that we are creating is just another version of fractal of ourselves. And so this is why design systems really, really, really work so well to get an organization talking, is because you cannot stand up a design system without having these good conversations.
Chris Strahl:
Do you think this also might be why design systems often have a pretty high failure rate after the first year or two?
Richard Banfiel:
Absolutely. Yeah. You've nailed it, because it's like if you're not willing to have the conversation then what's going to happen? You're not going to get to the answers. You're not going to have good quality answers. And that is for you maybe a leading indicator. How good quality are these questions? How good quality are these conversations? Because that is an indicator of what will follow.
Chris Strahl:
We actually used to have this, funny enough, in our lead scoring framework. First time we would ever talk to a customer, we had this maturity assessment that we would make associated with the way they think and the way they talk about these systems concepts. And we ultimately felt like it was a little too subjective, but it was something that I did enjoy the process of going through, is to try to understand how much do we reasonably or how confident are we that an organization is willing to make the change necessary in order to see a successful design system towards some fruitful realization?
Richard Banfiel:
Yeah. Yeah. And the question that the organization would need to ask itself that you could ask them to go and think about or noodle on is how are we going to be complicit in the failure of this? So before we've even started, how are we going to fuck this up?
Chris Strahl:
Right, exactly.
Richard Banfiel:
And how are we going to be complicit in that? Because if they are willing to do that thinking about what could be the things that they could do in order to really screw this, they will also be aware of what the failure points might be. So I love the idea of the lead scoring because subjectivity and lead scoring actually works really well, surprisingly. And it's the same as team health. If you walk into a room with your team or you have a virtual meeting and you draw a horizontal line across the screen or on the whiteboard, depending on your context, and you asked everybody in that room to place themselves either above the line or below the line, where above the line would be open, curious, in discovery mode, empathetic, below the line would be frustrated, angry, closed, not willing to work with others. And just ask people, "Hey, it's Monday morning. Where are you? Are you on the line? Are you above the line?"
It's perfectly acceptable for somebody to walk in the room and say, "I'm below the line. My dog got sick on the carpet. I slipped and fell. I've injured my ankle in puke. It was a bad morning." So that subjectivity, people are really good at understanding where they are. And then the knowledge that they've shared as to where they are is also instructive in telling them where they need to be. So you're not saying, "Well, you need to be above the line, otherwise you're not a good team member." What you're saying is, "Where are you? And subjectively, how do you think that's going to help you with today?" You can be below the line and still do work. Maybe that's where you need to be. Maybe you just need to be, "Hey, don't bother me. I'm just going to focus on my work. I haven't had my coffee yet." Or, "Hey, I'm ready for my one-on-one. I'm feeling like this is the perfect time for that kind of thing."
And the same is true of design systems. If I walk into a conversation about design systems, one of the things that I'm going to ask the team is, are we above the line? Do we feel like this is going to be helpful? Is this going to be instructive? Is this going to create good conversations? Are we going to have an interesting dialogue about the work that we're going to do here or do people feel defensive about it? Do they feel like the design system is replacing them in some way or that it's here to undermine their craft or whatever it is, which are all reasonable conversations, very reasonable conversations? Yeah, I'm scared of this thing. Yeah, it sounds like a lot of extra work. Yeah, I don't want to have these personal conversations because I'm an introvert. I don't know. Any number of those things.
But once you start having those conversations, the subjectivity quickly becomes objective because now, it's out in the open. It's not rattling around in my head, scaring the crap out of me. It's now something that we can all look at empathetically and say, "Hey, that's a reasonable way to react to this. It's a reasonable way to be feeling about this. Let's talk about that." And that's why these conversations are important. It starts subjective but it moves to objective very quickly, and then that pattern of behavior starts to become the new way of working, and that's when you see a design system really take hold. It's not the design system, Chris. It's the patterns of behavior that have changed that support that.
Chris Strahl:
Absolutely. I think to some degree also, it's a bit of a change in the power structure of the organization. I like thinking about this in terms of power structures. I do that a lot with a lot of things. But when it comes to design systems in particular, who makes the decision in a traditional design organization? You would go into a design review. There'd be a VP or a director there that would critique a design, give feedback and be like, "All right. Go change these 11 things and then come back to me with red line designs in six days or something like that."
That process would go through this filter, and that filter was, I don't know if important or necessary are the right words, but that filter was present largely because somebody needed to represent that flow control for the organization. That was the vision, the one mind. And even in books like Mythical Man-Month, you have this where the single vision, single product owner or engineering mindset owner that is the one that builds the best software because it doesn't dilute the vision. But I think that the power of design systems in this is you're basically saying like no, there is a collective vision that is actually better than what any single person's, executive or not, opinion is. And we need to decide that all together based on a series of incremental improvements to the building blocks of our system.
Richard Banfiel:
Okay. So let's stop there for a second because you've just nailed a critical part of the work that needs to be done, and that is these iterative things. So iterative is not we have a plan, now we're going to go and execute on the plan. We spent three months thinking about how we're going to do this, and now, all we have to do is do the thing. I can guarantee you that's going to fail a hundred percent of the time, not 99%, a hundred percent of the time.
Iterative means we have a pretty high confidence, maybe 80-plus percent confidence that this might work the way we think it does. But in order for us to actually find out, we have to do thinking by doing. We have to make a thing. We have to create a thing. We have to prototype a thing. We have to build a thing. And only once that thing touches the universe will we know whether the thing that's in our head is actually manifested in reality in a workable way. And that feedback loop has to be tight. Small teams doing small chunks of work in this almost experimental way are going to build knowledge really, really, really fast, and they're going to get excited about the work because they're going to see evidence for their thinking.
Teams that spend six months planning and then 18 months executing are always going to fail because nothing survives touching the universe. As the most important philosopher of our time, Mike Tyson said, "Everything is great until you get punched in the face." And that's true of design systems. It's true of any work that we do, is that if we are not prepared for hard conversations on a regular basis, we're not going to build the muscles associated with finding answers, finding ways forward. We're always going to get stuck in complain mode, which is, well, the plan that the engineers handed down to us is shit, or the managers didn't know, or the critique was too subjective. There's always a complaint.
But when you're actively doing the work and you're doing it in these fast cycles, you're the only person who can complain because it's you doing the work. You're not waiting on anybody. You're doing the work. You're making the thing. You're putting it out there and you're getting feedback immediately.
Chris Strahl:
Well, I think this gets back to the point about organizations and the insidious nature of top-down organizations, that idea of in a potentially positive light, I'm always waiting on somebody. In a potentially negative light, I'm always passing the buck because it's always somebody else's fault. There's a lot of people that I think would say, that are listening to this podcast right now, that I work for ... the type of organizations is the inverse of that, a Theory Y organization, to use Maslow's definition, where you have this idea that everybody is empowered and creative and enabled to do their own work. But the reality is that the vast majority of us don't work in that kind of company. And it takes active constant reminders that hierarchy and titling are unimportant, that what matters is the way that we collectively meet and get the work done.
And Theory X organizations, the hierarchical top-down ones, are very insidious about masquerading as things that they aren't. This idea that like, "Hey, I'm not a top-down organization. I'm empowering you. I'm giving you this bit of work or this zone of control inside of the organization that is yours." But ultimately, there's still that communication flow and that idea of approvals and resources that are flow controlled through a very small collective of individuals at a lot of these companies.
I think that's fundamentally what it comes down to. When I think of about the disassembly of that power structure inside of big enterprises specifically, is what a design system is doing is it's collecting all that power, all that resource, all that communication, all that capability into one place and then giving it away to everybody, and then also letting them change it. And that is an incredible amount of power that then all of a sudden gets removed from people that have traditionally controlled how those resources move through an organization and how that communication moves through an organization. And that to me is a bit of brilliance. I've always been like a smash hit. I loved punk rock growing up. And being able to do a little bit of that to the corporate structure feels really good with this stuff.
Richard Banfiel:
Yeah. And it's necessary. So we've outgrown those old structures. We've outgrown those hierarchies. We've outgrown that language, that vocabulary, and it's necessary for us to come in and ask these hard questions. The design system allows us to have that conversation in a constructive way, not in a smashy way. So we're not coming in and saying, "You guys are all assholes. We hate you. You should be thrown out with the rest of the old white guys." We're rather saying, "Here's a great place to start a conversation. Here's a great way to return authority. Here's a great way to empower people. Let's start here, and over the coming months, we can build this thing and provide for the opportunities for us to all learn."
It's a great filter as well. Some people are not going to show up for that. THey're going to be like, "Well, I don't want any part of this, or this is going to affect my job, or I'm not going to be able to manage people in the same way." Great. You have now shown your true colors. Now we understand why you're there and we can deal with that.
Chris Strahl:
Right. It's because it's out in the open. It's funny. I live in Portland, Oregon, so I immediately go to the inner protestor in me. I'm definitely much more about marches and megaphones than molotovs, especially when it comes to business.
Richard Banfiel:
Yeah. Yeah. My son and I just launched, I have a 20-year-old son, we just launched an apparel brand called Domestic Propaganda, and the tagline for that is the lies we tell ourselves are the worst lies. So it's the internal conversation. It's the organizational conversation that we're talking about here. The light that shines when you walk into the kitchen and turn on the light and you see all the cockroaches scurrying away, that's the design system. That's the light switch, when you turn the light switch on and the cockroaches are suddenly exposed. That's what I like about it. You're like, oh, here's a mechanism for us to expose what the actual incentives are, why we use these languages, what the biases are, what the privileges are. That's a great place to start.
It's a very, very different starting conversation when you walk in and you're saying, "Well, we're just going to turn everything over here. We are going to throw those molotovs monotypes around and see what happens." That's not constructive, but a design system is a constructive way to do exactly the same thing. It's soft power versus hard power.
Chris Strahl:
Right. That's a great way of putting it.
Richard Banfiel:
There's a series on Netflix, I think it's on Netflix, called Diplomat. It's new-ish, and there's a line in that movie, which I just absolutely loved. I think he was previously an ambassador and he's doing a little talk at the Chatham Club, which is where the Chatham House Rules came, or the Chatham House. And he's talking about diplomacy, and he says, "Diplomacy fails every single time until it doesn't." And his point is keep talking, talk, talk, talk, talk, talk until somebody answers you, somebody gets to an answer because the lack of talking is what's getting us in trouble. It's not that we're talking too much.
Chris Strahl:
Yeah, I can totally see that. I think that through those conversations, I view a lot of the intention behind design systems is trying to find the right working relationship that we want to have with each other. And often, that exists in some form within a team, but it's really hard between teams. And there's the old adage of design is in floor seven and engineers in sub-basement two, and if you just moved move them all to be on floor three, maybe everybody would get along and maybe the design system is floor three. I don't know. I feel like I'm stretching this metaphor a little bit too thin. But the idea being is that you want to have the same decisions, agreements, communication, trust inside your team as you do within all of the stakeholders that are involved in the creation of your product.
I think about that as it's never more present than in the design to engineering handoff process, but there's lots of other places too where that comes into play where just a little bit more trust or just the right kind of communication or just the understanding of the way of working and the empathy for the others' considerations in that goes so far at making not just things faster and better and feeling like it's not as draggy but actually making better product too.
Richard Banfiel:
Oh yeah, yeah, of course. Any of the things that lead to understanding and empathy are ultimately going to lead to a better product. I read somebody complaining recently on, I think it was on social media, where they were saying that the number of comments on engineering code has gone down dramatically since we started working remotely. And I thought that was such an interesting thing because does the number of comments on code have anything to do with team health?
Chris Strahl:
Fascinating. Yeah, of course, it does. Remote work and team health and all this other stuff like that. If people are dissatisfied, like that extra five or 10 minutes or whatever it is to make that comment to make something better, that feels like a lot, it feels like a lift.
Richard Banfiel:
Yeah. I don't know whether those things are correlated or not, but it should be that we are thinking about measuring team health, not necessarily by proxy. So I don't know how it'd come out on this particular comment thing, but is there a better way to understand whether those teams are healthy or not? Not just looking at the number of ... I'm old enough to remember when the number of lines of code was the indication of the productiveness of an engineer like, "Oh, I worked more lines of code than you."
Chris Strahl:
You must work at Twitter, right? Just kidding. I know there's Twitter people listening to this.
Richard Banfiel:
Obviously, the thing was we would then wonder to ourselves, "Oh, that's a vanity metric." Why does it matter? And I wonder whether comments or the number of comments is a vanity metric or whether it actually is a leading indicator as to whether the team health is not there. So these are like we're in interesting times. As leaders, we need to be asking these questions. How are we going to understand whether the team is working well together, whether those, as you said, across team or inter team disciplines are becoming healthier or not, and whether the systems that we're using are going to be able to encourage that kind of behavior? Maybe fewer comments is an indicator of higher team health. I don't know.
Chris Strahl:
Totally. That's interesting. It's an interesting thing to think about, the idea of how much does that one metric matter and what's the root causality of it. I think that regardless, we're in this interesting place where the idea of old product metrics, those have been completely fucked forever. What's your velocity in terms of sprint tickets is my least favorite metric of all time. Mostly because I was a program manager and having to do velocity reports to leadership was fiction. It was the least truthful and least authentic I was once a week, was basically figuring out what's our team velocity.
Richard Banfiel:
Hey, I was there as well. I think I said velocity more times in a week than most people.
Chris Strahl:
Oh, totally. And that's what everybody thought mattered. And same with the idea of lines of code or number of commits or frequency of releases, all this stuff that is frankly not nearly as important as is your team stoked about the work they're doing and do they trust each other and are they coming to work every day being really, really excited about what they're building or are they just dragging?
Richard Banfiel:
Rick Rubin just put a book out recently. I don't know if you've seen it, but it's a book about creativity and he's talking specifically about the music industry, but he has the same perspective of any creative work, which is we're not looking for consensus. That's not the point. We don't all have to agree on everything all the time. What we have to do is understand that the work that we're doing is meaningful, and if we're not spending time with each other and we're not relating to each other, how are we supposed to understand that? So even something as simple as like, oh, are we aligned? Well, that could be top down as well. Alignment could be like have you read the mission statement? Have you read the strategy for the year? Have you looked at your OKRs? Are those things really, really going to make a difference? Probably a little bit.
But what's really going to fundamentally change the team is the agreement on how they're going to behave each day. Here's how I'm going to behave, and when we have conflict, here's how I'm going to behave, and when things go right, here's how I'm going to behave. That way, you can be guaranteed that when somebody comes to work that you have trust, and when you have trust, you can build anything.
Chris Strahl:
I love that. So Richard, insightful as always, loving this conversation. Thinking about how we tie this up, we talked a lot about philosophy. We talked about some really practical things about systems. If you had to impart one piece of advice as an advisor to the audience, what would that look like?
Richard Banfiel:
So one of the things I encourage my clients or the teams that I'm working with to do is to create what I am referring to as how we work document. Now, it sounds ridiculously simple, but I think we've gone through the Simon Sinek era of why. So Simon Sinek was really good at telling us we need a purpose. We need meaningful work. We need a reason to get out of the bed and come to the office or just show up for work every day. But where we are now is that now that we are looking for meaning in our work, we also need to understand how to deliver on that meaning, and I encourage all teams to sit down and think a little bit about how they work with each other. How do we communicate? How do we make decisions? How do we come to agreements? What are the methods that we use to find answers to questions? How do we experiment?
All of those things are very, very, very simple questions but difficult to answer because they are context specific. There's no downloadable thing that you can just say, "Hey, this company over there did it. We've now downloaded the Netflix culture document. We should just do whatever they do." You've actually got to answer the questions in the context of your organization. And the how we work document becomes this living, breathing thing. It could be anything. It could live in code or a notion or it could just be a Google slide deck. It doesn't really matter, but it's a place where we can all go and say, "Yeah, how do we get to answers? Or if I'm new to the team and onboarding, how do we make decisions? Oh, there's a decision stack. We start here and then we go through all these things." It's a little bit like do you remember when the culture canvases were really popular?
Chris Strahl:
Business model canvas, culture canvas, all that stuff.
Richard Banfiel:
Yeah, it's kind of like that but it's a slightly updated version of it, saying in the simplest possible terms, "Hey, Chris, how are we going to have a relationship?" In the same way that you might write a charter with anybody meaningful in your life. I wrote a charter to myself when my wife was very, very sick with cancer and we knew that it was terminal. I wrote a charter. I was like, "Richard, future Richard is an idiot because he's going to be grieving. He's going to be a mess. He's going to have all these responsibilities, but he won't know what to do with it because he's going to be an emotional hot mess." So I wrote a charter to myself, and I encourage teams to do that.
Write a charter, a how we work charter for your future selves. "Hey, it's all good and dandy. We're all getting along right now, but what happens when the shit hits the fan? What happens when the runway isn't quite as long as we thought it was? What happens when the crypto winter descends on our particular market or our investors and our board decides that they want us to pivot in a different direction?" What's going to happen in the future? And let's talk about how we're going to make those decisions. How are we going to come to an agreement? How are we going to resolve conflict? Because if we do that now, we're going to be in a much better position to be able to reference that and say, "Hey, remember when we were in a great state and we were talking about those things? That's when we were smart. Now we're not very smart. Now we're panicking. Now we're stupid."
That's the same thing with design systems. Build a system that is anti-fragile, that as you use it, it gets more and more powerful because it has better and better answers to your questions. Not something that's just robust or reliable, but something that's building on the future of the company with new knowledge. As we integrate new ideas, new feedback, we are getting more and more anti-fragile. It's like the Hydra. You cut off one head, two more grow. Design system should be like that, or any system, communication system should be like that. If I use this system, it gets stronger, not weaker over time.
Chris Strahl:
That's great. I haven't heard anti-fragile in a while. I was trying to think about the last time I heard that, but it is a really good way of thinking about what kind of system to build. It's a system that, yeah, it's about design and code and patterns and components and all these other different things, but it's really intended to be the system that governs your way of working between all the different disciplines in your organization and making sure that has this anti-fragile idea baked into it is going to make it so that it doesn't end up one of those failure statistics I was talking about.
Richard Banfiel:
Yeah, exactly.
Chris Strahl:
Well, Richard, it's been so great. It's always wonderful to have you. Great chatting and let's catch up again soon. This has been wonderful.
Richard Banfiel:
Thank you. Thank you for hosting it. Really appreciate it.
Chris Strahl:
This has been the Design Systems Podcast. I'm Chris Strahl. Have a great day, everybody.
That's all for today. This has been another episode of the Design Systems Podcast. Thanks for listening. If you have any questions or a topic you'd like to know more about, find us on Twitter at @TheDSPod. We'd love to hear from you with show ideas, recommendations, questions or comments. As always, this pod is brought to you by Knapsack. You can check us out at knapsack.cloud. Have a great day.
