Working remotely

It all started 6 months ago. I was pressed by management to improve our team’s productivity. We are a team of 4 programmers with me as a leader. I identified some factors that in my opinion influenced our productivity and I reckoned working remotely could eliminate them. As a result we could increase our productivity.

I identified the following factors:

  1. A lot of noise outside our office
  2. A lot of interruptions either by fellow employees, by the management or even by members of our team.
  3. Not enough facilities to relax or make small breaks without thinking about the job
  4. Lost time for commuting
  5. Not a viable way to exercise before, during or immediately after work.

I presented my proposal to the management. Although, the initial reaction was positive some skepticism creeped in later and we spent about 6 months thinking it over, until two weeks ago when we finally started working remotely.

Although we discussed a lot of issues with management, I identified three major concerns they had:

What if anyone in the company wants to communicate with us directly?

When I say directly, I mean someone opening our door barging in, and start “communicating” regardless of what the other person is doing or if they want to be interrupted.

I said that this should not be a concern. In fact, not being able to communicate directly would be a benefit. That led to the next concern.

What if people start spending more time preparing feedback for the development team?

In the company I work, there are three methods for giving feedback to the programmers: 1) Using FogBugz, 2) “Communicating” directly, and 3) A combination of the aforementioned methods.

Direct and informal communication is the least work for someone. It can be also viewed as a tool that helps us organize our thoughts. We think out loud, throw our thoughts to our listener and they help us polish our thoughts by occasionally expressing their opinion.

This is all good and fine, if it happens with the consent of the listener. Unfortunately most of the times this is not the case. Furthermore, the majority of people are kind and try to be polite by not making it clear to the interrupter that they didn’t want to be interrupted in the first place. However, the ultimate truth is that programmers don’t like being interrupted.

Consider for a minute a car production line. No one in their right mind would ever think interrupting the production flow, even if restarting it might take a few seconds. Why, then, is it natural for most people to interrupt a programmer? Their “restart” takes about 15 minutes and after a couple of these, the whole work day might go down the drain.

You can either be polite and ruin your flow, be harsh and ruin your relationship with your fellow coworkers or maybe choose an alternative that may eventually make people come to you as a last resort.

Nevertheless, interrupters complain that all other forms of communication make them lose time. Writing, taking screen shots, making videos, talking using Skype or similar IMs, or making mock-ups takes more time and needs more effort than barging in and talking directly.

I say that taking more time to create descent feedback brings better results, because the effort and the thinking one must do forces them to do a better job.

However, what happens when something urgent comes up and trying to communicate without direct contact is inefficient? Which brings us to the next concern.

What if something urgent happens that demands direct communication and cooperation?

Usually after a fresh software release (but not only) problems arise at the customer. These are the problems that couldn’t be caught by the programmers and the testers. Sometimes, these problems might be show stoppers and that is when the issue is marked as urgent. The pressure by the customer and the management is big and people that try to solve the problem are anxious and in a hurry.

This is a situation when direct communication is better. We chose to deal with such situations in a proactive way. Each time we know the chances are high for such urgent situations, the programmers involved should be in the office. For example, the day of release, the programmer in charge of the project comes in and is available to solve any urgent problems.

Of course, problems don’t always appear at the same day of the release. They might even appear months later. We created another rule for that. The programmers come at the office, if they feel they can’t solve a problem quickly because of the fact they are away. This is possible because every programmer is 20 to 40 minutes away from HQ.

The team works remotely two weeks now. The first feelings are positive. I get reports from my fellow team members about how wonderful it is to work without being directly interrupted. Also, how less they get tired during the day and how peaceful it is to be at home. They also say they feel their productivity improved, but I think we need more time to reach a safe conclusion.

Our fellow consultants and testers, look at this positively and I want to take the opportunity and thank them for their patience. Of course, they spend more time trying to prepare their feedback, but it is very early to say if the time they spend will remain at the same levels or whether it will drop. Also, we don’t know yet if the time they spend is compensated by the potential increase in the programmers’ productivity.

Finally, ITS S.A., the company I am cooperating very closely with, is I think among very few companies in Greece that would allow such an experiment. If I am wrong, please feel free to post a comment.

In my next posts I will try to describe how we try to avoid alienating the team and generally disconnecting them from the workplace. Also, I am going to write about more practical things we do and tools we use to help us work remotely.

I would be very pleased if you posted some comments with questions I could answer or with your experience in similar situations.

Related articles:

4 thoughts on “Working remotely

  1. Thumbs up for you and your team.! You managed the impossible in Greece 😉 May you lead the way to more tele-working !

  2. Thank you Daphne! I am trying whatever makes us work better, improve the quality of our work day and bring better results for the company. I want to thank once more ITS S.A. for trusting our proposal.

    May all the programmers in Greece start applying alternative techniques and choose whatever works better for them.

  3. Hi.
    We also have a team of developers in UK who work from London.
    In fact they prepare the ground for our new office there.
    This type of working has a lot to do with the willing and ability of people to work together and be productive no matter what.
    As both sides goals are met things can run smoothly.
    Customers have no complaints as costs of communication (phones, fax, various messengers, or even adobe tools) help a lot to keep the touch.
    Also regular visits to london and athens help a lot and we are more than a group of workers. We are a group of friends who take care each other and are happy working with each other.
    Yeah!. This is doable as long as people are mature enough to do so.
    Technology is also in a good place to help a lot.

  4. chris :
    We are a group of friends who take care each other and are happy working with each other.

    I have to say that this is one of the best ways to ensure working remotely will not fail.

Leave a Reply