Podcast: Play in new window | Download

Paul [00:00:01] Hello everybody, we are super excited to be joined by Richard Banfield today. I am honored to be in the presence of product hero of mine. He is a prolific author. He is known for his curiosity, his product design and leadership. He has four books on the subject and he’s coauthored on the topic of design sprints with a book of the same name as well as product leadership. Richard also authored Design Leadership and Enterprise Design Sprints. And when he’s not writing, speaking or teaching, he is V.P. of Design Transformation at InVision. Previously, Richard was the CEO of Fresh Tilled Soil, an international product design agency. Over the past two decades, he’s delivered design and product work for hundreds of companies. Welcome, Richard. How are you?

Richard [00:00:46] I’m great. Thanks for having me, Paul.

Paul [00:00:48] Excellent. Tell us a little bit about what you’ve been up to lately at InVision and within the product community at large.

Richard [00:00:53] Yeah, I’d love to. So I’ve been with InVision about eight months now and a lot of that time has been spent trying to understand both our internal workings and also the workings of our customers. Most of our customers are very large, enterprise, what sometimes is referred to as a tier one or tier two customer. Those are kind of big strategic enterprise customers. We obviously have a lot of others, but just trying to understand the workings of these organizations. What goes on behind the scenes? I call it organizational underwear, which is something we’re going to be talking about when we get together for the conference. But yeah, what goes on behind the scenes? What happens in those nooks and crannies? So that’s what I’ve been spending a lot of time and tons of time with customers in the field, plus working with our teams, just getting my head around it to satisfy my curiosity.

Paul [00:01:44] Well if organizational underwear doesn’t get folks’ curiosity piqued, I don’t know what will.

Richard [00:01:48] Pure clickbait, right?

Paul [00:01:50] Exactly. In writing on product leadership with your coauthors in the past, you’ve made a career of finding product teams who are performing at a high level. In doing so, when we’ve spoken previously, you’ve called yourself, I think a bit harshly, the poster child for unfocused. But now that you’ve spoken with hundreds of teams and you’ve given dozens of talks since the book’s release two and a half years ago, what’s changed? Have we gotten better at product leadership as a product community, or is the challenge now as big as it ever was?

Richard [00:02:18] I think it depends on who you ask. I certainly believe that we’ve got better at it. It depends how much you are able to distance yourself from the day-to-day work and take a bigger picture viewpoint or a perspective. I think if you’re in the weeds every day, it’s hard to believe that we’re making progress because those things that take up our attention every day, those daily challenges. haven’t necessarily gone away. They’re different, but they haven’t gone away. But as an industry, we’ve got better at a bunch of things. One thing that we’ve gotten very good at is communicating what our challenges are and we understand what those challenges are. Part of that is understanding that we’re not the first people to go down this road. High-performing teams happen in every single industry and across a very wide range of sectors. And the tech bubble that we often find ourselves in has started to realize that, well, actually, you know, we’re not the only people to have to figure out what high-performance looks like when you get a bunch of strangers together or when you get a sort of domain experts or cross-functional people together. So I’ve been very, very fortunate to spend time with Formula One racing teams, the Red Bull high-performance athletes, things like that that open your eyes and you realize, wow, these guys have been dealing with this stuff for decades and sometimes even longer than that, trying to figure out how to get people to work together and build a practice of high performance. And I think that that’s where the industry is starting to maybe unlearn some of the myopic thinking that it started with. You know, I think in tech, we generally are a little navel gazing sometimes, but we’re starting to look outside of the space, we’re starting to look at what works for other teams, and invite those people into the conversation so that we can learn from them.

Sean [00:03:56] So one of your quotes is people don’t know how to work together. I’ve heard you say that in a few different places.

Richard [00:04:01] Yeah. I mean, I don’t know if it’s the same for everybody, but it’s been my experience that I think it’s getting increasingly more difficult to work with each other, not because we don’t want to. I think there’s more desire to work with each other and more desire to work cross-functionally and with domain experts in different areas. But it’s becoming increasingly more complicated, or complex, because there’s just so many things to consider: new technologies, new platforms, new devices, new modalities. I mean, you guys know this. You just cast your mind back 10 years and half the things that we do and interact with everyday didn’t even exist and go back another 10 years and almost nothing that we use every single day existed. I mean, just this podcast alone, the fact that we’re using this technology, doing this thing…

