Detailed Notes
In this episode of Building Better Developers, we sit down with Adam Malone, founder of The Tenacious Operator, to explore the Power of Trust — the real foundation behind leadership, performance, and team success.
Adam shares stories of transformation, from ERP project breakdowns to high-performing cultures, showing how trust and psychological safety turn challenges into collaboration.
What you’ll learn: • Why the Power of Trust drives results across every level of leadership • How to build psychological safety so teams speak up early and often • Using disagree and commit to transform conflict into alignment • How guiding principles create clarity and accountability • Why great project management keeps trust alive
🎧 Part 1 of our in-depth interview - https://develpreneur.com/power-of-trust-adam-malone-part-1
*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/
#PowerOfTrust #Leadership #Teamwork #Podcast #AdamMalone #BuildingBetterDevelopers #SoftwareLeadership #BusinessGrowth
Transcript Text
[Music] recording the there because yeah, I need to grab our normal stuff. Will be joining in a minute, I assume. And yeah, we'll do this um a little different from what we've done in the past. Um because what we'll what we'll end up doing is we will and I'll tell Michael this here in a minute. I guess I Well, tell you what, I'll wait on a minute. That way I'll just sort of make sure he's up to speed so I don't have to repeat it twice. Great. >> Let's see. Okay, he's rebooting his laptop. All right. The struggle that we all have to endure. >> No kidding. The updates are the killers. Mhm. You guys have any plans for fall? >> Uh, not really for the fall. We're just trying to Well, I guess our plans are prepping for the winter because we're >> Oh, yeah. Y'all are doing the move, aren't you? >> Yeah, we're doing the big move. So, we've got a house that we're prepping to uh for uh rental for long-term rental and stuff like that. So, we're got it all got it emptied and now we're going through and doing all the like standard, you know, painting and fixing some stuff up and things like that. It's it's needed some it's needed a touch for a while. And so we're going to get that done and then uh that will hopefully have us that's going to probably take a good port that and just the final steps of getting ourselves ready to uh head across the the ocean there will think pretty much fill up our our October. We do have also like we got a vacation in um Vegas. We're going to spend a week there which should be interesting because I keep seeing where they're cutting prices and they're just like begging people to come back. The tourism is I guess really like cut back a lot there. So, be interested to see how that goes for us. >> Yeah. I wonder I wonder why tourism's taking a hit there. >> I don't know. I don't know if it's I think it it seems like most of it seems to be it has to do with how high the prices got for a lot of this stuff is that they were just starting to price people out of it. Certain like Disney World's done the same. They just have like been going up and up and up and people are like, I've got something better to do, you know? So they, you know, basically comes down to supply and demand. And, you know, if you can't, if you price yourself out of reach, then people are going to stop coming. >> Yep. That is for sure. >> Okay. >> That'll be fun. What do you uh what do you all like to do in Vegas? >> Uh we've got So, wife's liked um roulette for a while and got me sort of I like it. I think we're gonna try we're gonna because I guess they have like u daily professionals will teach you how to play some of the various games and so I think we're gonna go tryh get somebody teach us craps so we can understand how that all works and things like that. It looks like a an interesting kind of uh >> interesting game so we figured we'll try that out and then uh we've we were recently playing just friendly poker with some people that blew our minds as to how they played it. We're like, "Oh, well, maybe we'll go back and see like because and they had one of them had lived in Vegas for years, so we figure we'll go get like some professionals to tell us like some of the things we need to know about that just for just for grins." >> Yeah. Uh, so I love crabs. It is a lot of fun. Um, one of the great things about crabs is if you are wise, you can enjoy watching what's going on with the audience and having fun and actually play for a really long time. I mean, it's odds are the closest thing to 50/50 in the house if you play it the right way. Um, but if you get dumb and start throwing a bunch of money in the middle, which I of course have done, um, you don't you won't last quite as long. Uh, but if you just want to people watch and have a little bit of action, there's no better game. Well, and that's why we like roulette. It's got some of that same you can you can find a way to play it for a decent amount of time. And a lot of it has to do with the people watching. And we noticed that as we were going by tables, you know, some of the the crafts tables, it's like, ah, that just looks like a, you know, fun crowd to hang out and just sort of watch how people are going and see, especially when a table gets somebody's getting hot and, you know, you get people jumping in. So, very being fun to fun to learn enough to be able to to join in and, you know, spend a while away some time people watching. >> Yeah, I will say craps has gotten you have to find places that have a live table and not a arcade style table. Now, it's been I've been very annoyed like I've gone somewhere to go play craps and you get there and it's just a video screen. >> It's like this is not this is not the dynamic that I wanted. Um I get that the odds are the same. I get the math is the same, but it is not the same feel. >> Yeah. It's like playing playing, you know, playing football on a PlayStation versus, you know, watching it in real life kind of stuff. There's a there's a big difference. >> Exactly. >> All right. So um it's a little bit because Michael's first Michael meet Adam. Adam meet Michael. >> Yeah. >> Hello Michael. >> Um we have just started a season which works out perfect. We're talking about foundations and stuff like that. And it's uh really for like building better developers, building better businessmen and and business people. And I think it actually works out really good that uh to have this conversation about like how trust really works into those c things about how you have it's important in your team dynamics important as a leader it's important you know running your business with your customers and a lot of the stuff that you and I sort of touched on when we had our conversation I think would be great for you know to sort of expound upon and just a little bit uh you know maybe even go down some rabbit holes here and there about like how people can you know do that better and and how you can advance your career. by making sure that you do some of those things to to build trust and things of that nature. So, it's it's >> great >> question or >> No, no, I said great. >> Okay. U and we tend to keep it pretty free flowing. So, it'll be it'll probably be a question here or there and then we'll just sort of see where the the conversation takes us. That has no pressure, but that has always worked out awesome for every prior uh interview. So, I'm expecting no less this time around. >> Awesome. I'll try not to disappoint. >> I'm sure you won't. Uh we'll start it off with uh Michael and I'll do sort of our standard introduction things. Um and then we will I'll send it over to you and I'll say and hey, we've got a guest and allow you to introduce yourself in your terms because I've always found that works better than me trying to to speak through it all. Uh and then we'll dive into the conversation. Uh Michael, what we'll do is this will be a we'll do it like an extended this will be probably a long this will be a longer than normal. You can you can cut it and then at afterwards uh after Adam heads out then we can you know if we want we can do a second intro and you know do that and then you can splice it back in and probably just do one bonus thing afterwards. >> Yeah, that'll work. >> Okay. Uh and I guess I've been recording for a little bit so there may be some bonus stuff you can throw there. So you know a little bit behind the scenes or whatever I guess. Um not too much at this point I guess. So, all right then. I will let me get this straightened out. So, I'm sort of looking at the camera and you guys. Did you want to kick my notetaker out? It doesn't It doesn't have to hang out there, but sometimes I struggle to get it to leave meetings when I want it to >> see. I think I can do a remove. There we go. >> Yeah, there we go. >> That'll make it a little easier so we can see each other. That's true. I don't think the notemaker was going to add to our conversation very much. So, >> probably not. like read that back. I'm not sure what >> not sure what was just said. All right, >> I'll give you a little three, two, whoops, my mic just jumped in the way. One. Well, hello and welcome back. We are continuing our season as we are building better foundations. This time around we are building better developers, the developer podcast. I am Rod Broadhead, one of the founders of developer, 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. Uh 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 Mike Malashsh. I'm one of the co-founders building better developers, also known as developer. 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, rockolid quality. We build tools that replace frustrating systems, streamline 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 I don't know if I'll bring any thunder, but I'll I'll do my best. Uh my name's Adam Malone. I founded a leadership consultancy called the Tenacious Operator in 2024. Uh we're focused on bringing trust into every relationship and using trust as the catalyst and the driver for delivering sustained high performance uh for the teams that we get to work with. Uh so I'm excited to talk uh with you guys today. Um I've worked with a lot of great developers over my time and um they're some of my favorite people. So love love that we can be together and uh I'm excited uh to get to know your audience better. >> Excellent. Well, and I think we'll dive right in because we're u we are working through the foundations and one of the foundations that uh anybody that we need actually this can be in any career but definitely as developers and entrepreneurs is uh we get into some of those like soft skills and things like that and one of those uh which is why Adam's here is trust is building trust because it really does impact so much of what we do the conversations uh assumptions things like that that are and even our uh 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 you know like our attitude and if we trust our co-workers if we trust our team if we trust our boss that makes a very very different relationship than if you don't um I think I'll I'll throw it right away into like maybe a let's start I if we can start on some of like a negative maybe if you've got do you have like a a negative story of like where you've seen uh trust cause an issue like that where maybe it causes you know either some miscommunication or some things that just you know missed deadlines of morale things of that nature. >> Yeah. So uh would love to talk about that. Uh I mean the easiest example, you know, generically we've probably all been in this situation. The specific scenario I'll share had an ERP implementation uh 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, you know, every metric, everything that could have been good was good. Um and everything felt like it was on time. Um, and and I'm saying this from the from the seat of I was I was probably a VP at this point. I'm not quite certain, but senior director VP, so executive E, we'll say. Um, and so from my perspective, everything looked and sounded great. Uh, 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. You know, 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 um it was my team who was kind of I was the executive sponsor. Uh 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. Um, so one was the team didn't feel comfortable speaking up um that 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 someway 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. Um similarly, you know, the the opportunity was going to deliver, you know, three different efficiency improvements uh on the operations floor and uh 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 the technology process change, which is technically a great outcome, but that had been solved like a month before, come to find out. Uh and then the the third issue um was that the business requirements weren't complete complete. They were just one complete. You know, they they just didn't get get all the way there. Uh but again because the operations team and the technology team were not in sync and 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 um 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 uh on the on the the ERP upgrade. Um we got through it. Things 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 and to me that is a classic sign of a trust failure. Well, when you do something like that because since it is like a like you said almost it's like almost an overnight change. Is it because um and this maybe I don't know how much this is definitive and how much is this is sort of like your your gut instinct on this but of it is like is it something that like triggers a trust event where somebody's like you know what suddenly I was feeling good about it and sudden I realize I really don't trust this person or is it something where it's like final straw on a back it breaks a camel back kind of thing where it's like there's just you only go so far and then the uh 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 or do you think maybe it's a combination of such things? >> Uh 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. Um but 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 you know 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 and every time we talk about this testing it's not delivering on that or you know so on 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 to come to light is one of a leader probably greatest challenges is how do we drive for performance and drive for delivery while allowing failure to be I don't want to say okay like oh it's fine but allowing people to say hey we're worried about failure so that we 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. Um that's those are the sorts of things that lead to to those events in my opinion. >> Now are there um cuz you like this kind of situation that you had is where it seems things are just sort of like going along. Are there maybe some warning signs or some uh some things that you can keep an eye out for to just to make sure that you're you're getting I guess the uh the real story essentially or the full story. >> Yeah. So, uh I have a operations background so I'm a big believer in continuous improvement and especially in lean. Um I don't know how much you guys your audience are familiar with a concept called gimba. It's a comes from Toyota production systems. It's gimba is the Japanese term that means uh to go to the place where value is added. Uh if the 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. Um and and what that speaks to is anytime 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. Um and and sometimes people mistake this and think like, oh yeah, on a factory floor you can do that and um you know there's a physical tangible thing you can go look at. That is absolutely true. You can and 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. Um, an example would be, uh, I had a team at one point that they owned a process that determined, um, how we worked with certain buyers, which which buyers do we use versus others? And there's 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? Well, we wanted to automate that and systematize it where it wasn't just a bunch of spread spreadsheet jockeyies doing it. Um, 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 was valuable. Um, and 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 a we have a source problem. Great. We can go fix that now. Right? Some of those 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. Um, but that watching and and that team engagement around the work is really helpful in identifying those sorts of shortcomings uh 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 kind of curious um 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 uh I guess the right tools and communication um processes in place for that the buildup of the trust from the beginning of the project? >> Yeah, it's a great question. I I would site a couple things. One, um 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 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 and that's an example to me of a of a faux outcome of 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, or I'm not certain that 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 and we weren't doing that. That's one of the things we all just kind of had sat back and assumed all right business unit one or team one they own their requirements team three owns their requirements. team forward 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 like 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 um and you risk watering them down. So that's one item. Um 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 or what um we probably chose to not hear when people were saying that these things weren't quite going 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. Um, 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. Um and that that would be a second one I would cite is a persistent issue that was really on the executive team and you know all executive teams do that at some point um in my experience. >> So I also have a follow-up to that one too. So you mentioned um you know being a negative Nancy. How would you look back on this and how would you communicate the issues that you know 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 that yes we're on track to see that hey there's a problem this is how we can address it without them feeling uh pressured or concerned about bringing up issues. >> Yeah. So, um, a couple tricks that I try to use when I talk to people is create opportunities for negative feedback. Um, and so often people are nervous about saying negative things as as you mentioned, Michael. Um, 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. Um, because they are often identifying systemic technical issues, they can feel ignored. Um, because the, you know, the business guy like me is like, "Oh, you'll figure it out. You're smart. We'll get it done." you know, um, and so the the thing I would say is creating opportunities for those folks to share negative feedback on purpose. And that's 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. like let's do a you know some call it like a reverse postmortem where you act like you're after the fact and say like hey what are the three things we might meet on in three months to say this is why the project failed. So when you do that sort of exercise you're giving people permission to say that negative thing. Um 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 uh where it was very uh um very productive, like we had very good back and forth feedback. Uh but I've had others where it kind of became, for lack of a better term, like a where it's all the time. Uh just basically bashing the project like nothing >> positive came out of that meeting other than people just venting their problems. So how would you in 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 where it's very negative. >> Yeah. So uh 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. You know 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 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. Um 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 6 months and say, I told you so. We disagree as a team. We worked 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 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 in 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 like we don't actually do anything with them. It's just a bunch of had a Scottish leader one time that called it winging and moaning. Um 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 I mean even even if like you're in the US you have so many different cultures that um are you know a part of almost every organization and not only um you know like nationalities and stuff like that but also even corporate cultures that people you know have dealt with and and so how often do you I guess one is that is that something that you end up having to address on a you know regular enough basis of like how do you and and in so doing like how do you bring that together? How do you find a way to like get that uh 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 the approach that we're going to take. Yeah. So, um I call them guiding principles. Some people call them something else. Uh 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 um we all sit down and we look at like what's the current situation, what's going on. We do a SWAT 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. Um 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 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 it's defining success criteria but some of it's just defining the ways we're going to work and so let me let me give you an example right um you know lots of organizations will say you know customer the customer experience is number one I've been in 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 at every step of this process there are things that can drive cost, can 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 and the truth is no one is saying that to the you know full extent right and so how do we define that more right so that would be an example of some of it's using metrics hey our NPS is a 4.2 two. This initiative cannot drop that below a four or it can't drop at all or um 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. Okay, great. Um uh defining the cost. Hey, this is going to increase our cost or it's going to decrease our costs to pursue this. XYZ 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 want to go? Is this what 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, uh, okay, we're gonna do this process that's going to increase handle time. Okay, how much is it going to increase handle time? Well, it's going to 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 going to say no to this? And often people try to have both of those debates at the same time. And that's often the the the biggest issue that I see. Um so that that helps on cult that helps on like how are we going to make the decision. You asked about culture though and I'm not certain I completely address culture. Um did I or uh I can address that separately. >> Yeah, that's a good qu because it sort of does is I guess it addresses it by running around it. I feel like it's an end run by saying and it's and I don't think that's a wrong answer either. So, um, it's basically saying let's let's get ahead of I guess more 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 going to 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 a decision. You know, sometimes it's if you've got a situation where you'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 got to be 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? >> Um, get this help maybe. And it's do you find that there's and I guess in as you do that do you find that that is it is it harder I guess it's a it's this going to 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 that's that's like a I'll 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 time. They do it all the time. >> Um, but this what I'm 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. Like when when things are when everybody starts out and it's all sunshine and roses and this is going to be an awesome project and it's all going to work. Uh, but I guess it's just they don't is it really just they don't give it the respect they they're just like or they just sort of like it's a a rubber stamp like oh sure we'll do that and then they don't follow it. Um, 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 shortcircuit 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. Like 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. Like that's where conflict is good, right? Um and so it's that 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 point points of contention that exist are actually not that contentious. Um and the really skilled leaders and developers of people help the help everyone see that that's an unhelpful way to view things. um almost regardless of the decision and instead learn to embrace hey I want to 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 um 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. Have a slide that says guiding principles that says here are the six ways we're going to 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. Yeah, I love the well we can all agree and sometimes everybody like you'll see all these nodding heads until you actually put it down like that till you put it to to paper. you put it down, you say, "Okay, well, this is what we're agreeing on." And everybody suddenly is like, "Oh, wait a minute. That's not what I'm agreeing on." You know, it's it's not a um Yeah, I think it's we underestimate where >> and part there's so it's there's so many of these psychological thing. There's projection and stuff like that where 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, you know, to dig into them. So how do you, you know, how do you how do you give that the graitas it needs at the beginning of a project? How do you drive that kind of stuff? Is it by finding like a u you know somebody that's a a leader that's gonna to champion that or is it more of a the bringing the team together so they all realize that like hey this is important or or what is a how do you how do you tackle that problem? >> Uh so I would encourage a couple things for people. Um one having individual conversations ahead of that whatever the roll out is is really important. Um, this is a place where I highly value great project management skills. when a when a great um PM is meeting with individual stakeholders and saying like here's here's what I'm hearing for how we want to do this and here's what I'm hearing from you about how you want to do this and here's what I'm hearing about your concerns and they're helping the team do the work of of coating all those points of view and then having um I think of it as an executive sponsor and also almost like an operational sponsor there's someone who's going to help kind of move this through all the political heartache and headache that exists. That's your executive sponsor. But then you you need a sponsor who's close enough to whatever operationally means in this context that help can help bridge the understanding of for example is this project going to deliver against the goals that we all have for it and that you need two separate people to own that ideally. Um 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, you know, spin up a VP and go have them fight that battle for you so the team can actually go work on solving the problem, right? Um, and I I think that we would all kind of do better if we would let our project managers, if we would overinvest in project management, really good project management to bring that stuff forward and highlight where, hey, we have 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 is the most valuable thing that I often had my PMs do. Well, we are gonna pause right here because we have to pause. Uh we are not making Adam hold his breath until the next episode. Don't worry, we are actually going to just dive right back 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. Uh 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 info developor.com and let us know if you would like to come on and be uh one of our interview topic subjects uh people co-host, however you want to look at it. uh we would love to uh talk to you about that and see what we can you know bring more voices and more perspectives into this season on foundations. Uh 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 developer.com at the developer channel on YouTube developer onx the developer Facebook page and leave us comments at any of those podcasts. Wherever you're listening to podcast, you can leave us a uh a review and notes. I don't care if it's five stars, 80 stars, one star, red fish, blue fish, goldfish, new fish, whatever it is. All of those things, just we want feedback. We want to 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. Um, be ready because it's going to 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 will talk to you next time. [Music]
Transcript Segments
[Music]
recording the there because yeah, I need
to grab our normal stuff.
Will be joining in a minute, I assume.
And yeah, we'll do this um
a little different from what we've done
in the past. Um because what we'll what
we'll end up doing is we will and I'll
tell Michael this here in a minute. I
guess I Well, tell you what, I'll wait
on a minute. That way I'll just sort of
make sure he's up to speed so I don't
have to repeat it twice. Great.
>> Let's see.
Okay, he's rebooting his laptop. All
right.
The struggle that we all have to endure.
>> No kidding.
The updates are the killers.
Mhm.
You guys have any plans for fall?
>> Uh, not really for the fall. We're just
trying to Well, I guess our plans are
prepping for the winter because we're
>> Oh, yeah. Y'all are doing the move,
aren't you?
>> Yeah, we're doing the big move. So,
we've got a house that we're prepping to
uh for uh rental for long-term rental
and stuff like that. So, we're got it
all got it emptied and now we're going
through and doing all the like standard,
you know, painting and fixing some stuff
up and things like that. It's it's
needed some it's needed a touch for a
while. And so we're going to get that
done and then uh that will hopefully
have us that's going to probably take a
good port that and just the final steps
of getting ourselves ready to uh head
across the the ocean there will think
pretty much fill up our our October. We
do have also like we got a vacation in
um Vegas. We're going to spend a week
there which should be interesting
because I keep seeing where they're
cutting prices and they're just like
begging people to come back. The tourism
is I guess really like cut back a lot
there. So, be interested to see how that
goes for us.
>> Yeah. I wonder I wonder why tourism's
taking a hit there.
>> I don't know. I don't know if it's I
think it it seems like most of it seems
to be it has to do with how high the
prices got for a lot of this stuff is
that they were just starting to price
people out of it. Certain like Disney
World's done the same. They just have
like been going up and up and up and
people are like, I've got something
better to do, you know? So they, you
know, basically comes down to supply and
demand. And, you know, if you can't, if
you price yourself out of reach, then
people are going to stop coming.
>> Yep. That is for sure.
>> Okay.
>> That'll be fun. What do you uh what do
you all like to do in Vegas?
>> Uh we've got So, wife's liked um
roulette for a while and got me sort of
I like it. I think we're gonna try we're
gonna because I guess they have like u
daily
professionals will teach you how to play
some of the various games and so I think
we're gonna go tryh get somebody teach
us craps so we can understand how that
all works and things like that. It looks
like a an interesting kind of uh
>> interesting game so we figured we'll try
that out and then uh we've we were
recently playing just friendly poker
with some people that blew our minds as
to how they played it. We're like, "Oh,
well, maybe we'll go back and see like
because and they had one of them had
lived in Vegas for years, so we figure
we'll go get like some professionals to
tell us like some of the things we need
to know about that just for just for
grins."
>> Yeah. Uh, so I love crabs. It is a lot
of fun. Um, one of the great things
about crabs is if you are wise,
you can enjoy watching what's going on
with the audience and having fun and
actually play for a really long time. I
mean, it's odds are the closest thing to
50/50 in the house if you play it the
right way. Um,
but if you get dumb and start throwing a
bunch of money in the middle, which I of
course have done, um, you don't you
won't last quite as long. Uh, but if you
just want to people watch and have a
little bit of action, there's no better
game. Well, and that's why we like
roulette. It's got some of that same you
can you can find a way to play it for a
decent amount of time. And a lot of it
has to do with the people watching. And
we noticed that as we were going by
tables, you know, some of the the crafts
tables, it's like, ah, that just looks
like a, you know, fun crowd to hang out
and just sort of watch how people are
going and see, especially when a table
gets somebody's getting hot and, you
know, you get people jumping in. So,
very being fun to fun to learn enough to
be able to to join in and, you know,
spend a while away some time people
watching.
>> Yeah, I will say craps has gotten you
have to find places that have a live
table and not a arcade style table. Now,
it's been I've been very annoyed like
I've gone somewhere to go play craps and
you get there and it's just a video
screen.
>> It's like this is not this is not the
dynamic that I wanted. Um I get that the
odds are the same. I get the math is the
same, but it is not the same feel.
>> Yeah. It's like playing playing, you
know, playing football on a PlayStation
versus, you know, watching it in real
life kind of stuff. There's a there's a
big difference.
>> Exactly.
>> All right. So um it's a little bit
because Michael's first Michael meet
Adam. Adam meet Michael.
>> Yeah.
>> Hello Michael.
>> Um we have just started a season which
works out perfect. We're talking about
foundations and stuff like that. And
it's uh really for like building better
developers, building better businessmen
and and business people. And I think it
actually works out really good that uh
to have this conversation about like how
trust really works into those c things
about how you have it's important in
your team dynamics important as a leader
it's important you know running your
business with your customers and a lot
of the stuff that you and I sort of
touched on when we had our conversation
I think would be great for you know to
sort of expound upon and just a little
bit uh you know maybe even go down some
rabbit holes here and there about like
how people can you know do that better
and and how you can advance your career.
by making sure that you do some of those
things to to build trust and things of
that nature. So, it's it's
>> great
>> question or
>> No, no, I said great.
>> Okay. U and we tend to keep it pretty
free flowing. So, it'll be it'll
probably be a question here or there and
then we'll just sort of see where the
the conversation takes us. That has no
pressure, but that has always worked out
awesome for every prior uh interview.
So, I'm expecting no less this time
around.
>> Awesome. I'll try not to disappoint.
>> I'm sure you won't. Uh we'll start it
off with uh Michael and I'll do sort of
our standard introduction things. Um and
then we will I'll send it over to you
and I'll say and hey, we've got a guest
and allow you to introduce yourself in
your terms because I've always found
that works better than me trying to to
speak through it all. Uh and then we'll
dive into the conversation. Uh Michael,
what we'll do is this will be a
we'll do it like an extended this will
be probably a long this will be a longer
than normal. You can you can cut it and
then at afterwards uh after Adam heads
out then we can you know if we want we
can do a second intro and you know do
that and then you can splice it back in
and probably just do one bonus thing
afterwards.
>> Yeah, that'll work.
>> Okay. Uh and I guess I've been recording
for a little bit so there may be some
bonus stuff you can throw there. So you
know a little bit behind the scenes or
whatever I guess. Um not too much at
this point I guess. So, all right then.
I will let me get this straightened out.
So, I'm sort of looking at the camera
and you guys.
Did you want to kick my notetaker out?
It doesn't It doesn't have to hang out
there, but sometimes I struggle to get
it to leave meetings when I want it to
>> see. I think I can do a remove.
There we go.
>> Yeah, there we go.
>> That'll make it a little easier so we
can see each other. That's true. I don't
think the notemaker was going to add to
our conversation very much. So,
>> probably not. like read that back. I'm
not sure what
>> not sure what was just said. All right,
>> I'll give you a little three, two,
whoops, my mic just jumped in the way.
One. Well, hello and welcome back. We
are continuing our season as we are
building better foundations. This time
around we are building better
developers, the developer podcast. I am
Rod Broadhead, one of the founders of
developer, 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. Uh 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 Mike Malashsh.
I'm one of the co-founders building
better developers, also known as
developer. 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,
rockolid quality. We build tools that
replace frustrating systems, streamline
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 I don't know if I'll bring any
thunder, but I'll I'll do my best. Uh my
name's Adam Malone. I founded a
leadership consultancy called the
Tenacious Operator in 2024. Uh we're
focused on bringing trust into every
relationship and using trust as the
catalyst and the driver for delivering
sustained high performance uh for the
teams that we get to work with. Uh so
I'm excited to talk uh with you guys
today. Um I've worked with a lot of
great developers over my time and um
they're some of my favorite people. So
love love that we can be together and uh
I'm excited uh to get to know your
audience better.
>> Excellent. Well, and I think we'll dive
right in because we're u we are working
through the foundations and one of the
foundations that uh anybody that we need
actually this can be in any career but
definitely as developers and
entrepreneurs is uh we get into some of
those like soft skills and things like
that and one of those uh which is why
Adam's here is trust is building trust
because it really does impact
so much of what we do the conversations
uh assumptions things like that that are
and even our uh 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 you know like our attitude and if we
trust our co-workers if we trust our
team if we trust our boss that makes a
very very different relationship than if
you don't um I think I'll I'll throw it
right away into like maybe a
let's start I if we can start on some of
like a negative maybe if you've got do
you have like a a negative story of like
where you've seen uh trust cause an
issue like that where maybe it causes
you know either some miscommunication or
some things that just you know missed
deadlines of morale things of that
nature.
>> Yeah. So uh would love to talk about
that. Uh I mean the easiest example, you
know, generically we've probably all
been in this situation. The specific
scenario I'll share had an ERP
implementation
uh 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, you
know, every metric, everything that
could have been good was good. Um and
everything felt like it was on time. Um,
and and I'm saying this from the from
the seat of I was I was probably a VP at
this point. I'm not quite certain, but
senior director VP, so executive E,
we'll say. Um, and so from my
perspective, everything looked and
sounded great. Uh, 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. You
know, 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 um it was my team
who was kind of I was the executive
sponsor. Uh 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. Um, so one
was the team didn't feel comfortable
speaking up um that 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 someway 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.
Um similarly, you know, the the
opportunity was going to deliver, you
know, three different efficiency
improvements uh on the operations floor
and
uh 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 the technology process change, which
is technically a great outcome, but that
had been solved like a month before,
come to find out. Uh and then the the
third issue
um was that the business requirements
weren't complete complete. They were
just one complete. You know, they
they just didn't get get all the way
there. Uh but again
because the operations team and the
technology team were not in sync and 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 um 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 uh on the on the the
ERP upgrade. Um we got through it.
Things 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 and to me that
is a classic sign of a trust failure.
Well, when you do something like that
because since it is like a like you said
almost it's like almost an overnight
change. Is it because
um and this maybe I don't know how much
this is definitive and how much is this
is sort of like your your gut instinct
on this but of it is like
is it something that like triggers a
trust event where somebody's like you
know what suddenly I was feeling good
about it and sudden I realize I really
don't trust this person or is it
something where it's like final straw on
a back it breaks a camel back kind of
thing where it's like there's just you
only go so far and then the uh 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 or do you think maybe it's a
combination of such things?
>> Uh 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. Um
but 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 you know
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
and every time we talk about this
testing it's not delivering on that or
you know so on 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 to
come to light is one of a leader
probably greatest challenges is how do
we drive for performance and drive for
delivery
while allowing failure to be I don't
want to say okay like oh it's fine but
allowing people to say hey we're worried
about failure
so that we 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. Um
that's those are the sorts of things
that lead to to those events in my
opinion.
>> Now are there um cuz you like this kind
of situation that you had is where it
seems things are just sort of like going
along. Are there maybe some warning
signs or some uh some things that you
can keep an eye out for to just to make
sure that you're you're getting I guess
the uh the real story essentially or the
full story.
>> Yeah. So, uh I have a operations
background so I'm a big believer in
continuous improvement and especially in
lean. Um I don't know how much you guys
your audience are familiar with a
concept called gimba. It's a comes from
Toyota production systems. It's gimba is
the Japanese term that means uh to go to
the place where value is added. Uh if
the 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. Um and and what that
speaks to is anytime 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.
Um and and sometimes people mistake this
and think like, oh yeah, on a factory
floor you can do that and um you know
there's a physical tangible thing you
can go look at. That is absolutely true.
You can and 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. Um, an example
would be, uh, I had a team at one point
that they owned a process that
determined,
um, how we worked with certain buyers,
which which buyers do we use versus
others? And there's 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? Well,
we wanted to automate that and
systematize it where it wasn't just a
bunch of spread spreadsheet jockeyies
doing it. Um, 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 was
valuable. Um, and 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 a we have a source problem.
Great. We can go fix that now. Right?
Some of those 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. Um, but that watching
and and that team engagement around the
work is really helpful in identifying
those sorts of shortcomings uh 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
kind of curious um 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 uh I guess the right
tools and communication um processes in
place for that the buildup of the trust
from the beginning of the project?
>> Yeah, it's a great question. I I would
site a couple things. One,
um 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
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 and that's an
example to me of a of a faux outcome of
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, or I'm not certain
that 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 and we
weren't doing that. That's one of the
things we all just kind of had sat back
and assumed all right business unit one
or team one they own their requirements
team three owns their requirements. team
forward 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 like 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 um and you risk watering
them down. So that's one item. Um 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 or what um
we probably chose to not hear when
people were saying that these things
weren't quite going 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. Um, 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. Um and that that
would be a second one I would cite is a
persistent issue that was really on the
executive team and you know all
executive teams do that at some point um
in my experience.
>> So I also have a follow-up to that one
too. So you mentioned um you know being
a negative Nancy. How would you look
back on this and how would you
communicate the issues that you know 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 that yes
we're on track to see that hey there's a
problem this is how we can address it
without them feeling uh pressured or
concerned about bringing up issues.
>> Yeah. So, um, a couple tricks that I try
to use when I talk to people is
create opportunities for negative
feedback. Um, and so often people are
nervous about saying negative things as
as you mentioned, Michael. Um,
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. Um,
because they are often identifying
systemic technical issues, they can feel
ignored. Um, because the, you know, the
business guy like me is like, "Oh,
you'll figure it out. You're smart.
We'll get it done." you know, um, and so
the the thing I would say is creating
opportunities for those folks to share
negative feedback on purpose. And that's
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. like let's do a you know
some call it like a reverse postmortem
where you act like you're after the fact
and say like hey what are the three
things we might meet on in three months
to say this is why the project failed.
So when you do that sort of exercise
you're giving people permission to say
that negative thing. Um 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 uh where it was very
uh um very productive, like we had very
good back and forth feedback. Uh but
I've had others where it kind of became,
for lack of a better term, like a
where it's all the time. Uh
just basically bashing the project like
nothing
>> positive came out of that meeting other
than people just venting their problems.
So
how would you in 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 where it's
very negative.
>> Yeah. So uh 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.
You know 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
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.
Um 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 6 months and
say, I told you so. We disagree as a
team. We worked 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 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 in
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 like we don't
actually do anything with them. It's
just a bunch of had a Scottish leader
one time that called it winging and
moaning. Um 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 I mean even even
if like you're in the US you have so
many different cultures that um are you
know a part of almost every organization
and not only um you know like
nationalities and stuff like that but
also even corporate cultures that people
you know have dealt with and and so how
often do you I guess one is that is that
something that you end up having to
address on a you know regular enough
basis of like how do you and and in so
doing like how do you bring that
together? How do you find a way to like
get that uh 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 the approach that
we're going to take.
Yeah. So, um I call them guiding
principles.
Some people call them something else. Uh
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 um we all sit down and we look at
like what's the current situation,
what's going on. We do a SWAT 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. Um 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 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 it's defining success criteria but
some of it's just defining the ways
we're going to work and so let me let me
give you an example right um you know
lots of organizations will say you know
customer the customer experience is
number one I've been in 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 at
every step of this process there are
things that can drive cost, can 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
and the truth is no one is saying that
to the you know full extent right and so
how do we define that more right so that
would be an example of some of it's
using metrics hey our NPS is a 4.2 two.
This initiative cannot drop that below a
four or it can't drop at all or um 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. Okay, great. Um
uh defining the cost. Hey, this is going
to increase our cost or it's going to
decrease our costs to pursue this. XYZ
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 want to go? Is this what 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, uh,
okay, we're gonna do this process that's
going to increase handle time. Okay, how
much is it going to increase handle
time? Well, it's going to 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
going to say no to this? And often
people try to have both of those debates
at the same time. And that's often the
the the biggest issue that I see. Um so
that that helps on cult that helps on
like how are we going to make the
decision. You asked about culture though
and I'm not certain I completely address
culture. Um did I or uh I can address
that separately.
>> Yeah, that's a good qu because it sort
of does is I guess it addresses it by
running around it. I feel like it's an
end run by saying and it's and I don't
think that's a wrong answer either. So,
um, it's basically saying let's let's
get ahead of I guess more 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 going to
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 a
decision. You know, sometimes it's if
you've got a situation where you'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 got to be
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?
>> Um, get this help maybe. And it's do you
find that there's and I guess in as you
do that do you find that that
is it is it harder I guess it's a it's
this going to 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
that's that's like a I'll 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 time. They do it all the time.
>> Um, but this what I'm 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. Like when when things are
when everybody starts out and it's all
sunshine and roses and this is going to
be an awesome project and it's all going
to work. Uh, but I guess it's just they
don't is it really just they don't give
it the respect they they're just like or
they just sort of like it's a a rubber
stamp like oh sure we'll do that and
then they don't follow it.
Um, 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 shortcircuit 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. Like 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. Like
that's where conflict is good, right? Um
and so it's that 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
point points of contention that exist
are actually not that contentious. Um
and the really skilled leaders and
developers of people
help the help everyone see that that's
an unhelpful way to view things.
um almost regardless of the decision and
instead learn to embrace
hey I want to 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 um 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. Have a slide that
says guiding principles that says here
are the six ways we're going to 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. Yeah, I love the well we can all
agree and sometimes everybody like
you'll see all these nodding heads until
you actually put it down like that till
you put it to to paper. you put it down,
you say, "Okay, well, this is what we're
agreeing on." And everybody suddenly is
like, "Oh, wait a minute. That's not
what I'm agreeing on." You know, it's
it's not a um Yeah, I think it's we
underestimate where
>> and part there's so it's there's so many
of these psychological thing. There's
projection and stuff like that where
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, you
know, to dig into them. So how do you,
you know, how do you how do you give
that the graitas it needs at the
beginning of a project? How do you drive
that kind of stuff? Is it by finding
like a u you know somebody that's a a
leader that's gonna to champion that or
is it more of a the bringing the team
together so they all realize that like
hey this is important or or what is a
how do you how do you tackle that
problem?
>> Uh so I would encourage a couple things
for people. Um one
having individual conversations ahead of
that whatever the roll out is is really
important. Um, this is a place where I
highly value
great project management skills. when a
when a great um PM is meeting with
individual stakeholders and saying like
here's here's what I'm hearing for how
we want to do this and here's what I'm
hearing from you about how you want to
do this and here's what I'm hearing
about your concerns and they're helping
the team do the work of of coating all
those points of view and then having um
I think of it as an executive sponsor
and also almost like an operational
sponsor there's someone who's going to
help kind of move this through all the
political heartache and headache that
exists. That's your executive sponsor.
But then you you need a sponsor who's
close enough to whatever operationally
means in this context that help can help
bridge the understanding of for example
is this project going to deliver against
the goals that we all have for it and
that you need two separate people to own
that ideally. Um 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, you know, spin up a VP and go
have them fight that battle for you so
the team can actually go work on solving
the problem, right? Um,
and
I I think that we would all kind of do
better if we would let our project
managers, if we would overinvest in
project management, really good project
management to bring that stuff forward
and highlight where,
hey, we have 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 is the most valuable
thing that I often had my PMs do.
Well, we are gonna pause right here
because we have to pause. Uh we are not
making Adam hold his breath until the
next episode. Don't worry, we are
actually going to just dive right back
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.
Uh 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 info
developor.com and let us know if you
would like to come on and be uh one of
our interview topic subjects uh people
co-host, however you want to look at it.
uh we would love to uh talk to you about
that and see what we can you know bring
more voices and more perspectives into
this season on foundations.
Uh 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
developer.com at the developer channel
on YouTube developer onx the developer
Facebook page and leave us comments at
any of those podcasts. Wherever you're
listening to podcast, you can leave us a
uh a review and notes. I don't care if
it's five stars, 80 stars, one star, red
fish, blue fish, goldfish, new fish,
whatever it is. All of those things,
just we want feedback. We want to 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. Um, be ready
because it's going to 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 will talk to you next time.
[Music]