6 Critical Mistakes Field Service Company Leaders Must Avoid When Building A Remote Team
Building a remote team is a piece of cake and here’s how to build them.
If you’re considering building a remote team—either onshore or offshore—this article might save you tons of headaches, time, and money because we’ll be going over some of the success patterns, mistakes, and pitfalls that can make or break that remote team in your organization.
After being in the trenches building remote teams for eight- and nine-figure Field Service companies for the last few years…
We’ve figured out and mastered a thing or two and we’ll be sharing here the good, the bad, and the ugly of it.
Read on to understand where the land mines are ahead and how to avoid them.
Not Getting Full Buy-In from the Local Team
Some executive decisions can be made just by “the boss” having the last word but that doesn’t mean the team executing that decision will buy into it and follow it (or even play nice). The truth is, if the local team feels that their well-being will be at risk—which can come from losing job security and needing more mental energy to perform their tasks—they will push back.
Bar none, the MOST important thing to do before starting a remote team is clearly, transparently, and fully communicating the "WHY" behind that decision to the local team.
You need to explain what they are going to get, what is going to be taken away, what it will mean to the workflow, and how that relationship will look like. For bonus points, start with a use-case that makes their life better at work. If they can clearly see what’s in it for them, it will be much easier to get their buy-in.
Here’s a sample “script” of how that would look like:
“Hey, guys, I see you’re doing amazing work but also see that you’re at capacity. If I hired more of you in the office, we’d need to get a new office soon; that would distract HR from finding technicians (which is our core priority) and it would increase our costs—all of which would hurt our margins. I’m sure you want us to stay profitable so that we can keep all your jobs secure and we can keep providing for our employees. So what I'm going to do as an alternative strategy is look for a remote team offshore that can take some tasks off your plate. That way, we can free you guys up and give you more bandwidth to do what you're really good at and even free you up for those projects that we keep leaving for later.”
Wow, that was good, wasn’t it? What we’re trying to point out here is:
Communicate the decision to them EARLY and CLEARLY
Let them know WHY you’re doing it
Tell them what’s in it for THEM
Let them know that there is NO THREAT to them
And that’s not bending reality. It’s the truth.
Out of the companies we’ve worked with—we wouldn't say none but in a few cases we’ve seen a reduction of onshore hiring. When our remote teams help them scale and be more profitable, we actually see the opposite and see MORE on-shore hiring—maybe not for the back office but other roles and functions—because, after all, they are growing.
Not Allocating Downtime
Yes, we’ll be the first ones to say it.
Even though our process is fine-tuned and optimized and we have some redundancy on our end to make it faster for our clients to get results, the truth is, deploying a remote team does not happen with one touch of a button. It’s more of a flywheel. It will take a few weeks to be deployed, maybe a few months until they become completely autonomous, and meanwhile, the onshore staff will need time to help them, troubleshoot, answer more questions than usual, even rectify some mistakes, etc.
So their productivity might suffer, and that needs to be factored in, otherwise, it just becomes a pressure cooker.
“I have all these KPIs to meet PLUS now, training a new person?!”
Not good. So a bit of downtime has to be allocated, just as it would happen with a new hire. With the BIG difference that once the remote “flywheel” is set in motion, it will then be the REMOTE team who will “eat” that downtime (helping, training, correcting fellow remote team members, etc.) so that your onshore team doesn’t have to.
Not Recognizing Small Mistakes
There’s a counterintuitive truth that we’ve found which is, “it's the SMALL things that break a remote team”.
It's not the big, glaring blunder that everyone recognizes but the tiny constant ones that are not addressed. Like a file that is not attached or a status that is not changed or small things like that which the remote team should be doing but the onshore team doesn’t flag—maybe because it’s quick for them to just do it instead of giving the feedback and correcting the source. These are the things that eventually make the remote team "not work" and make the onshore say “we’d rather just do it ourselves.”
And this ties perfectly into the next point which is:
Not Having Reliable Documentation (Or NOT Updating It)
Tribal knowledge is great to get a business off the ground, fast. When the team is small and you have each other always around, it’s ok to be in execution mode instead of documentation mode—to get deals coming in, techs going out, etc. But once the company reaches a certain size, you just can’t afford for everything to break down because Ms.Jones got sick. But even when there’s documentation in place, the team will keep finding paths of least resistance.
“I know the docs say to do it THAT way, but it’s actually quicker to do it THIS way.”
All of these practical findings are awesome but they must be documented, otherwise, remote teams (or all new hires, for that matter) will not be able to adapt to the REAL workflow.
Not Having the Tech Stack to Support It
Remote teams require tech: things being “on the cloud”, company chat software, VPNs, etc. If the onshore team is used to just talking things out over the water cooler, leaving Post-Its around for each other, and sending SMS, then deploying a remote team will be tricky.
And the topic of tech is a broader one. The case for tech can be made even if you have no intentions of deploying a remote team. Company chats are one of those things you can’t imagine how life was before you had them (at least for us). The same for cloud file storage and so on.
These are becoming the norm for a good reason and will be the default even if you don’t have a remote team but are pretty much mandatory if you intend to adapt and adopt remote teams.
Being Too Rigid with Role Boundaries
This is the final one and it’s a very important point..
We are used to talking about role boundaries and segregation of duties and I think that those things are extremely important. Except when they aren’t.
For example, let’s say you have two roles, Role A and Role B.
Role A performs tasks A, B, C, D, and E.
Role B performs tasks F, G, H, I, D, and E.
In this case, tasks D and E are common for both roles. So what does that have to do with remote teams?
Well, if these tasks happen to be administrative tasks or things that can be done overnight (like clearing a backlog for example), then these are perfect and practical reasons to:
Have a remote team doing them.
Have the local team focus on the remaining tasks and do more of them, expertly.
Increase efficiency and reduce errors.
This is part of the consulting job we do when we come in and work with clients. The whole process may involve breaking down roles and creating sub-roles to be fulfilled by the remote team and thus improve the workflow as a whole.
With this one, now you have a full picture and a roadmap to adapt and adopt remote teams and ride the remote-first wave that has started.
If you have any questions, feel free to reach out and we’ll be more than happy to help. And if you’re ready to get started with remote teams and discover all the benefits they bring to a scaling organization, get in touch and we’ll create an action plan especially for you and your business.