Ward Vuillemot on the Power of Celebrating Errors and Understanding Customer Behavior for Business Success

Listen:

Check out all episodes on the My Favorite Mistake main page.

My guest for Episode #195 of the My Favorite Mistake podcast is Ward Vuillemot. Ward is a seasoned C-suite executive with over six years of experience leading fully remote teams while building technology organizations from the ground up for companies with 150 to 650 employees in size and $50M to $125M in revenue across the Americas and Europe.

He is currently Chief Product Officer and CTO at RealSelf. He is a technical advisor with his own company, where he advises startup founders and CEOs on technical roadmap and technology organization along with lean approaches to finding market signals quickly.

I invited Ward because of this Forbes article about celebrating errors.

In this episode, Ward tells his favorite mistake story about launching “Amazon Tote” and why there was “too little friction” in user experience. What did he learn about understanding the customer experience? In a separate story, what was Ward's epiphany about seeing an ant on a bus?

Questions and Topics:

Innovation is doing something others haven’t done before
Tell us about the Celebration of Error (CoE) concept – and practice…
Chicken and egg between psychological safety and CoE?
How much Psychological Safety is necessary and how does CoE build more PS?
From Correction of Error (Amazon) to Celebration of Error?
Are all errors created equally in terms of what to celebrate?
Discovering mistakes that had been there for years
As a person who is “high-functioning autistic” – is it ever a mistake to disclose something that personal?
From mindset to document?

IMPACT of the error on business – send to whole company?… why it matters, not why it happened
RESOLUTIONS — short-term and long-term (countermeasures) – fire out, then prevention
ROOT CAUSE – “show your work”

When to use a CoE?
Mark's firefighting A3 cartoon
People “NEED” to make mistakes to hit ever-greater goals?
Taking an impersonal, non-blaming approach — easier said than done? Fighting the instinct to blame?

Scroll down to find:

Video of the episode
Quotes
How to subscribe
Full transcript

Find Ward on social media:

Watch the Full Episode:

Quotes:

"Mistakes are fundamentally the hallmark of growth in so many different ways and even where innovation comes from." - Ward Vuillemot

"How do you create a mechanism to create a culture that's psychologically safe to make mistakes and learn?" - Ward Vuillemot

"[I tell my teams] I don't mind you making a mistake. I really don't like it when someone else from the part of the organization, or worse our customer, tells us about the mistake. If you tell me about it, that's OK." - ward vuillmot

Please follow, rate, and review via Apple Podcasts or Podchaser or your favorite app — that helps others find this content and you'll be sure to get future episodes as they are released weekly. You can also become a financial supporter of the show through Anchor.fm.

You can now sign up to get new episodes via email, to make sure you don't miss an episode.

This podcast is part of the Lean Communicators network.

Subscribe to the “My Favorite Mistake” Podcast

Automated Transcript (Likely Contains Mistakes)

Episode 195, Ward Villuemot, Chief Product Officer, Chief Technology Officer, and advisor to startups.

Mistakes are fundamentally the hallmark of growth in so many different ways and even where innovation comes from.

I'm Mark Graban. This is My Favorite Mistake. In this podcast, you'll hear business leaders and other really interesting people talking about their favorite mistakes because we all make mistakes. But what matters is learning from our mistakes instead of repeating them over and over again. So this is the place for honest reflection and conversation, personal growth, and professional success. Visit our website at MyFavoriteMistakePodcast.com. To learn more about Ward, his work, and more, look for links in the show notes or go to markgraban.com/mistake195. As always, thanks for listening. Well, hi everybody.

Welcome back to My Favorite Mistake. Our guest today is Ward Villuemot. He's a seasoned C-Suite executive with over six years of experience leading fully remote teams while building tech organizations from the ground up for companies 150 to 650 employees in size, and from revenue ranging from 50 to 125 million across the Americas and Europe. He's currently Chief Product Officer and CTO at RealSelf, and he's a technical advisor with his own company. His website is wardvilluemot.com. I'll put a link in the show notes. Ward advises startup founders and CEOs on technical roadmaps and technology organizations, along with using what we call sometimes referred to in this podcast, lean approaches to finding market signal quickly.

So Ward, welcome to the podcast. How are you?

Excellent. Thank you, Mark. Thank you for having me.

We'll give people the spelling here if they don't want to go see the show notes, ward, w a r d v u i l l e m o t.com. Very French, as we were discussing before we

Yes, very, very, very French, though we do not pronounce it like the French.

More of a, a Washington Americanized pronunciation where Ward's joining us today from Washington. And, you know, the, the, the, the reason I invited Ward here, we'll talk about this after his favorite mistake story. There was an article written about Ward in, in forms about what he calls CoE, Celebration ofEerrors. So clearly in the right, yes, we're in the right place to have a discussion about that. But before, you know, we talk about that concept and, and, and the article as we do. I won't let you off the hook Ward. Looking back at the different things that you've done, what would you say is your favorite mistake?

Yeah, I think there's, there's, I I think your career, you know, mistakes are fundamentally the hallmark of growth in so many different ways. And even where innovation comes from, which is something I've written about, you know, ignorance and mistakes. That's how we learn. But if I think about, like, I think the earliest one where I, I thought I knew the answer and then I learned something along the way was a, a small startup program that we were doing outta Amazon. It was a sister program to Amazon Fresh. This was before Amazon Fresh went national. So we were still in the Seattle area, and I was, I was a part of that and I was asked to go over and help be part of the launch team for something called Amazon Tote.

