ZACH

Welcome to Season 2 of the Fleet Code, a podcast brought to you by Fleetio. You may have heard a couple different voices in last season’s episode, but I’m your new permanent host, Zach Searcy, here to help you dive into the latest fleet trends, technologies, and best practices.

This season, we’re bringing you even more tips and tricks from some of the leading voices in fleet who can help guide you through some of the tougher aspects of running a multi-faceted operation. From time management to prioritizing maintenance, we’ll dig into the nitty gritty of what makes fleets tick and how you can approach some of your most challenging fleet management problems.

We’re kicking this season off with a little longer of an episode featuring one of our personal favorites: Tom Rowlings, assistant fleet manager for the City of Cambridge and just an all-around delightful guy. Tom’s the kind of manager who knows how to get stuff done when it comes to implementing new technologies in fleet – he’s been through multiple fleet software migrations and has led transitions to new platforms at a few organizations now, including the department of public works for the second largest city in Massachusetts.

I had the *absolute* privilege of picking Tom’s brain for what was probably way too long to talk about software implementation, but I’m excited to share a little bit of his knowledge and experience with our listeners, and I think you’ll start to see why Tom is basically part of the Fleetio family now.

And just a heads up – this conversation was recorded in the Fall of 2021, so keep that in mind as we reference specific dates and years. (cut to interview)

ZACH

(:48) I promise I won’t have any hard questions for you, I took all of the algebra out of it —

TOM

— Perfect.

ZACH

— So as long as, as long as we’re not doing any long division, I feel like it’s right up your alley.

TOM

Sounds good.

ZACH

Awesome. I appreciate you taking time to chat with me today, we think your knowledge on adopting new technologies in the fleet space can help out a lot of other fleet managers and operators who are out there, so to start off, could you tell us about yourself, and your background?

TOM

I always wanted to be a mechanic as a kid, you know, growing up. Although I didn’t know it, my grandfather was a mechanic. My father was not a mechanic by trade, but I got stuck 10, 11, 12 years old working in the driveway, doing stuff with him. So I’ve always had that part of it in me. I went to school for it—I went to Benjamin Franklin Institute of Technology—I got my bachelors degree there in automotive. Started out as a dealership technician working at a Honda dealer. That’s actually where I got a part time job working in a fleet, and so ever since then I’ve always gravitated towards working in a fleet.

(02:36) I started off my career in fleets working emergency services—mostly ambulances and things of that nature—and really made my way through, from emergency services both public and private. I worked for Boston EMS, I worked for private local ambulance services, and then I made my way into, you know, the public works. Call it a natural progression.

(3:26) About 4-5 years ago, I decided to further my education—get my masters degree in operations and project management, and really just solidified my place in a management role within an organization. That’s really what brought me here; I’ve been with the City of Cambridge for about a year now. That’s really the long and short of what I’ve done over the last 20 plus years.

ZACH

(05:07) Cool. Well let’s talk about – so uh – you kind of experienced fleet management from all aspects, as to, management coming to you and sort of dictating processes and now you’re up at the top, dictating processes. Tell me about your first exposure to fleet management software, or fleet management solutions, and what was your opinion of those solutions at the time?

TOM

(5:29) I had used computerized systems in the private sector in, you know, neighborhood repair shops prior to fleet… I was prepared for the computerization of it when I worked at my first fleet, and we used a program called *BLEEP* in it’s very early stages. You know, this is probably 18-20 years ago at this point. (cut from interview)

ZACH

Hey, Zach popping in here just to say… that bleep you heard? Here at Fleetio, we love to promote tech advances across the whole industry but we don’t love airing other company’s dirty laundry from older versions of their products. The rising tide of fleet technology lifts all boats, right? So good on you, bleep. You go, bleep. (cut to interview)

TOM

(6:01) And it was… It was a very cumbersome system… Throughout my whole career, I’ve actually had the experience of, in some way, shape, or form, implementing new technology and new fleet software, and that was the first of it, believe it or not. I was a mechanic at the time, I was trained on how to use *BLEEP*. Back then, even though 20 years ago is not that long ago, a lot of fleets didn’t believe in having administrative staff. That was almost viewed as a waste. So you always had a foreman or maybe it was a parts guy or even the manager trying to put in information. So, where I worked—it was for the City of Boston at the time—they wanted the mechanics to put in their own information. So you’re out there working on a truck and then you have to come and sit down at a computer and type in all the information. It was, you know, it was a difficult yet easy program.

