updated 23rd August 2024
I’ve been working remotely in my capacity as a salesperson since July 2014. I have greatly appreciated the opportunity of working remotely as I can help my wife run her law practice by occasionally taking care of our two young children. There is sometimes work that needs to be done after the kids go to sleep but I have helped my boss, Mikel Lindsaar, grow the company consistently for the last six months as the Sales Manager for Asia Pacific.
Most of the employees at reinteractive are developers. All of the developers work remotely and working remotely is a condition stated in their contracts. Some companies struggle with the concept of remote work and the struggle is largely in answering the question: “how do you manage a remote developer?”
Tools
We use Slack for internal and client communication on specific topics. It is important to keep the channels and member of each channel relevant to avoid unnecessary chatter that can be distracting. By the same token though, having as much communication in writing as possible is invaluable when needing to refer back to something, or working out what decision was made on something. Being able to quickly view the history of a conversation creates more informed comments. Then we use Google Docs for collaboration and Slack Huddles or Google Meet for meetings. The job tracking software, finally, is an important communication tool, and once development has started, may be your most important.
It is important too, to ensure these tools can refer to each other, preventing the need to double up on communication where possible.
People
The productivity of a developer is very hard to measure. Measuring numbers of lines of code is a terrible metric to judge a developer, as code that is easy to maintain is often code that is as small as possible. The proxy most managers make for productivity is the number of hours sitting in front of a computer. Hours in front of a computer is also a terrible metric to measure the productivity of your developer as you have no idea what the developer is working on. Therefore it doesn’t matter if you can’t see someone sitting in front of a computer.
The number of features delivered is the only beneficial metric for measuring a developers productivity, unfortunately a “feature” is so wide ranging in complexity that just estimating the feature can be a whole exercise in itself. The method employed at reinteractive for measuring features makes it really simple:
- Each feature delivered and accepted by the client is 1 point.
This simplifies a lot of things, firstly, it encourages small features and optimises for features that are as small as can be accepted by the client, this aids in communication with the client and discourages the “epic feature” disease that can infect many projects where a feature becomes something like “As an owner I want a billing system”.
Sometimes features are more complex, sometimes less. Measuring the exact amount is less important than helping the developer get a trend of features delivered and encouraging clients to have small bite sized features which encourage fast feedback and iterative development.
The other major aspect is keeping up communication on a feature to enforce transparency.  You are better to get a task done in 2-3 hours with back and forth communication than get the task done in 1 hour with no communication, so that the developer clearly understands what they are meant to be building. Generally our developers need about 90 minutes of communication throughout the day excluding meetings.
Measuring features delivered is not an exact science and close analogy would be a flashlight in a dark room. However measuring features delivered is important in measuring productivity trends for developers. If a developer has a bad week then you’ll be able to quantify just how bad. If a developer keeps having bad weeks a manager will need to step in to correct the trend. The point here is that the statistic provides a metric to help spot departures from what the ideal scene would be and step in to assist as needed.
Bonus Time Management Tip
A bonus technique for managing developers is a time management technique called blocking. Blocking gets its name from undertaking similar tasks within a defined window of time i.e. a block of time. Every developer will spend some time researching how to best accomplish a task. We have found pushing all of the professional development/research into one day, allows our developers to focus better on the days they are responsible for pushing code. We have found that developers following a 4-1 schedule (four days client work, one day professional development), push more features each week than when they were working five “full” days.
Conclusion
To manage developers remotely you need to have a suite of software tools. You will also need to measure productivity using a feature points system. The most important takeaway is to keep communication high between the management and the developer. Leaving a developer alone for days at a time is a recipe for failure. Lastly if you can convince management to keep a day a week dedicated to professional development your developer productivity will increase.