And just real briefly, Amazon Tote was the idea that you could get free deliveries to your home, any item on Amazon, and we would deliver it sort of like your best friend. You know, imagine if you called me up Mark and said, Hey Ward, could you go down to the mall and pick me up? You know, I an iPod at the time and I put it in a little tote bag and I dropped it off at your door and you know, that's how you got it. You know, so to getting rid of all the boxes, you just get these totes. So we got Amazon tote, and, and I remember in the very beginning, you know, we were working with Doug Harrington, and Doug Harrington really was into this, you know, working backwards from the customer mindset, you know, very much of that lean mindset. And, you know, before we even wrote really any code I had, I guess it's not a mistake, but just to give you an idea of like how we were thinking about, I'll give to the mistake, but we, you know, we, we, I hacked his browser with his permission to be be clear, I hacked his browser and he would go to the Amazon website and it was everything.

It was Cheez Whiz or Cheezits. And he would order, he would order it and go through this, what we thought was gonna be the, the launch experience. And then I would get an email based on that little hacked browser experience and I would put the Cheezits in my bag and the tote bag and, you know, I'd walk down the, the hallway to his, his office and I would deliver the Cheezits. We learned some really interesting things around having too little friction in the user experience, which was really fascinating to us. And I think to myself, you know, we didn't really have an interstitial at that point. It was just too frictionless. So there's, that's a really good, interesting learning from Amazon tote was the lack of friction. You need some amount of friction.

You know, we always talk about reducing friction for consumer. There's such a thing as too little friction. Yeah. So that was a really important lesson. And again, lots of lessons in there. You know, as I, I mentioned like, we didn't even really write code. We were just learning this just by doing some really, really, really low level, low fidelity mockups. But the, the one that I had done before launch was this idea of multi quantity. So you could get multiple items. We had a cart like everyone else, but you could only order one. So let's just go back to that original example and just say you wanted to buy an iPad for your iPod for yourself and someone else. The way you would do it, the way we envisioned it was that you would add the iPod to the, to your tote bag and then you would go back to the detail page and you would add it again.

And this was to do with some ways that we were sort of quite literally hacking Amazon's inventory system. And we knew we could only guarantee a quantity of one at any one time when we put it in. We couldn't do a promissory greater than that. And I did a bunch of research around consumer experience. We knew that generally consumers might bought multiple items, but not multiple quantities. So you could have an iPod and a book, but very, very improbable. You would've two iPods and a book. So we knew that by not having that, that multi quantity, at least from a consumer behavior standpoint, we weren't like missing out on opportunity. And so we felt very confident going to launch with this thing without those multi quantity dropdown, right?

So we, we launched that and you know, every week we meet with our customer support folks and lo and behold, the number one complaint, as you might imagine as of the story yes, was where the f is your multi quantity, aren't you? A bunch of effing idiots. Like they, they were not played to us. Like,

And aren't you, aren't you Amazon, who should be?

Are you Amazon? How could you not have this thing, right? So, and like every week, and I kept on going to the customer support, I was like, Hey, I got the data, you know, it's not gonna change behavior. They're, you know, we, we knew this, you know, this is just the fringe, but it was like the number one complaint in terms of volume and even quantity of, no pun intended. So again, like I said, we were, we were sort of hacking the inventory system cuz this was really much meant to be like this grand experiment in customer behavior. So, you know, for me to put a multi quantity dropdown, I potentially had a race condition where you could ask for more than one item and I might only deliver you less than what you asked in terms of quantity. So there was exposure to like the, the consumer experience on the other end, which is really hard to communicate via website, right?

So we did a, we did some more research, we finally sort of came up with a way that we felt like, okay, I think we can probably cover the, for the race condition, or at least we know how to dive and save for it. And again, I measured out, before I had really great data leading up to this list, list launches, multi quantity. We launched multi quantity. Low and behold we went back and do you know what happened? What happened? Nothing. Yeah, nothing happened except for the complaints. The complaints went down. The consumer behavior did not change, huh. But the complaints disappeared. Hmm. So we did not open up, you know, cause there's some people hoping that somehow this was materially magically gonna change consumer behavior, but all the data, you know, and we had a lot reams and reams of data that wasn't it.

And so it was just an interesting lesson for me about how, you know, in, in the Amazon tote world learned a lot about like too little too much friction, right? You know, we were always thinking too, to remove more friction, but there's such a thing as actually removing. So it's sort of that goldilocks of friction that was like lesson number one. Lesson number two is, you know, there's a, there's a big golf between quantitative and qualitative understanding of the, the customer experience. And if you really want to create the best experience, you need to have both, right? Because there was a subset of our customers who really looked down on us who, you know, weren't happy with us. And it also created a lot of operational friction for our customer support folks too. Instead of being able to work on real problems, they were working on an optics problem, right?

Of constantly dealing with these upset customers. And so just recognizing that, you know, I think there's a world where a lot of people get really into, you know, reduce friction at all costs and also let the data entirely drive itself. And that's the only thing that you should pay attention to. And I walked away from a more nuanced position of like, you know, like there's sort of Goldilocks in everything. There is a right balance and you have to look at a lot of different dimensions, even when you know the answer is correct on one side of the equation, you have to look at other dimensions to really come back with a holistic view of the customer experience. And that was a really big epiphany and a big eye-opener for me if of, and which I've carried forward and how I think about the customer experience and, and always working back is really carrying, you know, multiple lenses Yeah.

Along the journey.

Yeah. So, I mean, there's a lot to dig into, but I was, I was gonna ask about the learning, right? Because, you know, we, we, you know, here in the podcast where we try to emphasize, you know, we're, we're not shaming anybody for making a mistake, we're celebrating the learning that comes from it. Can, can you think of a, you know, a situation later on where you were reminded, hey, don't, don't focus only on the, the quantitative data about the customer needs, for example.

