As an engineer, I've convinced a series of reluctant managers through simple principles of observability and connectivity and now, as a manager, my experience makes for simple guidelines for my team.
Here's what worked for me:
During your "pilot program", try it on one day a week and prior to that day, predefine with your boss the small, concrete deliverable you will produce on that day. After you produce it, make sure you and your boss discuss it the following day. Subtly point out your performance rather than say, "See, I told you I'd work and I did." Of course you did. What's important is some particular about your work, right? For example, if your deliverable is to write a section of a report, show up the next day and review the section, perhaps to clarify some point or another, with him or her.
Provide metrics for your work. This has all the side benefits that metrics provide and makes for an easy way for the boss to feel comfortable. If you are writing code, make it easy for him or her to generate a report on how many tested lines of code you write from day to day. If you are producing models or documentation, make sure your work is constantly checked-in and available so your boss can browse your progress at any moment. I don't want to start a thread on the usefullness of brain-dead metrics like LOC, I'm just making the point that the more visible you make your work, the more comfortable your boss (and your team members) will be.
Make yourself so available through mobile communications technology that nobody knows or cares if you are in the office or not. In my case, I was both a toolsmith and a support person so I made sure (as has been said already):
That I read and responded to email immediately,
That my voicemail immediately forwarded messages to my cell phone and I returned calls immediately, and
That I could be anywhere on the network when I needed to be - I could login to any server and anybody's workstation (we used PCAnywhere and X, but now use VNC) anywhere on the planet-wide corporate intranet and consult on problems from home.
For example, I regularily checked on machines in India at night, on India time, something no 9-to-5 office worker could do. I once walked a customer through a build issue while deep in the stacks at the library, whispering into my cell phone as I continued to browse. The guy was back on the air in minutes. My teammates and customers got my usual high quality interaction:-) and my boss heard nothing but positive comments when he asked for them.
Yeah, I worked harder just to accomplish the apparently minor goal of keeping my boss more comfortable and some people feel that shouldn't be necessary, but bosses are human. A boss in his comfort zone is a flexible boss, willing to take risks for his team.
Yeah, I responded to interrupts too much and this made it hard to concentrate some times, but I created a presence while retaining control of my location.
Now that I'm a manager, I tell new members of the team the same thing. As far as I'm concerned, any team member is welcome to telecommute if they:
Define their work clearly in terms of day to day micro-deliverables and make sure they achieve them. I don't really care what the deliverables are because we hire people who know how to work efficiently work towards their goals; I just ask that the microdeliverables are measurable. It's an impressive display when I can bring up a file or report and say, "this is what Joe's produced this week. He's not done, but he's making good progress."
Always, always, always hit their schedule in the small (day to day) even if the project experiences slips. This requires artful definition of micro-milestones. But, look at it this way: if somebody works for several days and doesn't produce the routine they said they would, how do I know it's because they ran into snags in the design and prototyping and not because they took the week off? If they make their experiments, design work, and prototyping visible, then I know it was unexpectedly harder than we thought(and I might be able to help along the way).
Make themselves instantly available via their prefered method of communication (email. voice, IM, whatever) so that if somebody needs to get in touch, they can
Come in to work for that human, face-to-face work that every corporate team needs from time to time and make a commitment to show up on the team's schedule when necessary. This means leaving early and showing up on time for an early meeting if that's the only time the entire team can get together. Obviously, we try to schedule these things away from high-traffic periods, but we don't always succeed.
I'm willing to always let somebody give it a shot and, if they establish a track record of measureable productivity and connectivity, I'm happy to champion their preferred work arrangements.
Slashdot Mirror
As an engineer, I've convinced a series of reluctant managers through simple principles of observability and connectivity and now, as a manager, my experience makes for simple guidelines for my team.
Here's what worked for me:
During your "pilot program", try it on one day a week and prior to that day, predefine with your boss the small, concrete deliverable you will produce on that day. After you produce it, make sure you and your boss discuss it the following day. Subtly point out your performance rather than say, "See, I told you I'd work and I did." Of course you did. What's important is some particular about your work, right? For example, if your deliverable is to write a section of a report, show up the next day and review the section, perhaps to clarify some point or another, with him or her.
Provide metrics for your work. This has all the side benefits that metrics provide and makes for an easy way for the boss to feel comfortable. If you are writing code, make it easy for him or her to generate a report on how many tested lines of code you write from day to day. If you are producing models or documentation, make sure your work is constantly checked-in and available so your boss can browse your progress at any moment. I don't want to start a thread on the usefullness of brain-dead metrics like LOC, I'm just making the point that the more visible you make your work, the more comfortable your boss (and your team members) will be.
Make yourself so available through mobile communications technology that nobody knows or cares if you are in the office or not. In my case, I was both a toolsmith and a support person so I made sure (as has been said already):
For example, I regularily checked on machines in India at night, on India time, something no 9-to-5 office worker could do. I once walked a customer through a build issue while deep in the stacks at the library, whispering into my cell phone as I continued to browse. The guy was back on the air in minutes. My teammates and customers got my usual high quality interaction
Yeah, I worked harder just to accomplish the apparently minor goal of keeping my boss more comfortable and some people feel that shouldn't be necessary, but bosses are human. A boss in his comfort zone is a flexible boss, willing to take risks for his team.
Yeah, I responded to interrupts too much and this made it hard to concentrate some times, but I created a presence while retaining control of my location.
Now that I'm a manager, I tell new members of the team the same thing. As far as I'm concerned, any team member is welcome to telecommute if they:
I'm willing to always let somebody give it a shot and, if they establish a track record of measureable productivity and connectivity, I'm happy to champion their preferred work arrangements.