Hey folks, Phil Zito here and welcome back. Well, today's post is going to be about how to execute training in the office. I mean, we've all done it right, we've all gone to that training session, you know, the Omni Bus Safety/building automation/sales/HR training session, that's all crammed into an hour. We show up, we get some stale bagels, maybe some donuts, maybe some coffee, sit down, and literally, if you're a senior tech, as you're walking in the room, ops manager pulls you aside and says, “Hey, Phil, I need you to teach something technical today.”
I laugh because it's happened to me so many times, and it's like, what am I supposed to teach? I don't care what you teach them, just teach them something technical. That is how a lot of training in the office goes down. That is it, it is literally an afterthought, once a month, right after safety training, but before the HR kind of updates, and you get to cram in about 15 minutes, maybe go through, “Hey, they just released this update, and it's got this capability that changed the PID Loop and how it tunes,” or something like that.
Yeah, so that is kinda, in a nutshell, how most office training goes on. But it doesn't have to suck like that, it doesn't have to be a giant waste of time. As much as I would love you all to buy our training and go through our training courses, they are the best in the market, bar none, I realize some of you aren't going to do that. Some of you are still going to try to create your own training in the office.
So, that is what we're going to guide you through today. Here is my three-step process, and it is ridiculously simple. Didn't say easy, but it is ridiculously simple. If you implement this process, you will be executing effective training in the office.
Why would you want to execute effective training in the office? Why would you care to invest in training? Well, training has a lot of positive outcomes. First of all, it reduces callbacks and slippage. So, if you have ever experienced a customer calling you and saying, “Ah, you know, ever since you upgraded the software, we're leaking water and….” Having training, on one hand, can help you be able to identify that, there's no way that could happen, we didn't touch that.
There's not just technical training, there's training on communication, there is training on upselling, there is training on document management. You know, folks hear me say training so often, and they associate that with technical training.
Now, as I look at our course library, we have a project management course, it's amazing. We have a sales course, it's amazing. We have a troubleshooting course, it's amazing. You know how many of those we sell, not a whole lot. Everyone wants to buy the technician training, they want to buy the installer training, they want to buy the programmer training. Then I ask these folks, I literally sit on the phone with some folks and this is how that goes:
Phil: “What are the issues you have?”
Them: “Callbacks to jobs, troubleshooting, not being able to upsell, not being able to project manage.
Phil: “But you bought the technician training?”
Them: “Well, yeah, because we need to train our technicians.”
Phil: “But you said your problems are this….”
So, I'm challenging you here. Do not get pigeonholed into the fact that you're an ops manager, you're a senior tech, so what you need to train people on is ops, or senior tech stuff. It doesn't have to be like that. You can train on other things, and like I said, I'm going to show you how, and it's ridiculously easy.
So, the benefits are reduced slippage/reduced callbacks, the benefits are increased employee retention, the benefits are the ability to execute more tasks on a job. You know, if all your folks know how to do is integrate BACnet cards from rooftops, and set up VAV boxes, then you're probably not going to be doing tier-four data centers, you're probably not going to be doing advanced corporate headquarters, you're probably not going to be doing large, level one trauma hospitals. You’re just not going to be doing that stuff if your team isn't experienced enough to do that.
Alright, so enough, I hope by this point, you've decided to give this training thing a go, or at least consider it. So, how do you do it? Well, here’s my 3-step process:
- Analyze roles
- Train
- Have a feedback loop
Analyze Roles
First thing you need to do is have job descriptions for everyone. These job descriptions cannot be those fluff job descriptions that are like, 40 years’ experience with Tridium N4, and it hasn’t even been out for 40 years. It can't be silly stuff.
We want to actually figure out what the person is supposed to do and what actions they take are going to have a direct impact on whatever we're trying to impact with them. That's where a lot of job misalignment comes from. If your technicians do not project manage, then we should not have their roles and tasks for their job aligned with project management. It doesn't make sense; they're not going to impact project management. The project manager may manage them, but they are not going to impact project management.
So, doing a job task breakdown from a solid job description is going to really help and it's going to create a baseline from which we can measure current capabilities, current profitability, in forms of revenue per employee, slippage per employee, margin per employee, time to execute, etc. We can start to measure all these things, and we can align them to our job task breakdown.
We can't just break down every task because all tasks are not created equal. Wiring up an exhaust fan, while definitely important, is probably not as common as working on VAV boxes, or bringing on fan coils, or working on rooftop units. You have to understand what kind of projects you do, then we have to identify the key tasks that are going to be executed on these projects. Whatever these key tasks are, we need to execute these key tasks near perfectly.
As we start to develop training and execute training, we really have to continue to challenge ourselves to think outside of, okay, maybe we want to focus on designers, maybe we want to focus on graphics, maybe we want to focus on programmers, don't just focus on technicians. I'm going to focus on technicians for this post because this is an easy example.
So, we’ve done job task break down. What does this look like? It looks like grabbing a job description, pulling out the fluff, then we identify our key tasks. We identify the metrics that we're going to measure. What are we going to measure? Are we going to measure revenue per employee? Are we going to measure margin per employee? Are we going to measure time to execute? Are we going to measure slippage per employee? What are we going to measure?
I usually recommend two financial measurements, and one time measurement. Those tend to do well. Some good ways I like to do things are revenue and margin. Revenue is going to tell us how much revenue did this person generate, and then margin is going to tell us how profitable this person was.
Now you can go for slippage in lieu of margin, because sometimes the margin is going to be just all over the place, and slippage will show kind of a better difference between how much that person was estimated to produce and how much they actually produced. You have positive and negative slippage, so you can measure those.
So, it's up to you, whatever you want to do, just have two financial measurements, one that shows overall execution, and one that shows profitability. Then we want to have a third measurement, and that's going to be time related. How long did it take for this person to execute said task?
This is why I highly recommend using task codes. I've done so many posts about task codes, about these are the job task codes you should use, and this is why you should use job task codes. Suffice to say, job task codes are you know, if you're installing, you have a task code for that. If you're designing you have task code for that, if you're programming, you have a task code for that. You can get as granular as you want, as long as you have a system to track it.
The important point is, once you get past six or seven task codes, the ability of people to just pencil whip their task codes on their timesheets increases dramatically. So, if you have three to five task codes, you have a high likelihood to adherence to people actually filling out those task codes. That is if you communicate the value. You need to help them WIFM, what's in it for me, right? So, you have to identify the WIFM of these task codes so that people will actually put them in.
So, we have our tasks code because we have our key tasks identified. We've done a job task matrix/job task breakdown, and we are going to identify these tasks and assess these tasks. We're going to baseline them, not just from a financial and time perspective, but from a performance perspective.
This can be done a lot of different ways. You can use an online skill assessment. We provide online skill assessments completely free, like you literally have to buy nothing from us. You just sign up, take it, and it's your time. If you buy something from us great. If not, you get free assessment. So, I encourage everyone to do that.
That being said, you can create your own assessment. How do you create your own assessment? You basically take the tasks that you have identified, and you think of three to five questions per task. These questions need to be clear. It needs to focus in on only one set of knowledge. So, for example, you don't want to ask them a question on something that assumes they know something else. You want to try to focus in on the key thing you're trying to assess their knowledge of.
Once you've done that, once you've built out this assessment and you’ve build out three to five questions per task. The reason why you want three to five is so that not everyone is getting the same question, but you also want them to have at least one to three questions for a task. That way, if they just mess up on something, you have another opportunity for them to answer that question, so it basically gives you a more realistic look at what they know.
For example, our assessment has 49 domains. Each domain has about 20 to 40 questions in it. So, it’s a pretty broad draw that we're able to pull from as far as questions. As your people answer the questions, if you see everyone getting a question wrong, then you need to evaluate the wording of the question. You need to evaluate the optional answers to make sure that it's not an invalid question.
Okay, so at this point, you've done the job task breakdown, you've done a key task identification, you started to measure what success looks like, both in two financial forms and one time-based form. Now you've assessed their skills, and you've ranked their skills, typically on a numeric ranking.
Now what you have to do is, you need to figure out, are we going to be moving to healthcare work? Are we going to be moving to data center work? Are we going to be doing analytics? Are we just going to be doing commercial like plan and spec bid work? What do I think we're going to be doing?
One of the best ways to determine this is if you have a healthy sales pipeline, you can look at the 18-month outlook and see kind of what is stacking in your sales pipeline. That should give you an idea of where your business is trending. So, once you understand where your business is trending, you can then say, okay, commercial office space: a lot of VAV boxes, a lot of air-cooled chillers, a lot of packaged rooftop units.
Okay, what do I need to know? I need to know how to line out my subs, need to learn how to do good point-to-point, some basic BACnet integration, some quick template graphics. The key with commercial real estate is fast and no slippage, like university work, healthcare work, tier four data centers, CDC labs, stuff like that, that stuff is forgiving of slippage, to a point. I mean, if you totally hose your design, yeah, you're going to get bent over, but if you make a little bit of slippage on those, those costs usually are high enough revenue that you can absorb.
The lower you are on the contracting tier and the closer you get to plan and spec work, typically the lower your margins are, and thus as lower margins you have lower tolerance for slippage. So, not that I advocate slippage, I don't advocate slippage. Ideally, we should strive for no slippage, right? We shouldn't have positive slippage either.
Slippage, by the way is when your costs, in the case of positive slippage, are under the estimated cost, so you're profiting. Negative slippage is where your costs are over the estimated cost. The reason why you wouldn't want positive slippage is because if you had positive slippage, that means that there was slack in your estimate, and if you're in a highly competitive bid environment, then having positive slippage means you could be overpriced, and you could be losing bids. So, hence why was sometimes we want to avoid positive slippage, right? We want to have our margin targets to where the market will tolerate our margin targets.
Train
We want to look at the project, and if it's a very low margin, very simple project, then we want to aim for perfection on our task execution. How do we aim for perfection on our task execution? Processes. So in that case, we're going to be training processes, where you're going to train processes, we're going to bring people in, we're going to drill them on VAV box installs, we're going to drill them on BACnet interfacing, we are going to drill drill, drill, drill, and what does drilling look like? It looks like creating scenarios, buying a VAV box, like an 8–10-inch VAV box, putting it on a pallet, rolling it out and having people drill VAV boxes till their fingers bleed, I mean not literally, but you get the point.
Keep doing it and doing it until it's second nature. As you go and perfect these processes, you're going to execute your processes and you're going to execute them well. You're going to have reduced slippage, better execution, you're going to be getting off jobs faster, and thus you have more capacity to work.
Now let's say that you're primarily a service organization. In that case, what we are going to do is we're going to train knowledge and theory skills, because oftentimes troubleshooting is dependent on your depth of theory skills.
So, do I understand psychometrics? Well, for example, if you get called on a troubleshooting call, and someone says the heating is causing condensation, if you understand psychometrics, and you realize that something else must be going on, understanding that theory immediately rules out a bunch of potential issues. If you heat air, then you are actually decreasing the relative humidity, all things considered, of the air. So, understanding theory and having theoretical knowledge and understanding how systems work for service people is very valid.
How do you know what theory you should focus in on? I'm glad you ask. Well, this is where we want to do a key task identification, we want to do a job task breakdown, and we want to actually analyze our service logs. We want to understand like, what is going on with our service logs?
So, we want to really figure out what is going on with the service logs, what common things are happening, and then based on what's commonly happening, we can say, “Okay, we're typically running into these service issues. Let's train on those.”
So, what would that look like? What that would look like is, you would say, this is the problem. Then, you would identify the root causes, and then based on those root causes, you would assign a probability to those root causes. If you're having XYZ issue, and then maybe 80% of the time, it's cause A, maybe 10% of the time it's cause B, and 10% of the time it's cause C, then we want to focus in on that cause A and all of the knowledge associated with determining that cause A. So thus, we train people that way.
Personally, I like to do a mind map, and that is a good way to do that kind of training. You basically flowchart it out and you train people on the individual pieces of the flowchart. So, those are kind of two different looks at training approaches you can take, but all of that is dependent on you implementing the third step.
Have a Feedback Loop
The third step is really where the rubber meets the road. Anyone can analyze a job task breakdown; anyone can create a skill assessment. I mean, it takes a lot of time, but you could do it. We have probably 1000 plus hours sunken into our skill assessment, but if you have the time and resources, you could do it.
Anyone could train. I mean, you know, training, it requires a certain temperament, but you can find people you could train. Where the things start to fall apart is the feedback loop. Okay, we analyze the roles, we do our key task analysis, we analyze our skills, we train, and then we put the people out in the field, and we never talk to them again.
Sadly, that's how things really typically happen. The issues with not having a feedback loop are that we don't know what's effective and what's not effective. If we have a feedback loop, and remember the data points I talked about, right, we should have two financial indicators, one time indicator, and a skill assessment. So, two financial indicators, typically revenue and profit, our time to execute, and our skill assessment. We should then, on a quarterly basis, and a health of the business review, we should analyze those metrics. We should have green, yellow, red metrics.
So, if we're looking for, you know, we have slippage, maybe we're taking that as one of our financial measurements, slippage. We're saying, Okay, we want to reduce slippage by 2%. Well, 2% slippage, that's maybe our green, that's our ideal goal. 1% slippage would be our yellow, red would be no slippage reduction, or more slippage, so, like an increase in slippage, that would be a red indicator.
Okay, so now that we have this green, yellow, red indication, we have essentially what's called a score chart, and this is what the large companies do, they do what's called score charting. That’s our health index, and that's one thing, but then we have to combine that with time to execute, because it's one thing to look at financials. If I look at financials and I see slippage has significantly increased, and my time to execute has decreased significantly. What does that tell me?
That probably tells me that my people are rushing through, and maybe I trained them how to execute VAV boxes really fast, but maybe that training really didn't stick or there was a key mistake in that training. Because of that, they're rushing through, executing these boxes, but they're doing them wrong, and they're getting callbacks, hence the slippage. Or maybe my team is executing really well, but there is some sort of material estimating issue, or a design issue, and that is causing slippage now. My team is executing, and the problem is we're executing more and more, so we're realizing the ramifications of those poor design choices, or the poor programming. We're seeing those faster, and thus, more slippage, because my team is executing faster.
So, we have to kind of think through the causation of what's going on. So, we say, Okay, we have those two things, right, time to execute, financial metrics, and then comes the skill assessment. Let's say, we figure out that the slippage is indeed being caused by the team executing. Well, how do we know where the issue is with executing?
Well, we reassess them and we see what has improved and what hasn't. If we reassess, let's say, once again, the VAV box example. So, we're having tons of issues with VAV boxes, and we reassess them, and they still don't know what the high and low port are on the air sensing for the VAV box. Okay, they don't understand high and low. Then we find out, sure enough, we look at the slippage and we look at the callbacks, and it’s because people have high and low flipped.
That's a pretty simple fix, right? We can do color coding of our pitot tubes, we can train them on things like, this is atmosphere, and this is not. We could do a variety of different things to help them understand, but only if we have that feedback loop.
If we just simply went based off financial data, or time to execute, we still would be making a lot of assumptions. That's where this feedback loop becomes so critical, because people will do a feedback loop, but they will often only do it based on one point of data. They'll either say financial data, time to execute, or they'll just try to figure out, by doing a simple knowledge check on their people again. They don't often do the three steps.
By not doing those three, you can't get this thing called triangulation. With triangulation, we're able to say, here's our financial data, here's our time to execute, here's our skill level. We're able to determine where the issue is, because as I mentioned with that previous example, if we just saw time to execute increasing, and slippage increasing, we could not determine why that is happening. We could make assumptions and maybe our assumptions are right, but all it takes for a $10 million business to tank is to make a couple assumptions and make directional changes based on those assumptions, and those assumptions be wrong.
If we assumed that it was programming, and we didn't do any way to validate that, and we started investing in all our programmers, sending them to programming training, we're working with them after hours, and we're hiring better programmers. Then all along, it turns out that the designer is selecting the wrong sensors and whatnot, and doesn't know what they're doing, or can't do take offs, we have just sunk a lot of projects potentially, and maybe not sunk them, but put a lot of cost on the projects because of what's going on.
So, that's the three-step process to how to execute training in the office. Thanks so much for being here and take care!