(7:18) It was one of those programs early on, you know, prior to everything. You know, everything was locally hosted, not web-based. So the biggest challenge—that was at a time where, you know, when you click to the next screen, you couldn’t go back, you couldn’t edit. Or if there was an error, it shot you right out of it and you had to start over. So it was just… with the times, I mean, it was probably the latest and greatest at the time, but it was challenging. And because of that, my boss at the time wanted to transition to a new program.

(8:19) We switched to another program that I don’t think exists anymore, and it was probably 10x more difficult to use than any other computer program of any kind that I have used. So that lasted about three months and we went back to paper and pen as a result. Which is kinda wild.

(9:28)I left that position, so I honestly don’t know, you know, how they transitioned after that, but I know it was—for years—they stayed with paper and pen because of the bad experience.

ZACH

(9:46) They tried a digital solution and it was more complicated than it needed to be and so they figured, let’s just go analog again, um —

TOM

— Yeah.

ZACH

That’s wild. That’s insane – just – thinking, in general, from a software standpoint, to think that your software was so bad, not only then did people revert to another software, they’re like, Oh no, we’re going with just, what we know, like —

TOM

Well, a funny story about that. Fast-forward 18 years to 2020 in August, here, when I started last year: the program they were using was very similar in its complexity and so I did what I had experienced years ago firsthand; I ripped the bandaid off. We shut it down. I created in excel a basic form that was a repair order and I made 150 copies of it, and the guys started writing everything on paper.

(11:31) I went back to ground zero. It was a situation where that software was brought here to the City of Cambridge under the advice of other local municipalities, but it was never properly set up. My boss came here after that program was already sort of in motion, and he hired me after he had been here for probably 7 or 8 months, so he never got the opportunity to sorta revamp it, so that was one of my first tasks coming on board.

(12:44) We probably—I’ll say from September until we fully, you know, got things up and running in say, April, March or April—we were writing everything on paper. We were doing our inspections with paper, you know, so I had to develop those forms manually—in an excel file, but essentially manually—and start from the beginning.

ZACH

(13:58) So I would like to go back, you said, 20 years ago, you’re a mechanic, these people introduce a new system, and pretty early on it sounds like you guys realized this new system was not going to work out. Talk me through what their implementation process looked like and what were some of the difficulties, what made, what do you think led to that not working and what did you learn from it?

TOM

It’s a very short yet long answer: training. If you think about, say the year 2003, 2004, around then, wifi wasn’t a thing. I mean it was, but not what it is today. Mobile devices were not a thing; everybody still used Nextel two-ways, so that was the method of communication. There were no tablets, there were no, you know—laptops were popular, but a laptop was still tied to something; you know, it might plug in, the wifi wasn’t great, there wasn’t a router on every pole in the building type of thing like there is today. There were certainly no cell phone hotspots or anything like that, the same way there is today. So the availability of the technology was a little more limited back then and so as a result, there was the training of sitting everybody down in front of a computer, showing them how to use the program. That didn’t happen.

Nobody came up with a plan, and I don’t want to sound like I’m beating them up; those things just weren’t easily available. And one of the things—this is something, in any fleet manager’s sort of history—guys know that oftentimes in companies, both public and private or municipalities, a fleet is often overlooked. The red-headed step-child, so to speak. You know, we’re a cost center; we cost the company a lot of money—or the municipality, whatever. So therefore, when you’re spending millions of dollars in repairs to vehicles and parts and service and things like that, when you need something as a support mechanism such as software, a lot of times, it’s hard to get the funding for it. And then when you do get the funding, especially for municipalities, a lot of times things go to the lowest bidder or, you know, you have to go with what is on an approved contract list—you know, state-approved or city-approved contracts and things like that. So it can become very difficult as a fleet manager to first select [FMS], but even once you select it, to then implement it.

And if you need more than what is already there—so if the contract specifies, you know, 20 hours of training for everybody, and it turns out that 20 hours doesn’t cut it, and maybe it doesn’t cut it not because the manufacturer did a bad job, maybe you just have guys who need the extra time. A lot of times, my experience has been the training—you know, planning for the training and then the actual training, and then follow up. When you sit there and plan for it and you say, “It has to go this way, this way, this way,” if it ever deviates, people have a difficult time circling back to that. And that’s really, I think, what has been, I’ll say a “cause of failure” in implementation—is a lot of the training and a lot of the prep-work ahead of time ––

ZACH