Sean [00:04:46] Brilliant.

Richard [00:04:46] If we wanted to do this 20 years ago, this would have been a hundred-thousand dollar project and NASA probably would have had do it and now everybody is doing this kind of thing and I think that just makes it more difficult to understand how to navigate that stuff. So it’s not that we don’t want to work with each other. I think we do want that, but we’re struggling to figure out what’s the best way to do that. What models, what modalities, what communications, what leadership skills are appropriate in different organizations. So it’s just that there’s just a lot to absorb and that’s making it hard.

Sean [00:05:18] Yeah, it’s funny, when I started my first software development agency back in the mid-90s, I was the designer, the coder, the project manager, the support technician, the quality assurance. You know, I was writing the code, deploying it and I was like a magician because you could see the problems. And design wasn’t even really that important. If you could solve the business problem it was like, wow. And now you look at these problems that we have to solve. The competition is so thick, the expectations are so high, it requires such a diverse set of skills to bring a really amazing product to life, is what you’re talking about. You know, we’ve got to figure out how to get designers and engineers to really get in the same room more frequently, to get better innovations out, right. And more more people. Nothing greater ever gets done by a single person anymore. It requires teams of people and coordinated teams of diverse skill sets.

Richard [00:06:12] Yeah, which makes you realize that now more than ever, the soft skills that we often refer to, the people skills, the interaction skills, the collaboration skills, that’s the stuff we really need to be doubling down on and understanding. It’s not going to go away. It’s just going to become more important. Maybe we should call soft skills hard skills because they really are the things that are difficult to master. You know, we all assume that because we’ve got friends and colleagues and connections that we know how to work with people, that we know how to collaborate. But we all bring with ourselves the biases and perspectives and backgrounds that are going to bring a different kind of idea to what’s going on. I mean, think about, we’ve got this coronavirus going on right now and I was watching something on Netflix and there are people who just don’t wanna be vaccinated. You know, I don’t think I want those people near me, but they’ve got a pretty strong perspective. Now what if we have to work with those people? What if you’re working at the CDC and you’ve got to figure out how to make this work? It’s just difficult.

Paul [00:07:13] Yeah, I think one of the things that’s implicit in your work in design sprints and also explicitly in the way that you sort of put the analysis of teams together, is this paradox of that we need to enable people to think freely. We need to empower them to behave autonomously but there’s also this paradox of we need guardrails in the design sprint itself. It’s a very formal process for a very freeform method of thinking. And with teams that work well together, it seems that you need this balance of creativity versus structure. And like you were just mentioning with people who think the same as you versus people who think differently than you, you need to work the same. What is it about this paradox, do you think, that makes it such a hard balance to strike? And I think that’s the quote of the pod by the way, “soft skills are the new hard skills.” What is it about these things that makes it so hard and do you find that the teams who have found it, did they just strike gold, are they lucky, or is it something that you can actually engineer?

Richard [00:08:17] They’re certainly not lucky. If they are lucky, I didn’t see that in the writing of the books or in the work that I do every day. I see teams creating that alignment, if you will, that idea that we’re all going to be facing in the same direction, working towards the same goal and understanding how we’re going to do that together through work. They are actively and intentionally doing the things that need to be done in order for that to happen. It all starts with what my friend Martin Erickson calls a decision stack. How do you make decisions every day? You come to work and you say, “Hey, I’ve got an idea; I saw this thing on 60 Minutes and I think it would be really fun if we tried something like that at our company” or “a competitor is doing this thing, what do we do about that?” How do you make decisions about stuff like that?