Yeah, I mean I, I I think maybe the quantitative shaming and, and sort of, you know, there's, there's a, there's a greater bit to that too. And I'll, I'll share a slightly different story. I've written about it before, but it's about me and an aunt and it was a, a previous place of work. Happy to be wearing the hat there. I I won't say it out loud, but you know, mainly cause that's not really about the story. It's not about them, it's just about me. But, you know, I was, I was on this bus, I commuted every day, hour and a half one way. So three hours a day kind of commute. And you know, I'm not a kind of person who generally goes outta my way to kill insects, but I don't have a problem killing them. And I'm sitting on this bus and I see this ant and I have this moment of like, I'm not gonna kill this ant, right?

He's crawling down around by my toe and I'm like, you know, a little bit of karma maybe, you know? And then I had another thought. It's like, I've been on this bus for 45 to 50 minutes, this aunt probably came with me or someone else. It's not like this. T's gonna get off this bus and go find a new nest and say, hey, you know, I'm moving in. I mean, this ant dead, right? Like it is, is effectively dead. It just doesn't know it's dead. It's just a matter of, it's a matter of when, not if like in because of the nature of ants, right? And so

They lost their, their…

Nest, their, their community. They're, yeah, they're away from their people, you know, as it were. Yeah. And then I had a moment of like, oh, this place I'm going to work is the same kind of way. Like, I am dead. I I am going to die. Because it was, or me a very toxic environment, very aggressive, very sort of, you know, you would go have coffee with a friend like you and I could only have coffee mark. We'd go into a meeting and next thing you know is you would open up up a 12 gauge shotgun to me, you know, in that meeting. And that was just sort of part of the course. And you'd be like, Hey Mark, I thought we were on the same team. And you'd be like, yeah, but I'm taking care of my career and you're in my way. And so it was, and it was sort of heralded as part of, actually as a hallmark of the culture.

They really liked that very aggressive culture. And, you know, as a, as a person, a long journey of, of understanding that I'm a high-functioning autistic person. And then furthermore, recognizing that I operate in certain kinds of ways that are very, I either, I have a very binary relationship with certain kinds of environments. I decided to change how i, I was behaving at work. And part that's because I grew up in an environment where there was a sense of professional self versus personal self, right? And we, you hear that a lot at work, you know, like show up to work, present yourself in a certain, you, you, you, you act in a way that is quote unquote, and I'm using quotes professional, right?

That's sometimes very counter to your, your how you behave outside of work, right? And there be some differences, right? But you, like, you get into this like, oh wow, like you're a loving, amazing human being, but inside of work you are like one, you, you're a completely different person, like unrecognizable, you know that kind of difference. I've seen that before. Yeah. Yeah. And what I found for myself, and this is sort of like that, and it was like trying to ape those behaviors that I thought were quote unquote professional. So here is an environment that's very aggressive, very in your face, not how I wanna reflect for myself. It's not how I want to act personally. And because I'm autistic, like a acting in a way that's inconsistent for me is, is Anthem to like basically doing personality suicide.

Like I just couldn't handle it. So I showed up to work the next day after having this quite cathartic, literally crying on the bus with this ant. As crazy as that sounds like I had a moment of just crying. I don't even think the ant actually cried, but I was crying on behalf of the ant myself. And, and I showed up to work and I, one of the things that I, I am, I don't know, noted for, but like I try to be a very o warm and caring person. And I would go into meetings sometimes and I would just look to the person to the left, to the right, especially if I worked with 'em closely and just say, you know, I really appreciate you. Or you know, I could tell that they're having a, they had a bad meeting and I might just take a moment as mark meeting just like, you know, just, no, I, I love you, you know, I care about you and not something that most people would expect to find at work.

And of course it went about as well as you might expected on the environment. A lot of people did not like it, or, you know, majority are probably indifferent. There's one or two are probably returned off. But I, what I found was there's a few people that really resonated with, and there were the people that I cared to work with the most. And that was like the other piece of this whole sort of mistake as it were, is I filed a career base sort of on ego and, and chasing after the most interesting intellectual problems. But I also wasn't solving the other aspect of myself, which was the, the interpersonal connections that I needed at work that I was not looking for when I went and interviewed for companies.

And so I, that was the moment, that was the epiphany, that was the pivot in my life where I started looking at my, my jobs and where I worked and who I worked with from a additional dimensions. Not just is it intellectually interesting, but are these people that I care about, do they care about me? Are we solving a problem that I can sort of, not just intellectually, but spiritually, emotionally get behind? And that was a complete game changer. And that allowed me to start as I would look for other jobs, people would extend offers and I would say, thank you, but no thank you. I've interviewed you. You're not the right company for me. You know, like intellectually, yes, I could do the job, I could knock it out of the park, but I don't think I would enjoy working for you and I don't think you would enjoy the way I work.

Right? And, and I don't need you to change, to make me happy any more than I'm gonna change to ma you know, to make my in some, some weird way. I'm gonna make myself unhappy to change for you. Like I'm not gonna do that. I'm not gonna make that sacrifice. And that was, that was a major change. That's how I ended up in Central Washington and with my wife is, you know, again, you start to understand what's the most important things in your life. And I think, you know, one of the biggest mistakes in my life, my twenties and my thirties was pursuing my, my career at all costs without sort of putting it in context to sort of the greater purpose or intent of my life. I don't think it's a zero sum game or a mutually exclusive game of you know, that you can't have a great career and also work with great people that are right for you again.

Right. For you.