–– Yeah, absolutely.

TOM

–– and not being able to set the proper expectations of that.

ZACH

Right. Right, I think that’s awesome. So, you’ve implemented Fleetio now, you’ve been through the implementation process with Fleetio a couple of times, you’ve experienced implementation of other softwares, how have you evolved your process throughout the years?

TOM

The way I implemented it this last time here at the City of Cambridge was I actually did not provide any group training the way I’ve seen it done in the past. In the past, what a lot of places tend to do is, they sit everybody in a room in front of a powerpoint presentation and say, “This is how you’re going to do it, and this is how you have to follow it.” Have you ever seen a mechanic take notes? It doesn’t happen. I was a mechanic; it’s not an easy thing to do. Mechanics, you know, they spend so much time on the floor, under a truck that they don’t necessarily want to sit in a conference room. They’re only there because of, you know, the bagels and doughnuts. And that’s just kind of the way it is. So my method here was, I’ll call it “lack of training.” It was cut back on the powerpoints and the “this is how you’re going to do it,” and tailor the training.

(20:51) So the implementation, I think, a lot of times, you have to base it on what your expectation of technology usage is. You know, it’s different if you’re using an iPad vs guys that are gonna sit down at a computer, ‘cause quite frankly the app and the desktop application are different. So you have to be aware of that in the way you train. So the way I see things on my computer and the guys see stuff on the tablet is different, but that’s just the nature of technology. So as part of it, I have my own tablet with the Go app. I have two separate accounts. I have my administrator account, I have a mechanic account. On the tablet, I use the mechanic account so that I can see—I can login and I see how the guys are seeing it with their permissions. So I make sure that I’m not blindly sitting in my office saying, “Hey, you guys can do this. Oh, no, you can only do that on the desktop version. It’s different.” So I tailored [the training] and I did more of a, you know, “Okay, everybody jump on in, the water’s warm. Here’s your tablet.” I showed everybody how to login and I said, “Take the next couple of days and get familiar with it. I want you to poke around and figure it out the same way—when you downloaded, you know, TikTok on your phone to look at videos—I want you to tell me how you get through it. And to be honest, five out of six of my guys are very tech-savvy mechanics, so that approach made the most sense given, you know, the skill level in technology of the guys I have. Now, the sixth guy, you know, he’s your typical older generation—and he has a smart phone, so he knows how to use things—but as he’ll tell you, you know, “My daughter showed me how to use that app or this app.” So, definitely had to spend more one-on-one time with him, but in doing so, that also—this approach, I’ve found, has worked the best because, not only did it allow me to let the guys figure things out a little bit on their own, it helped me tailor the process because instead of me saying, “I want you to do it my way,” it helped me take the feedback from the guys to then refine our overall—you know, not just using the app—but the overall process of doing repair work, work orders, how work orders are opened, who can open them, I tailored that based on all the feedback from the guys.

(26:28) I pull them in my office with their iPad and say, “Okay, this is what I’m seeing. Hey, Steve, Carlos does it this way, and it seems to work better for him. Why don’t we give this a shot? I think this is better for the process.” And little by little, we tweaked it all so that everyone’s now doing pretty much the same process, and I never sat them all down in a classroom with a powerpoint to do that, um —

ZACH

— I love that. Yeah, I love that you kind of started out with a trial period and you said, Hey basically you figure out how to use this app in a way that works for you, this is what we’re going to be doing, you have free reign, and then you revisited it at certain points to say like, what’s working and what’s not working, how can we standardize our processes now that we’ve been within it.

TOM

Yeah. And I’ll say,one of the things, sort of advice to anybody trying to implement this in that type of process, you have to make sure that your leadership, your leadership above you understands your expectations of time. That they’re not thinking, “Hey, oh, you have this new program. It’s three days in, let me see those cost savings reports and let me see where you spent all your money this month.” It’s like, you have to set the expectations and you have to have leadership that understands that it takes time to implement new technology like this. And you’re not going to get that automatically.

ZACH

(30:30) Cool, cool. So, let’s go back to the research. So when you’re vetting other products, what were some of the things you were looking for, of course cost is one of them and functionality but talk me through your research process.

TOM

