Summary
In this episode, Adam Malone shares his insights on building trust and reliability in project management. He emphasizes the importance of clear principles, empathy, authenticity, and performance in building trust with customers.
Detailed Notes
Adam Malone, founder of Envision QA, shares his insights on building trust and reliability in project management. He emphasizes the importance of having clear principles and revisiting them regularly to ensure everyone is on the same page. He also highlights the importance of empathy, authenticity, and performance in building trust with customers. Displaying empathy and asking customers for their input can help solve their problems effectively. Authenticity is crucial in building trust, and tone of voice can make a big difference. Regularly reviewing and discussing customer experiences can help identify areas for improvement.
Highlights
- Having clear principles and revisiting them regularly can help ensure everyone is on the same page.
- Empathy, authenticity, and performance are key components of building trust with customers.
- Displaying empathy and asking customers for their input can help solve their problems effectively.
- Authenticity is crucial in building trust, and tone of voice can make a big difference.
- Regularly reviewing and discussing customer experiences can help identify areas for improvement.
Key Takeaways
- Clear principles are essential in building trust and reliability.
- Empathy, authenticity, and performance are key components of building trust with customers.
- Displaying empathy and asking customers for their input can help solve their problems effectively.
- Authenticity is crucial in building trust, and tone of voice can make a big difference.
- Regularly reviewing and discussing customer experiences can help identify areas for improvement.
Practical Lessons
- Establish clear principles and revisit them regularly.
- Display empathy and ask customers for their input.
- Prioritize authenticity in all interactions.
- Regularly review and discuss customer experiences.
Strong Lines
- The argument is the disagreement is going to come to light at some point.
- Early and often, working through those early and often is almost always better.
- Empathy, authenticity, and performance are key components of building trust with customers.
Blog Post Angles
- The importance of clear principles in building trust and reliability.
- The role of empathy, authenticity, and performance in building trust with customers.
- The benefits of regularly reviewing and discussing customer experiences.
- The importance of authenticity in building trust and reliability.
- The role of tone of voice in building trust and reliability.
Keywords
- trust
- reliability
- project management
- clear principles
- empathy
- authenticity
- performance
Transcript Text
Welcome to Building Better Developers, the developer podcast where we work on getting better step by step professionally and personally. Let's get started. 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 Brodhead, one of the founders of development, or 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 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 roadmap for success that either you can execute or you can team with us. We'll 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. You can also do a really quick and quick and free assessment kind of thing to get some advice at matrix, matrix.rb-sns.com and check us out there. Good thing, bad thing. Good thing is, so we're continuing this working on a house that was its own little good thing, bad thing. And in doing so, 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 linoleum 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 customers. And it's like everything's up and we're ready to go. 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 I'm going to have a lot of time with a heat gun for a little bit as I'm slowly like peeling my way through four for the next 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 introduce yourself. Hey, everyone, my name is Michael Molloch. 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, replacing updated systems, we create tools tailored to your business. And we don't stop there. We 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. Good thing, bad thing. I guess a good thing. I've had a little bit of kind of downtime. I've been running some testing on software in that, which takes time and ties up my computer. So I've decided to clean my office. And well, I've made lots of progress in here. The good thing is I've eliminated probably too many bookshelves or a full bookshelf if you got a big, tall bookcase. Bad thing. My office is completely trashed at the moment. So I'm going to clean that up next. But 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 to principals and you talked about just now, you know, having the VP and the PMs and then breaking it out as you go through the process of working with 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 buy-in for the project? I would make them a touch point at nearly every, you know, depending on how you run your projects, you know, not daily, but the meetings where you're reading out on status and that you're especially kind of hashing through an issue that you're having. They need to start with this. And ideally, 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 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. OK. And then you actually ask people, hey, does everyone agree with Bob? Like, we all agree that that the risk that he 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. And then also saying, does anyone else feel this way? Is anyone else concerned about this as well? And having that conversation. But 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, even if it's just a hey, this is our biweekly readout. As we mentioned here, 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? In 90 percent 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 X, Y, Z 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 happened. 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 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 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 know you're talking within your team, within the products. 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? 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 give them a Cadillac when they bought a Kia. 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. OK, here's how we define as a group what that should look like. 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. And so defining those. Here's what we want that to look like. And then really. Meeting on them. 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 after action 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 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. OK, then what do we need to go fix and change? 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 in like the rest of us kind of don't need to be aware of it. Or if it's a supply chain thing, we don't want anyone to come and talk to us like we'll do a good job shipping product out, but kind of stay out of our business, drop the order to the ERP and we'll handle it from there. We need every group to be OK having those conversations about the customer and the customer experience in a way that we may tell each other that 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 that's great. I kind of have a follow up to that. I kind of want to flip that now. So we've talked a lot about your team and internally. So how do you build that trust using the same kind of model with your customer? OK, so the trust is built on three components and actually try not to say that and say build trust, but we'll take that for another time. There's three components of trust. 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. Here's an example of that. Have you ever if you're called into like a call center because you had an issue and 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, no, it's so frustrating. 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, you did. You did. You got that right. OK. And I also heard you say X is that I understand that right as well. Yes, it is. OK. Can you help tell me 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's some things I would like to do. You're going to have lots of people that listen to this to say, like, we should never ask a customer that. 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. 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 five 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 out to the CEO. Right. But can you can you display empathy in 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. 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. Thank you for calling AT&T. For, you know, I've called Comcast a couple of times, you know, thanks for reaching Comcast. It's a pleasure to serve you. It's like, I don't think so, but like we were 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 in our actions and it doesn't even feel like we're trying to be real. We need to show people that we authentically care about them and their problem and that they're seeing the real us. And then finally on performance, 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. And so we can improve people's perceptions of our performance by focusing on both of those. Hey, I'm not going to be able to do that. Hey, again, using the Dyson vacuum example. Hey, you know, Michael, 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 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. And I think a lot of the time that we fail with internal and external customers is we don't invest enough time in displaying that we're going to be reliable. But 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. 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 your internal trust, your internal meetings, kind of defining what you're doing. You have your customer experience in that. Do you ever, 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? Yes, a lot of my experience has been in 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. And both of you smiled real big when I said that. 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 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. That's one way is through compliance. Again, I've dealt with a lot of physical products, so I like to think of what we often called an out of box experience. And that was something like we would process an order and we would document all of that, whether it was screenshots or recordings 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 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 then understanding the output. Well, after a really appreciate your time and, um, you know, giving us a lot of great insights. So, and I'm sure a lot of the audiences out there applauding as well and saying, yeah, great times, standing ovation and stuff like that. What's the best way for people to get ahold of you? If they're like, I would really, I think my team needs some help. I think I'd love Adam's help. That's the best way to get ahold of you. Oh, I appreciate that question. The best way is 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. 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 somebody 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 love. 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 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'm in butting heads with things of that nature. So this is great value. Like I said, this has been perfect for us talking about like the foundations kind of says, you know, of how do you really 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 your call out there is really important that 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, the better off you'll be over the longterm. 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 three weeks or two or three months. Right. And the fight is bigger and harder and worse than it was before. 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, I thank you so much for your time and for hanging out with us for a while. It's been a great conversation. 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. You guys have, we will have show links to the show notes to reach out and check out, check in with Adam and ask your own questions and maybe have a little conversation as well. And hopefully we will bump into you again sometime soon and 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 effusively, hopefully effusively enough. It was great. It's been a while since we've done a, an interview. I really appreciate him stepping in and doing that. 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. We will have links. 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. I've had a couple of conversations with him in the past and I think you can get a lot out of it. And if you're, you know, if your company's struggling with some stuff, then 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 and info at developernerd.com, but more importantly, give us feedback. However it is you can give us feedback, whether that is leaving us a review and in some comment text on wherever you do podcasts. You can do it out on YouTube at the development or channel. You can, we have a contact us form on the developer nor.com site. You can leave comments on any of our blog posts over the last several years. You can also leave us something, send us something at X at developer nor Facebook page. We're out there as well. And someday we'll probably add some additional sites as well. 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 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 we'll see whether we decide to throw another curve ball and get another interview in there. We are going to mix it up a little bit in this season of foundations, but there are a lot of areas for us to cover to help you build that better foundation so that you're ready to go and you're ready to take advantage of whatever your career in life throws at you. As always, we appreciate you guys so much. Have yourself a great day, a great week, and we will talk to you. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success.