Richard [00:09:02] So I think we’ve become really good at figuring out what our tech stack needs to the like, or if you’re in design ops, what that stack of operational sequences are or processes are. But we’re not really good at doing decision stacking. And so we’ve taken the concept that Martin has created, this decision stack, and we’ve evolved that to see whether that’s something that can be applied to all teams. So are there ways that you can align a team around the big stuff, right, like the vision or the mission, or very large, big, hairy, audacious goals? And then the things that are subservient to that’s, so OKRs or team level, product level visions. And then within that, the team OKRs or the team goals or whatever the metric is that you measure by, whether you are an OKR fan or not. I’m not advocating for either, I’m just saying you need something to create that boundary that you’ve just described, Paul, that box in which creativity can happen. And then, once you’ve got that decision stack, you can start making daily decisions about, “where do we want to put our time and resources?”.

Richard [00:10:07] But what’s underlying all this stuff, the decision making, is also a set of principles or values. Like, do we agree on stuff? What do we agree on? Those agreements might sound implicit in the fact that we’re all human beings and we’re coming to work together in a sector or on a particular product, but I can tell you right now that I can walk into a room full of people and I can ask them 10 questions and see a dozen different answers from those questions. And we’re talking about basic stuff like, “Hey Paul, when you get home, do you take your shoes off at the threshold, or do you walk in, take your shoes off, you know, once you’ve walked around the house a little bit.” You’re gonna get half the team saying, “I would never walk into my house with my shoes on,” and the other half of the team saying, you know, “I don’t care.” And if we can’t even agree on shoes, how are we gonna agree on the really important stuff like, you know, the ethics of design or the principles of what we’re gonna use or the design system that we’re going to use? So these teams that are high-performing tend to spend a disproportionate amount of time doing the decision stacking and the value work to find mutual agreement, or social contracts, around those agreements. And then when that’s in place, they can always turn to that as an objective source of truth and say, “hey, I don’t agree with you on this thing, but we’ve got a higher cause, we have an objective thing that we can use as the tiebreaker, as the way to reach a decision. So individually, we may not agree on these things, but we know that from a product perspective or from a company perspective, we’ve already made an agreement and that social contract stands above all else.”

Paul [00:11:44] So I want to pull the thread on this just a little bit because I noticed you very deliberately use the words principles and ethics and vision and nowhere in that description of the challenges was process. so I’ll use the word agile, as you know, fill in the blank of your favorite system here, combine, scrum, whatever. So agile is often conflated term with these ideas of principle and vision: if we just do this better, if we just do this faster, then we’ll achieve what we want to achieve. Why is it, do you think, that teams who have these processes and who are very good at processes sometimes miss the mark so wrongly? Is process important at all if you haven’t gotten vision, or are they two sides of the same coin?

Richard [00:12:29] Oh, process is definitely important. So let’s look at it from two different perspectives. One is that process in and of itself hasn’t evolved massively over the last several decades. We still use fundamentally a scientific method which has been around for centuries. The scientific method essentially says, “I’ve recognized something in the world, it’s a problem, it’s a hypothesis. I think that we should probably investigate this thing because it’s either worth our time, money and effort to go and do that thing. We should come up with some ideas on how we think we might deal with that problem and we should experiment with it. We should test them in the real world and see if there’s some repeatable pattern. And if that pattern turns out to be something that we can secure our business or our product or our lives against, then we should continue to do that until it doesn’t work anymore and then we should go back to the beginning of the process.”.

Richard [00:13:22] And if you look at anything, whether it’s as discrete as a design sprint or as complicated as agile, that’s the methodology. That’s the general process. We haven’t really evolved beyond that. Too much. I know there’s going to be people listening to this who might disagree, but honestly, we’re using a similar methodology, a kind of a general idea there, and we’re just giving it different names and putting new labels on it. So that’s the one perspective, right? We have a known thing and if you understand the history of process and understand the history of how these formal dogmatic type methodologies have evolved, then that’s obvious, like you see it there. Where I see the principles-based and process-based stuff reducing friction is when we turn the process into dogma. Where we turn it into, this is the only way, like you have to hire this consultant to implement this thing at this time and in this manner in order for you to be successful. And the reality is, as we know from our personal lives, everybody’s different. Every company is different, every product different.

