Detailed Notes
In this episode of the Building Better Developers Podcast, we sit down with Dusty Gulleson, CEO of eResources, to explore how story driven discovery transforms software projects from the very beginning.
Dusty shares why understanding a client’s story, motivations, and workflow realities leads to better outcomes than relying on feature lists or technical specs. He explains how stories reveal true business challenges, expose hidden needs, and create alignment long before development begins.
We also dig into pitfalls of AI-generated RFPs, the dangers of skipping discovery, and how prioritization frameworks like MoSCoW and the 80-15-5 rule help teams stay grounded in value.
If you want to build better software, improve client communication, or strengthen your development process, this episode is packed with practical insight.
🔑 Key Topics Covered: • What “story driven discovery” really means • Why stories reveal deeper needs than requirements • How discovery prevents scope creep and misalignment • The problem with AI-generated RFPs • Tools for prioritization: MoSCoW & 80-15-5 • Building trust through better discovery conversations • How eResources scaled through people-first leadership
🎙 Guest: Dusty Gulleson — Founder & CEO, eResources https://www.linkedin.com/in/dustygulleson/ A 25-year leader who grew a 100+ person tech company without outside funding by focusing on relationships, trust, and people.
đź“Ś Watch more episodes: https://www.youtube.com/@develpreneur
đź‘Ť Like, subscribe, and hit the bell to get the latest episodes!
#StoryDrivenDiscovery #SoftwareDevelopment #ProjectManagement #Leadership #Technology
Transcript Text
Uh, See? So, let me pull this. Way we do this is um we do our we'll do a um an intro. Basically, we'll introduce ourselves. We'll pass it to you to introduce yourself because it's always easier to do that. Um >> just be sure. Is it Gullison? >> It's Gullison. >> All right. Thanks. >> And couple questions. >> I do smoke cigars. I can stop smoking for the interview. That's fine. Whatever you prefer. That's good. That's totally >> Don't know what your vibe. Some people like that's not our vibe. >> Yeah, we've had we've had more than a share our share what we've been doing whisies and tequilas and such along the way is a cigar is not going to break our vibe in any way, form or fashion. >> You'll be surprised. Some people get really weighed down about stuff. >> Yeah, I know. But those are not the people we care to mess with too much. And since we're sort of like we usually have like a pre-show, so if any of this shows up on the pre-show and you're offended by it, I'm sorry, but that's like we are we're live and let live people here. So if you're going to have fun, >> do it. You know, if you're bothered by his secondhand smoke, then well, you've got a better computer than I do. So, >> exactly. Good on you. >> Yep. >> I'm just trying to set things up here. >> Do we do this as a uh we tend to do this as more like a conversational kind of thing. We'll ask some questions here and there, but generally it's just like it goes. uh especially with your background and and some of the stuff. Yeah, you've you've had enough enough experience, enough things you've done that I have no problem I have no worries that we're going to get into. We'll we'll roam with the conversation. Um we'll end up running it. We usually run about an hour and then we end up cutting it into two roughly half hourish episodes. We'll start trim it down a little bit here and there just to make it flow. Uh but not too much. Mostly we keep everything and just try to find a good stopping point for episode one and episode two. Cool. >> Sounds great. >> Other than that, I don't think there's anything. There's really nothing else of note. So, any questions from you before we get started? >> No, I'm just trying to figure out how to deal with this filter in the back here. I don't know how it filters everything, but whatever. It doesn't matter. I don't care. >> Yeah, it's not. I mean, if you got a little blurred one, that is okay with us. Not a problem. >> I was just curious where it came from. >> Oh, actually, I'm going to kick that sucker out. >> Yeah, kick that guy out. That automatically joins me wherever I go. >> There we go. >> I have no idea where to change my filter, but whatever. Doesn't matter. >> Irrelevant to me. >> Okay. Well, good. Then uh we'll we'll we'll pick a better filter. Actually, I don't think we will. We'll just leave it the way it is. But that's >> exactly >> it. >> Okay. Sound levels good, Michael. >> Yeah. Sounds okay. >> Okay. I lowered my uh mic to maybe offset that. For some reason, the last one you were lower than me and I had a hard time balancing it. Uh that could be I'd gone to like I went to earbuds because I was I was remote on a couple of those. So, all right, we will dive into this one. Uh let's see. We're just going to dive right in. Three, two, one. Well, hello and welcome back. We are continuing our season of building better developers developer podcast. This is a building better foundation season. Uh part of it is we're having a lot of conversations this time around and this episode once again we will be doing an interview. We're going to be talking to Dusty Gullison in a few moments and if you don't know who he is that's okay you will soon enough. Uh for me I am Rob Broadhead, one of the founders of RB consult of developer building better developers also the founder of RB consulting where we help you ask basically assess your technology build a roadmap for success. Uh good thing bad thing that has happened to me lately um spent a week in uh Vegas just got back last night which was pretty cool. Uh it had been a while since I've been there. A lot of things had gone on. It had grown. There were a lot of cool places to go. um this place called Tap and Ash that we stumbled across if you ever want to go to a cool um cigar bar kind of thing. They are their their specialty is uh nearest green which happens to be one of my favorites. So uh it worked out really good. It happened to be on lot everybody's in town for Monday Night Football. So it was a good time. Uh and that was all great. The downside is is getting into Vegas and then leaving Vegas our everything went wrong basically good. It was nothing big, but it was just little stuff like we got, you know, you got our flight got moved, just bumped back a little bit, but then we had to go from one end of airport to the other airport. We had like luggage got moved in the wrong place. It was just, it was just like one of those things where we're so happy to be there and then we were so happy to be home. Just like I'm so happy to pass this over to Michael for him to introduce himself. >> Hey everyone, my name is Michael Malash. I'm one of the co-founders of Developer. I'm also the founder of Envision QA, where we help businesses build smarter, stronger software with custom development and rock solid testing. Uh, good thing, bad thing. Well, good thing my wife is back. She was gone for 10 days and the bad thing was I had to deal with the dogs and the animals for 10 days and that was very stressful with my workload. So, uh, I'm happy she's back and I'm ready for the holidays. >> All right. And now, Dusty, go ahead and introduce yourself. >> Hi, I'm Dusty Bellson. the CEO of E Resources and uh do I do the good thing bad thing too? Is that >> Yeah, you can go right ahead. You will be Usually people don't, but this would be awesome. We'd like to have that added. >> Yeah, I like it. It's a nice little icebreaker. Uh let's see. Uh good thing is uh you know, this has been a good year. Just reviewing the the last quarter and how this next quarter's showing up and uh you know, despite all the ups and downs, things looking good. So, uh looking forward to next year. going to have a little bit of a slingshot in there. Uh bad thing. This is when all the travel starts before the end of the year where everybody tries to squeeze in the last minute projects, resourcing and all that. Well, it's good, but it's stressful. You know, it's really at the end of the day, we only have maybe two, three weeks left of the year for all intents and purposes. >> Yeah, very much so. And that's uh yeah, I'm in that I'm this year I every year I say I'm going to take the last two weeks of December off and stuff gets just slammed in and I've had too many years where like Christmas Eve or New Year's Eve I'm I'm still like cranking a few things out just to cover some fire somewhere. And this year I am just desperately again like blocking stuff out and be like nope not going to do anything. Not going to be anywhere near you know where I can help other than like a couple status calls to just be like okay just keep things moving. But we'll see how that goes. >> Exactly. I want to dive right in because one of the things about your company that I noticed that's I think worthy of talking about is uh as you phrase this like what the story gap and why organizations struggle to explain their value and I think in particular this is or at least we've discussed this a lot in particular um service organizations I think in general but technology probably even more so anything that touches in that it seems like >> you're in one of those situations where you could you know, people can come to you and say, "Can you do this?" And you'll say, "Well, yeah, I can." And early on, you know, you struggle to, you know, you're you're really just trying to pay bills and you're surviving and you're like, "Yeah, I'll do that. I'll do that. I'll do that." And then you get to a point where you're like, "Well, that's not really what I'm intending to do." >> And so, I think this is where you step in and sort of say like, "How do you how do you tackle that? How is it that you maybe why do they struggle?" And then maybe are some things you can do to help people get unstuck with that. >> Yeah. I think uh by default in the tech field especially in digital and infrastructure things are communicated through specs right and statements of work are very spec heavy and and uh really miss the nuance where really the person at the receiving end of whatever solution you're having actually has a different expectation and so the expectation gap the way you the way we have at least successfully tried to bridge it from hey I want to have you know this integration or I want to have this workflow or using the story was a really really productive way of actually having them come back to what are your outcomes that you're looking for tell us the story what it looks like for you on your day-to-day you know I used to have a saying in our company when I was younger and stupider still learning um used to say always speak to me in bullet points you know tell me tell me exactly what you want to try just in bullet points and the problem with that is that you lost the actual nuance in it and I learned early on that it's the story that where you get the real expectation and you you can you know boil it down to a simple example of if our MSP division you know someone calls in and says something simple as this printer is not working but the real issue is he wants a great report to be printed out in time for that that's the real issue it's not the printer is working there's a time sensitivity you find out hey what are you trying to accomplish instead of the computer's work or the printer's We always tell our our team that we're customer service people first and we just happen to do technology and really learning about the person's expectations, what they're trying to do, what the end result is, what the story looks like. So when we do large big um um enterprise projects, you know, quarter million to a million dollars worth of work, um we want to look at what's the story of the organization, where are they going, what are they trying to accomplish, and what are all the characters involved, and that allows us to actually see how what we're doing and how it touches and what the real expectations are, not just plug in this widget. >> Does that make sense? >> Yeah, that that totally makes sense. Um I know one of the things that I find that um is a struggle I think especially people come out of technology world because they that very much spoke to me the whole hey speak to me in bullet points because that is very often they're like I just tell me what to do that's what I'm going to do and I'm going to go do it >> and too often I think that's that's part of what we talk about a lot is that's sort of what separates good developers from coders and and just technologists is the ability to actually solve problems >> right >> when you're working with and I guess it's on both sides of the conversation when you're whether you're working with your customer or you're you're training up your your people and your staff is how do you address them? Uh it it's I'm trying to think the best way to do it, but sort of the forest and the trees aspects of this because you want the story because you really need the why to be a Simon Synynic kind of thing. Throw that out there is you you need why you want to why do you why do you need this? you want it. >> But then there's also a need to dig into those sometimes and there needs to be, you know, it's it's a and sometime sometimes I've run into it both sides of it where it's either a technologist. It's like, well, I don't know, >> you know, I really need those details. So, they forget the story or I'm talking to somebody that's a business owner and they're like, they're telling the story. say, "Well, I really need some of these details." And they and it it hurts essentially for them to dig into them sometimes because it's not a level of detail they want to get into. So, it's how do you how do you marry it? How do you you share how those needs can both be met? >> Yeah. Uh really, I mean, any project really is two parts. It's that initial discovery and then of course the implementation. It's in a discovery where you really invest in conversations and developing the relationship with the end user. Um, we highly highly recommend actually interviewing everybody that's going to be touched by that project. Talk to them about how will this change your dayto-day? Tell me about what you do today. Tell me how long you've been here. What are the challenges you've had? It's really in those conversations and developing relationships with the end users and your your your partner that you're trying to solve a problem for that you really get the value in the implementation cuz we've come back to clients and say actually after we've interviewed everybody your discovery you don't need this. This is a shiny object you thought was solving all your problems, but the real problem is all this shadow data over here are these uh processes that need to be re-engineered and automated and you can save yourself hundreds of thousands of dollars. You know, I always think about folks that go off and still do, but used to go off and buy Salesforce thinking that they would sell more or they would do all these things. The platforms and the tools, they're really not that important. You have to start with people first and then processes and then platforms. And a lot of folks when they think they're solving a problem, they see something and go, "What we need is a CRM or what we need is a CMS or what we need is this." And actually, what you need is to talk to your folks and go, "How can they do their job better?" You know, what makes them tick? Do they understand why they're doing this? Because, you know, Simon says, right, start with why. But the key part of that statement is start with why. It's the start part. There's more to it than just the why. It's why and where and how and where we're going to end up in what is what does our company look like in, you know, next year after we implement this solution. What does it look like in three years? What do people's jobs look like? Are they being more productive? Are they are they able to handle new things? Can we add a new line to something? And there's just a lot of things. And it's really almost well everything in life. It's relationships. And uh story is a really good um vehicle to try to have those relationships, talk about them, and see how they can be affected by whatever solution you're building. >> So I got a question on that. Um so as you know, for all the years you've been doing this and uh I'm sure you've got some interesting uh stories in the trenches. What are some of the or can you give an example of you know how this a great experience getting the re uh doing the discovery and implementation and then follow that with your like worst or kind of your most challenging uh experience with pulling this information from your customer your client. Yes, I have a good and bad with one client that I could think of in my it was there's good parts to it and there's bad. Um, and it was a very large association. Um, you know, multi multi-million dollar probably about a$80 million organization and um, they had desperate service lines and when they had brought us in they wanted to talk about just something to do with their infrastructure because of our NSP side. I mean like you I mean this is the biggest problem probably in most organizations. Their RFP was not good. And I think you know if someone could start a company that just focus on coaching people to build good RFPs it would solve a bazillion problems I would think. But we got the RFP and I went down and said listen we're not going to build anything off this RFP. We we we declined the RFP and told them why. And that's been one of our best u ways to help get partners. who said, "Here's what's wrong with your RFP and why you can't actually respond to it." And so when I went down there and we did a story exercise with them over a couple days with their um executive team, walked through stuff and that was really helpful in uncovering what the real issues were underlying it. They thought it was X, but they took the time. And I think I I really challenge every person out there that's hiring a company, take the time to have a company that cares to listen to you come in and and walk you through a process. And you know, I know, you know, I I've been influenced by a lot of story brand and I've adapted some of that into a discovery process, talking about people's challenges and what their plan is, etc. But within that group, there's a subset. You talk about a bad part where that person just refused to talk because they knew change was coming and they did not want to reveal. And usually the folks at the top have a plan and then the person below them as soon as they start seeing what the questions are and start having to talk about them change is probably the worst thing for those folks because they know they will never actually make it right. um if this thing happens they have their little thief and they want to keep it. So I would say the challenges is getting people to engage and the reason why it doesn't work is when you don't have leadership at the top that makes people with engage and for some reason they didn't want to uh force that solution. Does that answer your question? It it does which I kind of have a followup because I have had a recently a similar situation to uh a project I worked on where we gathered most people were on board but of course you have your outliers that don't want to get involved and it has caused some interesting challenges. >> Sure. Do you have any tips on how to break these people out of their mold to get this information from them? Uh, or kind of maybe ease the tension a little bit to help them be more engaged even if leadership can't really like for lack of better per example, you know, lack of leadership where there just isn't a strong enough push to make people get engaged. >> Yeah. um you know the folks that don't want to engage is kind of like that see and cold pen loop where you know what we have here is people that don't listen and uh they so we get what we get right and you're going to have probably a good 3 to 5% of people that are immovable and usually I will sit down with the seauite the COO CEO or whoever the the uh champion of that initiative is in the organization I'll say listen you have two choic choices really. We either work with them and you encourage them that this is part of their job that we need to move forward or what's three choices are you replace them. Well, it's really two. You replace them. You either move forward or they get replaced. And I find in a lot of nonprofits and association the will to do that is harder because the job is a cozier job. generally speaking in some ways you know and you and that person has friends on the board and this is politics get involved so the way to overcome it though that we've had success in it is it takes time and I usually tell a seuite person hey we're not getting what we need let's not push this through as fast as you think we need to right let's take the time let me you almost have to be friend and you have to help walk the person through where, you know, what their future could look like. And part of that is really understanding what their pro their pain points are and having empathy for that because really at the end of the day, they want to know that they're more that they're valued and if they don't want to be replaced. And you go, okay, what would make you more successful at this job right now regardless of what we're doing? And you start pulling that out of them and you talk about what outcome would you like in this job? like how could what would you like to see in this department that you're working on and they're and generally speaking over time you show them that you're not a threat but you're an enabler to them. It's just like AI conversations with a lot of our clients when we come in to put in an AI solution or agentic uh automation of some sort. We stress that this is an enablement tool for you. It is not a replacement tool. The only time it becomes a replacement tool is if you resist uh some kind of you know betterment of your solution because you know especially in a commercial company seuite like you do it or you don't you know you don't be here. So I I always take it's about the relationship starting a relationship and we have some really good strategists and project managers and account managers that are really good in coming alongside and positioning ourselves as their partner not as a third party consultant. We're not the Bobs coming in and saying, "Hey, you know what? What do you say you do around here?" We come in there and say, "What can we do to make you uh happier at this job, more efficient at this job, and uh more successful so that you shine?" And so that's really the route to do. It's it's an empathy relationship side or you know, you get the seauite to to bring in some pressure. Oh, >> great. Thank you so much. Yeah, I've got talk back. I guess we'll flip back a little bit on the that whole that RFP comment. Um because I do find that a lot is that it's um it's like a crutch. It's it's really an interesting one is that like somebody will say there's a there's a combination of that is that there's I think people get a hold of like uh they'll hear ERP or CRM or something you know anything CMS, ABCYZ, it doesn't matter what they'll hear something they'll be like this is what it is. This is going to solve our problems. Y >> like you said and then you realize no it's not and there's been RFPs I don't know how many times I've seen RFPs big and small that they say this is what we want and this is what we want to build and these are the requirements and you look at them and you say >> no that is like what you say you want to build and what you're laying out is how to build it. >> Yeah. uh especially now I'm wondering if you've seen this is where I'm going with the actual question is like have you seen this because I have in the last few month have you seen this like I guess getting worse in the last 6 months to a year or something like that where people are now I'm seeing people are using AI chats to go generate rate requirements on something >> but they're not asking the right questions basically and so AI gives them answers but not the way they need to you know it's not something that's actually helpful. Yeah, I well I think a good RFP here's the hallmarks of RFPs that we'll look at seriously. One, they have a business case uh clearly articulated prior to actually asking for the solution they're looking for. So they identify the problem they they identify what the outcome they're looking for and then they have if they do not have this we will not respond. They have a budget that they want to apply to them. If you don't have a budget, you're not serious about solving a problem. And that's really where it starts. So a good business case that articulates the problem clearly where they want to see the outcome and the business. Now that's a good start. That's a start to talk when you if I you know we we actually do RFPs for other things in our company and we do that but we also want to say we would like a discovery for we want we want to see and we'll pay for a discovery. I just did it yesterday. If you don't want a paid discovery, you're not serious about the solution because there's no company in the world that will understand your RFP and be able to deliver on it without them sitting down with you and having a number of conversations getting a bit of data. And sometimes it's a little bit, sometimes it's a lot. But we really we really tell clients that you should budget anywhere from 10 to 15% for a discovery of your out of your budget for a company that you like that you think will fit the bill. And then that comes back and you do a Moscow, you know, must haves, you know, uh, like to have and don't need to have. And that's what you want back from a discovery where they price out that so you can see where you're going. But I see a ton of AI generated RFPs. A lot of cut and paste and I know because a lot of them are contradictory and they don't think it's contradictory and they really should have a either a consultant or RFP person help them develop that RFP if they're serious about making it and getting serious responders. The quality RFP is going to generate the quality of the responders that you have. And the last thing you want someone to do is giving you, "Yeah, that's your budget. We can do it." And then I just saw this with a CRM implication. Um they they brought us in to do a uh needs analysis and create an RFP for this. We sent it out and one of the vendors responded, "Yep, we can do this." And we told the client, "Do not hire them. They have not done their own discovery. They have not articulated that they understand your business need very clearly in their response." But of course, the client's like, "It's the cheapest one." I'm like, "Of course it's the cheapest one." Yeah, >> of course that's what it means. And so, um, yeah, any any company worth its salt will will invest in the RFP process and the discovery process. >> So, when you're working with these companies, have you, um, and if they don't have an RFP in place or they're still struggling to figure out >> what their problem is, do you have like a checklist or do you have um any type of documentation or suggestions to provide them? >> 100%. >> Okay. Yeah. So, >> well, we'll have companies come in and say, "Hey, can you help us with this?" They don't have an RFP. That's fine. We'll do a discovery. And what we tell them is you can take the discovery and you can have us build a RFP for you and you can shop it out. You don't have to use us, but or we can use it and respond to that said RFP. I said it's a little bit of conflict of interest, but we want you to be able to see what you truly need first because if we don't know what you truly need, we're not going to be able to build it. a discovery process if you don't have the RFP and have a company that's really good at that and presenting a a nice road map an understanding a schedule cuz there's nothing more glorious than receiving RP that actually has a Gant chart and a budget you're just like that's amazing we love these people it might not be right but they understand what what what it takes to go forward right especially on enterprise type projects that are you know half a million dollars So on the flip side of that, so if uh you're as you're advising these companies uh looking for people responding to the RFPs, how do you help them weed out the good from the bad? >> Sure. So when you're like so when we did this one project with this client where we reviewed a number of CRM vendors for them, we created a u a requirements document that tied back to the business case and to the story and said here are the requirements that need to be implemented in this solution for the CRM to work correctly. And then we actually created a a grading matrix for that for them. And so when we interviewed I don't know how many when I say we I didn't do any of this work our strategists and ams did uh when they reviewed it they could actually create a a checklist and they create notes next to each one based on the answers that they were given and so we could have a grading system and so the client was you know here this one's you know 92% capable of solving this these 8% issues have to be resolved this one's 80% this one's 70% % and so you have eyes wide open. So you might want to choose the 70% because of the 70% those are the majority of the things that are really in your Moscow are key. These are they got the must haves which are 70%. The other ones we can phase to them and then we usually have a 80 155 rule we try to tell our clients is that you want to try to get 80% of what you want done in the first uh engagement part because you're not going to get 100% perfectly done but don't make the you know perfect the enemy of good. So let's try to aim for 80%. things that are 15% of the time that you need. Let's face to those and see if they actually really are needed or you're going to accommodate some other. If it's 5% of the time, try not to accommodate education. That's where the price goes up significantly. So, we try to have that grading matrix. We tie it. Again, there's it's there's a lot of science, but a lot of art in that. And it gives people, especially our clients, a good perspective and eyes wide open of what to expect. And when that translates into a so it works out perfectly, right? And you can say, "Oh, the S so aligns perfectly with what we're expecting." >> Yeah. I think that's um I've run into it more than a few companies. It's gotten better, but especially in early years, I had to you had to educate them a little bit to say like this is part of the process. This is not this is not like a throwaway. This is not like you're going to go do this and then all that stuff is lost and you start all over again. It's like this is part of >> doing it right. Um, one of the things I've run into, I'm wondering how often you've you've run into this. That's uh I find an interesting and talks a little bit about our earlier conversation about where you go in and you sit down with people and you see what they do and what their pain points are. And sometimes that evolves as a relationship evolves. They're a little more open about like some of the pain points or some of their little, you know, side apps that they use and things like that job done. So we do the same thing is we'll do an RFP and it's a you know sort of like a straight up however we do it you just like you know one to 10 what is it do you have it and then behind that there's a then there's a secondary sort of a matrix that prioritizes stuff like you said so you're going to say like these are things we need these are things we want to have these would be nice to have one of the things we found several times is that you you trust the process and you you build it out and you get down to you know usually it's actually pretty easy I found even with dozens or hundreds of people responding you can actually get it down pretty quick with something like that to say, "Okay, we're going to go talk to Tim." Uh, but I found more than a few times where you do that and you get into the bottom list. You start getting into that short list and you get push back from the customer. They're saying, "Well, you know, well, this guy got a 90 and that guy got an 80, but we really like what the 80 is providing better." And it's which to me is like, okay, well, maybe we didn't prioritize these things right. I mean, some of it is like, I like that guy or that gal better than the other one, which I get that, but sometimes it is. It's it's at least I've seen that sometimes. I wonder if that's something you've seen as well. >> Yeah, that's that's a really good point actually. Um I appreciate that Rob because I think a lot of times in those matrixes it's the nuance uh that starts coming out. That's why we have that notes right next to whatever the grade is and we go you know this person greeted lobe on the delivery of this but I think they understand that holistic scope better based on that point. The other thing that's really great on a discovery is and when you look at an RFP that that's responded to after you've done that discovery, the ones that ask the good questions, the ones that are more questionbased responses in RFP, did you check about this? What about that are I feel like there's some shadow data over here that is should be incorporated into this solution. So that's one of the uh ways that you know while we still grade it at we give recommendations based on the holistic view like while they don't have the experience in doing x y that doesn't matter as much as them understanding exactly what you're trying to accomplish because they solve these problems. Yeah. This is where it goes back to the art and the relationship, right? If if if the vendor actually has a comprehension of what you're trying to accomplish and the story and where you're going and writes themsself into that story very well and and provides themselves as the guide to you very well, they're a better vendor at the end of the day. You know, I remember a story about I think it was in Harvard Bus Harvard Business Review about you know what's the best CEO or the best employee and it's not the A student, it's not the B student, it's the C student. the C student actually understands how to get from point A to point B quicker and more efficiently and can see through the BS and doesn't, you know, dot every dot. And the reason why is at the end of the day that they know the the long-term outcome, what will help them get to the the end point more efficiently and actually address the root issues. Whereas the A student, you know, trying to be perfect in everything >> that that's you're gonna be stuck. I think it's for the companies that are the the the grinding companies that have the grit that go through it day in day out and aren't all flashy about everything going perfect. Um they're the ones that I really admire because they actually know how to get from the point A to point Z and they know it's going to take a hard time and they they're not trying to blow smoke. They just going to grind right through there. I have a lot of respect for those. >> And that is where we're going to pause this first part of our interview with Dusty Gullison. And it keeps going. Uh it's really a great time. Uh first I want to thank him again for his time and jumping on and uh having just really it's one of these it has been a great conversation. It's one of these things that like when you uh are surrounding yourself and getting input from people that have done the things that you're you're looking to do, you get a lot of great ideas. There's a lot of stuff that comes out of it that is um especially when you let them just talk that is better than just throwing questions out there. You can hammer people with questions all day long, but there's going to be to me this is one of those where there's going to be things you don't know what you don't know. And I think some of those things come out. And there was along the way I was taking a few notes as well. Some things like, "Oh yeah, I should do that. Oh yeah, I'd forgotten about that." Um, bonus material for those of you guys out there. We talk about RFPs. We do have, and I think out, I don't know if it's available. I'd have to figure out where it's at right now, but shoot us an email at infodelveloper.com for we do have an RFP course. I think there's actually like an intro and then a more advanced one. A lot of the stuff we talk about here, uh, it's in there. spend a couple hours investing. We'll, you know, in walking through it and we would be happy to talk about it. We've got some templates and things like that. Some of the things that we touch on here, but then we also go a little deeper about, uh, how to ask some of the questions and and some areas that you need to make sure you cover when you're putting together an RFP. So, uh, it was just awesome for that to come in. So, we will do a little bit of shameless self-promotion for that as well. Uh, but let us know if you need any help with that because it is critical. It is so many projects. the RFP did not go well and that's honestly why RB Consulting exists is to correct all of the the bad starts and find ways to fix those. Uh and a developer that's why we hope you will be a better developer if you can understand these sorts of things. Thank you so much for your time. We appreciate you. Go out there and have yourself a great day, a great week and we will talk to you next time.
Transcript Segments
Uh, See? So, let me pull this. Way we do
this is um we do our we'll do a um an
intro. Basically, we'll introduce
ourselves. We'll pass it to you to
introduce yourself because it's always
easier to do that. Um
>> just be sure. Is it Gullison?
>> It's Gullison.
>> All right. Thanks.
>> And couple questions.
>> I do smoke cigars. I can stop smoking
for the interview. That's fine. Whatever
you prefer. That's good. That's totally
>> Don't know what your vibe. Some people
like that's not our vibe.
>> Yeah, we've had we've had more than a
share our share what we've been doing
whisies and tequilas and such along the
way is a cigar is not going to break our
vibe in any way, form or fashion.
>> You'll be surprised.
Some people get really weighed down
about stuff.
>> Yeah, I know. But those are not the
people we care to mess with too much.
And since we're sort of like we usually
have like a pre-show, so if any of this
shows up on the pre-show and you're
offended by it, I'm sorry, but that's
like we are we're live and let live
people here. So if you're going to have
fun,
>> do it. You know, if you're bothered by
his secondhand smoke, then well, you've
got a better computer than I do. So,
>> exactly. Good on you.
>> Yep.
>> I'm just trying to set things up here.
>> Do we do this as a uh we tend to do this
as more like a conversational kind of
thing. We'll ask some questions here and
there, but generally it's just like it
goes. uh especially with your background
and and some of the stuff. Yeah, you've
you've had enough enough experience,
enough things you've done that I have no
problem I have no worries that we're
going to get into. We'll we'll roam with
the conversation. Um we'll end up
running it. We usually run about an hour
and then we end up cutting it into two
roughly half hourish episodes. We'll
start trim it down a little bit here and
there just to make it flow. Uh but not
too much. Mostly we keep everything and
just try to find a good stopping point
for episode one and episode two. Cool.
>> Sounds great.
>> Other than that, I don't think there's
anything. There's really nothing else of
note. So, any questions from you before
we get started?
>> No, I'm just trying to figure out how to
deal with this filter in the back here.
I don't know how it filters everything,
but whatever. It doesn't matter. I don't
care.
>> Yeah, it's not. I mean, if you got a
little blurred one, that is okay with
us. Not a problem.
>> I was just curious where it came from.
>> Oh, actually, I'm going to kick that
sucker out.
>> Yeah, kick that guy out. That
automatically joins me wherever I go.
>> There we go.
>> I have no idea where to change my
filter, but whatever. Doesn't matter.
>> Irrelevant to me.
>> Okay. Well, good. Then uh we'll we'll
we'll pick a better filter. Actually, I
don't think we will. We'll just leave it
the way it is. But that's
>> exactly
>> it.
>> Okay. Sound levels good, Michael.
>> Yeah. Sounds okay.
>> Okay. I lowered my uh mic to maybe
offset that. For some reason, the last
one you were lower than me and I had a
hard time balancing it. Uh that could be
I'd gone to like I went to earbuds
because I was I was remote on a couple
of those. So, all right, we will dive
into this one.
Uh let's see.
We're just going to dive right in.
Three, two, one. Well, hello and welcome
back. We are continuing our season of
building better developers developer
podcast. This is a building better
foundation season. Uh part of it is
we're having a lot of conversations this
time around and this episode once again
we will be doing an interview. We're
going to be talking to Dusty Gullison in
a few moments and if you don't know who
he is that's okay you will soon enough.
Uh for me I am Rob Broadhead, one of the
founders of RB consult of developer
building better developers also the
founder of RB consulting where we help
you ask basically assess your technology
build a roadmap for success. Uh good
thing bad thing that has happened to me
lately um
spent a week in uh Vegas just got back
last night which was pretty cool. Uh it
had been a while since I've been there.
A lot of things had gone on. It had
grown. There were a lot of cool places
to go. um this place called Tap and Ash
that we stumbled across if you ever want
to go to a cool um cigar bar kind of
thing. They are their their specialty is
uh nearest green which happens to be one
of my favorites. So uh it worked out
really good. It happened to be on lot
everybody's in town for Monday Night
Football. So it was a good time. Uh and
that was all great. The downside is is
getting into Vegas and then leaving
Vegas our everything went wrong
basically good. It was nothing big, but
it was just little stuff like we got,
you know, you got our flight got moved,
just bumped back a little bit, but then
we had to go from one end of airport to
the other airport. We had like luggage
got moved in the wrong place. It was
just, it was just like one of those
things where we're so happy to be there
and then we were so happy to be home.
Just like I'm so happy to pass this over
to Michael for him to introduce himself.
>> Hey everyone, my name is Michael Malash.
I'm one of the co-founders of Developer.
I'm also the founder of Envision QA,
where we help businesses build smarter,
stronger software with custom
development and rock solid testing. Uh,
good thing, bad thing. Well, good thing
my wife is back. She was gone for 10
days and the bad thing was I had to deal
with the dogs and the animals for 10
days and that was very stressful with my
workload. So, uh, I'm happy she's back
and I'm ready for the holidays.
>> All right. And now, Dusty, go ahead and
introduce yourself.
>> Hi, I'm Dusty Bellson. the CEO of E
Resources and uh do I do the good thing
bad thing too? Is that
>> Yeah, you can go right ahead. You will
be Usually people don't, but this would
be awesome. We'd like to have that
added.
>> Yeah, I like it. It's a nice little
icebreaker. Uh let's see. Uh good thing
is uh you know, this has been a good
year. Just reviewing the the last
quarter and how this next quarter's
showing up and uh you know, despite all
the ups and downs, things looking good.
So, uh looking forward to next year.
going to have a little bit of a
slingshot in there. Uh bad thing. This
is when all the travel starts before the
end of the year where everybody tries to
squeeze in the last minute projects,
resourcing
and all that. Well, it's good, but it's
stressful. You know, it's really at the
end of the day, we only have maybe two,
three weeks left of the year for all
intents and purposes.
>> Yeah, very much so. And that's uh yeah,
I'm in that I'm this year I every year I
say I'm going to take the last two weeks
of December off and stuff gets just
slammed in and I've had too many years
where like Christmas Eve or New Year's
Eve I'm I'm still like cranking a few
things out just to cover some fire
somewhere. And this year I am just
desperately again like blocking stuff
out and be like nope not going to do
anything. Not going to be anywhere near
you know where I can help other than
like a couple status calls to just be
like okay just keep things moving. But
we'll see how that goes.
>> Exactly.
I want to dive right in because one of
the things about your company that I
noticed that's I think worthy of talking
about is uh as you phrase this like what
the story gap and why organizations
struggle to explain their value and I
think in particular this is or at least
we've discussed this a lot in particular
um service organizations I think in
general but technology probably even
more so anything that touches in that it
seems like
>> you're in one of those situations where
you could you know, people can come to
you and say, "Can you do this?" And
you'll say, "Well, yeah, I can." And
early on, you know, you struggle to, you
know, you're you're really just trying
to pay bills and you're surviving and
you're like, "Yeah, I'll do that. I'll
do that. I'll do that." And then you get
to a point where you're like, "Well,
that's not really what I'm intending to
do."
>> And so, I think this is where you step
in and sort of say like, "How do you how
do you tackle that? How is it that you
maybe why do they struggle?" And then
maybe are some things you can do to help
people get unstuck with that.
>> Yeah. I think uh by default in the tech
field especially in digital and
infrastructure things are communicated
through specs right and statements of
work are very spec heavy and and uh
really miss the nuance where really the
person at the receiving end of whatever
solution you're having actually has a
different expectation and so the
expectation gap the way you the way we
have at least successfully tried to
bridge it from hey I want to have you
know this integration or I want to have
this workflow or using the story was a
really
really productive way of actually having
them come back to what are your outcomes
that you're looking for tell us the
story what it looks like for you on your
day-to-day you know I used to have a
saying in our company when I was younger
and stupider still learning
um used to say always speak to me in
bullet points you know tell me tell me
exactly what you want to try just in
bullet points and the problem with that
is that you lost the actual
nuance in it and I learned early on that
it's the story that where you get the
real expectation and you you can you
know boil it down to a simple example of
if our MSP division you know someone
calls in and says something simple as
this printer is not working but the real
issue is he wants a great report to be
printed out in time for that that's the
real issue it's not the printer is
working there's a time sensitivity you
find out hey what are you trying to
accomplish instead of the computer's
work or the printer's
We always tell our our team that we're
customer service people first and we
just happen to do technology and really
learning about the person's
expectations, what they're trying to do,
what the end result is, what the story
looks like. So when we do large big um
um enterprise projects, you know,
quarter million to a million dollars
worth of work, um we want to look at
what's the story of the organization,
where are they going, what are they
trying to accomplish, and what are all
the characters involved, and that allows
us to actually see how what we're doing
and how it touches and what the real
expectations are, not just plug in this
widget.
>> Does that make sense?
>> Yeah, that that totally makes sense. Um
I know one of the things that I find
that um is a struggle I think especially
people come out of technology world
because they that very much spoke to me
the whole hey speak to me in bullet
points because that is very often
they're like I just tell me what to do
that's what I'm going to do and I'm
going to go do it
>> and too often I think that's that's part
of what we talk about a lot is that's
sort of what separates good developers
from coders and and just technologists
is the ability to actually solve
problems
>> right
>> when you're working with and I guess
it's on both sides of the conversation
when you're whether you're working with
your customer or you're you're training
up your your people and your staff is
how do you address them? Uh it it's I'm
trying to think the best way to do it,
but sort of the forest and the trees
aspects of this because you want the
story because you really need the why to
be a Simon Synynic kind of thing. Throw
that out there is you you need why you
want to why do you why do you need this?
you want it.
>> But then there's also a need to dig into
those sometimes and there needs to be,
you know, it's it's a and sometime
sometimes I've run into it both sides of
it where it's either a technologist.
It's like, well, I don't know,
>> you know, I really need those details.
So, they forget the story or I'm talking
to somebody that's a business owner and
they're like, they're telling the story.
say, "Well, I really need some of these
details." And they and it it hurts
essentially for them to dig into them
sometimes because it's not a level of
detail they want to get into. So, it's
how do you how do you marry it? How do
you you share how those needs can both
be met?
>> Yeah. Uh
really, I mean, any project really is
two parts. It's that initial discovery
and then of course the implementation.
It's in a discovery where you really
invest in conversations and developing
the relationship with the end user. Um,
we highly highly recommend actually
interviewing everybody that's going to
be touched by that project. Talk to them
about how will this change your
dayto-day? Tell me about what you do
today. Tell me how long you've been
here. What are the challenges you've
had? It's really in those conversations
and developing relationships with the
end users and your your your partner
that you're trying to solve a problem
for that you really get the value in the
implementation cuz we've come back to
clients and say actually after we've
interviewed everybody your discovery you
don't need this. This is a shiny object
you thought was solving all your
problems, but the real problem is all
this shadow data over here are these uh
processes that need to be re-engineered
and automated and you can save yourself
hundreds of thousands of dollars. You
know, I always think about folks that go
off and still do, but used to go off and
buy Salesforce thinking that they would
sell more or they would do all these
things. The platforms and the tools,
they're really not that important. You
have to start with people first and then
processes and then platforms. And a lot
of folks when they think they're solving
a problem, they see something and go,
"What we need is a CRM or what we need
is a CMS or what we need is this." And
actually, what you need is to talk to
your folks and go, "How can they do
their job better?" You know, what makes
them tick? Do they understand why
they're doing this? Because, you know,
Simon says, right, start with why. But
the key part of that statement is start
with why. It's the start part. There's
more to it than just the why. It's why
and where and how and where we're going
to end up in what is what does our
company look like in, you know, next
year after we implement this solution.
What does it look like in three years?
What do people's jobs look like? Are
they being more productive? Are they are
they able to handle new things? Can we
add a new line to something? And there's
just a lot of things. And it's really
almost well everything in life. It's
relationships. And uh story is a really
good um vehicle to try to have those
relationships, talk about them, and see
how they can be affected by whatever
solution you're building.
>> So I got a question on that. Um so
as you know, for all the years you've
been doing this and uh I'm sure you've
got some interesting uh stories in the
trenches. What are some of the
or can you give an example of you know
how this a great experience getting the
re uh doing the discovery and
implementation and then follow that with
your like worst or kind of your most
challenging
uh experience with pulling this
information from your customer your
client.
Yes, I have a good and bad with one
client that I could think of in my it
was there's good parts to it and there's
bad. Um, and it was a very large
association. Um, you know, multi
multi-million dollar probably about a$80
million organization and um, they had
desperate service lines and when they
had brought us in they wanted to talk
about just something to do with their
infrastructure because of our NSP side.
I mean like you I mean this is the
biggest problem probably in most
organizations. Their RFP was not good.
And I think you know if someone could
start a company that just focus on
coaching people to build good RFPs it
would solve a bazillion problems I would
think. But we got the RFP and I went
down and said listen
we're not going to build anything off
this RFP. We we we declined the RFP and
told them why. And that's been one of
our best u ways to help get partners.
who said, "Here's what's wrong with your
RFP and why you can't actually respond
to it." And so when I went down there
and we did a story exercise with them
over a couple days with their um
executive team, walked through stuff and
that was really helpful in uncovering
what the real issues were underlying it.
They thought it was X, but they took the
time. And I think I I really challenge
every person out there that's hiring a
company, take the time to have a company
that cares to listen to you come in and
and walk you through a process. And you
know, I know, you know, I I've been
influenced by a lot of story brand and
I've adapted some of that into a
discovery process, talking about
people's challenges and what their plan
is, etc. But within that group, there's
a subset. You talk about a bad part
where that person just refused to talk
because they knew change was coming and
they did not want to reveal. And usually
the folks at the top have a plan and
then the person below them as soon as
they start seeing what the questions are
and start having to talk about them
change is probably the worst thing for
those folks because they know they will
never actually make it right. um if this
thing happens they have their little
thief and they want to keep it. So I
would say the challenges is getting
people to engage and the reason why it
doesn't work is when you don't have
leadership at the top that makes people
with engage and for some reason they
didn't want to uh force that solution.
Does that answer your question? It it
does which I kind of have a followup
because I have had a recently a similar
situation to uh a project I worked on
where we gathered most people were on
board but of course you have your
outliers that don't want to get involved
and it has caused some interesting
challenges.
>> Sure. Do you have any tips on how to
break these people out of their mold to
get this information from them? Uh, or
kind of maybe ease the tension a little
bit to help them be more engaged even if
leadership can't really like for lack of
better per example, you know, lack of
leadership where there just isn't a
strong enough push to make people get
engaged.
>> Yeah. um you know the folks that don't
want to engage is kind of like that see
and cold pen loop where you know what we
have here is people that don't listen
and uh they so we get what we get right
and you're going to have probably a good
3 to 5% of people that are immovable
and
usually I will sit down with the seauite
the COO CEO or whoever the the uh
champion of that initiative is in the
organization I'll say listen you have
two choic choices really. We either work
with them and you encourage them that
this is part of their job that we need
to move forward or what's three choices
are you replace them. Well, it's really
two. You replace them. You either move
forward or they get replaced. And
I find in a lot of nonprofits and
association the will to do that is
harder because the job is a cozier job.
generally speaking in some ways you know
and you and that person has friends on
the board and this is politics get
involved so the way to overcome it
though that we've had success in it is
it takes time and I usually tell a
seuite person hey we're not getting what
we need let's not push this through as
fast as you think we need to right let's
take the time let me you almost have to
be friend and you have to help walk the
person through where, you know, what
their future could look like. And part
of that is really understanding what
their pro their pain points are and
having empathy for that because really
at the end of the day, they want to know
that they're more that they're valued
and if they don't want to be replaced.
And you go, okay, what would make you
more successful at this job right now
regardless of what we're doing? And you
start pulling that out of them and you
talk about what outcome would you like
in this job? like how could what would
you like to see in this department that
you're working on and they're and
generally speaking over time you show
them that you're not a threat but you're
an enabler to them. It's just like AI
conversations with a lot of our clients
when we come in to put in an AI solution
or agentic uh automation of some sort.
We stress that this is an enablement
tool for you. It is not a replacement
tool. The only time it becomes a
replacement tool is if you resist
uh some kind of you know betterment of
your solution because you know
especially in a commercial company
seuite like you do it or you don't you
know you don't be here. So I I always
take it's about the relationship
starting a relationship and we have some
really good strategists and project
managers and account managers that are
really good in coming alongside and
positioning ourselves as their partner
not as a third party consultant. We're
not the Bobs coming in and saying, "Hey,
you know what? What do you say you do
around here?" We come in there and say,
"What can we do to make you uh happier
at this job, more efficient at this job,
and uh more successful so that you
shine?" And so that's really the route
to do. It's it's an empathy relationship
side or you know, you get the seauite to
to bring in some pressure.
Oh,
>> great. Thank you so much.
Yeah, I've got talk back. I guess we'll
flip back a little bit on the that whole
that RFP comment. Um because I do find
that a lot is that it's um it's like a
crutch. It's it's really an interesting
one is that like somebody will say
there's a there's a combination of that
is that there's I think people get a
hold of like uh they'll hear ERP or CRM
or something you know anything CMS,
ABCYZ, it doesn't matter what they'll
hear something they'll be like this is
what it is. This is going to solve our
problems. Y
>> like you said and then you realize no
it's not and there's been RFPs I don't
know how many times I've seen RFPs big
and small that they say this is what we
want and this is what we want to build
and these are the requirements and you
look at them and you say
>> no that is like what you say you want to
build and what you're laying out is how
to build it.
>> Yeah. uh especially now I'm wondering if
you've seen this is where I'm going with
the actual question is like have you
seen this
because I have in the last few month
have you seen this like I guess getting
worse in the last 6 months to a year or
something like that where people are now
I'm seeing people are using AI chats to
go generate rate requirements on
something
>> but they're not asking the right
questions basically and so AI gives them
answers but not the way they need to you
know it's not something that's actually
helpful. Yeah, I well I think a good RFP
here's the hallmarks of RFPs that we'll
look at seriously. One, they have a
business case
uh clearly articulated prior to actually
asking for the solution they're looking
for. So they identify the problem they
they identify what the outcome they're
looking for and then they have if they
do not have this we will not respond.
They have a budget that they want to
apply to them. If you don't have a
budget, you're not serious about solving
a problem. And that's really where it
starts. So a good business case that
articulates the problem clearly where
they want to see the outcome and the
business. Now that's a good start.
That's a start to talk
when you if I you know we we actually do
RFPs for other things in our company and
we do that but we also want to say we
would like a discovery for we want we
want to see and we'll pay for a
discovery. I just did it yesterday.
If you don't want a paid discovery,
you're not serious about the solution
because there's no company in the world
that will understand your RFP and be
able to deliver on it without them
sitting down with you and having a
number of conversations getting a bit of
data. And sometimes it's a little bit,
sometimes it's a lot. But we really we
really tell clients that you should
budget anywhere from 10 to 15% for a
discovery of your out of your budget for
a company that you like that you think
will fit the bill. And then that comes
back and you do a Moscow, you know, must
haves, you know, uh, like to have and
don't need to have. And that's what you
want back from a discovery where they
price out that so you can see where
you're going. But I see a ton of AI
generated RFPs. A lot of cut and paste
and I know because a lot of them are
contradictory and they don't think it's
contradictory and they really should
have a either a consultant or RFP person
help them develop that RFP if they're
serious about making it and getting
serious responders. The quality RFP is
going to generate the quality of the
responders that you have. And the last
thing you want someone to do is giving
you, "Yeah, that's your budget. We can
do it." And then I just saw this with a
CRM implication. Um they they brought us
in to do a uh needs analysis and create
an RFP for this. We sent it out and one
of the vendors responded, "Yep, we can
do this." And we told the client, "Do
not hire them. They have not done their
own discovery. They have not articulated
that they understand your business need
very clearly in their response." But of
course, the client's like, "It's the
cheapest one." I'm like, "Of course it's
the cheapest one." Yeah,
>> of course that's what it means. And so,
um, yeah, any any company worth its salt
will will invest in the RFP process and
the discovery process.
>> So, when you're working with these
companies, have you, um, and if they
don't have an RFP in place or they're
still struggling to figure out
>> what their problem is, do you have like
a checklist or do you have um any type
of documentation or suggestions to
provide them?
>> 100%.
>> Okay. Yeah. So,
>> well, we'll have companies come in and
say, "Hey, can you help us with this?"
They don't have an RFP. That's fine.
We'll do a discovery. And what we tell
them is you can take the discovery and
you can have us build a RFP for you and
you can shop it out. You don't have to
use us, but or we can use it and respond
to that said RFP. I said it's a little
bit of conflict of interest, but we want
you to be able to see what you truly
need first because if we don't know what
you truly need, we're not going to be
able to build it. a discovery process if
you don't have the RFP and have a
company that's really good at that and
presenting a a nice road map an
understanding a schedule cuz there's
nothing more glorious than receiving RP
that actually has a Gant chart and a
budget you're just like that's amazing
we love these people it might not be
right but they understand what what what
it takes to go forward right especially
on enterprise type projects that are you
know half a million dollars
So on the flip side of that, so if uh
you're as you're advising these
companies uh looking for people
responding to the RFPs, how do you help
them weed out the good from the bad?
>> Sure. So when you're like so when we did
this one project with this client where
we reviewed a number of CRM vendors for
them, we created a u a requirements
document that tied back to the business
case and to the story and said here are
the requirements that need to be
implemented in this solution for the CRM
to work correctly. And then we actually
created a a grading matrix for that for
them. And so when we interviewed I don't
know how many when I say we I didn't do
any of this work our strategists and ams
did uh when they reviewed it they could
actually create a a checklist and they
create notes next to each one based on
the answers that they were given and so
we could have a grading system and so
the client was you know here this one's
you know 92% capable of solving this
these 8% issues have to be resolved this
one's 80% this one's 70% % and so you
have eyes wide open. So you might want
to choose the 70% because of the 70%
those are the majority of the things
that are really in your Moscow are key.
These are they got the must haves which
are 70%. The other ones we can phase to
them and then we usually have a 80 155
rule we try to tell our clients is that
you want to try to get 80% of what you
want done in the first uh engagement
part because you're not going to get
100% perfectly done but don't make the
you know perfect the enemy of good. So
let's try to aim for 80%. things that
are 15% of the time that you need. Let's
face to those and see if they actually
really are needed or you're going to
accommodate some other. If it's 5% of
the time, try not to accommodate
education. That's where the price goes
up significantly.
So, we try to have that grading matrix.
We tie it. Again, there's it's there's a
lot of science, but a lot of art in
that. And it gives people, especially
our clients, a good perspective and eyes
wide open of what to expect. And when
that translates into a so it works out
perfectly, right? And you can say, "Oh,
the S so aligns perfectly with what
we're expecting."
>> Yeah. I think that's um I've run into it
more than a few companies. It's gotten
better, but especially in early years, I
had to you had to educate them a little
bit to say like this is part of the
process. This is not this is not like a
throwaway. This is not like you're going
to go do this and then all that stuff is
lost and you start all over again. It's
like this is part of
>> doing it right. Um, one of the things
I've run into, I'm wondering how often
you've you've run into this. That's uh I
find an interesting and talks a little
bit about our earlier conversation about
where you go in and you sit down with
people and you see what they do and what
their pain points are. And sometimes
that evolves as a relationship evolves.
They're a little more open about like
some of the pain points or some of their
little, you know, side apps that they
use and things like that job done. So we
do the same thing is we'll do an RFP and
it's a you know sort of like a straight
up however we do it you just like you
know one to 10 what is it do you have it
and then behind that there's a then
there's a secondary sort of a matrix
that prioritizes stuff like you said so
you're going to say like these are
things we need these are things we want
to have these would be nice to have one
of the things we found several times is
that you you trust the process and you
you build it out and you get down to you
know usually it's actually pretty easy I
found even with dozens or hundreds of
people responding you can actually get
it down pretty quick with something like
that to say, "Okay, we're going to go
talk to Tim." Uh, but I found more than
a few times where you do that and you
get into the bottom list. You start
getting into that short list and you get
push back from the customer. They're
saying, "Well, you know, well, this guy
got a 90 and that guy got an 80, but we
really like what the 80 is providing
better." And it's which to me is like,
okay, well, maybe we didn't prioritize
these things right. I mean, some of it
is like, I like that guy or that gal
better than the other one, which I get
that, but sometimes it is. It's it's at
least I've seen that sometimes. I wonder
if that's something you've seen as well.
>> Yeah, that's that's a really good point
actually. Um I appreciate that Rob
because I think a lot of times in those
matrixes it's the nuance uh that starts
coming out. That's why we have that
notes right next to whatever the grade
is and we go you know this person
greeted lobe on the delivery of this but
I think they understand that holistic
scope better based on that point. The
other thing that's really great on a
discovery is and when you look at an RFP
that that's responded to after you've
done that discovery,
the ones that ask the good questions,
the ones that are more questionbased
responses in RFP, did you check about
this? What about that are I feel like
there's some shadow data over here that
is should be incorporated into this
solution. So that's one of the uh ways
that you know while we still grade it at
we give recommendations based on the
holistic view like while they don't have
the experience in doing x y that doesn't
matter as much as them understanding
exactly what you're trying to accomplish
because they solve these problems. Yeah.
This is where it goes back to the art
and the relationship, right? If if if
the vendor actually has a comprehension
of what you're trying to accomplish and
the story and where you're going and
writes themsself into that story very
well and and provides themselves as the
guide to you very well, they're a better
vendor at the end of the day. You know,
I remember a story about I think it was
in Harvard Bus Harvard Business Review
about you know what's the best CEO or
the best employee and it's not the A
student, it's not the B student, it's
the C student. the C student actually
understands how to get from point A to
point B quicker and more efficiently and
can see through the BS and doesn't, you
know, dot every dot. And the reason why
is at the end of the day that they know
the the long-term outcome, what will
help them get to the the end point more
efficiently and actually address the
root issues. Whereas the A student, you
know, trying to be perfect in everything
>> that that's you're gonna be stuck. I
think it's for the companies that are
the the the grinding companies that have
the grit that go through it day in day
out and aren't all flashy about
everything going perfect. Um they're the
ones that I really admire because they
actually know how to get from the point
A to point Z and they know it's going to
take a hard time and they they're not
trying to blow smoke. They just going to
grind right through there. I have a lot
of respect for those.
>> And that is where we're going to pause
this first part of our interview with
Dusty Gullison. And it keeps going. Uh
it's really a great time. Uh first I
want to thank him again for his time and
jumping on and uh having just really
it's one of these it has been a great
conversation. It's one of these things
that like when you uh are surrounding
yourself and getting input from people
that have done the things that you're
you're looking to do, you get a lot of
great ideas. There's a lot of stuff that
comes out of it that is um especially
when you let them just talk that is
better than just throwing questions out
there. You can hammer people with
questions all day long, but there's
going to be to me this is one of those
where there's going to be things you
don't know what you don't know. And I
think some of those things come out. And
there was along the way I was taking a
few notes as well. Some things like, "Oh
yeah, I should do that. Oh yeah, I'd
forgotten about that." Um, bonus
material for those of you guys out
there. We talk about RFPs. We do have,
and I think out, I don't know if it's
available. I'd have to figure out where
it's at right now, but shoot us an email
at infodelveloper.com
for we do have an RFP course. I think
there's actually like an intro and then
a more advanced one. A lot of the stuff
we talk about here, uh, it's in there.
spend a couple hours investing. We'll,
you know, in walking through it and we
would be happy to talk about it. We've
got some templates and things like that.
Some of the things that we touch on
here, but then we also go a little
deeper about, uh, how to ask some of the
questions and and some areas that you
need to make sure you cover when you're
putting together an RFP. So, uh, it was
just awesome for that to come in. So, we
will do a little bit of shameless
self-promotion for that as well. Uh, but
let us know if you need any help with
that because it is critical. It is so
many projects. the RFP did not go well
and that's honestly why RB Consulting
exists is to correct all of the the bad
starts and find ways to fix those. Uh
and a developer that's why we hope you
will be a better developer if you can
understand these sorts of things. Thank
you so much for your time. We appreciate
you. Go out there and have yourself a
great day, a great week and we will talk
to you next time.