So, you know, going back through my experiences, I was familiar with some names of other, you know, other softwares out there that I’ve utilized or friends in the industry have utilized, and so I took that as sort of my starting point and believe it or not, cost was not anywhere in my research equation. Cost was actually—I don’t want to call it an afterthought, but it was at the end of my research. I didn’t even factor in cost until I found the couple of softwares that would actually function the way I wanted them to. And during that process, some of the big things that were extremely important to me were the integrations with other technologies, or ability to, or willingness to. I had demos, I had looked through it, and they had, I’ll say a fair amount of similar functionality. I mean ‘cause, let’s face it, you know, most fleet softwares have similar functionalities in what the end result is, but it’s how you get to the end result and how user-friendly the interface is. So I was looking at something that had to have a mobile app, you know, given the world we were living in. So it was something that, it had to have a mobile app or a mobile app in the works, and it had to be able to integrate with other softwares, specifically either telematics or GPS softwares and things of that nature. And fuel management softwares.

(38:15) And the other thing that was key in my selection is, you know, the fact that I didn’t have to pay for like additional modules. So like, you pay what you pay and you get everything, like you get the full monty. And that was huge where — a lot of— like *BLEEP* for example wanted, “Okay, you have to pay by the amount of users, you have to pay by the amount of vehicles, you have to pay by the functionality of the system, you have to pay like.. It was like… it was menu pricing so you ended up—it was so much more costly —

ZACH

— Mhmm

TOM

— because you were choosing from the menu and it’s not the value menu over here, it’s the add-on menu ––

ZACH

–– Right

TOM

––that you end up paying so much for.

ZACH

Everything’s a la carte. (inaudible)

TOM

And ultimately, to get what I needed—I didn’t need everything on this menu and this menu, I needed a little bit here, a little bit there. I’d like to meet the person that uses all of the functionality of every computer program they have. There’s nobody out there that uses every function that you guys offer, and if there is, I want to meet them because that has gotta be a hell of an operation if they can, you know, both with manpower and everything else because there are so many functions that you guys have that it would be cumbersome to utilize all of them.

ZACH

Yeah. So you’ve talked about buy in, and how for municipalities especially, the fleet is kind of just viewed as this cumbersome, fund-needy section of the business. So cost is something you had to tackle and you had to convince them not to go with just the cheapest possible option um so, what are some of the most compelling data points that you presented? What were the things that made them understand the value of the software that you were implementing?

TOM

A couple of things on my end made it a little bit easier. One is: I found out that in Cambridge, the police department and fire department had been utilizing Fleetio separately. Neither one of them really talked to each other, so as is the case in many municipalities, you know, we’re a little segmented in that regard. So that helped convince my leadership that this was the way to go ‘cause, “Hey, this is Cambridge, they’re using it too.” So that helped.

So I went and sort of sat in front of everybody and brought it up on the screen and said, “Look, it can do this, this, and this.” One of the things was: I can give access to the individual department heads to see their vehicles, and to see, you know, when things are due for PMs, they can add issues. If the opps manager wants to download the app on his phone and he’s out in the yard with his ten guys and ten trucks and he wants to—you know, instead of sending me an email with the list, he can open the app and quickly throw in an issue for one of the trucks. And it goes right in there, so it doesn’t matter if I’m on vacation, it’s in there.

(44:20) So really convincing everybody was—a lot more of it was seeing the functionality than it was even a discussion about costs.

ZACH

(46:07) Right yeah… I feel like you’ve covered so many things that have been super helpful… Do you have any just general tips or advice for people implementing new technologies, things that you’ve learned, um, recommendations just in general?

TOM

(47:20) You know, it really boils down to the planning of it and making sure that you’re listening to people. More often than not, and I’ve experienced it first hand, this happens—it doesn’t matter what industry; in life in general—if you’re a manager that is going to say, “You’re going to do what I do and what I’m telling you to do because I’m the boss,” then you are not going to be successful in implementing even the greatest of technologies out there. You have to be open and know that, “Hey, I consider myself to be a fairly intelligent individual, but you know what? These guys that work for me are not idiots.” You know, they got to where they are because they can perform their jobs well and they’re doing a good job at it and I recognize that. So listening to them is extremely important. Hearing them out, you know, with whatever it is: “Hey, we’re going for paper and pen to technology. What are some of your requests? What would you like to see? What have you experienced? Maybe you were also a mechanic in a shop that switched technologies and things were nightmares.”

(50:24) The moral of the story is: just listen to the people that are going to be using it and don’t think that you’re the smartest guy in the room. You gotta listen to people. You won’t be successful if you don’t listen to the people. (cut from interview)

ZACH

A huge thanks to Tom Rowlings for gifting us with his knowledge on implementation. A few key takeaways from our talk you might want to keep in mind if you’re looking for new software solutions:

