Advisor

Managing Remote Workers in the Time of Coronavirus

Posted April 23, 2020 in Business Agility & Software Engineering Excellence
Remote work

“How can I tell that they’re working if I can’t see them?” It is a common complaint, based on a centuries-old style of working that we now need to move past. My rejoinder usually is, “When you CAN see them, how do you know they’re not shopping Amazon or playing solitaire?” But, in the days of unplanned, unusual work from home (WFH), this question deserves a closer look. In this Advisor, I’ll make use of decades of remote working, and managing remote workers, in the IT industry, but these same principles apply to many kinds of work.

Many of us are viewing the lockdowns and WFH requirements surrounding the novel coronavirus pandemic as a burden — and for many people who have lost their jobs or for whom WFH is not a possibility, it is devastating — but I would argue that it also offers a huge opportunity for some. For much of the workforce, the elimination of the horrendous commutes that have been a fact of life in cities like Washington, DC, and Los Angeles, California, are an enormous potential time-saving and quality-of-life benefit. For management and stockholders, the opportunity exists to cut overhead expense like office space that will prove to be unnecessary going forward, and to implement changes in the workplace that will boost staff productivity, improve the quality of life for many workers, and even take a giant step toward achieving that elusive “work/life balance” goal. To get there, however, we need to step up our game in some specific ways. Trying to duplicate the cubicle experience in a corner of the house, coupled with a virtual timeclock to punch, is not the answer.

You Can’t Manage What You Don’t Measure

When you hire an employee or contractor, you agree to pay them. What do you expect to receive in return? A body sitting in a seat? That’s an easy number to measure: what’s your headcount? Who’s absent today? You can measure who’s there, but you hired them to do some things — things like write software, write documents, answer questions, fix bugs, file forms, call people. Whatever it is you want them to do, you can’t manage it if you don’t measure it. So how do we do that, exactly?

Status reporting is not the same as measuring work. That should be obvious; inaccurate status reports, copied and pasted from the prior status report, are often unreliable. If you must have a status report, create a simple email format and require one from each worker at the close of his or her workday. That allows a manager to baseline all those status reports at the start of his or her day. You can, of course, measure whether workers submit the required report, and that tells you ... what? It tells you they sent an email. We need to measure more than that.

Shared Code Repositories

If you are managing programmers, what do you want to measure? Whether they are in their cubicle by 8:30 am and how long they sit there before they leave? Of course not. You want to measure programs written, bugs fixed, documentation produced, tests run, and so on. Every single one of those activities can be measured with automation — and don’t forget to add things like static code analysis and defect rates to your list of measurements.

In the bad old days, we either kept our software work in a personal directory or in a locking centralized repository that allowed us to “check out” some code to work on it. Checking out code pretty much worked like checking out a book in a library: you get the file on your local computer and it’s marked unavailable (locked) for everybody else. (Yes, you can check code out without a lock, but the lock normally is part of actually doing some work on the code.)

Nowadays, the best practice is to use a distributed source code control system, and the market leader is an open source software called Git. With Git, every worker has a copy of the system being developed and cannot be immobilized by an Internet outage or another programmer’s lock. And most providers of Git, like GitHub or Bitbucket, add features so that you can maintain lists of bugs and issues there if you want to. However, if you do want to manage defects and the work done to fix them, low-cost alternatives or open source systems like BugZilla allow better management of the bug-fixing effort. And there are systems for managing test cases and tests as well.

Shared code repositories allow and promote collaboration between developers, and they produce a great view into what everybody is doing. The one thing you have to change is the idea, prevalent in some shops, that it is okay to take a programming assignment and “go dark” until it is turned in two weeks later. Code should be checked in on one or more times a day, not just at the end of the assignment; that way, other people can benefit from the work, and management can see if somebody is struggling and needs help.

Requiring Remote Workers to be Accessible

Being able to reach out to a worker, whether it is to provide some information, ask a question, or provide some leadership by asking how they’re doing all require that you be able to reach that person. It doesn’t necessarily mean “right away” unless there is truly an emergency, but they cannot be out of touch for extended periods of time, either. You can use email for some kinds of communication, but you also need a messaging system and you need to give the workers some control so that messages don’t become a useless string of interruptions.

Here are some alternatives to consider, with varying sets of features:

  • Skype — owned by Microsoft, with a large market share

  • Teams — owned by Microsoft, with a large market share

  • Slack — independent provider of collaboration and messaging

  • Telegram — secure messaging, requires a phone number for identification only

What you need is to get everybody on the same system, so taking a test drive and surveying the results is a good idea if the choice is open. If it’s a choice dictated by company management, then just use it.

Flexible Hours, Within Reason

If you think about it, requiring fixed hours only makes real sense for jobs with a service-level agreement (SLA). What is an SLA? In this context, it means workers have to be available within a window of time, and have to respond to a request for services or information within some number of minutes or hours. If you work on a help desk, you can do that job from pretty much anywhere, but you’re going to have to follow the hours that allow your company to meet their contractual commitments.

Working from home is different, and every person has varying productivity during the day. We can start with the great benefit of losing one or two hours a day commuting! But beyond that, some people are best in the morning, some are night-owls, and some can successfully intersperse periods of intense productivity (“I’m gonna get this bug!”) with periods of lower productivity or the need to run an errand or two. But remember: at the end of the day, the job has to get done, in a manageable way, with visible results every day.

Summary

Teams and companies that can respond intelligently to the surprise upending of the daily commute and cubicle life will emerge the winners from the coronavirus pandemic. We need to manage performance, not presence. We need to trust our workers, not micromanage them with a timeclock. And we need, above all, to show leadership, to be strong, and to focus on getting the job done. The benefits of higher productivity and real work-life integration await.

About The Author
Tom Bragg
Tom Bragg has over 30 years of experience working with high technology and information systems for clients in industry and government. He has defined software development processes for organizations ranging from small development firms of less than a dozen engineers, to multi-modal development processes for a Fortune 50 corporation. He teaches advanced software topics at George Washington University, and has written for Federal Computer Week and… Read More