Richard [00:14:26] So what is absolutely true is that agile principles are fantastic and valuable. But you also need to have the thoughtfulness to understand that those are gonna be implemented slightly differently in every single case, in every single business, at every single path in that business. So even within a single business or a single lifecycle of a product, you may need to change things. So, for example, when you’re just starting out things can be a little loose and flexible and you don’t need as much rigor, but as things get more and more, how shall we say, there’s more at stake. There’s more material, there’s money and people and resources at stake, you want to tighten up certain things and you want to maybe keep other things a little flexible.

Richard [00:15:13] We have to understand that nothing is static and we live in a more of a biological system than we would like to believe. We want to believe we live in a mechanical system and we want to believe that there is a process that’s mechanical enough that you can just substitute chaos for that process and you can do it anywhere. That’d be great. That’s what agile at the consultant level looks like. It’s like, “we’ve got a thing and it’ll work for you as well.” But the reality is, that’s probably not true, and everybody knows that, but it’s just harder because then you have to do the real thinking, which is, well, what’s good for us now? What do we need at this point in this part of our evolutionary lifecycle that’s going to be relevant and useful? And that requires leadership and that’s where product leadership has become this, as I point out in my curiosity or my fascination, is like, at what point do those leaders say, “we need something different” or “we need something that’s going to be relevant to us at this point,” and how do we implement that? And that’s where that decision stack comes in. If you can do that, then you can be successful. But if you’re constantly trying to reinforce dogma, I mean, we know what that looks like. That’s like any economic or political system. The more you enforce the dogma, the less valuable it becomes.

Sean [00:16:25] Yeah I mean, that’s the natural tendency. Businesses, if they’re going to invest money, they want predictability. And engineers are trained to produce things from the ground up to be predictable. And our world doesn’t work that way. You know, and agile is supposed to be, it’s meant to be, even as a word, it’s something that you are. It’s not something that you do. And we’ve taken the manifesto, which is a set of amazing principles, to your point, that we all believe in, and we try to turn it into this predictable process so that we get more predictability out of our chaos. And it just doesn’t work. It doesn’t work that way. I agree.

Richard [00:16:58] I mean, one of the reasons why I like design sprints… Again, I’m not advocating that everybody should use the design sprint, I don’t think that’s true either. But I like design sprints because you can learn all of the things that we’ve discussed in the last few minutes in a very short space of time. You can practice them, you can experience them, and then you can select from them the things that you care about and want to do and discard the things that are not maybe relevant to you at that time. So, you know, I’ve said this a million times. If I could do one thing, I would change the design sprint to not be called a design sprint. I think, A, it’s not really to do with design in the way that people think it is. It’s more to do with big D design, like conceptual thinking, thinking generally. Not design thinking, but just thinking. And then sprinting is somewhat irrelevant in that context, and I know it’s a borrowed word from agile, but we don’t really need that either. What we need is just a way to describe, “hey, we’re going to do some really interesting work over the next few days and we’re going to think through this in a methodical way that gives us great answers. We want to teach everybody that. I mean, that’s, you know, that’s the other half of my curiosity is when are we gonna start teaching people to think? Because they come out of school, they’ve got degrees and we’re like, well, they’re smart, they graduated, they must be awesome. And you put them in a job and there’s absolutely no way for these people to think through these problems because we haven’t taught them how to go from identifying problems or framing problems to figuring out what steps need to happen in order to get to an answer or a solution. And even when you got to the solution, is there even a fit? Do you fit it into the market? Can you even sell this damn thing? Will anyone even pay for it? So I think we need to teach people how to think. You know, building a practice within an organization is almost the most important thing you can do, is to teach people how to work together, think together, and make really interesting choices and decisions every day. That above all else is going to be timeless because the technology will change. Do we really believe that React or AWS or anything like that is going to be persistent for the rest of our lives?

Sean [00:19:03] Hasn’t happened yet.

Richard [00:19:04] No, I mean, it just keeps changing. So why are we putting on resumes, we’re like, “oh, you need to understand these technologies, you need to do these things, you have to experience, you know, five years of that.” What I want is somebody who’s adaptable, who is flexible, who can learn the new technologies when they come along, full stack and beyond.