Yeah. And that's why I wanna be really gentle with that statement. I think sometimes we take overly strong proclamations, especially in the news, the way we talk about companies. There are companies and places I know I would never wanna work. Or even some great companies, like for an example, apple. I've been, I grew up with Apple. I was, I'm almost 50 now. I've been programming since I was like five starting with Apple. So, and I always thought I was gonna work at Apple, love Apple. But like Apple's a very much in-person, you gotta be hands-on. You gotta be down and down with the Apple company, you know, physically. And I don't wanna move. I wanna be, you know, I don't, me and my wife, we do not wanna locate to that. So I would probably never be able to work for, for Apple or Disney for the example.

Cause again, they want that, you know, always on in-person kind of a setting. And that's not right for me. That doesn't make them a horrible company any more than like I worked at Amazon, Amazon's an amazing company with some amazing people, but I can tell you for a fact that I'm really not well fit, suited for their culture. And I know a lot of people who it's great for and they love that culture and you know, who am I to sort of turn to them and say, no, you're wrong. Right? Right. They should know what's best for themselves, you know, even if I would say it's not best for me. So Yeah,

Yeah. Bad, bad fit doesn't mean bad for all bad fit for me. Yeah. Doesn't mean bad for all. But, you know, ward, thank you you for, you know, sharing both those stories and you know, there's something you said earlier that I jotted down. It's a great phrase and I I think it maybe connects the two stories. It connects to a lot of the stories people have told here on the podcast. And I've come to understand better from having these conversations. I thought I knew something and then I learned, right? The difference between like, we think we know something versus being able to recognize it's really more of a hunch or an assumption or a hypothesis. And you know, I think back to even this connection to lean former Toyota people I've worked with, one of the things they would, they'd love to ask is if, you know, if you make some sort of statement, do you, how do you know that?

What do you know and how do you know it? And I think it's really helpful to be able to distinguish knowledge knowing something versus an assumption. And sometimes assumptions are necessary. But I think when, when you test an assumption with that thought process of, I could be wrong, I think that that leads to, to better results instead of being stubborn or doubling down or refusing to be wrong. Cuz we're, we're all, we're gonna be wrong and let's, let's learn from it.

If, if you, if you think about what innovation is, innovation is doing something, something, something that someone has not done before you. And to go a little bit off from the weeds, and I'll tie it back in is, you know, I I came up through probably a culture and a and to a belief of like in, in worship of the written word, right? Declarative knowledge. Someone else sat down, they, they gathered all the information together, they put it down in formula. You could read it, you could, you could study off of it and you know, you'd go get a four year degree and lo and behold you were quote unquote, and I think you and I are, maybe you talked about this prior, but you know, just because you have a four year degree doesn't make you an aerospace engineer, right?

I have advanced degrees in aerospace engineer. What it meant though was I was qualified to go start at a company and become an aerospace engineer after another 10 or 15 years worth of experience. But we have sort of perverted what it actually means to acquire knowledge. And we have an overdependence on declarative knowledge, which is the, the knowledge written down, which is not innovative knowledge. Those are sort of quote unquote unknowns when most of the work we do is actually innovative, which means it's procedural knowledge, which it means it's knowledge acquired by doing, which means you're actually operating off assumptions and hypothesis all the time under the guise of, I don't know, but I will figure that out.

And so you can get into this, I like to talk to this fate or destiny, right? Your fate or your destiny is, your fate is pre, you know, predetermined by, you know, the sister's fate. You know, if you, if you believe in that or you know, like God has ordained for you if, if you want to go down that route. But the idea is that at some point your fate has already been decided for you. Versus destiny to me is the idea that I make for myself my future. And I would argue your fate and your destiny come from the same place, right? So if you look at, I know, and I don't know, you can create this little like four by four, two by two grid, right? A quadrant and you can come up with I know, I know. Which is the stuff you've already learned either procedurally or decoratively. I know, I don't know.

Which is the stuff that you intentionally didn't decide to go learn. Right? You know, didn't take that class in accounting and I don't know, I know it just oftentimes as we get older, as you, as you know, you and I are probably about the same age. You start forgetting stuff. But it's very internalized to us. It's so deep in us. We don't even recognize that we have that as pattern recognition. But our destiny, our fate comes from that last box. And does the, the future of a company, if it's being innovative, trying to solve problems is, I don't know what I don't know, right? That box is actually disproportionately larger because that's the universe of actual existing possible knowledge out there to which we only know maybe let's say 1%.

And I'm being very generous by saying 1%, it's, it's probably like 0.0, 0, 0, 0 1%. So most, most of things that could be understood or or known are actually in this box if I don't know, I don't know. And so that is our ignorance, right? That's, that's where our innovation comes from. So if you do not have a culture, if you are not set up personality-wise to go, I just fundamentally normally don't know, then you'll never truly be successful as an innovative leader. Nor will you be able to create teams that are innovative. And that gets back to that celebration of errors, which is really about, which I took from Amazon, they called it correction of errors. But the idea is how do you create a mechanism to create a culture that's psychologically safe to make mistakes and learn?

And that is what celebration of errors is all about. Because fundamentally what we're trying to do is just acknowledge, I don't know, but it's okay. Please go figure it out. Go make a ton of mistakes. Cause that's how you're gonna learn. The mistakes are actually gonna teach you. And then through those mistakes you go on and find new interesting mistakes to make. And that is fundamentally at the core, that sort of flywheel of innovation comes from, I don't know. Yeah. And then you trip, you fall, you pick yourself up and you go, oh, now I know. Yeah. And then you go, do you do it all over again? You find another thing to go trip up over. And I think so much of us, you know, the last thing that I learned, and I, I'll put this gently.

