The Power of Trust: Interview with Adam Malone (Part 1)

Welcome to Building Better Developers, the Develop-a-Nord Podcast, where we work on getting better step by step, professionally and personally. Let's get started. Well, hello and welcome back. We are continuing our season as we are building better foundations this time around. We're building better developers, the Develop-a-Nord Podcast. I am Rob Brodhead, one of the founders of Develop-a-Nord. We're also the founder of RB Consulting, where we are essentially one of those boutique consulting firms. We sit down with you. We talk about your business. We help you find out how to leverage technology, build a roadmap and execute on that roadmap, whether it's you executing on it or us sitting down beside you and guiding you through such things. We're going to cut it a little short today. We actually have a special guest. So instead of going through some of our normal stuff, I will pass it right on over to Michael so he can introduce himself. Hey everyone, my name is Michael Mollosch. I'm one of the co-founders of Building Better Developers, also known as Develop-a-Nord. I'm also the owner and founder of Envision QA, where we help businesses take back control with custom software that's built around your needs, not the other way around. Our focus is simple, great service, great solutions, rock solid quality. We build tools that replace frustrating systems, screen line operations and fully test to work the right the first time. Check us out at EnvisionQA.com. And our special guest today. Yes, we are finally, we have talked about this for a while. We're finally back to getting some interviews in and we're going to be speaking with Adam Malone and rather than steal his thunder, I am going to let him bring the thunder himself. Please introduce yourself, Adam. I don't know if I'll bring any thunder, but I'll do my best. My name is Adam Malone. I founded a leadership consultancy called The Tenacious Operator in 2024. We're focused on bringing trust into every relationship and using trust as the catalyst and the driver for delivering sustained high performance for the teams that we get to work with. So I'm excited to talk with you guys today. I've worked with a lot of great developers over my time and they're some of my favorite people. So love that we can be together and I'm excited to get to know your audience better. Excellent. Well, I think we'll dive right in it because we are working through the foundations and one of the foundations that anybody that we need, actually this is going to be in any career, but definitely as developers and entrepreneurs, is we get into some of those like soft skills and things like that. And one of those, which is why Adam's here, is trust, is building trust because it really does impact so much of what we do. The conversations, assumptions, things like that, that are, and even when you look at all of the mental things we can do that are all the ways we can fool ourselves and things like that, a lot of it comes down to our attitude and if we trust our coworkers, if we trust our team, if we trust our boss, that makes a very, very different relationship than if you don't. I think I'll throw it right away into maybe a... We can start on some of a negative, maybe if you've got it, do you have a negative story of where you've seen trust cause an issue like that, where maybe it causes either some miscommunication or some things that just missed deadlines, blossom morale, things of that nature? Yeah, so I would love to talk about that. I mean, the easiest example, generically, we've probably all been in this situation, I'll share, had an ERP implementation at a company I was at for many years and in the midst of that transition, every single light was green, every single scorecard was awesome, every metric, everything that could have been good was good and everything felt like it was on time. And I'm saying this from the seat of, I was probably a VP at this point. I'm not quite certain, but senior director of VP, so executive E, we'll say. And so from my perspective, everything looked and sounded great on track, on time, all that sort of stuff. And then it felt like overnight that project went from, oh yeah, we're going to hit all of our deliveries, we're going to deliver, we're less than 30 days away to almost overnight. It felt like every single thing turned red and it wasn't going to deliver. And it was my team who was kind of, I was the executive sponsor. And so I had to go inspect that a ton and try to figure out why. And what it came down to was a couple things all related to trust. So one was the team didn't feel comfortable speaking up, that they felt like they would get in trouble if they came across as a negative Nelly. Oh, hey, I'm worried that this isn't going to deliver on time. Well, somehow, some way they got the idea that they were going to get in trouble for that point of view. And so they kind of pushed it down and equivocated. Similarly, the opportunity was going to deliver three different efficiency improvements on the operations floor. And we'll come to find out two of those actually weren't opportunities anymore. They had solved them through physical process changes and didn't actually need the technology process change, which is technically a great outcome. But that had been solved like a month before, come to find out. And then the third issue was that the business requirements weren't complete complete. They were just one complete. You know, they just didn't get all the way there. But again, because the operations team and the technology team were not in sync and the bonds of trust between those groups weren't solid, the operations team, frankly, did a bad job feeling the pain of the developers as they were going to have to write the code. And they didn't understand how poor, frankly, the business requirements were. And so, you know, they just from the ops team's perspective, they did this work every day. They just kind of told people how it should work. And they expected that to be enough. And they didn't go and kind of approach that tech team with enough empathy to understand what they really needed to deliver on the ERP upgrade. We got through it. We got solved eventually. But to me, all of those items point to like various breakdowns in trust that I think probably all of us have dealt with every day of the project that's going to change the world and is all green. And then it feels like it goes to, you know, stop lights almost overnight and no one can figure out why. And to me, that is a classic sign of a trust failure. Well, when you do something like that, because since it is like, oh, like you said, almost an overnight change, is it because, and this maybe I don't know how much this is definitive and how much is this is sort of like your gut instinct on this. It is like, is it something that like triggers a trust event where somebody is like, you know what, suddenly I was feeling good about it. And so I realized I really don't trust this person. Or is it something where it's like final straw in a bag that breaks a camel back kind of thing, where it's like, there's just you only go so far. And then the the fakeness or whatever, or the or the like fake it till you make it kind of thing sort of falls apart and the facade falls away. Or do you think maybe it's a combination of such things? I think some of it is the facade falling away. Like there's only some of those things have to come to light eventually that they're not tied off. But my belief is that most of those things become clear once enough people realize that what is supposed to be isn't going to happen, whether that's the value that's supposed to show up, isn't going to show up. And that's a finance partner potentially figuring that out. Or whether it's an operations partner saying, hey, this is supposed to deliver on this challenge. Every time we talk about this testing, it's not delivering on that or so on and so forth. That that kind of critical mass builds where all of a sudden people realize, I'm not the only one who thinks this isn't going to go well. And I think that's actually I think that's actually one of the learnings that folks can take away is the more you can bring the team together to talk about success criteria and performance and those things, the more you can have people realize either they are or they are not the only person who feels a certain way about a systems upgrade or a change. And developing enough psychological safety is the term that lots of people would use to make it possible for those conversations to come to light is one of a leader's probably greatest challenges is how do we drive for performance and drive for delivery while allowing failure to be I want to say, OK, like, oh, it's fine. But allowing people to say, hey, we're worried about failure so that we can go fix it if we don't if we don't if we push so hard and require success so much that people feel like they can't raise their hand. Those are the sorts of things that lead to to those events in my opinion. Are there because you're like this kind of situation that you had is where it seems or things are just sort of like going along. Are there maybe some warning signs or some some things that you can keep an eye out for it just to make sure that you're you're getting, I guess, the the real story, essentially, or the full story. Yeah. So I have an operations background, so I'm a big believer in continuous improvement, especially in lean. I don't know how much you guys, your audience are familiar with a concept called Gimba. It comes from Toyota Production Systems. It's Gimba is the Japanese term that means to go to the place where value is added if the exact translation is actually to go to the actual place. But what they're talking about is the actual place where value is added. And what that speaks to is any time you have a group of people who are working on a process, a key aspect of improving that process or changing that process should be getting as close to as possible to where the actual value and change, transformational change occurs. And sometimes people mistake this and think like, oh, yeah, on a factory floor, you can do that. And, you know, there's a physical, tangible thing you can go look at. That is absolutely true. And those sorts of exercises are super helpful. But what I found in these sorts of engagements is helping people to see that on in nearly every space, you can go to Gimba and you can see how work is done. An example would be I had a team at one point that they owned a process that determined how we worked with certain buyers, which which buyers do we use versus others. And it was all kinds of things like credit terms and lead times and minimum order quantities, all these kind of like big calculations to say, is this a good financial decision or not? But we wanted to automate that and systematize it where it wasn't just a bunch of stretch spreadsheet jockeys doing it. And so literally every single person that we had in that project, we put them in a room and had the analysts who usually navigated the spreadsheets show them page by page, formula by formula. Hey, here's how this happens. And then this is what it means. This is what would happen if we did this wrong or this is where the breakdown is. And that hour long meeting that included data partners and developers and operations people helped everyone see the full picture of how this is valuable. And because of that, you get a lot richer conversations where people say, well, hey, Rob, you showed us this thing in the spreadsheet or in your process. I'm really worried that what I'm developing isn't going to deliver that because here's where the data comes from that I'm using. It doesn't have that. Where's your data coming from? Oh, well, we have it. We have a source problem. Great. We can go fix that now. Right. So, I think these conversations, I think, can really get lost or we can assume that simply documenting them is enough as opposed to having 10 or 15 people all sit and like watch this relatively boring process. But that watching and that team engagement around the work is really helpful in identifying those sorts of shortcomings or opportunities in what we're doing together. Do you have a question, Michael? Yeah. So, you kind of started out, you know, with where the trust kind of broke down. I'm curious. In retrospective, when you look back on this, I know you mentioned things like maybe the requirements were wrong or things like that. Was it a process issue that led to the mistrust or just a total breakdown of not having the, I guess, the right tools and communication processes in place for that, the buildup of the trust from the beginning of the project? Yeah. That's a great question. I would say a couple of things. One, there's like a, there was some aspect of like what I would call a false trust, meaning people say like, oh, well, Rob's got it. He knows his face. Surely he's asked this question. I don't need to go ask that question. Right. That's not my area. I don't want to step on his toes. I'm just going to trust that Rob has it. And that's an example to me of a foe outcome of trust. Like there are maybe some spaces where that can be acceptable, but we need to create environments where people are comfortable saying, hey, Rob, when we talked about this, I know this is your area, but I'm not certain I understood if this is going to solve the problem you have. This is going to achieve what you want. And so creating an environment where we encourage people to challenge one another, but also just challenge the problem and challenge the solution I think is really helpful. And we weren't doing that. That's one of the things we all just kind of had set back and assumed. All right. Business unit one or team one, they own their requirements. Team three owns their requirements. Team four owns their requirements. And I don't need to like get my hands messy and make certain that they're doing their work because that would be offensive if I insinuate that they don't know their job. Well the outcome of that is everyone only focuses on their own stuff and you actually lose the value that teams bring because teams have lots of perspectives and experiences and you risk watering them down. So that's one item. The second was, and this is I blame the executive leadership for, we had, we weren't having a good year and we really wanted to hit plan and we put a lot of pressure on folks to deliver value through these types of projects. And I don't know if you want to call it hubris or what, we probably chose to not hear when were saying that these things weren't quite going to do what we wanted. And we chose to always read those things better than they were. We chose to always kind of translate them just differently enough that we felt okay with the green statuses and I felt okay telling my SVP, we felt okay telling his COO, you know, this is all going to deliver. And as leaders we always have to inspect whether or not our drive for performance is hollowing out our ability to perceive and understand the team's actual challenges and what's actually going on. And that would be a second one I would cite as a persistent issue that was really on the executive team and all executive teams do that at some point in my experience. So I also have a follow up to that one too. So you mentioned being a negative Nancy. How would you look back on this and how would you communicate the issues that, how would you encourage the developers to bring up issues that they have in a different way? So instead of it being kind of like confirmation bias, yes we're on track to see that, hey, if there's a problem, this is how we can address it without them feeling pressure or concerned about bringing up issues. Yeah. So a couple tricks that I try to use when I talk to people is create opportunities for negative feedback. And so often people are nervous about saying negative things as you mentioned Michael. And especially certain types of people can get discouraged there. And I especially find that to be true in technical areas, whether it's software engineers or electrical engineers, which I dealt with both in my time, because they are often identifying systemic technical issues. They can feel ignored because the business guy like me is like, oh, you'll figure it out. You're smart. We'll get it done. And so the thing I would say is creating opportunities for those folks to share negative feedback on purpose. And that's as simple as asking questions like, hey, how could this go wrong? Hey, great. I'm glad we're all doing this together. Let's do a, some call it like a reverse postmortem where you act like you're after the fact and say, hey, what are the three things we might meet on in three months to say this is why the project failed? When you do that sort of exercise, you're giving people permission to say that negative thing. Does that make sense? Have you ever kind of experienced one of those? Yeah. In fact, I've kind of experienced it two ways. One where it was very, very productive. Like we had very good back and forth feedback. But I've had others where it kind of became, for lack of a better term, like a bitchfest where it's all the time, just basically bashing the project. Like nothing positive came out of that meeting other than people just bending their problems. So how would you in your experience, how would you handle a situation like that? Trying to go into a meeting with that. But you have kind of one outcome that's positive, but one outcome that is the opposite the other spectrum or it's very negative. Yeah. So one of the things I like to do is talk to people about the idea of disagree and commit. So I have a belief that disagreement is exceptionally valuable. That when people are willing to be in conflict, they are showing that they believe something valuable is at risk. Companies like we hire consultants, we do all kinds of things to have people come tell us like where there are valuable things that we should work on. All the while, it's not uncommon for when our team members are in conflict over something, we kind of like push it down and almost ignore it. But we'll go pay a consultant to tell us those things. Not that I'm down on consultants, guys. I'm a consultant. You're a consultant. You know, whatever. But but instead, if we can identify that conflict and use it as a way to ask the question, hey, Michael, what do you find valuable here? What are you concerned about that we're going to put at risk if this goes wrong? Hey, Rob, like you seem really concerned as well, but you are concerned about the same thing. And you and Michael are kind of at loggerheads. Can you explain what you think is valuable and at risk? Well, when when both people do that and we embrace both of those, that is the disagree phase. Right. And we need everyone to talk about what the potential is. But the the culture that we need to build is that we disagree. We then all work through what the right path is. And then we commit together to what we're going to do. And the commit phase is part of like, hey, no one gets to come back in a month or six months and say, I told you so. We disagree as a team. We work through the right answer as a team. And then we all committed to that answer as a team. And at that point, we're all together. And and the disagree and commit process not only is about no one gets to say, I told you so, but also as leaders, we need to hold our people accountable to say, Adam, you were in the room, you committed to this solution, but now you're kind of doing it halfway. That's not what we agreed to. I know you think something else is a concern, but that's that doesn't mean you get to do this halfway and we need to hold each other accountable and our teams accountable for all the phases of that process. And often where kind of what you laid out fails is we spend a lot of energy disagreeing. We write down all the disagreements and then someone puts them in a SharePoint folder and we don't actually do anything with them. It's just a bunch of had a Scottish leader one time that called it whinging and moaning. But it doesn't end up being productive and you're not productive. You can't start being productive, I should say, until you get to the commit phase. Now, you even these days, even if like you're in the U.S., you have so many different cultures that are a part of almost every organization and not only nationalities and stuff like that, but also even corporate cultures that people have dealt with. And so how often do you I guess one is that is that something that you end up having to address on a regular enough basis of like how do you and in so doing, like how do you bring that together? How do you find a way to like get that agreement line essentially of like here's what we're going to do regardless of what your backgrounds are. This is this is the culture that we have here or this is the approach that we're going to take. Yeah. So I call them guiding principles. Some people call them something else. EOS has a term for them that's different than guiding principles. I don't remember what it is. But but think of it as to me, the most one of the most important aspects of these processes is that we all sit down and we look at like what's the current situation, what's going on. We do a SWOT analysis like old school strengths, weaknesses, opportunities, threats, right? I mean, old school. And then the third step is everyone agreeing on the guiding principles before we go forward with anything else. And and often I think companies skip over the guiding principle phase or teams do. And that means when they're trying to make decisions, they start arguing about the decisions because they don't all agree on the principles by which we're going to govern what we do. And so it's almost like a higher level. Like if you think about a development effort, a lot of this should be before we get into even business requirements. This is some of its defining success criteria, but some of it's just defining the ways we're going to work. And so let me give you an example. Right. You know, lots of organizations will say, you know, customer, the customer experience is number one. I've been in an organization like that. I think we all believe that customer experience is important. But someone on the team is going to say customer experience is the number one thing that we need to use to make decisions. By the way, to me, that is an example of a really unhelpful statement because it doesn't actually help us make decisions unless you really mean that. Which means really meaning that means that every step of this process, there are things that can drive cost, can drive difficulty, can drive all kinds of tangible or intangible costs that would improve the customer experience. Are you actually saying that every single one of them we should pursue and do? And the truth is, no one is saying that to the full extent. Right. And so how do we define that more? Right. So that's the first step. And then we can add more. Right. So that would be an example of someone that's using metrics. Hey, our NPS is 4.2. This initiative cannot drop that below a four or it can't drop it all. Or right now, our handle time for these phone calls is 360 seconds. This process will add time, but it can't add more than 10 seconds to that. All right, defining the cost. Hey, this is gonna increase our costs or it's gonna decrease our costs. To pursue this, X, Y, Z has to happen with cost. And so you write all those down and then you get all the leaders together and you actually do that disagree and commit process that I just talked about. Do we, how do we feel about these? Is this how we wanna go? Is this how we want the outcomes of this project to look? And then you all agree and commit to the principles. And then after that, when the decisions come up to work through, it's a whole lot easier to say, okay, we're gonna do this process that's gonna increase handle time. Okay, how much is it gonna increase handle time? Well, it's gonna increase it by 30 seconds. I'm sorry, we said we could only add 10 seconds to it. So do we need to go revisit the guiding principles and change them or are we gonna say no to this? And often people try to have both of those debates at the same time. And that's often the biggest issue that I see. So that helps on like, how are we going to make the decision? You asked about culture though, and I'm not certain that completely address culture. Did I or I can address that separately. Yeah, that's a good question because it sort of does, I guess it addresses it by running around it. I feel like it's an end run by saying, I don't think that's a wrong answer either. So it's basically saying, let's get ahead of it. And I do think that seems to be, for me, that's been the best in experience in a lot of different areas like that is to start out by saying, let's set the rules. Let's set the standards. Let's set our some agreed terms of this is how we're gonna proceed because now you have the rules for engagement basically. You have the rules for when we disagree. You have the rules for when we need to make the decision. Sometimes it's, if you've got a situation we've got like one decision maker, you got a CEO or you've got one customer or one product owner and they just, okay, they get to make the decisions. But if you have to do it outside of that one, which almost always happens, there's a level of the team has to have some guiding principles to not have to wear out that decision maker with what about this? And what about this? And what about this? Yeah, maybe. And it's, do you find that there's, and I guess as you do that, do you find that that is it harder? I guess it's gonna sound like a lame question, but is it sort of hard? Is it easy to get people to buy into it from the start? Is it something that usually you find that as you're starting in a project, it's a little easier to get them to buy into it? No, no. That's like, I'll ask you the exact same question in the, for a technologist. Do people really embrace the business requirements phase and give it enough due diligence? No. It's time. They do it all the time. But it's just what I'm getting at is like, is it easier? I guess I feel, I know from experience, it's easier to tackle those things when you're not in the middle of a fire, when things aren't going wrong. Yes. Like when things are, when everybody starts out and it's all sunshine and roses, and this is gonna be an awesome project and it's all gonna work. But I guess it's just, they don't, is it really just, they don't give it the respect? Or they just sort of like, it's a rubber stamp, like, oh sure, we'll do that. And then they don't follow it. So it's often more like people want to move through it really fast because it can be a little bit meticulous and slow you down. And so you'll have someone saying like, listen guys, like we all agree, I love it whenever people say that sort of thing. We all agree on what we want to have happen here. All the while you've got like four business units and three different levels of employees involved. And I can tell you that an entry level analyst does not have all the same incentives and drives that a VP has. That's not wrong. And that's not saying that any perspective is more important. But when we kind of short circuit those conversations with, you know, kind of like motherhood statements of, well, we all agree that we want the best things for customers. I don't know. I ran an operational finance group. We like customers, but we really like making money. And so we didn't always agree with the customer experience team. And that's not bad. We shouldn't. That's where conflict is good, right? And so it's that same aspect with business requirements that I've seen is people assume that there are fewer places to disagree than there actually are. And then they also assume that we all likely agree on what the right outcome is. And so we're like, we're having a, we think there's fewer points of contention than there are. And we think that the points of contention that exist are actually not that contentious. And the really skilled leaders and developers of people help everyone see that that's an unhelpful way to view things, almost regardless of the decision. And instead learn to embrace, hey, I wanna show these principles to you to make this decision, but hey, I think I might have a bias because I'm from supply chain. From a technologist point of view, can you help me identify maybe where I have, where I've missed a principle that we should have to be a part of this or from a CX team or whatever. And the more time you can dedicate to it, and probably the dumbest thing that I have to say is write it down, write it down. I have a slide that says guiding principles that says here are the six ways we're gonna make this decision. Because until you write it down, it's all theory and everyone agrees. And then when you write it down and everyone stares at it, and they're like, well, I don't know if that's how we should say that. Well, Jim, why do you think that? And that's where it comes out. Yeah, I love the, well, we can all agree. And sometimes there will be like, you'll see all these nodding heads until you actually put it down like that. So you put it to paper, you put it down and you say, okay, well, this is what we're agreeing on. And everybody's sentence is like, oh, wait a minute, that's not what I'm agreeing on. You know, it's not, yeah, I think it's we underestimate where, and particularly there's so many of these psychological things, there's projection and stuff like that. We're like, well, I assume that you understand this the same way I do, because you've got the same background and all that kind of stuff. And then when you start digging into it, you realize that, oh no, we actually have very different opinions on this. And we do need to dig into them. So how do you give that the gravitas it needs at the beginning of a project? How do you drive that kind of stuff? Is it by finding like somebody that's a leader that's gonna champion that, or is it more of the bringing the team together so they all realize that like, hey, this is important or what is, how do you tackle that problem? So I would encourage a couple of things for people. One, having individual conversations ahead of that, whatever the rollout is, is really important. This is a place where I highly value great project management skills. When a great PM is meeting with individual stakeholders and saying like, here's what I'm hearing for how we wanna do this, and here's what I'm hearing from you about how you wanna do this, and here's what I'm hearing about your concerns. And they're helping the team do the work of collating all those points of view. And then having, I think of it as an executive sponsor and also almost like an operational sponsor. There's someone who's gonna help kind of move this through all the political heartache and headache that exists. That's your executive sponsor. But then you need a sponsor who's close enough to whatever operationally means in this context that can help bridge the understanding of, for example, is this project gonna deliver against the goals that we all have for it? And that you need two separate people to own that ideally. Because often those two things get mixed up and confused. And there's like a political thing that sometimes needs to be managed. And you need to spin up a VP and go have them fight that battle for you so the team can actually go work on solving the problem. And I think that we would all kind of do better if we would let our project managers, if we would over invest in project management, really good project management to bring that stuff forward and highlight where, hey, we've written down the principles, but actually every business unit disagrees with one of them. We need to talk through them. Let me help you. Let me help guide you through that conversation is the most valuable thing that I often had my PMs do. Well, we are gonna pause right here because we have to pause. We're not making Adam hold his breath until the next episode. Don't worry. We are actually gonna just dive right back into that currently. But for now, you guys will have to hold your breath and wait for the next episode unless you're waiting long enough in the future that both of these have released. Thank you, Adam, for your time and for hanging out with us. And we will have more of the conversation with him coming up in the next episode. But for now, shoot me an email. Send us an email at info at developer.com and let us know if you would like to come on and be one of our interview topics, subjects, people, co-hosts, however you wanna look at it. We would love to talk to you about that and see where we can bring more voices and more perspectives into this season on Foundations. You let us know what you think about us, what you think about some of the topics and where you may want us to go. Feel free to check us out at developerner.com, at the Developerner channel on YouTube, at Developerner on X, the Developerner Facebook page, and leave us comments at any of those. Podcasts, wherever you're listening to podcasts, you can leave us a review and notes. I don't care if it's five stars, 80 stars, one star, redfish, bluefish, goldfish, new fish, whatever it is. All of those things, just we want feedback. We wanna hear from you because you guys help us be better. That kind of feedback, good and bad, helps us become better podcasters for the better developers that we're trying to make you guys. As always, I appreciate your time. Thank you for hanging out with us. Be ready, because it's gonna continue to have some really good discussions as we get into the next part of this one, part two of the interview. Go out there and have yourself a great day, a great week, and we'll talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Nor podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts, we are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success.