Sean [00:19:24] Yeah, I think that’s the function of leadership is to create the environment for that so people remain flexible and are constantly learning. I want to pull on something you said earlier about vision and getting everybody aligned on the same vision and you mentioned metrics as a way to do that. So what do you think constitutes a reasonably complete vision that will get people, or can get people, aligned to be rowing the boat in the same direction?

Richard [00:19:48] Well, we’re going to talk about this at the conference as well, so I do want to give away too much. But we know for sure that a great vision isn’t always something that everybody agrees on and that’s really interesting to me is that, at first I thought the perfect vision is something that everybody reads and goes, “wow, that’s something I want to get behind, that big idea, that future that that’s describing, is something that I want to be part of.” But the more I looked into really great visions, the more I realized that the best visions are actually quite divisive and they are things that don’t include everybody all the time. So if you’re saying, “listen, we’re gonna go to Mars.” You’ve got a bunch of people saying, “that’s the stupidest idea I’ve ever heard; why would we use time, resources and money to go and do that?” And you’ve got a bunch of people saying, “I love this idea, where do I write the check?”

Paul [00:20:42] It’s like Amundsen’s post for the South Pole expedition, yeah.

Richard [00:20:46] Exactly, yeah. So do you want a vision that is inclusive of everybody? I think the answer is no. So that’s the first step and then I think beyond that, where does your vision percolate into your organization? So is your vision aligned with all the other parts of what you do? And so you think about it, I’ll pick on Elon Musk right now just because we started there. We think about the vision of Tesla as a company. I think their vision is something along the lines of, accelerating the rate of sustainable energy, something in that realm. And that’s interesting to a lot of people, except maybe for the fossil fuel industry. They probably hate that idea. But within that, there are lots of other things going on. I mean, he’s got maybe 10 other products inside Tesla and then within those there are probably I don’t know how many skews might be involved in that in an organization that large. You know, is there a vision for the product? So the Tesla S is very different from the Tesla 3. It’s a different market, it’s a different persona type, it does a different thing for that persona type as well. It achieves it a different Job to be Done, to use Christensen language. Is the vision capable of being exciting and somewhat divisive, but then also applicable at product level? And I think that thread is something that’s not very well considered in terms of vision construction. Can you create a product vision from your big vision and understand that that product may have a lifecycle that has a beginning and an end to it. It might be, we’re going to create this thing and then we’re going to stop making this thing 10 years later or whatever, that the vision remains timeless, and that’s really hard for people. They’re like, “wait, we’ve got a company vision.” I’m like, “do you have a product vision?” and they’re like, “well, do we really need one?” I’m like, “I think if you’re on the team that’s building Model S cars, you want a vision for your organization,” because it’s different from photovoltaic tiles, which is another part of the business, right. So it depends on who you are in the organization where you’re aligning yourself to. So I think that’s the first part of vision.

Richard [00:22:53] And then the second part of vision is, do you understand that your vision is unachievable for the most part? You know, a mission is different, like going to the moon or Mars or whatever, that’s a mission, but a vision is somewhat unachievable in the sense that we’re always working towards that. We’re almost there, we’re just getting closer and then maybe it’s a little bit further away and then that’s exciting, that’s aspirational. Whereas the product vision or the mission within those different products has to be very achievable. You have to know that you can get there and that’s why people sign up for it and go, “yeah, I like that big crazy idea, but I’m also bought into the fact that my job security and my career path is connected to a thing that I can then tell my family or my friends and say, like, I do this thing and we do these things together and this is what makes me happy.”

Paul [00:23:41] That’s a great answer. I think the way that you’re describing it maps to a conversation that I had with Jared Spool about vision as a flag in the sand and it’s something that you can decide to put there and if you do have these subordinate teams, photovoltaic tiles and the Model S, on the same organizational plane, they’re marching towards the same flag but each team has its own sub flag that gets them going in the right direction.

Richard [00:24:03] Yeah.