When I was at my first company, Boeing, I met a lot of people. I was coming outta grad school at that point. I was like in my late twenties coming into my early thirties. So I would meet people at their anniversaries at work and they'd been there for like 30 years, which still to this day sort of blows my mind. And someone would be at one company for longer than I had been alive at that point. You know, it's just, it's, it's amazing, right? It's an amazing testament. But what the, the interesting thing I saw a lot with folks who became used to getting experts, and I don't think this is, I'm, I'm using an example from Boeing, but this isn't specific to Boeing, this is true of anyone, and this is something we should all aspire to avoid, is that they got very used to being experts in a single subject and they got very brittle emotionally and intellectually around not knowing something.

And so what they did is they tended to avoid things that they didn't know, and they focused on the things that they knew as experts. And I found that that created a, a gap in their ability to grow and be innovative as engineers. And they tended to just retread the same space over and over again, in part because the culture did not promote, hey, it's okay to say you don't know, right? Just go out and figure it out. And so that was another learning that again, through people, I, I just realized I did, I wanted to become an expert, but I also did not want to have my intellectual self, my curiosity be stamped out because my ego, that was my read on it.

My ego would not allow me to sort of say, I don't know. Because a culture wouldn't allow you to say, I don't know.

You touched on a couple important aspects of psychological safety in a workplace. The, and and, and there's a book that I really love that I read this year, the Four Stages of Psychological Safety. So first off, you know, just go go through it real quickly. I think you'd be interested in Yes, please. In this first off is inclusion, safety. Do you feel accepted, valued as yourself? Like, well the one, the one expression Tim Clark uses is, is it expensive to be yourself or not? So you've, you've touched on this of environments where you feel fully accepted for the human being that you are not the resource who's contributing whatever work.

And then the second stage is learner safety, which includes, is it safe to say, I made a mistake. Is it safe to say, I don't know. Is it safe to try and learn something new? Like I, you know, in pandemic times, you know, I think this is a helpful exercise. Go force yourself to go take a class on something that you really don't know much about, to remember what it's like to be a new learner. You know, I think that builds Exactly Yep. For people that you're, you're hopefully working with. So you have inclusion, safety learner safety, contributor safety. Are you safe to do work that makes a difference because that's a human need. And then the fourth level that's harder to get to is challenger safety. Is it safe to challenge the status quo?

And that's where innovation comes from. Yep. And I think it's all connected. Like you said, if, if you have a culture where you're only allowed to do experiments that you know are going to succeed, that's not innovation. That's the primary objective though in a lot of workplaces is never be wrong, don't have a hypothesis that doesn't play out. And like you could survive that way, but you're, you're not really gonna thrive.

Yeah. I mean even if, even if you argue 80% of what you should be doing is maybe more turn the crank kind of work, you still need some amount of innovation in that to keep on growing and evolving and changing to the times. Right? Customers, you know, we as consumers are inherently fickle and you know, how we behave, you know, and operate and what drives us today is gonna be different, you know, even in a, a span of a year or two. So companies who, you know, know how to listen to their customers and, and use that as as to drive their innovation will always succeed. And those who just keep on doing the same thing, at some point they will be left behind. And you know, we can see lots of companies gone that way and you know, and that's, that's part, that's part of the nature of companies.

But yeah, I I love, I love the the, for the, for the idea of like, hey, I get to first be myself, then I get to sort of acknowledge that myself in flawed, right? And the next piece is even as a flawed person, I can contribute. And then as the final one is, is, is really the test is like with all those things said, I can also come in and I can challenge and that's, that's as much a statement about like what kind of leadership do you have and the psychological safety, the leadership be it okay to say, I don't know. And also being able to share in, in the, in the sort of leading of the company and that, and that's an interesting, that's, I think that four stages are really deep. One that's actually probably the hardest for a lot of a lot of companies to get to because it requires everyone at the company top to bottom to buy into psychological safety.

Cause I've definitely been in places where I can create a lot of safety for everyone around me, but maybe my peers don't agree with the psychological safety. So the moment I allow someone to challenge me, even I, even though I might be comfortable with it, they see that my, my peers, you know, my boss might see it as a weakness is like, oh, ward has, you know, his team completely like undermining him and you know, they question him, so why don't I even have ward? Right? Like, cuz they don't understand the value of psychological safety. So,

Or yeah, there's, there's misunderstandings or mistakes. People think psychological safety is the safety to not be challenged. Like no, yeah, no, no, no, no. Creating the safety for people to challenge you. And if you're not a leader who wants to be challenged, then for like, for one, don't promise people that you're gonna have a culture of psychological safety or don't promise people that you know, this should, this is a safe space. Like no, like saying that doesn't make it happen. But, but that, I wanna go back to, you know, celebration of error. CoE I I think you said something war that, you know, I wanna explore that, that all errors are not created equally. Like would you equally celebrate the error that comes from the part of the work where you like, say you're just cranking out work versus an error that's made when you're trying to be innovative and doing something brand new or, or do you need to have a culture that celebrates all the errors?

You, I mean it's a, yeah, it's a great question. I mean obviously I prefer to see the more innovative like, hey we were really pushing ourselves over at skis. You know, I always go back to like when I was learning to ski with my father and I used to like complain that it would fall flat down in the snow and like how horrible of a skier and he is like, you know, no matter how good you are, if you don't fall down at least once or twice a day, you're probably doing it wrong, right? Like, you're not pushing yourself. So like I wanna see more of the, hey, we pushed ourselves on the, in the edges caught like we really were pushing on the envelope of what we could do. But that said, you know, like there is this, there's nothing wrong with it operationally. Like that can be a celebration too cuz I want people to own our process, their processes. You know what, what does lean teach us? It really advocates for pushing decision making down to the lowest level in the organization.

