by Jean H. Weber
Intercom 43 (7), August/September 1996, pp. 22-23. (Society for Technical Communication)
You’ve got agreement from your manager: you and your team of technical writers (plus editor) can work at home several days a week. You’ve organized your equipment (computers, modems, and so on). You’re looking forward to saving hours of driving, being more productive and less stressed, and reaping praise for your work.
What’s wrong with this picture? Plenty.
Within a few weeks, you discover that several members of your team are complaining about the other teams (and each other). Even worse, you discover that the other team leaders on your project are complaining about you.
This was the situation I found myself in last year. I was staffing up a team of writers for a large software development project. The writers worked for one department, who hired us out as a team to do the project.
Team leader interactions
The first major issues raised by the other team leaders had to do with my availability and the precedent set by the writers working off site. The other team leaders were used to working near each other and being able to interrupt each other whenever they felt the need. They expressed concern about not being able to do the same with me if I wasn’t there. (These same people complained that they couldn’t get their own work done because of all the interruptions.)
After some discussion, we all agreed on these points:
- People working at home are not necessarily less available to other people than if they were in the office, because in the office they can be in meetings or otherwise unavailable.
- Interrupting people in the workplace, except in urgent situations, detracts from their efficiency. Many of us need to change our habits, "batch" our questions, plan ahead better, schedule meetings with each other, and so on, whether we work in the office or at home. Many personal contacts, for example, could be done by e-mail.
The other team leaders were also concerned that if the writers worked at home, the programmers would also want to do so. The other team leaders didn’t want that to happen. "Why not?" I asked. You can guess the problem: "How do we know they’re working if we can’t keep an eye on them?"
My response was: "How do you know they’re working when you can keep an eye on them?" This led to quite a discussion. What do we consider "working"? How do we measure productivity? We have assumptions. Do we have understandings and agreements?
When you outsource work (say, sending a book to a printer), you need an explicit contract that spells out what’s to be done, when it’s to be finished, what reviews there will be (for example, checking page proofs), how much the job will cost, when payment will be made, and so on. We’re used to that, but in many cases we haven’t applied similar criteria to workers within our own organizations.
With the emphasis these days on planning and estimating, establishing checkpoints, and empowering workers, there shouldn’t be a lot of difference between outsourcing contracts and internal agreements. Writers (or programmers, or team leaders) need to agree with their peers or managers on checkpoints and deliverables, so that everyone understands the obligations of all involved. Then, if a writer at home consistently doesn’t deliver, the situation isn’t fundamentally different from a writer in the office who doesn’t deliver: it’s a personnel problem,
not a location problem.
Here are some of the principles we developed:
- Everyone needs to get used to a new way of working. The concept of the "team" is changing, but not everyone has the same concept. Teams need to define explicitly the working relationship of their members.
- Members of a team need explicit job goals or statements of work expected, detailed on a weekly basis (employees who work in the office need this, too).
- Some people may not be able to work at home because their jobs cannot be done remotely (for example, hardware support).
- Many meetings can be done over the telephone (conference calls). We do this all the time with overseas contacts.
- Some people might need to be "on call" to come in on a planned day at home, but this should be for urgent business only.
- Checkpoints and deadlines become even more important when participants are not all in the same location.
- Keeping in contact with team members is vital – your co-workers need to know what you are doing and that you are keeping up with your share of the work.
The team leaders reluctantly agreed to our "experiment," and the writers happily went off to telecommute. (And within a few months, the project manager, all the team leaders, and many of the programmers were telecommuting as well, and productivity was improving.)
All is not well in the writing team
This was all very well at the team-leader level, but problems soon arose within the writing team:
- There was much opportunity for misunderstanding and resentment, especially while the idea was new. This adversely affected team morale and lead to gossip about what people were doing and whether they were doing their share of the work.
- Some team members felt they didn’t know what the others were doing, if the telecommuters didn’t maintain regular contact with the group.
- Many people expected others (particularly team leaders and managers) to be available; they saw this as an important part of the job. An important part of teamwork is sharing expertise and mentoring; if people aren’t present, there is little opportunity to contribute in this way. New ways of handling mentoring need to be developed.
- Telecommuters were cut off from a lot of office gossip, which led to their being out of touch with important (and often unofficial) things that were going on in the company or the project.
Probably the biggest problem within the team was that each of us had our particular idea about what a team was and how it should work. Eventually we were able to express some of these ideas and deal with them, but it wasn’t easy.
Aside from the personal issues, there were practical ones. Here are some of the techniques we developed to deal with problems:
- At least one or two members of the team should be in the office each day, so that the programmers can consult with us. (We’d fought hard to be on the approval list for changes to the user interface, so we weren’t going to give them any excuse not to consult with us.)
- All plans for working at home must be okayed by the team leader.
- You must keep people informed of where you are, how you can be contacted (for example, a telephone number) and any hours during the normal working day when you will not be available.
- If you keep odd hours (either by personal preference or because your job requires it – you could need to make late-night telephone calls to colleagues on another continent, for example), be sure your co-workers understand why you aren’t always available during "office hours."
- Schedule meetings on specific days, as far in advance as possible, so all who need to attend can either be there or make arrangements for telephone contact. People can then plan their days at home around these requirements.
- The latest versions of all documents you are working on (including source files) must be available where other people can get to them in case of emergency. (This applies even when you are working in the office" and is particularly important near deadlines.)
- Try to batch your questions to those at home so you make one or two calls a day rather than many. Do this in the office as well. Better still, e-mail if at all possible.
- Do not expect people working outside the office to be able to come to the office on short notice.
I’d like to say we solved all our problems, but that isn’t true. However, we made a good start, and we certainly identified a lot of problems that we hadn’t thought about at the beginning of the job. Next time, I’ll know a lot more issues to bring up and discuss with the team before the issues become problems.
Last updated 23 November 1998