Paul [00:24:04] I think it’s an analogy that maps well with what you were just sharing. I want go back to one comment that you made about design sprints. I’m a fellow fan of design sprints. I’ve participated and facilitated a few, and what you were describing about the naming of the thing resonated immensely because it’s not a UX problem. The best design sprints have engineers in the room informing the process, and it’s not a sprint in that you’re going to go produce something. It’s really, you know, the rapid prototyping that we’re doing is more, this is maybe controversial, but I think it’s more akin to wargaming than anything else. You’re putting a simulated scenario together. You’re getting some parties, you’re seeing what happens when you put them all on a pot and shake it up and I think that it’s really in the lineage of wargames than it is of anything in the creative. I think it does a disservice. And I think the name itself turns people off when it really could be more helpful. Maybe we should think about a rebranding strategy.

Paul [00:24:57] But I want to ask a selfish question because of your experience as it maps to my own. I am at an agency as a product manager for clients, similar to folks you worked with Fresh Tilled Soil. You’ve now been at InVision for a couple months now. What has it been like going from the agency world as someone informing the product process and product thinking into an organization where you have a product and you’re leading it from the inside? Is there a difference or is this a un-useful line of demarcation?

Richard [00:25:29] I mean, there are differences for sure. You know, every company is different and I am not sure I can speak to the point of like, you know, is enterprise-size organization always going to be the same depending on where you are, because I haven’t worked at enough places to know that. I think it depends on what kind of leader you are. So my curiosity has always pointed me in the direction of how people work together and why would they want to work together and giving them a reason to do that. And I don’t think that those things are different. I don’t think they are different just because you’re an agency. I mean, you could be at a nonprofit, you could be selling T-shirts, ultimately, if you’ve got people working together towards something, then that’s the leader’s, right, that’s what they need to understand is, you know, somebody can be made a manager, you can be promoted into management and you can be given the role.

Sean [00:26:21] The title.

Richard [00:26:22] But leadership is something you go and get, right. Nobody gives you leadership. You get it yourself because you’re curious about it, because you are interested in the way people work together. I mean, you can be a leader at the bottom of an organization just through influence or creativity or whatever it is that you’re participating in that draws people to you and says, “wow, this is somebody that’s doing cool, interesting things. I want to be around them. I want them to help me make better decisions or I want to be close to that energy.” Leadership is common in any company and my curiosity has always been, where is that stuff? And I wish that I was a better leader because, you know, every interaction that I have with all these people that I see around the world, I realize, jeez, I got a lot of work to do. There’s so much to learn here. But that’s also part of it, is that you become subservient to the work and you become subservient to the path and you’re less about like, “well, I’m a manager at this position and I need to get to the next level up.” So I don’t really think about like, “hey, I’m in a big company and I need to kind of level up.” I’m thinking, “oh my God, I’ve got this opportunity to talk to the Fortune 500 design and product leaders, imagine all the crazy stuff you can learn over the next several years.” So that’s the only thing that’s in my head right now. Paul, I don’t know if that’s a really good answer. The mechanics of it are there. The mechanics are different, but I think they’re gonna be different for every company.

Paul [00:27:45] Yeah. Like I said, it was a selfish question, just out of curiosity, what it’s like on the other side. I appreciate your insights and I think that spirit of learning and the humility that it takes to say, “I have this experience,” and if you look at a person’s resumé, it might be impressive. But I think that the humility that it takes to check your ego and say, “I still have a lot to learn and there’s still a lot out there that I can be informed and influenced by, and I don’t have all the answers.” I think, in my opinion, it’s the single most predictive indicator of a successful leader or not, if you can be humble.

Richard [00:28:19] Yeah, and surround yourself with people who keep reminding you of that.

Sean [00:28:23] There you go. So I obviously stopped you on Twitter before this and have read all your books and done that thing. But I found a cool quote from not too awful long ago on Twitter that you posted out there: “a leading indicator for whether a team member is going to be valuable to their team is how much self development work they do on understanding their own value and how that value translates to their team.” I think that’s a pretty humble statement right there. Not only a team member, but it applies to a leader as well.