Who can, is most informed by the decision. So celebration is there is also letting them know, hey, it's okay if you made mistakes. You know, what I ask is like, there's, there's a few things that we go through is like, I always ask my leaders, cuz I'll ask, should we celebrate every everything or you know, like, cause we actually write a CoE for, you know, look, at some point there's diminishing returns to writing everything up. So you should be really focused on am I gonna learn something from this? If you don't think as a leader, don't spend the time and energy to do the root cause analysis and look for the short term and the long-term solutions going forward. And also make sure you follow through. That's the other thing is like, I don't want a bunch of CoEs where we say, Hey, we could do this in the future to avoid this mistake.

No, no, no. If we say, if we, if we're gonna do a CoE and we put a long-term fix in it, guess what we're, we are promising we are committing ourselves to actually following through. Cause that's the other piece is I wanna teach the follow through, you know, and there's lots of things we do with CoEs, but a lot of it is about ideally trying to make building better and better processes that protect us more and more, giving us more and more opportunity to spend on the edges. Like when I first showed up at RealSelf with no, no disrespect to anyone, you know, at RealSelf when I joined mis a lot of the mistakes that we discovered in production had been there for three or four years, five years. No, no one was paying attention, no one was looking, you know, nowadays we're down to about 15 minutes of something sits in production normally before we find out about it because over time through the CoEs we've added better and better instrumentation monitor and learning.

We know what to look for and the teams know how to more proactively monitor those for those things, which is incidentally driven a lot more trust from the rest of the organization back into the technology org. That the technology org is taking care of things. Cuz the worst thing I always tell my teams is it's, I don't mind you making a mistake, I really don't like it when someone else from the, the other, other part of the organization, or worse our customer tells us about the mistake, right? Like if you tell me about it, that's an okay thing. Otherwise, you know, you should, we should all look at us go, hey, we failed our partners at the company because they had to tell us that we made a mistake in production, right? And in the worst one would be our customer coming back to us after a month and saying, Hey, do you know you have a bug in your code?

You know, so again, I'm, it's, I want people to have, like you said, being psychologically safe doesn't mean being challenged. It actually means being challenged and and being okay with that. And it means being accountable without being fearful of the consequences of that. And so how do you build a culture around that accountability, around the ability to communicate outwards and keep people informed? So we use CoEs as a way of on our weekly business reviews, we, we share out our CoEs and the rest of the organization uses CoE is the same way as a broadcast mechanism. Like, hey, customer support, you know, all those complaints you're getting about, you know, yeah, engineering knows about it and here's what we're doing about it, you know, and we also have mechanisms if that's truly the case, to escalate.

So customer support doesn't wake until the next week to find out about this. You know, cause that, that oftentimes happens, right? Like something happens in the system at least, especially in software where customer support is on the other end of the phone getting these people screaming at them and they have no idea what's going on because they're not involved in the day-to-day, you know, nuances of production releases. So it's really important for engineering to immediately go off to customer support and say, Hey, you know, all those calls, they're from us, we know about it. So you can tell customers we're aware of it, thank you. And here's our ETA, our, you know, our ETC when we're gonna get this fixed and we'll tell you once we get it fixed. Right? So that makes customer support a really great ally in that case versus another other companies, if you don't do that, customer support starts to hate the engineers.

Cause the engineers keep on breaking stuff and not telling them and they're just, they just end up being the, the, the poor souls on the end of the phone call getting yelled at, you know, with no recourse, no way to communicate, no way to, you know, so they never get to feel like heroes, which is a, is a shame. So, you know, it's how do you build the connective tissue in your organization? That's another reason why we do CoEs formally. So should you do it, I think the underlying question I would sort of say is I try not to prejudge CoEs, right? I'm, I'm actually trying to maximize for learning and I don't want to say, oh, your organization isn't at the edge of innovation, therefore I don't care if you make a mistake. No, I want you to improve your processes and I want you to feel ownership over it and not be fearful that, that your process isn't working the way, you know, because again, this is a deeper lean learning, right?

You know, one thing when I was working with Shingujitsu always talk about, it's always process over people. People don't make mistakes, processes do, right? People don't show up to work and go, you know what? I'm gonna have a really bad day today and I'm gonna ensure that something goes wrong. Right? Right. Yes, you can go find me an exception case, but like, let's, let's not lose lose that as like that's an anecdotal one versus 99.999% of people actually do show up and care about the quality of their work.

Yeah, right. There's a difference between sabotage and errors and I think…

Pretty rare. Yeah. Yeah. And it's, that's, yeah, that's another way to say this, like what you're talking about is a sabotage. What we're talking about is human error and the human error really drives from processes, communications, setting expectations, there's lots of things, but it's not the person themselves that made the mistakes. So the CoE is, is also meant to create psychological safety. It's not you, it's us somehow we failed you like as a team. So how do we as a team go ensure that this doesn't happen again? And hey, since it happened to you, could you also be a part of the process? Cuz you probably know best. Like, oh yeah, that wording and that little line there was really confusing or that link is old and it sent me off to like, well let's update, you know, sometimes they're super easy things, but again, if we don't enculturate people to go, just go fix it, then, then people won't, well they'll just go, well that's, that's someone else's job.

No, it's all our jobs. Like if you're touching that, go fix it Again. That's what lean always teaches is makes those decisions at the lowest level have, have the people on the line own the line. Yeah. Right, right. And so CoE is really just another, another means for exactly that, that sort of philosophical belief.

