Myth Busting: My Techs Won't Use New Tech

Speaker A: I want you to picture a specific corner in your office. You know the exact one. Every service manager has it. It's, well, the graveyard of software. Speaker B: Oh yeah, that shelf. Or maybe that bottom drawer. Speaker A: Right. The bottom drawer where expensive, highly touted technology just goes to die. If you look closely, you can basically read the headstones in there. Speaker B: Definitely. Speaker A: Right there in the front is that digital inspection tool you bought. The one that was guaranteed to increase your upsells. Speaker B: But it actually required your technicians to perform what, 15 distinct tabs on a screen? Speaker A: Exactly. 15 tabs, scrolling through a massive drop-down menu, and manually typing out conditions just to log a single vehicle. Speaker B: A total nightmare. Speaker A: And then, over there is the massive shop management upgrade that looked absolutely flawless in the sales demo. Speaker B: Right. The one that took three agonizing months for the team to learn. Speaker A: Yeah, and honestly, navigating it still doesn't flow as well as the clunky old legacy system you replaced. Speaker B: I mean, let's be real, it never does. Speaker A: No. And then way in the back, gathering dust, are those expensive tablets from that big initiative last year. Speaker B: Oh, the ones that were abandoned by week two. Speaker A: Yeah, because the screens basically turned into mirrors the second you walked out into the sunlight. And you couldn't even unlock them if you were wearing nitrile gloves. Speaker B: It is a very crowded, very expensive graveyard. Every item sitting in that drawer represents a huge hit. Speaker A: A massive hit to the budget. Speaker B: Well, yeah. But we aren't just talking about the upfront financial cost of the software. We're talking about the lost productivity during the training phase. Speaker A: Right. Speaker B: The lost momentum in the bay, and, I mean, perhaps most damaging of all, the lost trust from your team. Speaker A: That's the real cost, isn't it? Speaker B: Exactly. Because when you force a rollout that fails, the next rollout becomes twice as hard. Speaker A: That lost trust is exactly why it's completely understandable that when someone walks into your shop and says, "Hey, there's this incredible new tool for the service bay," your first thought is, "Absolutely not. Tell me more." Speaker B: No, your very first thought is a brick wall. Speaker A: Right. You just think, "My guys won't use it." Speaker B: Yep. Speaker A: So today, the mission of this deep dive is to unpack and completely dismantle that exact sentence. We are taking aim at the ultimate service management myth, which is the idea that technicians inherently refuse to use new technology. Speaker B: And we have to start by validating that initial skepticism you might be feeling. I mean, your doubt is earned. You've lived through the friction. Speaker A: For sure. Speaker B: You've stood in the shop and seen the eye rolls from your team when a new system is announced. But we need to introduce a massive paradigm shift here. Speaker A: Okay, lay it out for us. Speaker B: It reframes the entire issue for service managers. Speaker A: Right. Speaker B: The problem was never that your technicians were resisting the technology. Speaker A: Right. Speaker B: The problem is that the technology was resisting your technicians. Speaker A: Oh, wow. Okay, that is a crucial distinction to make. It flips the blame completely from the user to the tool itself. Speaker B: Exactly. Speaker A: And if we want to prove that technicians aren't just stubbornly resisting technology, we really don't have to look very far. We just need to look out into the bay at what they are successfully using every single day. Speaker B: Just look at their toolboxes. Speaker A: Right. Let's just list off the highly technical tools they rely on without anyone forcing them. Scan tools. Speaker B: Multimeters. Speaker A: TPMS programming tools. Speaker B: Yep. Speaker A: The tire pressure monitoring system tools. Torque wrenches with digital readouts. Factory diagnostic software. I mean, you have technicians out there hooking up oscilloscopes and fuel pressure transducers to diagnose complex electrical issues. Speaker B: Which are highly sophisticated pieces of equipment. Speaker A: Totally. Speaker B: And an oscilloscope requires an understanding of complex waveforms, timing, and voltage. Speaker A: Huh. Speaker B: A modern scan tool is essentially a ruggedized laptop communicating with dozens of onboard vehicle computers simultaneously. Speaker A: Right. They aren't simple. Speaker B: Not at all. Speaker A: Technicians are interacting with more processing power in a single morning than most office workers do in a week. They are. These technicians are not Luddites hiding from the modern world. They readily, eagerly adopt tools that make their jobs faster. Speaker B: Because it benefits them. Speaker A: Yeah. And notice something about that list of tools. There was no massive management mandate to get them to use a scan tool. Speaker B: No memo required. Speaker A: Right. There wasn't a week-long training seminar on why the digital torque wrench is good for the company's bottom line. They just use them. Speaker B: Because it works. Speaker A: What they reject are tools that slow them down. You know, tools that demand they stop turning wrenches, walk over to a clunky interface, and do redundant data entry. Speaker B: Right. And when you look at the mechanics of compensation in a service bay, it becomes completely clear why they reject those tools. Speaker A: Because of how they're paid. Speaker B: Exactly. Many technicians are paid on a flat rate system, meaning they're paid per job, not per hour. For a technician, time is literal money. Speaker A: Yep. Speaker B: Their livelihood depends entirely on their efficiency and how many hours they can flag in a day. So when a piece of software interrupts their physical workflow, it isn't just an annoyance. Speaker A: It's a penalty. Speaker B: From their perspective, a clunky user interface is a literal threat to their paycheck. Speaker A: Okay, let's unpack this. I think about it like a kitchen analogy. It's like assuming someone absolutely hates cooking because they refuse to use this massive, overly complicated 20-piece food processor. Speaker B: The one that takes an hour to clean. Speaker A: Yes. They don't hate cooking. They just prefer a sharp chef's knife because it gets the job done faster. You wipe it down and you move on with zero hassle. Speaker B: That's a great way to put it. Speaker A: So if technicians aren't anti-tech, how did management get this so universally wrong? How did we end up with that graveyard in the corner office? Speaker B: Well, we arrived at that graveyard because we've been asking the wrong question from the very beginning. Speaker A: Yeah. Speaker B: Whenever evaluating a new platform, management always asks, "Will the technicians use it?" Speaker A: Which seems like a logical question. Speaker B: It seems logical, but that is the wrong filter entirely. The only question that actually matters is, "Does this technology save the technician time and effort?" Speaker A: Ah. Speaker B: If the answer is yes, adoption happens organically. If the answer is no, no amount of top-down management pressure, no amount of mandatory usage policies, and no amount of catered lunch training sessions will ever make that tool stick. Speaker A: Because it's still costing them time. Speaker B: Exactly. Speaker A: So if we know, fundamentally, that techs will eagerly use tools that save them time, we have to perform a bit of an autopsy on those failed rollouts. Speaker B: Let's do it. Speaker A: Why did the tools in that drawer fail so spectacularly? The core issue seems to be this massive incentive misalignment. Speaker B: That is the root cause, yes. Speaker A: Let's break down how this happens. A software company builds a tool and sells it to management based on high-level reporting. They show off beautiful dashboards, key performance indicators, predictive analytics. Speaker B: And management is thrilled. Speaker A: Oh, they love it. They get all these shiny benefits. But the technician is the one who is forced to do the tedious data entry to actually power those dashboards. The tech bears the cost of the labor, while management reaps the benefit of the analytics. Speaker B: And it creates an incredibly unbalanced dynamic. The technician essentially feels like administrative busy work is being offloaded onto the shop floor. Speaker A: Yeah, totally. Speaker B: You're taking a highly skilled diagnostic expert and implicitly asking them to work as a part-time data entry clerk. Speaker A: Which they hate. Speaker B: Oh, and usually without adjusting their compensation for that lost wrench turning time. Technicians can smell that unfair trade from a mile away. Speaker A: I mean, who wouldn't? Speaker B: Right. And when you combine that incentive misalignment with what we can call an environment mismatch, you have a recipe for instant failure. Speaker A: Okay, the environment mismatch is huge. Because software developers often build interfaces in a pristine, quiet office. Speaker B: With good lighting and AC. Speaker A: Exactly. They're sitting in an ergonomic chair, coding on a 24-inch monitor with a precision mouse and a clean keyboard. Speaker B: Right. Speaker A: They assume the user is in a similar state of focus. But the service bay is the exact opposite of that environment. It's chaotic, it's loud. Speaker B: Very loud. Speaker A: And you're trying to translate a smooth desktop experience to a greasy smartphone screen or like a shared, beat-up terminal sitting in the darkest, dustiest corner of the shop. Speaker B: The physical reality of the bay is just hostile to traditional software. Trying to select a tiny checkbox on a screen when your hands are covered in brake dust. Speaker A: Good luck. Speaker B: Or trying to read small font when the glare of the overhead bay lights is hitting the screen. These are physical barriers that developers rarely account for. Speaker A: Oh, and then there's the dreaded mandate. The classic memo that goes up on the bulletin board. "Starting Monday, everyone must use the new system." Speaker B: The fastest way to kill morale. Speaker A: Truly. Nothing builds immediate, deep-seated resentment quite like a mandate that isn't backed by clear personal motivation for the user. Speaker B: Absolutely. Speaker A: But the part of this autopsy that really stands out is how management typically measures the success of these failed tools. They track things like logins per day. Speaker B: Which is such a flawed metric. Speaker A: I have to pause on that. Measuring success by logins per day. Isn't high usage sometimes just a symptom of high frustration? Speaker B: Often, yes. Speaker A: That's like measuring a surgeon's success by how many times they had to stop and wash their hands during an operation. High frequency does not mean high value. Speaker B: What's fascinating here is that the gap you just identified is where most software dies. It is the vast, treacherous canyon between a clean, controlled demo environment and an unpredictable production environment. Speaker A: Right. Speaker B: Because in a sales demo, clicking through five screens to log a vehicle looks impressive. It looks robust and thorough. Speaker A: Yeah, the manager sees it and goes, "Wow, look at all this detail." Speaker B: Exactly. But in the production environment, clicking through five screens while holding a heavy, oily part is infuriating. Speaker A: Oh, I bet. Speaker B: When management tracks logins or time spent in the app, they're tracking the tool's demands on the technician. They're not tracking the tool's value to the technician. Speaker A: They forget to ask the only metric that matters. Speaker B: Right. Speaker A: Did the technician's day actually improve? Did they flag more hours? Okay, so if we know what fails, how do we evaluate what actually survives the bay? We need a new filter. Speaker B: We do. Speaker A: And according to our deep dive into the sources, there are three unbreakable rules for evaluating new technology in a shop environment. Let's walk through them. Rule number one: Remove a step, don't add one. Speaker B: Which goes right back to the friction we just discussed. Speaker A: Exactly. If a digital inspection tool requires the tech to snap 12 distinct photos, navigate a drop-down menu, check 40 mandatory boxes, and type out three paragraphs of notes before they are allowed to pull the next car in. Speaker B: That's a massive tax on their time. Speaker A: Yeah, it really is. Speaker B: A bay-proof tool has to eliminate a step they already despise. For example, typing repair order notes on a sticky, unresponsive keyboard is universally hated. Speaker A: Yeah. Speaker B: Walking all the way across the shop to a shared terminal just to look up a simple torque specification breaks their physical momentum. Speaker A: I can see how that's annoying. Speaker B: If a tool eliminates those specific bottlenecks, it gets used. It gets used because it solves a real physical problem they care about in that exact moment. Speaker A: Okay, let's unpack this a bit because I am struggling with rule number one. Speaker B: Okay. Speaker A: If the cardinal rule is that we are only ever removing steps for the technician, no more checking boxes, no more typing out long paragraphs, don't we lose the vital structured data that management actually needs to run the business? Speaker B: That's the fear, yes. Speaker A: I mean, a service advisor suddenly has nothing to tell the customer if the tech doesn't type it out. Management goes blind. There has to be a trade-off between the manager's real need for data and the technician's absolute need for speed. Speaker B: Right. It is a totally valid concern, but the solution isn't to force the technician to do it. The tool itself must be the bridge. Speaker A: The tool itself. Speaker B: Yes. The technology has to do the heavy lifting of data collection and formatting automatically in the background. Speaker A: Okay, how does that work? Speaker B: Well, the ideal technology observes or listens to the technician's natural workflow, captures the necessary information, and then translates it into the structured reports that management and the service advisors need. Speaker A: Ah, so it's happening passively. Speaker B: Exactly. The AI acts as the translator, so the technician doesn't have to act as the secretary. Speaker A: Okay, that makes a lot of sense. The burden shifts entirely to the software. Let's move to rule number two. The learning curve must be measured in minutes, not days. Speaker B: This is critical. Speaker A: Because technicians have cars stacked up in the lot. They are quite literally on the clock. If you hand them a tool that comes with a thick user manual and requires a two-hour block of training in the break room before it's even slightly useful. Speaker B: It's dead on arrival. Speaker A: Dead on arrival. The scan tool we mentioned earlier is the gold standard here. You plug it into the OBD port under the dashboard, you read the codes, you get immediate value. Speaker B: Right. Nobody had to go to a seminar to figure out the basic value proposition of a scan tool. Speaker A: Exactly. Speaker B: And that immediacy is critical to adoption. If a technician doesn't see a tangible benefit on the very first attempt using a new tool, they will mentally discard it. Speaker A: They'll just go back to their old way. Speaker B: Yep. They do not have the luxury of spending a week getting used to something that slows them down. Speaker A: Makes perfect sense. Speaker B: And that leads right into rule number three. The tool must be built for the actual environment. Speaker A: Right, which we touched on with the grease and the lighting. Speaker B: But it bears repeating because designers consistently forget the acoustics. The bay is incredibly loud. Speaker A: Oh yeah. Speaker B: Compressors are cycling on and off, pneumatic impact wrenches are going off, radios are playing. Speaker A: It's a chaotic soundscape. Speaker B: So any technology that demands library quiet surroundings for voice recognition or clean hands for precise pinching and zooming on a glass screen is fighting a losing battle against physical reality. Speaker A: Okay, so now that we have these three rules, remove a step, minute-long learning curves, and build for the environment, we need to look at what this actually looks like in practice. Speaker B: We need a concrete example. Speaker A: Right. A tool designed to pass this brutal test, and more importantly, the exact playbook for how a manager should introduce it. Let's look at a platform called OnRamp, which is built specifically for this environment. Speaker B: OnRamp is a perfect case study for this. Speaker A: So how does it pass rule number one, removing steps? Well, OnRamp utilizes AI to actually write the repair order report. Speaker B: Without the tech typing anything. Speaker A: Exactly. It also physically briefs the technician before they start a job. It entirely eliminates those long walks to the terminal to read up on the customer complaint. It takes data entry off their plate. It doesn't add a single box to check. Speaker B: And looking at rule number two, the learning curve being minutes instead of days, OnRamp is designed around an eight-minute setup. Speaker A: Eight minutes. That's nothing. Speaker B: Right. There is essentially no complex software interface for the technician to learn. It relies on natural voice interaction. You don't need a software tutorial to learn how to speak. Speaker A: That's true. Speaker B: The technician simply asks a question out loud, something like, "What is the torque sequence on the cylinder head bolts for a 2018 F-150?" Speaker A: And it just knows. Speaker B: Yes. The AI instantly fetches the data and answers them directly through their earpiece. A technician who has never touched artificial intelligence in their life can be noticeably more productive on their very first repair order. Speaker A: That's wild. And rule number three, built for the environment. This is where the engineering gets really clever to solve that acoustic problem we talked about. Speaker B: The background noise. Speaker A: Right. They use what they call a brain button. It is a physical, tactile Bluetooth button that clips right onto the technician's shirt collar or lapel. Speaker B: Placing the microphone right on the collar is how you beat the environment mismatch. Speaker A: Because of the proximity. Speaker B: Exactly. By having the microphone mere inches from the technician's mouth, combined with modern noise-gating technology, the system isolates the voice and tunes out the background noise of the air compressor. Speaker A: And it is completely glove-friendly. You just tap the physical button to talk and tap to pause. It's designed to be 98% hands-free. Speaker B: Which means they keep turning wrenches. Speaker A: Yep. You only ever need to pull out a screen if you need to snap a photo of a broken part for the customer or, you know, pull up a complex wiring diagram where a visual is actually required. Speaker B: Makes sense. Speaker A: The rest of the time, the phone stays safely in a pocket, away from the grease and the drops. Speaker B: It is a prime example of designing for the reality of the bay, not the idea of the bay. Speaker A: Absolutely. Speaker B: But having a piece of technology that passes the three rules is only half the battle. The rollout playbook is where most managers snatch defeat from the jaws of victory. Speaker A: Oh, the rollout. Speaker B: There is a very specific, almost counterintuitive method for introducing a tool like this. The fundamental rule of the rollout is, do not mandate it. Demonstrate it. Speaker A: Okay, so the playbook suggests you give it to your most open-minded tech first. You don't automatically go to the shop foreman. You go to the tinkerer. Speaker B: Every shop has one. Speaker A: They really do. It's a technician who is already messing around with ChatGPT on their lunch break. The one who is always downloading new apps to find a slightly better way to route a belt or track their hours. Speaker B: That's your guy. Speaker A: You hand them the brain button and let them use it on just one single repair order. Give them 15 minutes to let the tool prove itself. No massive manuals, no pressure from management. Speaker B: And then, you completely change how you track success. Forget logins. Forget time in app. Speaker A: Right. Speaker B: You ask one question: Did that tinkerer flag more hours that day? Speaker A: You measure the outcomes, not the inputs. Speaker B: Exactly. But the true genius of this rollout strategy is what we can call the ultimate test. Speaker A: Okay, what's that? Speaker B: Once that tinkerer has used the tool for a few days and gotten comfortable with it, you do something unexpected. You take the tool away. You just walk up and ask for it back. Speaker A: Okay, wait, really? That seems so incredibly backward. Why would you take away a tool that is actually working? Speaker B: It seems backward, but it tells you absolutely everything you need to know about the software's value. Speaker A: How so? Speaker B: If you take the button away and the technician just shrugs and goes back to typing on the old shared terminal without a second thought, the tool failed. Speaker A: Ah, because they don't miss it. Speaker B: Exactly. It added no real visceral value to their day. But if they push back, if they get defensive and start arguing with you because going back to the keyboard suddenly feels like a punishment, then you know you have a winner. Speaker A: Precisely. Speaker B: You have fundamentally improved their workflow and they recognize it. Speaker A: Here's where it gets really interesting though. Let's pause on that rollout strategy for a second. Speaker B: Sure. Speaker A: Bypassing the shop foreman or the senior master tech feels like a recipe for a turf war. Speaker B: It does. Speaker A: If you just hand this powerful new tool to the tinkerer of the shop, the early adopter, and then basically walk away, what happens to the hierarchy? What if your senior master tech, the guy who sets the cultural tone for the whole shop, dismisses the tool simply because the new kid is the one using it? Doesn't management need to get the senior guys on board first? Speaker B: Yeah, that's exactly what I'm asking. Speaker A: It is a very common fear for any manager who is used to leading by directive. You want the leaders to lead. But peer adoption is infinitely more powerful than any top-down rollout you could ever engineer. Speaker B: Because it's organic. Speaker A: Because of shop psychology. That senior master tech is fiercely protective of their time, their efficiency, and their flagged hours. Speaker B: Right. Speaker A: That's their pride and their paycheck. Speaker B: When they look over to the next bay and see the tinkerer consistently finishing complex diagnostic jobs faster, avoiding the terminal, flagging more hours, and walking out the door earlier. Speaker A: Oh, I see. Speaker B: Curiosity is going to override their stubbornness. It happens every single time. Speaker A: Envy kicks in. Speaker B: Exactly. The master tech will not tolerate being left behind if there is a genuine, proven advantage sitting right in front of them. You aren't giving up control of your shop. You are actively leveraging shop psychology to drive adoption organically. Speaker A: Wow, that is the ultimate show, don't tell strategy. Envy is a much better motivator than a memo. Speaker B: Any day of the week. Speaker A: So what does this all mean for you, the listener? The next time you are sitting in your office looking at that drawer full of abandoned tablets and expensive software. Speaker B: It means it's time to re-evaluate. Speaker A: Yeah. It means the next time you catch yourself saying, "My techs won't use new tech," you need to stop and challenge your own assumption. Your technicians will not use bad tech. Speaker B: They won't. Speaker A: They will not use technology that was designed to make the front office's life easier at the expense of their own wrench-turning time. They will not use technology that adds clerical friction to an already difficult, physically demanding job. Speaker B: It's just human nature. Speaker A: But if you bring them technology that respects their time, speaks their language, and is built to survive the gritty reality of their service bay, they will adopt it faster than you can imagine. Speaker B: Because when the technology works for them instead of them working for the technology, the resistance just vanishes. Speaker A: It disappears. Speaker B: And as we wrap up this deep dive, I want to offer you one final thought to chew on. Speaker A: Lay it on us. Speaker B: We just talked about measuring the true value of a physical tool by using that takeaway test, physically removing it to see if the technician actually fights to keep it. Speaker A: Right, to see if they miss it. Speaker B: Think about the profound simplicity of that metric. Now, what if you applied that exact same takeaway test to your own management processes? Speaker A: Ooh, interesting. Speaker B: If you stopped requiring a specific daily morning meeting, or if you completely eliminated a routine paperwork step tomorrow, would anyone in your shop actually complain? Speaker A: Probably not. Speaker B: Or would your shop's overall productivity suddenly go up? Sometimes the greatest friction in the service bay isn't the new technology you were trying to introduce. It's the invisible legacy processes we continuously force our teams to navigate.