I’ve telecommuted for more than 5 years now, half of which was in a management/chief architect role, so anything in the news about telecommuting interests me.
Here is a brief interview with Jack Nilles, who, from all accounts, is the father of telecommuting, having coined the term back in 1973 while working for the ASAF and NASA.
He makes some great observations, among them:
- “They commute to the office, get on the phone and talk with someone somewhere else. What’s the point?”
- “Most people are relatively clueless about the human interaction aspects and supervision techniques and so forth required to be good managers”
- “Branch offices and telecommuting are similar.”
I’ve run into some of these things first hand; “I can’t see you, so I can’t manage you.” That sort of thing.
I once even got a telephone callback by one company that I’d responded to, who was a software vendor, but who’s ad was very vague about the actual kind of software they sold. Once I got on the phone and realized they made, essentially, spyware that would track websites you visit, keystrokes, time spent in particular applications, etc, I closed out the conversation quickly, turned and didn’t look back.
Their idea was that, along with a timesheet, you’d turn in this encrypted report of the log that this application generated. As the employee, you couldn’t alter the log, though you could view it. They argued that such software would encourage employers to support more telecommuting, because it would make the telecommuter’s day transparent, and it would be a “good thing” for telecommuters because it allows them to “prove” they’re doing the work they say they are. Mr. Nilles’s comments, or a good sit-down with Steve Maguire’s “Debugging the Development Process” should be proof enough that such thinking is so utterly wrong it makes the Flat Earth Society look like geniuses.
I’m sure they’ll sell the hell out of that app 🙁 .
Employees have to be judged by their work, not how long they’re in their seats, or how much time they spend with Visual Studio loaded. Successful development shops (telecommuters or no) understand this.
One Comment
Sing it, brother.
Many years ago I was part of a team developing the next generation data-sharing tool for government agencies, kind of a WAN-based BBS with project management aspects. This was, gosh, 1992? If I could jump into a time machine with a copy of MS Office I’d’ve put us all out of a job.
Anyway, our team leader was a dick. Everyone works in their cubicle for as long as it takes. I found it particularly frustrating since I had a high-end workstation at home that was faster than the crap they issued at the office. Naturally we were behind schedule and stress levels were off the chart. Code review meetings turned into wars over whose bugs were worse. One manager was so afraid of top management that he stopped delivering the weekly status report.
But Corporate wasn’t stupid: we got a visit from one of the top guys from corporate headquarters. He was an older guy (40 looked old back then) but knew enough about software to inspire confidence. He was there "only to advise" but it was clear he was the troubleshooter — the fixer sent in to get us back on track or send back the blood of the unworthy. He quickly (and very gently) took control.
We should’ve been terrified — he had the power to destroy us utterly — but instead he became a kind of subversive uncle.
"Don’t bother with that comment header shit! At this rate nobody will be around to READ the fucking comments, much less care about how they’re formatted."
"Do your timecards at the END of the day, instead of while you’re working. Right now I don’t care how much time you spent coding vs. talking on the phone vs. smoking a cigarette! In fact, if I don’t see your timecards for two weeks I won’t say a thing."
…and my favorite…
"I don’t care what you do or when you do it. Stand on your head! Sit in your cubicle and drink gin all day! The goal is to FINISH this project. If that requires you to work all night and sleep all day then so be it — but make it happen."
We all looked at each other with "is this really happening?" looks, but after that meeting a bunch of us gathered our stuff and went home for the day. The next day he seemed okay with it, so we all drifted into our own development schedule. One analyst was a complete type-A personality and could only function at the office and was there from 7:00 AM to 9:00 PM, so we used her as our point of contact for everything. She didn’t mind.
Long story short — the project was completed a few days late, worked as advertised, and was probably never deployed. There’s probably a stack of tapes and disks in a locked file cabinet someplace in a government warehouse. Future historians will decipher the encoded messages contained within and determine we were all morons for coding the thing in FoxPro.
What I took away from this experience: process indeed matters, but not as much as results. Your spyware employee "invisible leash" story simply reinforces that not many management types know this.