Yeah. So there's that philosophy. There are a lot of important mindsets here. And then there's the CoE document that, you know, when you refer to writing these up, is there a a template available on your website or is the template even not as important as covering the main components as article described?

I think the Forbes goes over the template. I'm happy to share out. It's super simple. It's, it's actually sort of how you talk about it. And I even have like an hour long lunch and learn. I'm happy to share out links to that or if anyone wants to, I'll come and talk to 'em about it. And cuz the format is, is again the vehicle floor, but the, the top of it is an impact statement. And that's, I use that actually to teach especially more junior leaders how to communicate more at an executive summary level. Can they write that in three to five sentences using quantitative data? You know, how many customers are impacted? How long, when did it start? When did we observe it? How long was it in production? Was there a monetary impact? Right? So again, quantifying, and again, this can be really useful, especially amongst people who, you know, I, I'll take engineers, engineers tend to oftentimes be the, the most distant from a business acumen standpoint of understanding the impact to a line of code to like impact to revenue for an example or cost.

And so when they write that CoE, they're like, oh wow, that one line of code that, you know, took down the site for 15 minutes maybe cost the company, you know, 5 million and like, you know, that's a lot of money. You know, like that's, that's, that's a lot of responsibility that I have as an engineer now versus they'll just go, you know, if you just look at it as lines of code, they'll go, oh, it's just one line of code. It's like, yeah, it's one line of code that you know, took down the site, you know, and it, you know, and that's okay at some level, but like please don't distance yourself from that. Please understand and connect yourself to how important, how much impact you can have at this business. Positive and negative in this case not so great, but like let's learn, use it as a learning, right? Like let's use that as an investment in your education about like how important that one line of code is.

And, and then you get into that's impact. So three to five sentences, really good to learn how to be succinct. And then what I do is I always put under the next section is resolutions. And I do short-term and long-term. I normally break it into short-term and long-term. Short term is like put the fire out, okay, we had a fire, that's the impact fire the extent of the fire, how much damage then it's short-term resolutions, here's what we did to put the fire out. Like you, I don't know, we went and started the server back over, we got customers back getting their orders. Fundamentally the error still like this but at least we're, we no longer have that issue out in production or we roll back the code or we fixed it and then, and then the long term solution would be okay, maybe it was just a simple bug fix, it might actually be something deeper like as you're getting through the root cause analysis might go architecturally we're set up incorrectly and like we have this massive set of major probability of this, this reoccurring.

Okay, should we go re-architect that? And again I get into like, please do not pontificate on the shoulds. Like either do it or don't do it. I don't want to hear about what we should do. Because a lot of times engineers will use that as a, i I pick on engineers, I I deal with 'em lot see this a lot. They'll use it as a parking lot to sort of gripe about like massive tech debt that no one's never, no one's ever gonna pay down. And it's like, okay, well let's not talk about that because it really doesn't engender anything helpful. I want you to be proactive about what you will do, not what you could do. Don't moralize the problem, you know, be very much like proactive and in the bottom it is really the root cause, which a lot of people will go, whoa CoE is a root cause analysis. I go, no, the, the bottom section is your, your dumping ground for your root cause analysis.

And that's when we get into the five why's. But I use that as homework. I, what I carry as an executive is the first two sections impact and solutions. I look at the root cause largely to make sure that I have faith in those first two sections. But I almost don't need that third section of like what was the root cause as an executive. I use that again as a fly by. Like did you actually dig into the code? Did you actually talk to other people? Do you really understand what you're proposing or were you just trying to like slap this, this problem shut and go away, you know, which sometimes happens. So that's, that's where I sort of, if I don't quite believe in the impact or I don't quite feel like the solution is really keeping it at the root of it, I will look at the root cause and that's sort of where I can interrogate the team's thinking there.

So the format's pretty easy and I try to keep it the one or two pages actually the the, the first two things should be one page. Yeah.

Well and as it's described in that article, and again that Forbes article that I'll link to titled Celebrating errors Create Psychological Safety in the Workplace. And when you talk about impact resolutions root cause it sounds like that's kind of the order of documenting it where the thought process is thinking through the root cause. So you know what the long-term resolution or the long-term countermeasure is, but like you said that that's where you show your work.

Yep, exactly. Yeah, it's a, it's the document's deductive to your point, inductively you would actually probably need to write the first piece, the bottom piece, the root cause first, though I'd argue the impact actually does not need to be done with the root cause. And that's, that's the, that's the one thing a lot of people trip up on is like, well I haven't done the root cause analysis, like the patient's dead on the table. Like you don't need to understand all the mistakes made the patient's dead. Like that's, that is your three to five sentences, right? Like I'm using an extreme example from when we're always talking about like the surgeon and, and, but it's sort of like there there's a defect, there is a problem. Like what is that defect? How big is it?

Like that has nothing to do with how you got there. That's just describing like here, here's the outcome of that and that's to inform people. And so that can be written normally within 24 hours of a, of a defect or an issue being found, especially if it has material impact to the business that other people need to be aware of in short order. I would recommend no later than 24 hours from time where you sort of cut the start writing the CoE and then that will, once you get that resolved then go spend time doing the root you probably and very quickly in the same time your short-term resolutions might also be written and done and executed in the same amount of time. Right? Because a lot of times you're just trying to make the mistake go away.

So put out the fire short-term, long-term is make sure the fire, this particular fire doesn't happen again. And I find that that framework is very useful for people cuz a lot of times they try to, they get, try to solve it all, doing it all at once. It's like no, just put the fire out, okay now then we've got the fire out, you know, and we've informed people of the fire we get, we've bought ourself a little bit more time to breathe and go, okay, what would we need to do to help us make sure this problem doesn't happen again? Or if we can't do that in a lot of instances, especially in an engineering world, how do we monitor an alert for ourselves to make sure that if it does happen again the meantime to response is faster and or ensure that it's not a customer telling us, but it's our on-call person getting alerted at two o'clock in the morning if we think it's important enough.

