In this episode of Solving Problems with Technology, the team discusses how to have a successful user adoption across your organisation. From foremen, to superintendents, managers and senior executives, Corbins Electric and Nox Innovations explain how they found and celebrated adoption evangelism early in their journey.
JC: Hello and thank you for tuning into this episode of Solving Problems with Technology on HxGN Radio. I’m your host, Josh Cranfill and today we’re going to be talking about one of the most underrated aspects of digital transformation, which is user adoption. Many projects die in the user adoption stage. It’s something that is definitely you can learn about over time, and it’s something that these guys at Corbins Electric are experts in. So, in this episode, I’m speaking with JD Martin. JD is VP and partner at Corbins Electric down in Phoenix, Arizona. And Nate Unruh, who is business solutions manager at NOX Innovations, also down in Phoenix. With us is Geoff Wakefield. Geoff is Hexagon’s Xalt Solutions continuous improvement expert. And with that, guys, welcome back to the show. Thanks for joining us.
All: Thanks, Josh. We’re excited for this discussion.
JC: All right, so the topic today is user adoption. My first question, what have you learnt from this experience? Obviously, you’re through six, seven years of this now. So, anything that we can start the discussion on as far as what are the biggest lessons learnt, how do you approach end users? Not only after you’ve built something, because obviously you’ve used them, we’ve talked in previous episodes about gathering requirements, but how do you approach end users before and after you’ve actually developed something that’s going to solve a problem with them using technology?
JDM: Yeah, good question. I’m going to graduate this question. So, what we thought we were doing, gosh, six years ago—is that how long we’ve been using this? Well, we’ve been vetting it out seven years ago— what we thought we were doing is just replacing some of our paper forms with digital ones. We thought we were solving a solution, using technology or solving a problem with technology as a solution. What we realised after going down this road and having some success even within the first few months is that this was bigger than us trying to use a technology solution to solve a problem. We were actually influencing the behaviours that we wanted out of our people through the process that we have created. Well, we’ve even graduated beyond that. We’re looking at it kind of holistically now. We are actually solving problems with processes. We just happen to be using a technology platform in order to do that. So, we’re kind of looking at this holistically as like we’re solving problems. We are standardising solutions. These solutions have to be scalable. They have to be intuitively understood by the users. And then that’s when we get into like user adoption. Okay, so how do you get people bought in and start using the thing that you create? We’re actually going to get into some of those details.
NU: Yeah. And one of the things that kind of first comes to mind, too, is there’s a big, I guess, separation when you’re talking about implementing user adoption for whether you’re talking about a new process. Right. So, if I have an application or a digital solution and I’m looking to replace an outdated solution that is already in place, but we’re mostly just upgrading the technology used, adding some little things in here and there on the process, that is a different situation from releasing something over a new process, a complete redesign, and we’re changing all kinds of behaviours of these individuals. So, we’re not just changing the entry point and the technology used, we’re actually changing the behaviours and the processes.
And a lot of times when you take a look at that and, you know, when you’re doing a digital transformation, you’re oftentimes doing both, right? It’s very few times are you taking an existing process that you love and all you’re doing is converting the paper process to a digital format. Most of the time when you get down and you start designing a digital workflow over top of that, you’re changing the workflow too. You’re changing the behaviours. You know, you have new opportunities to cut some of the fat out of the process, change up who is involved, and really make sure all departments are bought in there. So, differentiating the two, as we said, like the new process and new behaviours, is really the most common one, and that’s usually where you see the biggest issues with user adoption. So, I think that’s where we’ll be phrasing a lot of the conversations we’re talking about today. But the other direction does make it a little bit more difficult or make it a little bit easier.
JDM: And at Corbins, we’ve done both. We have implemented a digital workflow through Xalt, for example, for a process that didn’t exist. The process didn’t exist at all. And we said, hey, guys, here’s a solution. Well, one of the problems sometimes with doing that is that the users or the people doing that process didn’t realise there was a problem. And they were like, oh, what’s this? What’s the thing? I thought it was fine. And then we’ve also taken processes that already exist on paper or maybe on a different platform and have redone them in a way that, you know, after gathering requirements and checking with stakeholders, is going to be more valuable to us because either streamlining or it’s scalable or standardised. So, yeah, we’ve gone through the whole spectrum. We’ve done full things with success and failures on both ends of the spectrum.
JC: So how do you—let’s go back to the beginning. How and when do you approach the actual end users and, you know, is there a standing meeting? Is there—I know you have various people who are experts in different parts of your business that are actually developing these digital workflows. But how do you actually approach those end users in each scenario that you just described?
JDM: Yeah. I think I’ll let Nate get into the details. I want to talk about the culture of Corbins, like how we even get to a point to identify that there’s a solution we want to implement is because we actually have a culture, a lean culture, that’s focused on eliminating waste and continuous improvement. So, we’re constantly challenging our people or asking them to challenge themselves on like, is there a better way to do the thing that we’re doing right now? And we ask them really simply one way to get the conversation started is, hey, what bugs you about, you know, X, Y, Z process? And sometimes people are really honest and they go, oh, my gosh, where do I start? And they go naming off all the things. Right. And some people are like, no, no, it’s fine. I like the process. So basically, somebody has the key shareholder in that process. The one who is responsible for the output of that process is usually the one going, hey, I think we need to look at this. And then we’ll get various people in the process along the way. Let’s say there’s like 50 people who would be the end users. We’re not getting all 50 together to talk about—
NU: Sure.
JDM: —what they think is the best idaea. We’ll get a few people who are, you know, they’re leaders or maybe they’re influential in some way or maybe they’re just really, really freaking good at that process. They’re the subject matter experts. Right. Or some other people have some type of skin in the game or responsible for the outcome. Those are the ones we want to focus on initially before we go to beta, which we’ll talk about later, testing out the requirements.
But, Nate, what are some of the things you do? When you get these key stakeholders in a room—
NU: Yeah.
JDM: —what does that look like?
NU: Yeah. And, you know, kind of just branching from what JD was talking about with the culture, right, that it generates immediate buy in for those individuals. Right. So, when it comes from those guys, when they’re the ones driving it at first and it’s not, hey, we’re trying to force a solution down, if the idaea comes from, say, like a president or CEO and then it’s just thrown at the operations team as a solution to their problem, you have to go do this, right?
Now, obviously, having an executive level backing will work in some scenarios. But if the operations team isn’t bought in on that, the long term user adoption plan is going to fail. Right. And so, when we’re talking about stakeholder involvement and what that looks like, that’s why that lean culture and having those guys bought in on that process in the first place is key as they’re willing to drive that and they’re saying, hey, what can I do to help support this? What does it look like for rollout? What do you need from me? Do you need guys from my team? Do you need more department involvement? How can I get involved? And all of a sudden when they’re the ones driving some of that, it makes any, you know, technology developer, it makes their job pretty easy because you’re now a team trying to solve a problem instead of, hey, here’s a solution that I want you to force down.
And so, people always ask us, hey, do you need, like, executive level backing? Not necessarily. Right. Again, it will depend on the scale and the scope of the process that you’re trying to roll out. But if you have those key individuals that and again, you know, when we talk about this, one of the benefits that we’ve seen at Corbins is Corbins has a very well structured org chart in terms of each division and each sector of our work has a key individual that is involved and then they have key individuals that they can go after. It can be a struggle when you’re saying, hey, let’s roll something out to the field support team, but that means talking to six or seven individuals and getting them, all bought in, that can be hard. So, when you have a wide org chart and you don’t have a couple of key individuals you can go to really own and champion that process, it gets difficult. So as much as you can have those stakeholders involved near the beginning, if you have too wide of a berth to roll that out, it can be difficult.
Now when we’re talking about kind of geographical and other implementations, right, we touched on this a lot in the earlier episodes on requirement gathering and how to talk to those individuals and how that all works in. But that is really the key here. If you don’t have those stakeholders involved right at the beginning of the process, if they don’t have an ownership in the requirements, if they haven’t vetted that out, if they’re not bought in, it’s going to be impossible to get any user adoption. And if you start addressing who’s going to be doing it, the stakeholders at the end of the project, you’ve already failed because you know you’re going to have to go back, look at the requirements again, and honestly start from scratch a lot of times.
JDM: Yeah. I think so. I think Nate’s develop— Oh, sorry, Josh. I think Nate’s development team can’t want the solution more than the team who is going to value that, you know?
NU: Yeah, absolutely.
JDM: It’d be the tail wagging the dog, right? And sometimes they actually see the value, Nate’s team will see the value and go, I think this is going to be—we can make a really cool solution for you guys. But if the users and the stakeholders and the champion of that process, you know, they’re like, I don’t know, it’ll fall flat because it won’t get promoted.
NU: And that’s the direction—
JC: We see it all the time. We see that all the time. You have one enthusiastic person. We actually had to get to the place where we’re saying, hey, we’re not going to write a proposal for you unless you have your stakeholder buy in and understand who those stakeholders are. Right.
JDM: Yeah, yeah.
JC: So, if I can repeat back to you, it’s create a culture of continuous improvement where you’re able to drive ownership as wide as possible, away from the even the CEO. Right? And then it’s understanding your org chart. It’s understanding who is liable for a particular process, who cares the most. And then within those organisations, who are your influential people that can actually drive that culture wide outside of even the executive understanding of perhaps the business at that level. So that’s awesome. Perfect answer.
So now that we’ve kind of gone over that, that’s the first part of adoption, is getting their buy in. But then once you actually create that workflow, which might be a week of development or it might be two months, depending on the breadth and the depth of that particular workflow, what does it look like then? How do you get users to adopt it? What is your—you know, maybe you have a user acceptance testing among a small group and then you deploy it wide. What does that look like?
JDM: Yeah. At Corbins, we’ve done it a few different ways, depending on what the process is. I mean, we have scores and scores of workflows that we’ve implemented over the last five years. But let me give you an anecdotal, a personal, anecdotal experience from our very first workflow, our very first app that we launched, which was our time collection. It was our field time collection. It tends to be one of the biggest issues in construction, collecting the time from the field and other information that goes along with that, phase codes, hours—
NU: Production logging.
JDM: —tracking. Yeah, all that log stuff that you want to get in a timely manner. So that was the first solution we worked on. So, we said, okay, how are we going to roll this out to—at that time we had 40 foremen and 150 field guys. We’re like, how are we going to roll this out to that many people all at once? Well, I didn’t know what I was doing. Like, I was in charge of implementing this stuff. Right. So, I had helped build this solution and I was responsible for rolling it out. So, I thought about it and I was like, okay, I’m going to—I asked some people, hey, if I were to do this to people in our organisation, I want to do it with a small group, a beta test, if you will. Who is somebody that I should get? You know, I’m asking superintendents, I’m asking some project managers, like who do you think would be a good person? And I was able to field that out. And it came down to this one guy, Andy.
So, Andy, if you hear this, I love you. But he’s one of our superintendents. He’s a sasquatch of a man. I mean that with—that is a term of endearment, okay? He is just a big, Harley riding, construction electrician dude. He holds an iPad in his hand like I hold an iPhone. You know what I mean? He’s got just giant mitts and he’s been with us for 25 years, maybe more now. And, you know, he’s been around. He’s a salty old dog, a Navy Seabee. Like, he’s been around.
Anyway, I said, okay, if I can get him a superintendent, and then he had I think five foremen that worked for him at that time. I brought them in to show them what we were doing. It actually ended up being a good mix of foremen because he had a couple guys that were old salty dogs like him, who were used to doing stuff with pen and paper. And then he had a couple of young foremen who basically grew up with iPads. They grew up with technology. And then a guy that was this Gen Y guy who’s like kind of in between. Yeah, he had technology introduced early in his life, but he wouldn’t be considered like an early adopter.
So anyway, brought him in and said, hey, guys, I laid out the context, hey, what we’re doing, we’re switching from using paper forms—because that’s literally what we were doing, paper forms—to using iPads, which they’d never used before. They were using laptops to get their emails and things like that. And I kind of gave them all the context. Here’s what we want to do. Showed them the workflow. Here’s how it works. Here’s what happens when you click on this. Here’s how you add people. Here’s how you spread time, all the things, right? And they were like, okay, cool. They didn’t ask a lot of questions during the thing. And then at the end I was like, okay, so what do you guys think? Questions. Concerns. What do you want to see different? How do you think it’s going to work? And a couple of guys raised their hand. They’re like, I don’t know about this, man. I could do it faster on paper. And I was like, oh, my gosh, you’re absolutely right. I didn’t fight back with them because it was true. They could fill out their times faster on paper because the paper was just a simple little matrix with boxes. Right. You list your guys down the left hand column, you list your phase codes across the top, and you plot the hours, and you’re done. I said, yeah, you’re absolutely right. I anticipated this.
I actually had a copy of one of their timecards. I redacted the information to protect the innocent. And I showed them why, although it’s faster, why this information was incomplete. They wrote down the job number. Sorry, they wrote down the job name. It was some cutesy little name that we used for the project. You know, some nickname we used for the project. No project number. They had listed the guys’ names. It was all first names. Okay, not very helpful when it goes to payroll because they have no idaea. We have we have like 15 Jose’s that work for us. Right. So, like which Jose is this? Jose H.? Okay, great. You just narrowed it down to five guys. And then they can’t read their chicken scratch. Is that a four, an eight, or a nine? I can’t tell. Well, guess what payroll’s going to end up doing. They’re going to end up guessing or getting that number to whatever it needs to be so it adds up to 40 hours for that guy for the week, right? So, you can imagine all the things, all the things. Right. And once I was able to explain that to them and show them their example of their fast timecard—which was incomplete, missing information, unreadable—they started to get it and go oh, okay. All right. I get it. I get it.
Now, fast forward a couple weeks or a couple of months. Not all of those guys on Andy’s team stayed with us. Some of them chose to leave, and that’s because they looked at this adoption of technology, going, yeah, this ain’t for me. I don’t think I’m going to be able to survive here. But what it also did was create an environment where young people who are used to technology thrived. They saw this as an opportunity to really come into their own strength.
So, what we did, we sent that superintendent and those five foremen out and had them beta test this. We had them send in their daily reports. We had them do it on paper also just so we could make sure that all the information was coming through correctly. We obviously had to test the process through payroll. That’s a different department that had to validate all the information and make sure it worked. And then once we felt comfortable and worked out some of the kinks, we certainly got their feedback throughout this process. Hey, so you don’t like that wording? You didn’t know what that meant, so you filled in something that was incoherent? Okay, let’s talk about what should it say. Because these guys, when I explained to them these guys were setting the tone for the rest of the of the company, they felt important. That’s good. And they were. So, they felt a level of responsibility for their coworkers. So that’s good. That’s what we wanted. And it helped them to put some more thought into not just for themselves but like for the guys they work with. How could this process be better?
We took it one step further, Josh. This is totally shameless. I don’t really care about this. We asked Xalt to send us some shirts, because that’s a platform we use, to send us some T-shirts. We went and co-branded them. We put our logo on them also. And they were shirts that said Mobiliser on it. And we literally gave them to anybody who had any idaea. Whether it was a good idaea that got implemented or not, we gave it to these foremen and we said, dude, wear this. You can now put App Developer on your resume. Right. And that’s how we kind of started getting buzz, where people were like, oh, yeah. Oh, this is cool. Oh, okay, great. And when they saw their ideas get put into action in the thing that they use, it solidified and entrenched them into the process, almost to the point where they started throwing out ideas that were like kind of pie in the sky type of ideas. We kind of had to like throttle back a little bit. But I was totally willing to swing the pendulum that far to get some user adoption. So anyway, that’s a long explanation of like one anecdotal example, like how we got user adoption.
JC: And I think it’s great, by the way. Geoff and I have worked in situations where, you know, there’s these large organisations, with 40 operating companies. You have a programme of continuous improvement. You’re liable to save this amount of money over the next five years. Right. So, they have different ways of gathering those ideas. If you gather ideas from people and they never hear back about their idaea that they submitted, they’ll never submit an idaea again.
JDM: Yeah.
JC: Right? And so, I think it’s actually a huge point.
JDM: Yeah. I want to talk about something else like the next step of this process, iterative process, is that’s great. You could have a totally rock solid, airtight process. It’s going to add value to the business. I anticipated where the failure point was going to be and that was going to be in payroll. For example, we roll it out to the masses, right? We roll it out to the 40 different foremen and the six other superintendents and say, here’s a process I want you to use. We’ve already tested it. We know that it works. Well, if you get just even a couple of guys who are like, no, no, this is bull crap. I don’t want to do it that way. I’m going to continue to send in my piece of paper and drop it off to payroll or send them an email with my timesheet or send them a text or smoke signal or I don’t know, however other way they want to send it in, if payroll allowed them to go around the process, not do it through the process we developed in Xalt, to continue to do the old habits, well, you just undermined the entire integrity of all the things that we’re trying to do. So, I had to also go get payroll on board, and say, hey, guys, here’s the value—and they already knew what the value is. They didn’t want to go hand jam a bunch of information into our accounting system. They wanted to be able to import it, maybe look it over and then push it into payroll. So, they were already on board. They were like, yeah, I don’t have to hand jam this stuff.
But they would end up being the gatekeepers to this. You would think it would be the foreman. No, I need the foreman to do the thing. And inevitably, that wasn’t very hard, because the thing that I wanted from them, which was to fill out their daily report, was associated with the thing that they wanted, which was this is how you get paid. This is how you submit your time, that’s an easy way to get them on board.
Payroll, though, you know, hey, guys, you’re the gatekeeper of this thing. And if you let it get undermined, the entire thing is a house of cards that falls apart, because as soon as you let one guy who you let go around the process and then other people start picking up on that, well, now we’ve got a real mess on our hands. So, you also have to go identify who the gatekeepers are, who are going to maintain the structural integrity of the thing that you’re trying to implement.
NU: Right. And so, and kind of generalising that a bit. Right. So, applying that same practise to other rollouts and stuff, those are the individual stakeholders that you really have to make sure that, they’re at the right level where they have the ownership and they have the authority to be able to empower their teams to do that. For example, that was painful for the payroll team, right? They got calls on Friday and they’re like, hey, can you put in my time for this week? I need to make sure my guys get paid. And they had to say no. Right. They’re a support team, and they had to say no, you have to send it in through this application and you have to get your time in. That’s painful for them. And if they don’t have the backing of their manager, whoever they report to or the company as a whole, that’s not going to end very well for them, right? And so, when you’re looking at the impact of a process, you have to look at each group that it looks at, you have to find, identify those stakeholder champions, and you have to make sure that they have the authority and they believe in it enough that they can enforce those behaviours to make that process a success. You hear a lot of failures of processes, and we’ve done this even where we do a beta test and then we do like a half roll out, right, where you accept the old way and you have the new way. Well, whenever you open that up to interpretation and hey, guys, you can use it when you want to, and I promise you’ll like it, they’re not going to use it, right? Humans love patterns, we love doing everything the same, right?
JDM: We love our habits.
NU: We love our habits. Right. And that’s just a human thing to do.
And so how we approach that, the other side of the coin is you can’t just flip the switch and just roll something out and expect it to work. That’s just setting yourself up for failure. So that’s really where that beta testing in that small group user adoption is so important because you get yourself, that’s the best you can do, right? You can’t half roll it out and half not. You won’t get the user or the feedback that you want. You can’t just flip the switch and roll it out and hope everyone’s happy because you’ll fail almost every time. So, the kind of tradeoff there is, hey, let’s get a small group of users, and the key here is you have to balance this based on the scale and the geographical challenges of your company.
So, if you have divisions that operate extremely different all over the place, you have to make sure that your beta test might be five or six different groups. Now, if you’re rolling a process out to a department that’s pretty siloed, they all act together, well, you might only need one or two guys to do that. So, it’s going to look different for each process that you roll out, for each situation that you look at, and how your company and org chart and divisions are set up in order to have a successful rollout. But some sort of beta testing and buy in has to take place so you avoid both of those extreme situations that’ll get you in trouble.
JDM: And a nod back to our other podcast, right, when we talk about gathering requirements was one of the topics, right? The design was one of the topics. If you gather the right requirements and your design is good with a focus on the user, the user experience, and you give people context on why this thing is important and the value that it’s going to add, and you get the key stakeholders and champions and other gatekeepers lined up, user adoption should be pretty easy. I say that—this is tongue in cheek, right? I say like, all those things are super easy to do. No, it takes some corr—
NU: It’s hard.
JDM: Yeah. It takes some coordination, that’s for sure.
JC: For sure. We’ve seen it all done wrong. Right. And so, if I mean, the hidden message is there that this is all user adoption. So, our previous episodes on solution design and gathering requirements and everything else, it actually is all user adoption because the whole thing is smoked without it. Right.
JDM: Yeah. You can have the best requirements, the best design, this process is going to add a ton of value to your organisation. And then if users don’t use it, if user adoption isn’t there, all of that was for nothing.
It’s kind of like that last link in the chain. It doesn’t matter how strong the rest of the chain is. This last link, if that’s weak and it breaks, well, now you just got a broken chain, right?
NU: Yeah. And I wanted to touch on really quick the last part of JD’s kind of story there, where he was talking about how he went with those stakeholders, right, and talked to them about the pros and cons and other things like that. That’s a really important part. When we talk about getting champions and buy in, right, that sounds easy, but a lot of times, especially if you’re trying to change a process that’s been there for a while, that can be pretty difficult. And JD mentioned a couple of things that we make sure to focus on every time. One is context and providing them the correct context. And this will change depending on your audience that you’re talking about. If you’re talking to an executive level, you’re talking about upstream, data visualisation, and what the outputs of the system are. If you’re talking to a foreman or a field individual that’s entering in this information, you’re talking about, hey, this will make it so your life is easier. You won’t have to make as many phone calls, yada, yada. Right. So, it’s the same message, same context, but you’re personalising it for the individual that you’re talking to. And that’s how you’re going to get that buy in, because, as JD said, it’s not going to be faster, but that’s not what we’re trying to solve. We’re trying to solve correct, accurate information. We’re getting the same thing every time. So, when you change the lens of how they’re looking at it, it’s a lot easier to get that buy in.
The other thing with that is the in-person training that JD was talking about. Now, this is where the scalability aspect, you really have to personalise this for your individual company. A lot of times—
JDM: I know where you’re going with this, Nate.
NU: Yeah. A lot of times what we’ve seen is for those individual champions and stakeholders we’ve been talking about, that it’s really hard to just give them that and say, hey, go for it. Right. They need to own it, they need to understand it at a core level, and that usually means drilling into them exactly what that is. Now, of course, if they’re involved on the requirements gathering and the building side of things, that’s going to be pretty easy. But if they aren’t, for whatever reason, then having that in-person, let’s discuss this, let’s go over what this is, poke it apart, challenge it as much as you can, because you know that they’re going to have to go out there and be the champion for that. So, they’re now an extension of your team, right? And so, if they’re not 100 percent on board and you don’t have that in-person training, then that’s great, because the fact of the matter is, no matter how many people you have on a process development team, they can’t go train everybody in person. And there’s going to be at least, you know, depending on the scale your organisation, 100 to 600 people to 1,000 people that will touch your application and process without having you there to walk them through it. And so, if you don’t create a web of champions and masters of these processes, the idaea is that will filter down. Right. It’s kind of a top down, trickle down approach, where you train a couple of champions and they’re able to train their next set of champions and they’re able to train their next set of champions. And if they don’t have the context to provide to those individuals, if they’re like, hey, you got to do this process, and they start asking all these questions. They’re like, hey, we were just told we had to do it. The second you start that attitude—
JDM: Yeah. Why, man? Why do we have to do this? And they go, oh, that’s just because that’s what the CEO wants, you know? Yeah. That’s not a good reason, guys.
NU: So, the second attitude starts, that’s when your user adoption starts to fail. You will always just see that. You might get some, right, that forced adoption. You might see that be successful for one to two months. But the second there’s an opportunity, there’s a chink in the armour, whatever that looks like, they’ll hit it, and all of a sudden all the work you did, right, will kind of go out the window. So small thing there, but really it’s that I guess the—and making sure that’s an important part of the process is key to that kind of success.
GW: Have you ever then had to delay introducing a new process or a change because of how user adoption was approached, meaning maybe you didn’t set some of the things up, you know, in the earlier stages and had a false start?
JDM: Oh, all the time.
NU: Yeah. Beta testing’s painful, man. I’ll tell you that right now. That’s always one of the more difficult parts of this.
JDM: Tell him the quick story about our kit tracker.
NU: Yeah, yeah. So that’s a that’s a good example. We had a kit tracker. We were creating kits of material, blueprints, all the things like that. And all of these were kitted together—
JDM: It was prefab material, tools, and information. That’s what consisted of a kit.
NU: Yeah. And so, we were tracking these kits from the modelling prefab all the way out to delivery out in the field to install. Right. And so, there was all kinds of departments involved, six or seven departments involved. We got some key stakeholders together and we felt pretty good about the concept and we went to go roll it out.
Well, this one was kind of difficult to get a beta test group together for various reasons. And so, we flipped the switch, which is exactly what I told you guys not to do. And this is a great example of we immediately felt the pain of what that looked like. One, we didn’t have the buy in with every single department that needed to implement that. And so, we saw one to two months of success, and then it kind of fell off a cliff. And what wasn’t happening is we didn’t have a feedback cycle going, and so these users were getting frustrated that they were trying to implement it and all it was doing was slowing them down. So slowly they found other avenues and they started working around it.
JDM: Some people were using it wrong because the information they needed to input, the fields didn’t exist for those. So, they were just putting them in other random fields. Some people stopped using it altogether, which created, in the flow of information, these kits were started to get built out and then they just stopped and they would be in limbo forever. And anyway, just hosing up data, wasn’t adding a ton of value. Sometimes we had the stakeholders who were totally bought in, like the department leaders were bought in, but what they failed to do is cascade the importance of the process and the context to their people, the ones who are actually be using it.
NU: Yep. And so, at the end, part of that story is we kind of gathered the troops and identified and said, okay, where did we go wrong here? And like JD said, that main identification there was we did not focus on providing that context down. Right. So, we had some initial buy in on some of these guys, but they didn’t have the context to be able to go tell their individuals, hey, this is why we’re doing this. This is how it is supposed to work and provide a more approachable feedback loop back to our team so we could go adjust some of that. And so, the second time we released that, a much different language, a much different approach on how we did that, we honestly made a few changes, but not a lot of changes. It was more just clarification on what that looks like. And the second roll out was really successful, and we had a lot of great use out of that and saw the impact right away.
GW: So, was that as a result of getting better communication driven down in that kind of requirements gathering stage, in that here’s the problem we’re trying to solve, here’s the context of the problem we’re trying to solve? Or was that just a shift that happened because your culture was evolving? Or maybe a combination of both?
JDM: Yeah. Probably both, Geoff, to be honest. Like in the culture we have of continuous improvement, yeah, we learn from that failed attempt on that kit tracker. It forced us to go back to the gatherings requiring section and kind of tighten up, you know, and became an iterative process, just the gatherings requirements side of it. So, yeah, we’re constantly learning from our failures. Failing isn’t bad. Repeating failures is bad, right? You repeat failures—you have a failure once. Okay, that was a mistake. You do it twice. Well, now it’s a decision. Right. And now you’ve got a bigger problem on your hands.
GW: And to kind of tie in into culture a little bit more too. You know, you talk about the fix, what bugs you type of approach, and getting those ideas from bottom up. As that culture has evolved, how has your user adoption and your ability to get people on board with change been affected? Has it become, you know, what’s that journey been like? As people’s ideas have been transformed into reality, has that made overcoming change a lot easier?
NU: Oh, yeah, absolutely. I mean, what we’re talking about, I mean, that’s really the key, right, is all of a sudden we have, right, our stakeholders are driving the adoption and they’re coming up with the plan of, hey, here’s the individuals that I’ve already picked out. I know who we need to do it, and I know how impactful this is going to be. So, they’re driving us on how quickly we can do that, what that looks like. It completely changes the game for not only the process development team, but also for the field. Now, we’re working as a team and it’s not, you know, our team bugging you on trying to get some in there. Right. They’re just as excited about the solution. And they had their key individuals involved early because they know that’s also a key. They’ve seen how that works. They’ve seen the impact of that. And so, they’re now in part of helping us promote that early user adoption where if you can get user adoption at the process level, no matter what you’re rolling out technology side, will be successful if everyone buys in on a process map or whatever that looks like. And so that’s why, you know, we talk about having the buy in at the requirements gathering. And that’s the key, right? You get a bunch of warriors, right? People that feel like, hey, I’m an app developer. Right. I had a key piece in that. And that’s why this is personalised and this is great. And that creates little warriors out no matter where they’re at and no matter what part of the process they’re in.
JC: Yeah. One of our friends who we’ll have on one of these podcasts here pretty soon used to say look, this is process first and technology is an enabler. So, what it means is you’re just using technology to serve the best possible process, which I think people like.
GW: Kind of with that thinking, too, you mentioned there’s people with resistance to change. You know, how do you kind of give someone that message? Maybe if they didn’t get it before, you know, typically it’s the what’s in it for me. How does that typically come across in this approach when you do have one of those resistors?
JDM: I’m happy to say, Geoff, that doesn’t happen with us. I mean, I guess we kind of ironed out all the wrinkles early on, six years ago with us. And I don’t have that problem right now. I know there are some contractors that I know who are using technology as a solution. And they are kind of being held hostage by their users, like, for example, another contractor. Their foremen are dictating the usage and the implementation. And it’s kind of backwards that way. We don’t have that problem. We got traction early on. We saw success. What we did, I think that was different than a lot of people, besides our culture just generally being good and inclusive and focus on technology and solutions and things like that is we also celebrated and focused the bright spots. Like, where there was success, we made a big stink about it. I mean, we told people about it. We put it on our internal blogs. We put it on our newsletters. We celebrated it in our morning huddles. We gave out T-shirts. Right. So, we kind of made a big deal about it and gave it some hype. And that worked.
GW: Yeah, and that’s maybe the last thing, to tie a bow on this, that we can cover. I know that you guys have had success using technology to promote technology and even now using marketing to promote your internal user adoption and to make that easier. So, why don’t you get into that a little bit? What’s been successful? What’ve you learnt? I know you have your training videos. You also now have some newer marketing videos on how these things work, why you’re deploying them, and so forth. But it seems to have been a big enabler for you, if you want to comment on that.
NU: Yeah, absolutely. So, we’ve, again, really with the training aspect of things, it’s a huge part of user adoption. Already talked about that kind of in person context building portion for the champions. But then there’s that second part of that is making sure you have continued success. Right. And six months, a year, down the road, what is that going to look like when maybe the champions don’t have that at the top of their priority list anymore? Right. You don’t have somebody checking in on that. How do you continue that? New employees, new parts of how do you ensure that they are still just as bought in and they have the same context, they understand what’s going on? And so, we’ve kind of dealt with this in a couple different ways. One, some of this stuff we kind of build into process integration on the new hire. Right. We make sure the ownership is on their managers in terms of training those new individuals on whatever process that is. So, if it’s a field process, our superintendents own that. We make sure they are continued experts in those different processes. So, whenever there’s an issue or a new employee on their team, they are the ones that can go solve it. And it’s not some high level, you know, executive that’s telling them to do this. It’s their manager, somebody that they understand, someone that understands what they’re going through. So, that’s the first part of it.
But then we also provide some other material, specifically training videos. And one of the biggest impacts is a training video should not just cover the logistics of this is how the app works, this is what it does. It also needs to cover some of that context. Now, you can’t have a 20 minute video that details all of that, so you have to find that balance of context and usability. But if you’re able to get that in a digital format that’s approachable of, hey, here’s how you use it, here’s some context, then that enables stakeholders and champions and other individuals on their team to be like, hey, see this as a starting point. Let me know if you have any questions. But providing that context in those videos, along with a kind of walk through user guide is a great way to have something that’s lasting, that will continue even when the implementation and adoption piece gets a little bit out of the priority.
JC: Have you found a sweet spot, Nate, on those, where—and obviously, there’s analytics you can probably run behind it—but what’s your sweet spot in terms of practical length of the video, depth of the video, and so forth?
NU: Yeah, absolutely. Anything over 10 minutes is an absolute no. I would say honestly—
JDM: I would say we try to keep it around like three minutes.
NU: Yeah. Yeah. It’s quick hit. So, if it’s a huge process, we’ll actually split those up now into smaller bite sized chunks. Right. So, for example, if you have, right, our CRM, we split that up into contacts, companies, opportunity entry. Right. Those are three parts of the system, but there are three separate things, and so we split them up into something that’s approachable. And the other thing is making sure that if you do have a longer video, making sure that you have time stamps for what the user will need. A lot of times they have one specific problem with the process. It’s not like, I don’t know how to do time entry. It’s, I don’t know what payroll does with this and what they’re asking me at this specific part. What does spreading phase codes look like? Okay, well, if that video is time stamped and archived correctly, then the user can jump to those positions. So even if it is a six or seven minute video, it’s split up. Right. So, there’s multiple ways to go about it. But making sure that they can get the information they need quick and accessible without drawing on for too long, then that’s the important part.
JC: That’s perfect. Yeah, it’s funny. I’ve watched many, many of your videos and I always go back and remind myself about them if I’m about to be maybe talking to another company and I need to brush up on the, you know, the context there. So, I would imagine it’s been well adopted within your group as well.
All right. Before we conclude, is there anything we missed, anything that would be helpful to our listeners, to add on to what we’ve already discussed?
JDM: No. I just want to reiterate, anybody listening to this is who’s having a problem with user adoption, find a champion, celebrate, focus on the bright spots. If you’re having a problem with user adoption, maybe you chose the wrong process to work on first? Maybe there’s something else that you can look at to implement that could get some traction and have some smaller success that you can kind of build on. But certainly, you can call and reach out to Nate or myself and, you know, ping ideas off of us.
JC: That’s a good point. So, where can people learn more about you, JD, and Corbins Electric, and Nate, more about NOX Innovations, and the services you offer?
JDM: Yeah, corbinselectric.com is our website. It just got revamped a few weeks ago. We’re proud of it. It looks pretty cool. My contact information is on there. Just go to the crew section and you’ll find all about Corbins Electric and how to get a hold of me.
NU: Yep. And on the NOX Innovations side, same thing. Website, noxinnovations.com. That’ll get you started on kind of what we’re doing and solutions we offer. And then you can find me on LinkedIn. That’s probably the best way to approach probably both of us to get a hold of us.
JC: All right. Awesome.
So, thank you, guys. These are super intuitive and super useful for us. So, JD, Nate, Geoff, thank you very much.
Please, everybody, as you’re listening, be sure to check out all the other episodes on podcasts from across Hexagon at hxgnspotlight.com. Also, on Spotify and SoundCloud. So, thank you for tuning in. We’ll see you next time.