Number one – Find the right solution. Really do your research, take into account everything you need from it, and make sure it fits your needs and checks all your boxes, as Tom put it.

Number two – Train smart. No need for slides and donut bribes. Just pick a solid timeline for your rollout and let your mechanics and drivers move through the software at a pace that is reasonable for them.

You can keep the donuts, just don’t bribe people with them.

Number three – Get buy in by showing the functionality. Higher ups love results, so be sure to show them exactly how much time and effort can be saved with the product you want to implement.

And number four – Listen to the people that will use the software the most, and really take their feedback into consideration as you develop stronger processes.

And before you go, we have a special guest joining us again. Dominique Leupi, one of our Lead Customer Success Managers here at Fleetio, is joining us to provide an update from the last time we talked with her.

Dominique, last season you talked about a three-pronged approach to change management and we were talking recently and you said that you’ve since done some more research and that you wanted to share what you’ve learned with listeners.

Dominique

Hey Zach, yeah for sure. Definitely did a little bit more research on change management. I think we had a sense of what was successful with our customers based on, you know, our experience of, of assisting customers with rolling out the technology to their end users.

There's a company called Prosci and they are basically all things change management. Um, and they, they have, again, through decades of research, they have uncovered that if you are pairing successful change management with successful project management and successful, or, you know, solid executive sponsorship, you're six times more likely to achieve your business outcomes.

And, and another kind of model that Prosci, uh, talked about is this, this, uh, this model of individual change with components of individual change to successfully achieve an outcome.

So there's an individual element that I think is really — it's really useful. It's an acronym. It's ADKAR, which is A D K A R. Um, and the first thing is the first a is awareness of the change. So, you know, an understanding that this change needs to happen, the D is the desire to participate and support the change.

So I think like that to me is the why, like, why is this change important? Right? Like, we all want to know why we should do something. Uh, the K has the knowledge on how to change. So tell me what it is I need to do to successfully make a change. Uh, the second is the ability to implement the desired skills and behaviors.

So teach me, what do I need to do, you know, to be successful, um, and, and to change my behaviors. And then the R is reinforcement. Um, and I think, you know, that's with anything, like, is this repeatable. So if I document this, if I, um, if I ensure that this is scalable and repeatable, I am just further reinforcing the ability to sustain this change.

Right. And so if you think about those elements and, you know, change management is all about getting individuals to make change. So if you keep all of that in mind, which is, I think what we try to do with coaching customers through any sort of change management. No, it just, again, it supports that success that they're ultimately trying to achieve, whether it's, you know, increasing revenue, decreasing costs, reducing risks, whatever their desired outcomes are.

Let's figure out how we can come together to create a really solid plan to help you and your end users get there, um, and achieve that desired outcome.

Zach

Yeah, I think what you’re saying sounds like a great extension of the conversation we just had with Tom – everything from creating champions for the change to putting a plan in place and even training your team in a way that best fits their specific needs and experiences.

I can’t say for certain that Tom knows the ADKAR acronym, but I feel like he's following it even without knowing it. And, uh, as you can see, he's had a successful implementation of the product and – and I think that, um, it's just invaluable to, to not only have a plan upfront and to get that buy in from people, but then to follow up on it and see how you can replicate that moving forward. So thanks for, thanks for following up with us.

Dominique

Yeah. Yeah. Most definitely. I think, um, there's a in historian, um, Thomas Fuller and he said, all things are difficult before they are easy and it's just, sort of like common sense and intuition. And if we just kind of follow what makes sense, which is what Tom did it, it does make it easy. But now we also have like all of this research, um, and sort of a scientific approach that really can help give us the confidence to know that we're doing the right thing. We're doing the right thing.

Zach

And that’s The Fleet Code, y’all. Thanks again to Tom and Dominique for sharing their tips and experiences with implementing new technologies and changes throughout your fleet.

In case you’d like to continue your research on implementing new fleet softwares, check out the description of this episode for a link to our white paper on this same exact topic.

We’ll be back next month with another episode full of tips and tricks from other fleet vets. In the meantime, check out Season 1 in its entirety at fleetio.com slash podcasts, and be sure to subscribe on your podcast service of choice so you don’t miss any Fleet Code goodness. Be sure to join our newsletter and follow us on Twitter, LinkedIn, and Facebook to stay up to date on all things Fleetio and get access to all kinds of free tools and resources.