So I'll be looking for those kinds of things, you know like okay was this a manual detection? Okay, how do we automate the detection? Was this seven hours from injection or seven days or seven months? How do we get it till like being seven minutes or seven seconds or better yet how do we get it in unit testing before we even get it the production so that we don't even really ever see it and it just becomes part of the course. So you're always trying to just improve things even if you can't necessarily eliminate things. And so you can, you can use a CoE as a very good way to sort of gauge the healthier organization and crucial, like I said along the way teach all these other things. But it's all rooted on s psychological safety. You won't get the accountability, you won't get the communications, you won't get the growth if people don't feel safe.
It's as simple as that. Yeah. Yeah. They gotta feel safe. We all have to feel safe. We do, you know, top leaders too.

And I was gonna ask you one final question before we wrap up again. Our guest has been Ward Villuemot, you can find his website wardvilluemot.com when you talk about the firefighting and the root cause analysis. And it's a visual joke because it was a cartoon that I created with somebody, I'll share it with you later ward. I'll put a link in the show notes. But it's a couple of firefighters. There's literally a burning house and they're grabbing the hoses and the one turns the other with this piece of paper and says, well hey wait, have you started doing your A three yet? So this is a very nerdy lean Toyota Production System, problem solving kind of joke. But the point is a serious one, it's you gotta put the fire out first.

And then we can think about defining the problem. Well the pro the problem was right in front of us and we, we can do the root cause analysis once the sa the everyone's safely out of the building. Exactly. And the fire is no longer spreading.

Absolutely agree. Yeah, that I love that. I love that.

So the other question I was gonna ask, and it's kind of unfair to ask you this question maybe like sort of on, on the way out cuz this could be a whole 30 minute discussion in and of itself. And when you talk about the safety to be yourself and to be who you are and you disclose under your website, you mentioned earlier that, that you are autistic. Is, is it ever a mistake to disclose something that, that personal with people you're working with?

I think it's only a mistake if you think it's a mistake. I mean, I I I am personally of the opinion, you know, every, every decision has a cost. There's nothing that's costless. So for me, sharing that I'm autistic, I'm sure there are people who don't wanna work for me or work with me or don't want to hire me, the way I look at it is I'm okay with that because it's more important for me to be true to myself than necessarily have that opportunity. Now a different person might decide differently, their calculus might be different. So, you know, it's hard for me to sort of say, hey, do tell that, especially if it does mean that hey, maybe that one opportunity, that job you really wanted, you're not gonna get, I would argue it's not worth the job if it means I can't be my true self. But that's me. That's, that's, that was something that I learned.

And so like I'm always trying to, I try to take the weak form of the opinion, which is like, for me, for me, this is what I know. You, you, you know, you can use that framework to make a different decision for yourself. I rarely will have the strong opinion but I, you know, I don't wanna work in a world where people have to hide themselves cuz I don't wanna work in a world where I have to hide myself. And you know, I think when we think about like inclusivity, as you talked about even from C oe, but I even think of like diversity and equity and inclusion. I think that's a part of, you know, allowing people to come for as they are. And you know, I, I quit but the T in c t o, you know, people, you know, what is it, you know, technology and sometimes say it's chief therapy officer. Cuz so much of my job as a people leader is really helping other people become more comfortable, more integrated with themselves.

Which I find a little ironic because I am autistic, but probably cuz I've spent the last 40, 50 years trying to integrate with myself. I'm a pretty good observer of human behavior and at least have some ideas of help helping people. But I do spend a lot of time like helping just people become more integrated versions of themselves. And that's important to me. That might not be important to everyone. And some people that might be like, oh my God, that would be my nightmare if I had to work in that environment. And that's great. Like there's lots of companies that aren't like that, you should go work for those, but if you come work for me, I told my, he's now head of Titan Caskets. Well, I interviewed him from Amazon. I said, the last thing I said as we were ending the interview, I said, by the way, I, I will oftentimes tell you I love you. And if you're uncomfortable with that or have uncomfortable with telling your team, you probably shouldn't come work with me.

So that was the thing that sort of cinched the deal. You wanted to come work with me because of that. And again, that's sort of like a, it's again, I, I am true to myself and I want people to be true to themselves too. And yeah. One more. Can we ask of anyone? I think so, yeah.

Well, Ward, we can't ask anything more of you today. Thank you so much for sharing your stories and your experiences and your insights here. Really appreciate it.

Thank you. Thank you, Mark. Really appreciate it.

So again, we've been joined by Ward Villuemot. Go check out his website, wardvilluemot.com and great article. At first, I, I almost made the mistake of attributing the authorship to Ward, but it was actually written by somebody else about the CoE method. I'll link to this in the show notes, celebrating errors, create psychological safety in the workplace. So Ward, thanks again.

Thank you.

Well, thanks again to Ward for being our guest today. For a link to that article about celebration of error and links to his company and a whole lot more, look in the show notes. Or you can go to markgraban.com/mistake195. As always, I want to thank you for listening. I hope this podcast inspires you to reflect on your own mistakes, how you can learn from them or turn them into a positive. I've had listeners tell me they started being more open and honest about mistakes in their work, and they're trying to create a workplace culture where it's safe to speak up about problems because that leads to more improvement and better business results. If you have feedback or a story to share, you can email me MyFavorite Mistakepodcast@gmail.com.

And again, our website is My Favorite Mistake, podcast.com.