How to keep your remote workers productive
If you can't see them, how do you know they are really working? If you have hired remote freelancers, or a remote working dev shop, or you're employing a remote-working person, chances are you will get this question every day.
If you can't see them, how do you know they are really working?
If you have hired remote freelancers, or a remote working dev shop, or you're employing a remote-working person, chances are you will get this question every day.
In fact, this is a question I get every day.
Two years ago, I co-founded MarsBased, a remote-working development consultancy with my two best friends. Among a bunch of other things, being 100% remote is part of the company culture.
As a matter of fact, two years in and we still do not own an office. Here's another question I get all the time: when are you guys going to get an office?
But back to topic. Throughout these two first years of working 100% remotely, from very exotic places such as Mexico, San Francisco, Poland or Murcia, I think I've got a good answer to the aforementioned question.
It all boils down to these three things:
1. Hire only proactive people
This is probably the hardest one, and not everyone is born with hiring skills. Thus, it is really difficult to find out whether a person is proactive or not without knowing him.
How will that person react to uncertainty? Will he slack off when he's finished all the work or will he come to you asking for more?
There are some ways to find out: leave them hanging on the phone for a while to see if they come up with questions, ask them what would they do in a certain situation, or else put them in that situation during a trial period with some test work.
One way we solved this at MarsBased is by only hiring people we know, or else, people someone we know can vouch for.
2. Let them know what your schedules are
One of the main causes why remote workers stop working is because they find a stopper in their way. And most of the times, that stopper happens to be you.
For instance, you delegate the design of a certain functionality on an external designer, but you forgot to specify something crucial. Let's say, you forgot to tell him whether the payment workflow will work for logged in users only or not.
A mediocre designer - or, rather, someone with low proactivity - will try to contact you before working on that, because no one likes to undo his job. But if you're working remotely, there's a great chance that you won't be in the same time zone, or that you will be working in different hours.
Thus, maybe he needs to wait until you get back to him with an answer on the next day.
Perhaps, a more proactive person would have either:
- Found a way to contact you.
- Thought through whether it makes sense for that workflow to work for logged out users.
- Designed both things, since it takes only half an hour more of work.
- Worked on something else as important.
- Researched what's the trend in the rest of the benchmarked companies he drew inspiration from.
- etc.
Whatever action he might take, it is surely not 'sat on his ass'.
In order to avoid you being a stopper, let them know upfront what your schedules are, either at the beginning of the project or on a daily basis. This way, he will reach out to you before stoppers might happen, or else decide whether he can put it off till the next day or not.
3. Keep their pipeline full
Finally, another great way to avoid these situations is to keep them always busy.
Busy does not mean overstuffed with meaningless work. It means that they have other important and meaningful work that can be used as a filler for those waiting moments.
Big projects have lots of features, sometimes conflicting with one another. But there are also loads of things that need to be re-worked on, or bugs to be fixed, content to be changed, parts of the application that need a refactor or stuff that needs to be deleted or documented.
If your developer gets stuck in the development of feature X, you might not want him to start developing feature Y until X is finished, but you might want to allow him a fixed number of hours per week of bug-fixing so that his buffer is never empty.
Of course, there are many other things you can do to avoid this situation, but these are the three that came to mind speaking to my buddy Wojciech today. He actually asked me that question and I thought that it might be relevant to a broader audience.
What are your experiences? What do you do in such situations? Share your advice with us!
Now Playing: Isis - Deconstructing Towers 🤘🏻