Detailed Notes
In this episode of Building Better Developers (S26E04), hosts Rob Broadhead and Michael Meloche continue their conversation with Adam Malone on how trust and reliability shape successful teams and lasting customer relationships.
Adam explains how consistency, empathy, authenticity, and performance define reliability — and how revisiting your principles keeps teams aligned and customers confident. Learn why early, honest communication builds stronger foundations and how shared ownership transforms every part of the customer journey.
🔗 Read the full blog post: https://develpreneur.com/trust-and-reliability-matter-interview-with-adam-malone-part-2/
*Connect with Adam Malone*
If you enjoyed this conversation and want to learn more from Adam, he’s always open to sharing insights and connecting with like-minded professionals.
LinkedIn: Adam Malone on LinkedIn https://www.linkedin.com/in/adammalone-speaks/ Website: http://thetenaciousoperator.com/
Visit him on LinkedIn and drop him a message to continue the discussion around leadership, reliability, and building consistent customer experiences.
*Connect with us:* 🌐 Michael Meloche | Envision QA | https://envisionqa.com/ 🌐 Rob Broadhead | RB Consulting | https://rb-sns.com/
#BuildingBetterDevelopers #Trust #Reliability #Leadership #Teamwork #CustomerExperience
Transcript Text
[Music] Well, hello and welcome back. We are able to breathe again. We've been holding our breath since the last episode. We're going to get into part two of our interview with Adam Malone as we continue our season on building better foundations. But first, I am Rob Broadhead, one of the founders of Developer, also the founder of RB Consulting, where we help you do technology better. We sit down with you. We help you assess where you are at, where your business is at, not only today, but also like what are your plans? What are your visions? What are your goals? And then we help you create a roadmap to utilize technology better than you're doing it today, but also to position you for tomorrow so that you have a road map for success that either you can execute or you can team with us uh will help you out as needed to execute along the way, even completely executing it for you if needed. Check us out at rb-sns.com. Uh you can also do a really quick and quick and free assessment kind of thing to get some advice at matrix mat r ix.rb-sns.com and check us out there. Uh good thing, bad thing. Uh good thing is uh so we're continuing this uh uh working on a house that was its own little good thing, bad thing. And in doing so, uh it's like it's the fun things that you have. So, we're redoing some floors and a good thing is one of them was like and it's lenolium and it was laid out not terribly well and it was pretty beat up but ripping it up was super simple. It was like basically you just like you know a little hammer, a little nail, some stuff like that, a little screwdriver to pry some stuff up and then just lift and you know a couple of minutes later and a few you know not even very bad cuss words and it's like everything's up and we're ready to go. Uh the bad news is that we did have one of the three rooms that was we're not so lucky that the glue was done differently and stuff like that. So um I'm gonna have a lot of gun time with a heat gun for a little bit as I'm slowly like peeling my way through floor for the next uh next little bit here. So not the funnest thing. Hopefully more not it will be much more fun to listen to Michael and his introduction than playing around with a heat gun. But you never know. I guess it depends on how much of a gadget person you are. Go a introduce yourself. >> Hey everyone, my name is Michael Malash. I'm one of the founders of Building Better Developers, also known as Developer. I'm also the owner of Envision QA, where we build custom software that helps businesses owners take back control of their operations with a strong focus on service reliability and long-term success. From streaming to workflows to replacing outdated systems, we create tools tailored to your business. And we don't stop there. We uh back everything through testing and quality checks to make sure it works right the first time. Check us out at Envision QA where we combine great software with great support so you can run your business with confidence. Uh good thing, bad thing. Uh I guess uh good thing I've had a little bit of kind of downtime. I've been running some testing on software and that which takes time and ties up my computer. So, I've decided to clean my office and well, I I've made lots of progress in here. Uh the good thing is I've eliminated probably two uh mini bookshelves or a full bookshelf if you got a big tall bookcase. Uh bad thing, my office is completely trashed at the moment. So, I'm I'm got to clean that up next. But, uh hey, making progress. And here we go. We're going to dive right back into part two of our conversation with Adam Malone. We're talking about trust and building it and how it impacts projects, teams, and all that kind of goodness. So, here we go. Picking up almost exactly right where we left off. >> So, you know, we've been talking about principles and you talked about just now, you know, having the VP and the PMs and that and breaking it out. As you go through the process of working with the all the players and you define these principles, how often do you feel that you need to go back and revisit the principles to make sure that they're not stale, that you're on track, and that everyone continues to have the same buyin for the project. >> Um, I would make them a touch point at nearly every, you know, depending how you run your projects. um you know not daily but the the meetings where you're reading out on status and that you're especially kind of hashing through an issue that you're having um they need to start with this uh and ideally you've you've codified these enough that they are maybe one or two PowerPoint slides and that you can say hey guys we are here today uh because we have some contention about how we handle this business requirement. Well, part of the reason that we are in contention is we don't all agree how that ties into the principles we set out at the beginning. As a reminder, here are the principles that we agreed to for making these decisions. Now, here's the business requirement that we're trying to work through and the solution. Bob, you you cited that you were concerned that we might not deliver against the principles because of that. Can you explain that? Yeah. Okay. And then you actually ask people, hey, does everyone agree with Bob? like can we all agree that that the risk that he's cited would violate the principles we've agreed to because sometimes this is helping some a member of the team see like hey you're concerned about a risk that we've solved for elsewhere right um and then also saying does anyone else feel this way is anyone else concerned about this as well and having that conversation but um I mean to put a timeline on it I would say these should be in front of the team almost every two weeks or so. Um, even if it's just a, hey, this is our bi-weekly readout. As we mentioned, here are the five ways we're making the decisions around here on this. Does anyone have any concerns about those as we kind of have learned more over the last two weeks? And 90% of the time, it's going to be really annoying because no one has anything to say. And you're going to be like, why did we even spend five minutes on this? But it's that one time that someone says, "Hey, when I was doing XYZ thing on that business requirement, that's not how I built it or that's not how the development team is working on that or that's not how the operations team is going to deploy that because that's what you have happen, right? Is the tech team goes and does stuff and then the operations team goes and does stuff of like how they're going to operationally handle the outcome of what the system tells them frequently. and we don't like go revisit those enough. And so that's that's part of why I'm saying it's helpful to look at them regularly and also helpful to have the different views from the team in there to say, "Oh, this doesn't actually meet what I just built with my team." Um, and get and make it acceptable for people to say that. They're not going to get in trouble when they say that. >> Now, with these principles, I I know you're talking, you know, within your team, within the products. Um, have you defined or have you ever worked out principles with dealing with the customer like the end goal within these principles or within different teams? Um, just kind of curious how you handle that or what your thought process is on putting that together with a team that may never have worked with something like that. >> Yeah. So definitely have and that can that has involved everything from hey we have a replacement strategy for how we want to handle a customer who complains about their product for example and again if you say well we just want to deliver the best customer experience possible well that's going to mean that you just give that customer a bunch of either money directly or you you know give them a Cadillac when they bought a Kia. Um, and so helping people to to really codify, yes, we want a great customer experience. What does that look like when someone says, "Hey, I have a product return as an example." Okay, here's how we define as a group what that should look like. Um, so there's going to be some process discussion. How do we treat the customer? What documentation do we ask for from them? Are we going to require them to return their product to us before we give them a replacement product? All of those things need to be discussed and thought of through the lens of we want a great customer experience, but we can't break the bank and we have to be able to deliver it in a reasonable time frame, right? Um, and so defining those, here's what we want that to look like, and then really meeting on them and being open to people saying, "I don't like I don't think we're delivering what we want or ideally reviewing, especially if it's an exception like a return or something like that." Those likely happen infrequently enough that you can bring the team back and do afteraction reviews and say like, "Hey, Michael called in. He had a return. Let's walk through how that return went for Michael." And then we're going to like at the end everybody raise your hand if you think we did the right thing for Michael or if you think we didn't do the right thing for Michael, right? And and then you can start to build group consensus on, you know, I don't actually think we treated him the way we all wanted to treat him based on what we said the principles are. Okay, then what do we need to go fix and change? Um, but but too often we can accidentally act like, well, if it's a customer thing, the customer experience team or the customer support team needs to be involved and like the rest of us kind of don't need to be aware of it. Um, or if it's a supply chain thing, hey, we don't want anyone to come talk to us. Like, we'll do a good job, you know, shipping product out, but kind of stay out of our business. drop the order to the ERP and we'll handle it from there. Well, we need every group to be okay having those conversations about the customer and the customer experience um in a way that we may tell each other that the the baby's ugly and and we all have to own again back to the commit concept. We all have to own that it's our baby. It's not Michael's baby and Rob's baby or Adam's baby or customer solutions baby or supply chain's baby. This is what we all agreed to build. So, we're not indicting anyone when we say it's not delivering what we want. We're if anyone's being indicted, we're all in it together. We're not kind of pointing fingers and throwing people under the bus. I'm sorry I rambled a bit there, Michael, but >> Oh, that's great. I I kind of have a follow-up to that. I kind of want to flip that now. So we've talked talked a lot about you know your team and internally. So how do you build that trust using the same kind of model with your customer? >> Okay. So um the trust is built on three components and actually try not to say build trust but we'll take that for another time. Um there's three components of trust. Uh these are empathy, authenticity and performance. And so when someone chooses to give us their trust, we have delivered on their need to feel empathy, to feel that we are being authentic and to feel that we will deliver on our performance or our commitments, right? And so we are our goal is to the language I like I want to inspire Michael to give me his trust. I don't get to build trust because it's not permanent and I don't get to decide when you trust me. I can invest in each of those components of trust such that you're inspired enough to give your trust to me. So first I would try to use that language of how do we inspire our customers to trust us? And I would look at each of those buckets. So empathy is when someone feels like they are seen and cared for. Um uh here's an example of that. Um, have you ever have you ever called into like a call center because you had an issue and um the call center rep just said like, "Well, I'm sorry. We can't do that." And you How does that feel like when they just kind of flatly tell you like, "I'm sorry. That's not how it works. We can't do that for you." Does that feel good? You feel seen? >> No. It's frustrating. >> No, it's so frustrating. And and so like what you can see is and this can't be fake. That's going to be on the authenticity piece. But on the empathy piece, there are little cues that can be so helpful in developing and showing empathy to your customer. Hey, Michael, I've heard your concern. I want to make certain I understand it. You said that this was the part of your Dyson vacuum cleaner that wasn't working. Did I get that right? Yeah. Yeah, you did. You did. You got that right. Okay. And I also heard you say X is is did I understand that right as well? Yes, it is. Okay. Can you help tell me h how you would want this how you want us to handle this for you or what would solve this problem for you? Well, all of a sudden the customer has felt seen on what's going wrong. They felt seen on kind of what their concern was and now they've been engaged potentially on well here's here are some things I would like to do. You're going to have lots of people that listen to this to say like, "Well, you should never ask a customer that." Um, but I'll tell you, lots of times you'll find that people actually want far less than you think they do. They just want a new knob for their vacuum cleaner or something. Um, and so sometimes there can be a lot of power in asking because you'll find that there's a bunch of people that you can just solve their problems outright for them and it's way less than you thought when you were going to build a standard response. The second piece is after that is you can say let me go let me let me go review that for you right let me go compare that and even if it's just 10 seconds or 5 seconds where you go and you kind of work on that and you need to be authentic like I said but that doesn't mean you know you have to like go run it up to the CEO right but can you can you display empathy and that Michael's got a problem and he wants to feel like someone actually tried to work on it and didn't just look at a matrix on a screen and go, "Sorry, I can't help you with that." Right? Um, so, so developing empathy is one, showing authenticity is the second, and authenticity is, do I think I'm getting the real you? And so, when you're engaging with a customer, the times where they feel like they're not getting the real you, that could be as simple as tone of voice. Um, thank you for calling AT&T. Um, or you know, I've called Comcast a couple times. You know, thanks for reaching Comcast. It's a pleasure to serve you. It's like, I don't think so, bud. Like, we we're starting this out in the wrong place. But how often do we all have engagements like that with like external customers or even customers within our own company that way of where we're just kind of like reading from a script uh in our actions and it doesn't even feel like we're trying to be real. Well, we need to show people that we authentically care about them and their problem and that they're seeing the real us. Um and then finally on performance um that's about do you have the skills to help me with this problem and then will you do so reliably? Performance breaks really carefully or easily into performance or capability versus reliability. Um and so we can improve people's perceptions of our performance by focusing on both of those. Hey, um, again using the Dyson vacuum example. Hey, miss, you know, Michael, um, we do have the part that you want in stock. I have allocated that part. It's it's on order for you and your name is attached to that order and you will get a whatever a confirmation code in your email in the next 10 minutes telling you that that that part is on the way. Right? So, you kind of you establish I have the thing. I know what to do with the thing. and here's a way that you can test my reliability because I've told you, hey, in 10 minutes or 30 minutes or an hour, you're going to get an email confirming your order. And so now you can expect that email. And when you get that email, all of a sudden, that's a confirmation point that I delivered on my performance. Um, and I think a a lot of the time that we fail with internal and external customers is we don't invest enough time and displaying um that we're going to be reliable. Um, but and reliability is actually a huge part of people's perception of performance. And so you can actually do yourself a disservice if you ignore those things. If your system has a gate that when it goes through people get notified, tell them about that. Your system is going to do it no matter what. But now when people see that happen, they're not like, "Oh my gosh, Rob sends me an email every 10 minutes." No, they're going to say, "Oh, Rob told me that when my project kind of got through this stage gate, I would get an email or I would get a note. I got that note. Not only did Rob do what he said, but I feel good about the fact that my project moved forward or my shipment has come here or whatever." Um, and so using concepts like stage gates, even if they're to reinforce communication patterns, can really help develop trust in ways that are very low cost, often they only cost us communication, which is nearly free. >> Nice. Now, do you ever combine the two? So you have like your internal trust, your internal meetings kind of defining what you're doing. You have your customer experience and that do you ever uh how do you combine the two processes so that you know that your customer expectations and your internal expectations are kind of in line with each other? >> Yeah. So a lot of my experience has been in um regulated products like insurance products and so sometimes like you literally have compliance departments that are supposed to help you make sure you do that. Um, and both of you smiled real big when I said that. Um, and I would say part of the benefit that you can do is if you can help people see the value of that compliance department as opposed to, uh, the compliance people are here again to harass us. Instead, saying, hey, these are some of the few people in the business that see everything end to end. They can really help us inspect and understand what's going on. Um that's one way uh is through compliance. Um again I've dealt with a lot of physical products. So um I like to think of what we often called an outofbox experience. Um, and that was something like we would process an order and we would document all of that, whether it was screenshots or recordings or or whatever. And then when that physical product was delivered, we would document that. And then that physical product would like be opened in a conference room with people around the box saying things like, "Oh, like what is the experience like when you were opening that tab? Is that what we want for our customers? When I open the box, what is the first thing I see? Oh, like the first thing I see isn't very appealing or interesting. Okay. Well, I need to change that. Right? But bringing in a broad set of people to see the outcome of the work and then inspect like the process that got your customer there can really help you unite like front of office customer experience type people with operational and technology delivery people to say hey we all delivered this product to the customer. It took all of us to get here. What did that feel like through the entire journey? How can I show that to you as a customer journey and get as tangible as possible with it? Screenshots, videos, voice recordings, and then if you have something where there's a tangible physical product, if it can be opened like in a room with people huddled around it, like invest the time to fly people in and do that. Um, it is highly valuable and I think it's one of those places again that we can sometimes get a little cheap and we'll say like, well, I don't want to pay the travel budget or take people off the phones or get people off their computers to to do the dev work. So, we'll just have the leaders do it. We'll just have the VPs sit around and do this or something. That's the wrong way to do it. You need to bring as many people as possible that are scattered throughout the process to experience that stuff. Um, and some of that gets back to that concept of gimba that I'm talking about. But the the every single process in your company, there is a supplier um and there is a receiver. And um the more you can bring those people together to look at processes end to end um the better off you'll be in understanding the customer and understanding internal needs and in understanding the output. Well, after uh really appreciate your time and you know, giving us a lot of great insights. So, and I'm sure a lot of the the audiences out there applauding as well and saying, "Yeah, great time. It's standing ovation and stuff like that." What's the best way for people to get a hold of you if they're like, "I would really I think my team needs some help. I think I'd love Adam's help." What's the best way to get a hold of you? >> Oh, I appreciate that question. Uh the best way is uh just go to LinkedIn and search Adam Malone. Uh there's a black and white photo of a bearded pudgy white guy with a microphone. That's me. Uh click on that and send me a message. Uh I love to hear from people. Um and and whether that's you just want to kind of toss around, you know, an issue like this, you want someone to talk about it, I'd love to, you know, give you 45 minutes and and do that sort of thing. It's it's the sort of thing I I enjoy doing. Um so I would love to hear from your listeners. >> Excellent. Well, and I'm sure they would love to like us, you know, a lot of great conversations around this. It's a it's and they're the kinds of conversations too that I think you walk away from and you sort of think like I wonder how I can apply this a little bit better and you know in this situation I'm running into or that situation or you know this person that I've been butting heads with things of that nature. So this is great value. Uh like I said, this has been perfect for us talking about like the foundations kind of, you know, of how do you really, you know, set yourself up for success moving forward. And one of them is, you know, like we talked about even like at the beginning getting those things in place and and being clear and a few less assumptions and a few more, you know, maybe even some some tough discussions, but you know, going through those things to make sure that we even if we're not on the same page, that we agree whatever page we're on and we can we can move forward from there. Yeah. >> Yeah. I think uh your call out there is really important that um we're we're going to have the argument one way or the other. And I think that's often why people shy away from a lot of the things we've talked about is they feel like it is conflict and argumentative and we're all going to not like each other. But in my experience, the argument is the disagreement is going to come to light at some point. And if it doesn't, failure is even more certain. But most of the time, that disagreement is going to come to light eventually. And just like, you know, just like fish, it doesn't get better with age. Like the earlier you have those discussions and those debates, um, the better off you'll be over the long term. Um, or you can like leave the fish in the back of the cabinet and, you know, it'll stink when you get there in two or 3 weeks or two or 3 months, right? Um, and the the fight is bigger and harder and worse than it was before. Um, so yeah, working through those early and often is almost always better. Excellent. I think that's a great place for us to wrap this one up. Well, thank you so much for your time and for hanging out with for us for a while. Uh it's been a great conversation. Uh a lot of great ideas going forward from here. So, I'm going to take some of this and be chewing on it mentally for a while as well. Uh you guys have we will have show uh links in the show notes to reach out and uh check out check in with Adam and ask your own questions and maybe have a little conversation as well. And uh hopefully we will uh you know we'll bump into you again sometime soon and uh you know appreciate your time. Appreciate you coming out here and hopefully we'll be able to continue to have some great trust conversations as we move forward. >> Thanks guys. It's been a pleasure. >> All right. Thanks a lot. >> Thank you. >> And that will wrap this up. So this was a great time with Adam. I want to thank him again so much. We've thanked him ausively hopefully affusively enough. Uh it was great. It's been a while since we've done a an interview. I really appreciate him stepping in and doing that. Uh, and it was a great conversation as I think you guys know if you guys so often if you guys got half out of it what I did then I'm sure that it was more than worth your while. Um, we will have l as I mentioned we will have links to to reach out to him if you have questions or if you want to have some conversations. Great guy. Uh, I've had a couple conversations with him in the past and I think you can get a lot out of it. And uh if you're, you know, if your company's struggling with some stuff, then uh he's definitely that kind of guy that you want to point the right people to and have them come in and maybe straighten a few people out and get your team back on track, get the train back on the rails. That being said, it is that time where I have to ask you for an email. Send me an email at [email protected], but more importantly, give us feedback however it is you can give us feedback. Whether that is leaving us a review and and some comment text on wherever you do podcasts. You can do it out on YouTube at the developer channel. You can we have a contact us form on the developer.com site. You can leave comments on any of our blog posts over the last several years. Uh you can also leave us something. Send us something at xdevelopure uh Facebook page. We're out there as well. And someday we'll probably add some additional sites as well. Uh but for now, all of those places are great ways and positive or negative, we want to get your feedback because that is what helps us grow. We're going to let you guys uh dive back into whatever it is you're doing, becoming better, building that better foundation, becoming better developers, and we will return next episode most likely back on topic. But uh we'll see whether we decide to throw another curveball and get another interview in there. We are going to mix it up a little bit in this season of Foundations. Uh but there are a lot of areas for us to cover uh to help you build that better foundation so that you're ready to go and you know you're ready to take advantage of whatever your career in life throws at you. As always we appreciate appreciate you guys so much. Have yourself a great day, a great week and we will talk to you next time and bonus material. Um so we've got like a little mix and match stuff. we had some bonus material at the start of last one basically and then just sort of a quick wrap-up. Um I guess bonus would be just like what are your thoughts? How do you what are like maybe is there what's a good takeaway? Let's like what's the takeaway that you had from the conversation with Adam? >> So it's interesting because I take it he's in a product based like a physical product based uh industry with a lot of the discussions he was talking about with the trust in principles and things of that nature. It it was just very interesting how a lot of it follows like the agile principles with software development if we actually follow agile correctly and we do our sprints right where you can have those discussions to reinstill the trust. Uh a lot of what I was hearing really reflected you know defining the definition of done what is done which is uh you know kind of his whole guidelines those principles he was talking about. Um, I just thought it was a wellrounded uh discussion with them. He had a lot of uh knowledge and information that was really great for him to share with us. Yeah, I think that um it's a little scary and I had this the first time I talked to him as well is when you have the um I don't know what it's called, but it's basically the you know, we'll call it the, you know, the nodding head syndrome or the yes man syndrome or something like that where everybody's just sort of like, "Yeah, it's going well and all's going good." Um, I've had that in more than a few places where, you know, you get into and even with daily standups where people just get into like this rhythm of, "Yep, this is what I'm doing. Yeah, it's fine. Everything's good. Every, you know, it's sunshine and roses. Let's just keep marching on as opposed to, you know, having and a lot of times it is like if it's an agile, it's the scrum masters probably should be doing that stuff like that." It's just somebody sort of that's rocking the boat a little bit to say, "Hey, is it really?" You know, it's just like when you pass somebody on the street a lot of times like, "Hey, how you doing?" They're like, "It's great. It's fine." Sometimes it's useful to come back and say, "Really? Is it really fine or are you just saying that?" And I think we that is something that even although I agree, I think agile helps us break it up. We have a lot of if you do it right, at least at each sprint, you have the retrospective and the review and you have like a really good point, you know, stopping and uh true up point kind of thing, you know, a gut check of, okay, well, let's talk about this. Where are we going? How are we doing? So, you don't get too far into it. But I do think that that is something again that you have to be aware of is that like you have to make sure that when you get into those retrospectives that people are being you know a part of that that they are acting that they are bringing in you know positives and negatives and stuff like that. You don't want to have them turn into just like a big kumbaya thing and everything's awesome and we all love everything. you. It's, you know, it's almost in a lot of places that's just like you have to come up with two things we can do better or two things that you don't like or two things that we need to stop doing or something like that. Just you give people an assignment so they have to figure something out. If they really struggle because you're so perfect in your software development group or whatever, then great. But usually something's going to come up. And usually when you get a team, there's going to be more than one person that's going to hit on those, which is going to help you get to, you know, the truth of it all. And it's, you know, it really is worth, I think, as a final recommendation, I would just say it's worth it to everybody to go spend a little bit of time understanding how we screw with ourselves mentally. Um, the uh loser think by Scott Adams I have recommended many times. I continue to do so because it is it is not a light read. I mean, yes, he did Dilbert and he's got some Dilbert cartoons in there, but it is um it will make you think. Uh and it's I think that's the purpose and it will make you it will point out some of the things that uh you need to be worried about when you are thinking and how we confuse and and fool ourselves. And if you just look at like um I would even say just do like a Google search or ask you know your favorite AI chatbot about um ways that we fool ourselves mental issues that we don't realize we have uh things like you know um uh some of the bias and stuff confirmation bias and things like that. Uh, but there's a lot of others and even things just like looking into things like the the Mandela principle or or syndrome or whatever it's called, but the Mandela effect, I'm sorry. And some of these things where it's like it is it's like we brainwash ourselves on a regular basis. And I think the trust is one of those things is that we need to make sure that we're we are regularly checking in on these things so that we haven't convinced ourselves that we're doing something right when we actually aren't. And I've seen teams drift from that many times. We're like, "Oh yeah, this is our guiding principle." And you look at like, "No, that's not your guiding principle. That was never a guiding principle. I don't know where that got introduced." And it does go back to like write it down, review it regularly, get yourself like centered back, get your your your cornerstone so you can build your wall out from there. That being said, this has been uh this has been fun. Uh also a little bit exhausting because there's just a lot going on this time around. Uh but we will be back. We will rest. We will sleep. Probably not a lot, but we will get some sleep in between now and the next time we do this. So, we are fresh and ready to take on whatever the next topic is. Thank you so much for your time, for hanging out with us, and we will talk to you guys next time around. [Music]
Transcript Segments
[Music]
Well, hello and welcome back. We are
able to breathe again. We've been
holding our breath since the last
episode. We're going to get into part
two of our interview with Adam Malone as
we continue our season on building
better foundations. But first, I am Rob
Broadhead, one of the founders of
Developer, also the founder of RB
Consulting, where we help you do
technology better. We sit down with you.
We help you assess where you are at,
where your business is at, not only
today, but also like what are your
plans? What are your visions? What are
your goals? And then we help you create
a roadmap to utilize technology better
than you're doing it today, but also to
position you for tomorrow so that you
have a road map for success that either
you can execute or you can team with us
uh will help you out as needed to
execute along the way, even completely
executing it for you if needed. Check us
out at rb-sns.com.
Uh you can also do a really quick and
quick and free assessment kind of thing
to get some advice at matrix mat r
ix.rb-sns.com
and check us out there. Uh good thing,
bad thing.
Uh good thing is uh so we're continuing
this uh uh working on a house that was
its own little good thing, bad thing.
And in doing so, uh it's like it's the
fun things that you have. So, we're
redoing some floors and a good thing is
one of them was like and it's lenolium
and it was laid out not terribly well
and it was pretty beat up but ripping it
up was super simple. It was like
basically you just like you know a
little hammer, a little nail, some stuff
like that, a little screwdriver to pry
some stuff up and then just lift and you
know a couple of minutes later and a few
you know not even very bad cuss words
and it's like everything's up and we're
ready to go. Uh the bad news is that we
did have one of the three rooms that was
we're not so lucky that the glue was
done differently and stuff like that. So
um I'm gonna have a lot of gun time with
a heat gun for a little bit as I'm
slowly like peeling my way through floor
for the next uh next little bit here. So
not the funnest thing. Hopefully more
not it will be much more fun to listen
to Michael and his introduction than
playing around with a heat gun. But you
never know. I guess it depends on how
much of a gadget person you are. Go a
introduce yourself.
>> Hey everyone, my name is Michael Malash.
I'm one of the founders of Building
Better Developers, also known as
Developer. I'm also the owner of
Envision QA, where we build custom
software that helps businesses owners
take back control of their operations
with a strong focus on service
reliability and long-term success. From
streaming to workflows to replacing
outdated systems, we create tools
tailored to your business. And we don't
stop there. We uh back everything
through testing and quality checks to
make sure it works right the first time.
Check us out at Envision QA where we
combine great software with great
support so you can run your business
with confidence. Uh good thing, bad
thing. Uh I guess uh good thing I've had
a little bit of kind of downtime. I've
been running some testing on software
and that which takes time and ties up my
computer. So, I've decided to clean my
office and well, I I've made lots of
progress in here. Uh the good thing is
I've eliminated probably two uh mini
bookshelves or a full bookshelf if you
got a big tall bookcase. Uh bad thing,
my office is completely trashed at the
moment. So, I'm I'm got to clean that up
next. But, uh hey, making progress.
And here we go. We're going to dive
right back into part two of our
conversation with Adam Malone. We're
talking about trust and building it and
how it impacts projects, teams, and all
that kind of goodness. So, here we go.
Picking up almost exactly right where we
left off.
>> So,
you know, we've been talking about
principles and you talked about just
now, you know, having the VP and the PMs
and that and breaking it out. As you go
through the process of working with the
all the players and you define these
principles, how often do you feel that
you need to go back and revisit the
principles to make sure that they're not
stale, that you're on track, and that
everyone continues to have the same
buyin for the project.
>> Um,
I would make them a touch point at
nearly every, you know, depending how
you run your projects. um you know not
daily but the the meetings where you're
reading out on status and that you're
especially kind of hashing through an
issue that you're having um they need to
start with this uh and ideally you've
you've codified these enough that they
are maybe one or two PowerPoint slides
and that you can say hey guys we are
here today uh because we have some
contention about how we handle this
business requirement.
Well, part of the reason that we are in
contention is
we don't all agree how that ties into
the principles we set out at the
beginning. As a reminder, here are the
principles that we agreed to for making
these decisions. Now, here's the
business requirement that we're trying
to work through and the solution. Bob,
you you cited that you were concerned
that we might not deliver against the
principles because of that. Can you
explain that? Yeah. Okay. And then you
actually ask people, hey, does everyone
agree with Bob? like can we all agree
that that the risk that he's cited would
violate the principles we've agreed to
because sometimes this is helping some a
member of the team see like hey you're
concerned about a risk that we've solved
for elsewhere right um and then also
saying does anyone else feel this way is
anyone else concerned about this as well
and having that conversation but um I
mean to put a timeline on it I would say
these should be in front of the team
almost every two weeks or so. Um, even
if it's just a, hey, this is our
bi-weekly readout. As we mentioned, here
are the five ways we're making the
decisions around here on this. Does
anyone have any concerns about those as
we kind of have learned more over the
last two weeks?
And 90% of the time, it's going to be
really annoying because no one has
anything to say. And you're going to be
like, why did we even spend five minutes
on this?
But it's that one time that someone
says,
"Hey,
when I was doing XYZ thing on that
business requirement, that's not how I
built it or that's not how the
development team is working on that or
that's not how the operations team is
going to deploy that because that's what
you have happen, right? Is the tech team
goes and does stuff and then the
operations team goes and does stuff of
like how they're going to operationally
handle the outcome of what the system
tells them frequently. and we don't like
go revisit those enough. And so that's
that's part of why I'm saying it's
helpful to look at them regularly and
also helpful to have the different views
from the team in there to say, "Oh, this
doesn't actually meet what I just built
with my team." Um, and get and make it
acceptable for people to say that.
They're not going to get in trouble when
they say that.
>> Now, with these principles, I I know
you're talking, you know, within your
team, within the products. Um,
have you defined or have you ever worked
out principles with dealing with the
customer like the end goal within these
principles or within different teams?
Um, just kind of curious how you handle
that or what your thought process is on
putting that together with a team that
may never have worked with something
like that.
>> Yeah. So definitely have and that can
that has involved everything from hey we
have a replacement strategy for how we
want to handle a customer who complains
about their product for example and
again if you say well we just want to
deliver the best customer experience
possible well that's going to mean that
you just give that customer a bunch of
either money directly or you you know
give them a Cadillac when they bought a
Kia. Um, and so helping people to to
really codify,
yes, we want a great customer
experience. What does that look like
when someone says, "Hey, I have a
product return as an example."
Okay, here's how we define as a group
what that should look like. Um, so
there's going to be some process
discussion. How do we treat the
customer?
What documentation do we ask for from
them? Are we going to require them to
return their product to us before we
give them a replacement product? All of
those things need to be discussed and
thought of through the lens of we want a
great customer experience, but we can't
break the bank and we have to be able to
deliver it in a reasonable time frame,
right? Um, and so defining those, here's
what we want that to look like, and then
really
meeting on them and being open to people
saying, "I don't like I don't think
we're delivering what we want or ideally
reviewing, especially if it's an
exception like a return or something
like that." Those likely happen
infrequently enough that you can bring
the team back and do afteraction reviews
and say like, "Hey, Michael called in.
He had a return. Let's walk through how
that return went for Michael." And then
we're going to like at the end everybody
raise your hand if you think we did the
right thing for Michael or if you think
we didn't do the right thing for
Michael, right? And and then you can
start to build group consensus on, you
know, I don't actually think we treated
him the way we all wanted to treat him
based on what we said the principles
are. Okay, then what do we need to go
fix and change? Um, but but too often we
can accidentally act like, well, if it's
a customer thing, the customer
experience team or the customer support
team needs to be involved and like the
rest of us kind of don't need to be
aware of it. Um,
or if it's a supply chain thing, hey, we
don't want anyone to come talk to us.
Like, we'll do a good job, you know,
shipping product out, but kind of stay
out of our business. drop the order to
the ERP and we'll handle it from there.
Well, we need every group to be okay
having those conversations about the
customer and the customer experience
um
in a way that we may tell each other
that the the baby's ugly and
and we all have to own again back to the
commit concept. We all have to own that
it's our baby. It's not Michael's baby
and Rob's baby or Adam's baby or
customer solutions baby or supply
chain's baby. This is what we all agreed
to build. So, we're not indicting anyone
when we say it's not delivering what we
want. We're if anyone's being indicted,
we're all in it together. We're not kind
of pointing fingers and throwing people
under the bus. I'm sorry I rambled a bit
there, Michael, but
>> Oh, that's great. I I kind of have a
follow-up to that. I kind of want to
flip that now. So we've talked talked a
lot about you know your team and
internally. So how do you build that
trust using the same kind of model with
your customer?
>> Okay. So um the trust is built on three
components and actually try not to say
build trust but we'll take that for
another time. Um there's three
components of trust. Uh
these are empathy,
authenticity and performance. And so
when someone chooses to give us their
trust, we have delivered on their need
to feel empathy,
to feel that we are being authentic and
to feel that we will deliver on our
performance or our commitments, right?
And so we are our goal is to the
language I like I want to inspire
Michael to give me his trust.
I don't get to build trust because it's
not permanent and I don't get to decide
when you trust me. I can invest in each
of those components of trust such that
you're inspired enough to give your
trust to me. So first I would try to use
that language of how do we inspire our
customers to trust us? And I would look
at each of those buckets. So empathy is
when someone feels like they are seen
and cared for. Um
uh here's an example of that. Um, have
you ever have you ever called into like
a call center because you had an issue
and um the call center rep just said
like, "Well, I'm sorry. We can't do
that."
And you How does that feel like when
they just kind of flatly tell you like,
"I'm sorry. That's not how it works. We
can't do that for you." Does that feel
good? You feel seen?
>> No. It's frustrating.
>> No, it's so frustrating.
And and so like what you can see is and
this can't be fake. That's going to be
on the authenticity piece. But on the
empathy piece, there are little cues
that can be so helpful in developing and
showing empathy to your customer. Hey,
Michael, I've heard your concern. I want
to make certain I understand it. You
said that this was the part of your
Dyson vacuum cleaner that wasn't
working. Did I get that right? Yeah.
Yeah, you did. You did. You got that
right. Okay. And I also heard you say X
is is did I understand that right as
well? Yes, it is. Okay. Can you help
tell me h how you would want this how
you want us to handle this for you or
what would solve this problem for you?
Well, all of a sudden the customer has
felt seen on what's going wrong. They
felt seen on kind of what their concern
was and now they've been engaged
potentially on well here's here are some
things I would like to do. You're going
to have lots of people that listen to
this to say like, "Well, you should
never ask a customer that." Um, but I'll
tell you, lots of times you'll find that
people actually want far less than you
think they do. They just want a new knob
for their vacuum cleaner or something.
Um, and so sometimes there can be a lot
of power in asking because you'll find
that there's a bunch of people that you
can just solve their problems outright
for them and it's way less than you
thought when you were going to build a
standard response. The second piece is
after that is you can say let me go let
me let me go review that for you right
let me go compare that and even if it's
just 10 seconds or 5 seconds where you
go and you kind of work on that and you
need to be authentic like I said but
that doesn't mean you know you have to
like go run it up to the CEO right but
can you can you display empathy and that
Michael's got a problem and he wants to
feel like someone actually tried to work
on it and didn't just look at a matrix
on a screen and go, "Sorry, I can't help
you with that." Right?
Um, so, so developing empathy is one,
showing authenticity is the second, and
authenticity is, do I think I'm getting
the real you? And so, when you're
engaging with a customer, the times
where they feel like they're not getting
the real you, that could be as simple as
tone of voice. Um, thank you for calling
AT&T.
Um, or you know, I've called Comcast a
couple times. You know, thanks for
reaching Comcast. It's a pleasure to
serve you. It's like,
I don't think so, bud. Like, we we're
starting this out in the wrong place.
But how often do we all have engagements
like that with like external customers
or even customers within our own company
that way of where we're just kind of
like reading from a script uh in our
actions and it doesn't even feel like
we're trying to be real. Well, we need
to show people that we authentically
care about them and their problem and
that they're seeing the real us. Um and
then finally on performance
um that's about do you have the skills
to help me with this problem
and then will you do so reliably?
Performance breaks really carefully or
easily into performance or capability
versus reliability.
Um and so we can improve people's
perceptions of our performance by
focusing on both of those. Hey, um,
again using the Dyson vacuum example.
Hey, miss, you know, Michael, um, we do
have the part that you want in stock. I
have allocated that part. It's it's on
order for you and your name is attached
to that order and you will get a
whatever a confirmation code in your
email in the next 10 minutes telling you
that that that part is on the way.
Right? So, you kind of you establish I
have the thing. I know what to do with
the thing. and here's a way that you can
test my reliability because I've told
you, hey, in 10 minutes or 30 minutes or
an hour, you're going to get an email
confirming your order. And so now you
can expect that email. And when you get
that email, all of a sudden, that's a
confirmation point that I delivered on
my performance. Um, and I think a a lot
of the time that we fail with internal
and external customers is we don't
invest enough time and displaying
um that we're going to be reliable. Um,
but and reliability is actually a huge
part of people's perception of
performance. And so you can actually do
yourself a disservice
if you ignore those things. If your
system has a gate that when it goes
through people get notified, tell them
about that. Your system is going to do
it no matter what. But now when people
see that happen, they're not like, "Oh
my gosh, Rob sends me an email every 10
minutes." No, they're going to say, "Oh,
Rob told me that when my project kind of
got through this stage gate, I would get
an email or I would get a note. I got
that note. Not only did Rob do what he
said, but I feel good about the fact
that my project moved forward or my
shipment has come here or whatever." Um,
and so using concepts like stage gates,
even if they're to reinforce
communication patterns, can really help
develop trust in ways that are very low
cost,
often they only cost us communication,
which is nearly free.
>> Nice. Now,
do you ever combine the two? So you have
like your internal trust, your internal
meetings kind of defining what you're
doing. You have your customer experience
and that do you ever uh how do you
combine the two processes so that you
know that your customer expectations and
your internal expectations are kind of
in line with each other?
>> Yeah. So a lot of my experience has been
in um regulated products like insurance
products and so sometimes like you
literally have compliance departments
that are supposed to help you make sure
you do that. Um,
and both of you smiled real big when I
said that. Um, and I would say part of
the benefit that you can do is if you
can help people see the value of that
compliance department as opposed to, uh,
the compliance people are here again to
harass us. Instead, saying, hey, these
are some of the few people in the
business that see everything end to end.
They can really help us inspect and
understand what's going on. Um that's
one way uh is through compliance. Um
again I've dealt with a lot of physical
products. So um I like to think of what
we often called an outofbox experience.
Um, and that was something like we would
process an order and we would document
all of that, whether it was screenshots
or recordings or or whatever. And then
when that physical product was
delivered, we would document that. And
then that physical product would like be
opened in a conference room with people
around the box saying things like, "Oh,
like what is the experience like when
you were opening that tab? Is that what
we want for our customers? When I open
the box, what is the first thing I see?
Oh, like the first thing I see isn't
very appealing or interesting. Okay.
Well, I need to change that. Right? But
bringing in a broad set of people to see
the outcome of the work and then inspect
like the process that got your customer
there can really help you unite like
front of office customer experience type
people with operational and technology
delivery people to say hey we all
delivered this product to the customer.
It took all of us to get here. What did
that feel like through the entire
journey? How can I show that to you as a
customer journey and get as tangible as
possible with it? Screenshots, videos,
voice recordings, and then if you have
something where there's a tangible
physical product, if it can be opened
like in a room with people huddled
around it, like invest the time to fly
people in and do that. Um, it is highly
valuable and I think it's one of those
places again that we can sometimes
get a little cheap and we'll say like,
well, I don't want to pay the travel
budget or take people off the phones or
get people off their computers to to do
the dev work. So, we'll just have the
leaders do it. We'll just have the VPs
sit around and do this or something.
That's the wrong way to do it. You need
to bring as many people as possible that
are scattered throughout the process to
experience that stuff. Um, and some of
that gets back to that concept of gimba
that I'm talking about. But the the
every single process in your company,
there is a supplier
um and there is a receiver.
And um the more you can bring those
people together to look at processes end
to end um the better off you'll be in
understanding the customer and
understanding internal needs and in
understanding the output.
Well, after uh really appreciate your
time and you know, giving us a lot of
great insights. So, and I'm sure a lot
of the the audiences out there
applauding as well and saying, "Yeah,
great time. It's standing ovation and
stuff like that." What's the best way
for people to get a hold of you if
they're like, "I would really I think my
team needs some help. I think I'd love
Adam's help." What's the best way to get
a hold of you?
>> Oh, I appreciate that question. Uh the
best way is uh just go to LinkedIn and
search Adam Malone. Uh there's a black
and white photo of a bearded pudgy white
guy with a microphone. That's me. Uh
click on that and send me a message. Uh
I love to hear from people. Um and and
whether that's you just want to kind of
toss around, you know, an issue like
this, you want someone to talk about it,
I'd love to, you know, give you 45
minutes and and do that sort of thing.
It's it's the sort of thing I I enjoy
doing. Um so I would love to hear from
your listeners.
>> Excellent. Well, and I'm sure they would
love to like us, you know, a lot of
great conversations around this. It's a
it's and they're the kinds of
conversations too that I think you walk
away from and you sort of think like I
wonder how I can apply this a little bit
better and you know in this situation
I'm running into or that situation or
you know this person that I've been
butting heads with things of that
nature. So this is great value. Uh like
I said, this has been perfect for us
talking about like the foundations kind
of, you know, of how do you really, you
know, set yourself up for success moving
forward. And one of them is, you know,
like we talked about even like at the
beginning getting those things in place
and and being clear and a few less
assumptions and a few more, you know,
maybe even some some tough discussions,
but you know, going through those things
to make sure that we even if we're not
on the same page, that we agree whatever
page we're on and we can we can move
forward from there.
Yeah.
>> Yeah. I think uh your call out there is
really important that um we're we're
going to have the argument one way or
the other. And I think that's often why
people shy away from a lot of the things
we've talked about is they feel like it
is conflict and argumentative and we're
all going to not like each other. But in
my experience, the argument is the
disagreement is going to come to light
at some point. And if it doesn't,
failure is even more certain. But most
of the time, that disagreement is going
to come to light eventually.
And just like, you know, just like fish,
it doesn't get better with age. Like the
earlier you have those discussions and
those debates, um, the better off you'll
be over the long term. Um, or you can
like leave the fish in the back of the
cabinet and, you know, it'll stink when
you get there in two or 3 weeks or two
or 3 months, right? Um, and the the
fight is bigger and harder and worse
than it was before. Um, so yeah, working
through those early and often is almost
always better. Excellent.
I think that's a great place for us to
wrap this one up. Well, thank you so
much for your time and for hanging out
with for us for a while. Uh it's been a
great conversation. Uh a lot of great
ideas going forward from here. So, I'm
going to take some of this and be
chewing on it mentally for a while as
well. Uh you guys have we will have show
uh links in the show notes to reach out
and uh check out check in with Adam and
ask your own questions and maybe have a
little conversation as well. And uh
hopefully we will uh you know we'll bump
into you again sometime soon and uh you
know appreciate your time. Appreciate
you coming out here and hopefully we'll
be able to continue to have some great
trust conversations as we move forward.
>> Thanks guys. It's been a pleasure.
>> All right. Thanks a lot.
>> Thank you.
>> And that will wrap this up. So this was
a great time with Adam. I want to thank
him again so much. We've thanked him
ausively hopefully affusively enough. Uh
it was great. It's been a while since
we've done a an interview. I really
appreciate him stepping in and doing
that. Uh, and it was a great
conversation as I think you guys know if
you guys so often if you guys got half
out of it what I did then I'm sure that
it was more than worth your while. Um,
we will have l as I mentioned we will
have links to to reach out to him if you
have questions or if you want to have
some conversations. Great guy. Uh, I've
had a couple conversations with him in
the past and I think you can get a lot
out of it. And uh if you're, you know,
if your company's struggling with some
stuff, then uh he's definitely that kind
of guy that you want to point the right
people to and have them come in and
maybe straighten a few people out and
get your team back on track, get the
train back on the rails.
That being said, it is that time where I
have to ask you for an email. Send me an
email at [email protected], but more
importantly, give us feedback however it
is you can give us feedback. Whether
that is leaving us a review and and some
comment text on wherever you do
podcasts. You can do it out on YouTube
at the developer channel. You can we
have a contact us form on the
developer.com site. You can leave
comments on any of our blog posts over
the last several years. Uh you can also
leave us something. Send us something at
xdevelopure
uh Facebook page. We're out there as
well. And someday we'll probably add
some additional sites as well. Uh but
for now, all of those places are great
ways and positive or negative, we want
to get your feedback because that is
what helps us grow. We're going to let
you guys uh dive back into whatever it
is you're doing, becoming better,
building that better foundation,
becoming better developers, and we will
return next episode most likely back on
topic. But uh we'll see whether we
decide to throw another curveball and
get another interview in there. We are
going to mix it up a little bit in this
season of Foundations. Uh but there are
a lot of areas for us to cover uh to
help you build that better foundation so
that you're ready to go and you know
you're ready to take advantage of
whatever your career in life throws at
you. As always we appreciate appreciate
you guys so much. Have yourself a great
day, a great week and we will talk to
you next time
and bonus material. Um so we've got like
a little mix and match stuff. we had
some bonus material at the start of last
one basically and then just sort of a
quick wrap-up. Um I guess bonus would be
just like what are your thoughts? How do
you what are like maybe is there what's
a good takeaway? Let's like what's the
takeaway that you had from the
conversation with Adam?
>> So it's interesting because I take it
he's in a product based like a physical
product based uh industry with a lot of
the discussions he was talking about
with the trust in principles and things
of that nature. It it was just very
interesting how a lot of it follows like
the agile principles with software
development if we actually follow agile
correctly and we do our sprints right
where you can have those discussions to
reinstill the trust. Uh a lot of what I
was hearing really reflected you know
defining the definition of done what is
done which is uh you know kind of his
whole guidelines those principles he was
talking about. Um, I just thought it was
a wellrounded
uh discussion with them. He had a lot of
uh knowledge and information that was
really great for him to share with us.
Yeah, I think that um it's a little
scary and I had this the first time I
talked to him as well is when you have
the
um I don't know what it's called, but
it's basically the you know, we'll call
it the, you know, the nodding head
syndrome or the yes man syndrome or
something like that where everybody's
just sort of like, "Yeah, it's going
well and all's going good."
Um, I've had that in more than a few
places where, you know, you get into and
even with daily standups where people
just get into like this rhythm of, "Yep,
this is what I'm doing. Yeah, it's fine.
Everything's good. Every, you know, it's
sunshine and roses. Let's just keep
marching on as opposed to, you know,
having and a lot of times it is like if
it's an agile, it's the scrum masters
probably should be doing that stuff like
that." It's just somebody sort of that's
rocking the boat a little bit to say,
"Hey, is it really?" You know, it's just
like when you pass somebody on the
street a lot of times like, "Hey, how
you doing?" They're like, "It's great.
It's fine."
Sometimes it's useful to come back and
say, "Really? Is it really fine or are
you just saying that?" And I think we
that is something that even although I
agree, I think agile helps us break it
up. We have a lot of if you do it right,
at least at each sprint, you have the
retrospective and the review and you
have like a really good
point, you know, stopping and uh true up
point kind of thing, you know, a gut
check of, okay, well, let's talk about
this. Where are we going? How are we
doing? So, you don't get too far into
it. But I do think that that is
something again that you have to be
aware of is that like you have to make
sure that when you get into those
retrospectives that people are being you
know a part of that that they are acting
that they are bringing in you know
positives and negatives and stuff like
that. You don't want to have them turn
into just like a big kumbaya thing and
everything's awesome and we all love
everything. you. It's, you know, it's
almost in a lot of places that's just
like you have to come up with two things
we can do better or two things that you
don't like or two things that we need to
stop doing or something like that. Just
you give people an assignment so they
have to figure something out. If they
really struggle because you're so
perfect in your software development
group or whatever, then great. But
usually something's going to come up.
And usually when you get a team, there's
going to be more than one person that's
going to hit on those, which is going to
help you get to, you know, the truth of
it all. And it's, you know, it really is
worth, I think, as a final
recommendation, I would just say it's
worth it to everybody to go spend a
little bit of time understanding how we
screw with ourselves mentally. Um, the
uh loser think by Scott Adams I have
recommended many times. I continue to do
so because it is it is not a light read.
I mean, yes, he did Dilbert and he's got
some Dilbert cartoons in there, but it
is um it will make you think. Uh and
it's I think that's the purpose and it
will make you it will point out some of
the things that uh you need to be
worried about when you are thinking and
how we confuse and and fool ourselves.
And if you just look at like um I would
even say just do like a Google search or
ask you know your favorite AI chatbot
about
um ways that we fool ourselves mental
issues that we don't realize we have uh
things like you know um
uh some of the bias and stuff
confirmation bias and things like that.
Uh, but there's a lot of others and even
things just like looking into things
like the the Mandela principle or or
syndrome or whatever it's called, but
the Mandela effect, I'm sorry. And some
of these things where it's like
it is it's like we brainwash ourselves
on a regular basis. And I think the
trust is one of those things is that we
need to make sure that we're we are
regularly checking in on these things so
that we haven't convinced ourselves that
we're doing something right when we
actually aren't. And I've seen teams
drift from that many times. We're like,
"Oh yeah, this is our guiding
principle." And you look at like, "No,
that's not your guiding principle. That
was never a guiding principle. I don't
know where that got introduced." And it
does go back to like write it down,
review it regularly, get yourself like
centered back, get your your your
cornerstone so you can build your wall
out from there.
That being said, this has been uh this
has been fun. Uh also a little bit
exhausting because there's just a lot
going on this time around. Uh but we
will be back. We will rest. We will
sleep. Probably not a lot, but we will
get some sleep in between now and the
next time we do this. So, we are fresh
and ready to take on whatever the next
topic is. Thank you so much for your
time, for hanging out with us, and we
will talk to you guys next time around.
[Music]