Richard [00:28:51] It’s hard to hire people in the traditional way, like, “oh, send me a resume, I’ll read it,” and then try and match up that with the job spec, like, “oh, I’ve got a job spec, I’ve got a resume.” But what you can do is you can, maybe interrogate is too harsh a word, but you can ask people what they do with their time to grow and evolve. And I remember this one interview, we actually never ended up hiring this person, she ended up working somewhere else, which good for her, she got way more money than we were offering her. But she came in and we were talking to her about her work and her portfolio was good, it wasn’t great, and her work was good, but again, it wasn’t like stand-out. But when we started asking her questions about how she spent her time, she was like, “oh, yeah, you know, when I get really curious about something I go super deep on it, like I recently got into bread making and I got to the point where I actually built my own brick oven outdoors; I imported pieces of a brick oven from Italy and I constructed this entire like outdoor bread making oven.” I’m like, “oh my God, you’re hired.” Like, yeah, somebody who thinks like that and says, “OK, I’ve got to find an answer,” and goes deep on that and develops the skills to do that and is not afraid to fail and and mess up en route to getting there.

Sean [00:30:13] Yeah.

Richard [00:30:13] That was so exciting for me and since that meeting, I’ve always started to ask questions like that is, you know, what are you doing to get where you want to go? Is this job it? Are you done? Are you done evolving? Are you done experiencing? Like what else are you gonna do with your time to get to the next level? What other parts of your brain you want to use? Those are really insightful equations for somebody like me when I’m working with other people to understand where they intend on going.

Sean [00:30:41] Yeah.

Paul [00:30:41] I think that’s a much more human version of the more entitled question, “what’s the last book you read?” It was about that question to be a little bit privileged when asked in an interview. You know, I have five kids. I do read a lot of books still, but, you know, the question itself presupposes that you’ve got a fixed method of learning and this is the only way to learn, but building a brick oven in your backyard is absolutely valid. I think that’s a way more human approach.

Sean [00:31:08] You’ve got to pick of a bunch of ancillary skills, not just bread making, but brick building and all sorts of things. It’s interesting.

Richard [00:31:16] Right.

Sean [00:31:16] Cool. Well, we have a couple more quick questions for you. One we ask many of our guests, and I am really interested to hear this answer from you, how do you define innovation?

Richard [00:31:27] You know, I don’t think I had a really good answer until I read Safi Bachcall’s book Loonshots. That’s L-O-O-N-S-H-O-T-S. I don’t think I really even understood what innovation was until I read that book. And he’s in a super interesting guy, got a background as a physicist and an economist and got into the investment world, I believe, through that path. He sees innovation through that, almost like physical math lens, like what are the inputs and outputs that affect the way we behave so that ultimately innovative things happen? The core concept here is you can invent things, right? You can make a thing and you can say, “I created this and nobody else has created this thing before, and I put a patent on it.” But unless people actually adopt it, then it’s not innovative. Like if nobody’s using it, then it’s just an invention, but if it’s adopted, it’s innovative. It’s going to change people’s lives. And if you read the book, you’ll see that there are components that ultimately are really just incentives to behavior that will encourage you to think about how you spend your time creating things. Are you creating things that will ultimately be adopted by others or are you creating things because it’s going to get you a promotion or a raise or status in your company? And so depending on how you set up those incentives, you get a different outcome. And actually at the conference, we’ll talk about this a little bit, because I think it’s important. When you think about it like that, then you start to go, “gee, what am I actually spending my time on? Like if I’ve got three or four hours at the end of the day, am I spending that time on managing my status in the company or am I spending it on coming up with innovative ideas?” And so it’s less about like, “what is innovation and how you define it?” and it’s like, is there a environment in which innovation can happen? Because we’re all human and we all have that kind of innovative streak in us. We all want to be creating solutions. But do we have an environment around us that encourages that or allows that to happen?

Paul [00:33:30] That is the most unique answer I think we’ve gotten to that question so far, Sean.

Sean [00:33:35] I love it.

Paul [00:33:35] That’s fantastic. Richard, if that wasn’t the best lead in for inviting everyone who’s just listened to this and enjoyed our conversation to attend our conference… It’s been a pleasure talking with you this morning and getting to know your thoughts a little bit. I really appreciate the time that you to with us today and share your insights.

Sean [00:33:52] Super honored.

Richard [00:33:53] Thank you for the invitation. Really, really appreciate the time, guys.

Paul [00:33:56] Absolutely. Cheers.