How to know if your remote workers are working

Let’s get right down to it: many managers worry about whether or not their employees would work or goof off if they were allowed to be remote. It’s a huge fear; it requires faith in your employees, since you can no longer see them or glance at their screen from time to time. Employees are expensive to have on board, so you’d rather they spend their time actually solving problems rather than playing Sudoku or watching Star Trek on Youtube.

And yet, there are dozens if not hundreds of companies that are partially, mostly or completely remote. From Automattic to Github, these companies have figured out how to get things done while partially to fully remote. And the good news is, so can you.

Figuring out if your remote employees are working is not as hard as it might seem. Here’s how you do it.

Setting regular goals

At Mozilla, everybody had quarterly goals to accomplish. These goals were specific, measurable things that we could evaluate and see, was this completed or not? In any given quarter, we missed 10% – 15% of the goals (we did stretch ourselves, so missing goals was sometimes an outcome), but the quarterly goal system offered a great way to know whether or not people were actually getting things done.

With regular goals, you move your employee from a “time-based scale” to a “value-based scale”. The goals are an agreement between you and the developer that says “I expect these things out of you in exchange for your salary in a given period.” And considering that really what you want to pay for anyway is results, not time, this system can help you accomplish that.

Overcommunicate!

People don’t read. Since you may not have read that, let me say it again. People don’t read.

We assume that if we write an email about something, the person who receives it, knows whatever we wanted them to know. We especially assume this if they replied to the email. But that’s not necessarily true.

Humans are bad at assimilating information sometimes. And so, it’s important that you overcommunicate with your employees. Make sure they fully understand theirs, and your, priorities.

One of the ways we did this at Mozilla was with the regular 1:1 call (one-to-one). This was a call between a report and their manager, to discuss important issues. It happened once a week (mine was on Thursday). There were three questions: what are you working on? What are you struggling with? What do you need from me?

These three questions helped Laura to understand exactly what I was doing, but also helped me to have an opportunity in an un-rushed, open way. It also helps if you see your role as to remove the roadblocks and offer encouragement to your employees, because you have an opportunity to figure out and solve your employees problem and gauge their mood and attitude. This can help keep them engaged, even when they aren’t physically present in the office.

With remote employees, there’s no such thing as overcommunicating.

Use metrics – sparingly.

Metrics are useful things – if you know how to use them.

For example, pull requests and git commits can help show productivity, or more importantly, when someone is stuck or bored. Participation and questions asked in a channel or on a bug can help highlight these things as well. Bugs opened against the work of a particular developer can show some quality control concerns. All of these are useful if used correctly.

Emphasis on correctly.

Some managers like to use metrics as a substitute for communication and interaction with employees. Metrics are easier than direct interaction, of course, especially if you have 20 or 30 direct reports. But metrics don’t tell the whole story.

You might think that pull requests and git commits show whether or not someone is working or just being lazy, but that’s not true. Git commits can be a symptom of a health problem like depression, or problems at home, or some other problem that you as a manager are responsible for discovering and helping correct. Chastising a depressed employee for their lack of productivity during a downturn in git commits won’t help them, and it will only hurt you.

Metrics can help point to a problem, and highlight developers who might need additional attention. They can help you keep an employee happy and productive if you use them as a tool, not a cudgel.

Trust is key.

I’ve regularly said that if you can’t trust your employees, they shouldn’t work for you. This is true in many ways, and you should trust your remote employees to do the work, whether they’re in the office or a thousand miles away. And yet, my mother is fond of saying, “trust but verify”. This can be done too, and should be done, through regular interaction, correct use of metrics, and constant communication.

Working remotely is becoming more common, and many employees demand it or expect it. Refusing to work with a remote person closes off a huge segment of the job market, and limits your talent pool significantly. Opening up that talent pool will let you compete on a truly global level for the very best and brightest, including those who won’t move to you for just a job. Seize this opportunity, and learn to trust those who work for you, along with a healthy dose of verification.

Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP

stratigos wrote at 5/13/2015 10:46 am:

Thanks, I really needed to read this, especially that last paragraph about employees expecting or demanding a remote model of employment.

Copyright © 2023 by Brandon Savage. All rights reserved.