Episode information
Episode Number: 47
Date: August 12, 2024
Duration: 20:11
Host: Justin Deese
Website: JustinDeese.com
Contact: Justin@JustinDeese.com
Co-Host: Kristen Deese
Website: KristenDeese.com
Contact: Kristen@KristenDeese.com
Summary
In this episode, we delve deep into the critical importance of implementing effective systems in your business to ensure growth and efficiency. Justin & Kristen discuss how to successfully document and roll out these systems, engaging your team in the process and overcoming common pitfalls. Learn the power of the “trust but verify” approach and discover strategies to gain team buy-in and ownership for seamless system integration.
Takeaways
1. Importance of Systems: Systems are vital for preventing bottlenecks and ensuring consistency in operations.
2. Team Engagement: Engaging your team in the process and explaining the “why” behind systems boosts buy-in and morale.
3. Avoiding Pitfalls: Avoid common mistakes, such as not explaining the purpose behind system documentation.
4. Trust but Verify: Implement a process of continuous check-ins and adjustments to ensure systems are followed and effective.
5. Influencer Strategy: Use positive team influencers to beta test new systems before rolling them out company-wide.
Chapters
1. Introduction to Systems – 00:04
2. The Importance of Systems – 01:00
3. Engaging Your Team – 02:30
4. Common Mistakes – 04:00
5. Trust but Verify – 06:50
6. Influencer Strategy for Implementation – 09:10
7. Continuous Improvement – 11:00
8. Conclusion and Call to Action – 16:00
Keywords
Plumbing, HVAC, Air Conditioning, Electrical, Contractor, Freedom Blueprint Podcast, Justin Deese, Kristen Deese, When Your Business Partner is Your Spouse, Business Systems, Team Engagement, System Implementation, Trust but Verify, Leadership in Home Services, Documenting Processes, Effective Communication, System Efficiency, Customer Service Systems, Accounting Systems, JustinDeese.com, KristenDeese.com
Transcript
Justin Deese (00:04.366)
Hey, and welcome to Freedom Blueprint podcast. I have an amazing co-host hanging out with me today who also happens to be my beautiful wife; Kristen Deese. And what are we going to talk about today? Well, we're going to pick up our conversation on systems that we started before. So this is, I guess you could call it your systems 2 .0 conversation. I like it. I like it. I like it. Again, to recap, systems are
I don't think important actually describes it. I don't think that's a strong enough word. Vital. Yeah. I mean, if you want to not be the bottleneck in your business, if you don't want to be, really the one holding your company back, you have to have systems. they allow you to get out of the way. Yep. Let's create some consistency and reduce your frustration and everybody's not everybody. That's not a good word.
there's people who feel like systems makes everything too constricting and too tight and too many rules. And that is a hundred percent. Not the case actually. yeah, people, people do think that. And I, and I think that, I mean, you can make it like, if that's the case, then do you give enough flexibility in your systems in order to allow your team to make good decisions? I don't know. Well, yes. And systems is not micromanaging. Right. Ooh.
That's a mic drop right there. That was pretty good. Yeah. I mean, systems really allow you to do that whole trust but verify thing, right? Like if you, you, they know what to do and they know how to do it. And now you can just check in and make sure that they're, they're doing, what it is they're supposed to do. So, well, so last time we talked about like what different kinds of systems there were and when do you start writing systems and that kind of stuff. But,
Coming up with a system and documenting it is only half of the project. The other half is you have a team of people more than likely, and you need them to actually do the system that you have just documented. And sometimes if the system is already going well and you're just documenting it, okay, that's one thing. But let's say it's a new system or it's a change to something that you guys are already doing. Now you have to get your team on board and fired up and willing to...
Justin Deese (02:30.094)
follow the system the way that you want it to be done. And that in itself can be quite a challenge. No one on your team is going to get fired up about a system. About a change. About a change. Yeah. So I know that, okay, so I always like to talk about mistakes that we or I made in our business. And I think this is a good one. I think the timing is good. So I remember we were starting to write systems and
trying to really figure out what does it look like for us not to be the bottleneck and growing was not the problem. It was getting out of the way that was the problem. And I remember going to the team and going, okay, I need you all to write down everything that it is that you do. Cause in my head, I knew the why behind it, but I didn't tell any, like I didn't share the why or the vision of what I was trying to accomplish. And man, the mood in that room after I did that, it was so flat cause they're like,
my God, we're getting fired. Yeah. So, and kind of a little bit of backstory on that would be to utilize your team who's already doing the systems in order to help you write them. Cause sometimes it feels like just this huge elephant that you're trying to eat when it comes to writing down your systems. But if you already have people who are doing systems and they're doing them well, you just don't have them documented, then lean on them to just document what they're doing. But.
If you come up to them and say, I need you to write down everything that you're doing and you don't tell them why you're doing that, then yes, they're going to think they're making the training training manual for their replacement. Yes. And morale is going to not, it's going to tank. So don't do that. Yeah. Don't do that. We should have renamed the podcast of what not to do, what not to do. Learn from our mistakes. Yes. but once we explained the why and we, and we got them involved as part of the process,
Then we backed it up a little bit to where we took one step at a time. Cause just like for us writing all these systems is like a huge ordeal. You go up to Smite and you say, start writing down everything that it is that you do. That gets a little weird. So if you're like, I need to know how you, whatever, let's say answer the phone and then they can start answering like, okay, great. What do you say to the customer? Hopefully you already have all that figured out. But if you don't, that's how you start doing it. And if you're a little bit bigger of a company and,
Justin Deese (04:53.678)
you might not necessarily know in that just like you're saying, you might not actually know how to do what it is that they're doing as well as they do because they're doing it in a house like booking a call or, you know, certain ways to use computer software or whatever. Even from a technical standpoint, there's a lot of times that we don't know all of the ins and outs and every step in order to be able to document it. So you can lean on team for that. It makes it a little
a little bit less of a project when you're going on team for it. And with a good delivery to your team will come buy in and with buy in comes ownership. So if you, if you do a good job of the Y and then you go in and you explain, and now they know, and now they own this project, it's amazing. Sometimes what you get, you'll get like this really nice binder with really nice borders on it. Like it just let your team.
Let your team own it. Yeah. That's, that's always a fun thing is when you're, when your team kind of gets it and then they go to do that kind of stuff to see they put a little oomph. Yeah. Cause they own it. Yeah. one of the things that we talked about in the last, pike or the last recording on systems was a, how do you know where to start with writing your systems? And we talked about, if it's something like a frustration or a pain point.
But there's actually another place that you can start too in a little bit more of an organized fashion, which would be take your job descriptions. We actually call them team member commitments because we like to fancy it up a little bit. Well, and who wants a job? Yeah. And so part of the team. Yeah. Which that's a whole nother episode that we didn't talk about that. But the team member commitments slash job descriptions list out all the things that we want that position to do.
So just start at the top of that and write a system for everything that's on there. And then when you take all of the written systems and the team member commitment and you put it together, now you have a nice little training manual for anybody who would be new coming into that position. So that is another way to tackle the systems project, just one position and one task at a time.
Justin Deese (07:04.91)
So really what we're talking about though in this episode is implementation of the system and getting people to do it, especially if it's new or it's changed in some way. So if you've got a new system that you're trying to roll out to your team, how are you going to ensure implementation? I'm asking you. you're asking me. So it really depends. So there's a good chance that I'm not going to be a part of that process. There's team members, but.
For me, a lot of times it's check -ins, right? Like you're gonna have a huddle about it and you're gonna go over whatever it is that that new system is. So I don't know. Give me an example. Okay, a new system would be whatever the folder packet that they leave behind on the job. job packages. Okay, so job packets. So we roll out the job packs. First of all, we meet with our leadership team to go over what it looks like. Okay, here's the job packet. What goes in it?
Okay, here's what goes in it. When, so we write the system for that too. So you gotta have the job packet. You gotta have what goes in the job packet. And when does it, what jobs does it go to? Right, if you run a drain call, we don't actually give customers, and I know some people are like, well, you should, we don't. We do it for bigger jobs. But then from that point, then the leadership team buys in and then they give those jobs on every, so like for instance, a water heater goes out or an HAC system.
those packages are with them. And then we just do check -ins on it just to make sure, hey, do you understand? Do you get the why? When we do happy calls, we will ask the customer, did they leave you a job package today? Yes, they did. If the answer is no, then that goes back to the manager and the field manager is gonna kind of circle back with that team member. So it goes down to trust but verify. So it is a really good tool for the company. It's a really good tool for the technician.
Cause it allows them to kind of introduce new things to the customer without being, you know, salesy a lot of times on the install team, they don't, I mean, sales is like, so it's a tool, right? So, and typically if, if someone's not using a tool that helps their life, like makes their job easier, it's cause they either don't understand it or they don't buy in. So normally the, the field manager will go back and figure out which of the two it is. Like if you don't understand it, we need to do a better job of explaining it.
Justin Deese (09:29.646)
if you don't buy in, then it probably comes back to a better, better job of explaining it as well. Yeah. So there's the difference between delegating and abdicating, which abdicating was a relatively new word when our coach introduced it to us. But I understood the concept once she explained it. And that would be, okay, cool. We wrote this system, we gave it to our employee and we literally turned around and walked away, assuming that it was done.
Check that off the list. We are done. They are good. We don't need to do anything else. And that's really not how delegating works and delegating and systems and documentation. I think all of that goes hand in hand. So for me, when I implement a system, typically I'm implementing it in either customer service or the accounting department, because that's my lane, right? And so obviously with accounting, we accuracy is like a huge thing. Like we have to be accurate in accounting.
And so when I'm introducing a new system to somebody, I will show them how to do it. I will sit with them while they, while they do it, while they watch. And then I'll sit with them while they show me that they know how to do it. And then for a certain period of time, I will go back through pretty much everything that they have done and check it, checking it for accuracy. If it is all accurate for a couple of days in a row, then I'll back up and I only check about 50 % of it. Right.
I do that for another few days. If that is coming back accurate, then I'll back up and I'll check 10 % of it. And I will continue to check 10 % of it. That's the trust, but verify that is like literally the steps on how you implement trust, but verify. And if I ever get to a point where I'm finding mistakes in that 10%, then I crank up the number of times that I'm the number of items that I'm auditing basically. And I'm talking with the employee and trying to figure out what it is that could be causing those mistakes that were not happening before.
and it might highlight a training opportunity or maybe they're stretched too thin or whatever, who knows what it could be. But it is a very systematic approach to implementing a system. Systematic approach to managing systems, got it. But really from any like that Trust But Verify, it's not at all about saying, okay, well, I've written the system and I told them how to do it. Now we should never have to talk about this again, because that's not how it goes. But that's a lot of times how we initially
Justin Deese (11:50.51)
You know, throw out a system and, and then we're like, wait a minute. Why isn't anybody doing this? We wrote a system for it. So systems are a lot like your. Really mission or training or anything like there's very few things in business that you do once and you can put in a drawer and leave it there. Under fact, I can't think of really maybe the, your logo design until you redesign it, but most things are living, breathing documents. And so with systems.
if you write a system and now you have your team member operating that system, you got to fine tune it. There's a good chance that you forgot something, especially if you're not the one that runs the system. And when you have your team member run that system for the first time, there's a good chance that they forgot something because they might be a little uncomfortable and have never done this kind of thing before. So as you go through this process, you want to keep checking in. And even once you get through that phase of you've been doing the trust, but verify,
you know, one -on -ones or whatever you're doing with your team to connect with them. That's another good time to bring up, you know, Hey, how's, you know, how's this? Well, you know, this one thing would have made it a heck of a lot easier. Great. Let's do that. Yeah. Having, having an open line of communication with your employees so that they can come to you and say, Hey, just so you know, either the system that was working current, like isn't working anymore or something's changed, or we need to be able to tweak it. obviously you take feedback like that.
with a grain of salt, right? Like you want to really, you want to take in what they're hearing. Like you want to listen to what they're saying and you want to evaluate whether or not it's worth making a change to your system. One, sometimes things become, you know, obsolete or whatever, and we don't necessarily realize it, but hopefully in that, in that 10 % trust, but verify check, you'll be able to find that. And then in terms of implementation, let's say, okay, we did this with our time clock feature. We changed the way that we wanted everybody to do time clocks and,
We did a whole bunch of research from the management side, but we don't clock in and out every day. Right. and so what we did is before we rolled it out to the entire team, we picked two, we call them influencers. They are the super positive. Everybody listens to them. if they're in a good mood, everybody's in a good mood. People most of the time, most of the time positive. And so we taught them how to, we basically beta tested the new time clock system on them.
Justin Deese (14:13.358)
And so we had them go out, use the new time clock system, give us feedback, solve problems, make changes. We did that with those influencers before we rolled it out to the whole team. So we basically broke it as many times as we could before we gave it to everybody else. And then when we gave it to everybody else, it was a much more smooth process because we weren't breaking the system with everybody. We were only doing it with those couple of people.
that creates confidence that your employees trust your managers, that they know what they're doing. If you roll out a system and it's broken and you don't know it, then the next time you roll out a system, they're going to be like, they're going to grumble about it. Even that system, there's a good chance that they're not going to tell you what's broken about it. They're just going to grumble about it. You're like, well, why didn't you tell me? You didn't ask me. Wait a minute. But I will say if you don't have a group of leaders in your
and your organization that you're using to help you roll things out and test it. I'm saying you should do that. It's made a big impact on our business. For the team members that get to be a part of that group, they love it. They love it because they know they're on the front end of stuff. They know what's coming down the pipeline. And then once it's rolling out, they're already fired up about it. So when we announced it, they're like, woo, yeah, this is great. And they're like, yeah, let me show you guys how to do it.
Yeah. Yeah. You're usually going to want to pick the people who are excited about change, who like technology, who like to learn new things. not the ones who are, who are struggling with using that button, that button, push that button. So yeah, implementation is definitely harder than getting it documented for sure. yes. And like anything else, it's a habit. It becomes, second nature. So once you're getting good at documenting,
then you start to get good at implementation. And then once you roll some systems out that work, now your team starts to buy in. So it's this really cool snowball effect of, well, wait, now it's making their lives better. Cause let me tell you, your team, if you're rolling things out to make their life better, they will do it. Yeah, for sure. Sometimes they have to understand the why and things like that. But I think they will definitely, definitely do it. So, so here we go. System 2 .0 implementation.
Justin Deese (16:31.822)
I think that's all I have to say about that. That's all I got to say about that. So yes, that's kind of a two part. We wanted to break it up. We didn't want to be taking your time for, for however long I don't even know how long spent, but thank you guys so much again. If you have any systems you would like kind of our input in, or if you need some help writing systems, we do have some forms on the website, but feel free to reach out. We're here to help. It's the whole point of the podcast. So,
Reach out, let us know if we can help you. Sounds good. All right, we'll see you guys.