Telecommuting Culture - What it tells me about your company | Hacker News Reader

Telecommuting Culture - What it tells me about your company

travisswicegood.com

74 pointstswicegood62 comments

I don't think it's as simple as saying, essentially, "people who forbid telecommuting are idiots" or "there's no legitimate reason why telecommuting should be difficult." There are legitimate reasons to co-locate a team.

We allow working remotely one or two days a week, but our experiments with full telecommuting have not gone so well (though we'll probably keep trying). The level of success probably depends pretty heavily on the type of product you're trying to build and the resulting level of communication that's required. For enterprise software (or perhaps I should say "domain-specific apps" or something), you really need a customer proxy/subject matter expert on hand that you're talking to on a fairly constant basis, because the developers themselves aren't really experts in the domain; as a result, you want your development setup optimized for high-bandwidth communication. When 10 people are onsite but 1 team member is offsite, that communication just doesn't happen, and that 1 person ends up out of the loop and much less productive (at least that's what's happened with us). For other types of software, that's less of an issue.

I think it's also much less of an issue if the entire company telecommutes, or if at least a large percentage do: in that case, communication channels are optimized for that. If 5% of the staff telecommutes, the communication channels are optimized for face-to-face communication, and the people telecommuting are left out.

And on top of that, there are just different ways to go about developing: they're not necessarily better or worse, but they make different demands on physical presence. A lot of agile/XP practices work best when people are co-located in small cross-functional teams that are in constant dialog, pair-programming, etc. That doesn't mean it's the only way to develop, but it can be an effective way to develop (more so for certain domains than for others), and it doesn't mesh very well with full-time telecommuting. Other development strategies and methodologies make different trade-offs and will be more accommodating of telecommuting.

As someone who does and has worked on enterprise-grade software, and someone who now helps client teams facilitate development, both in-person, remote on-shore, and remote off-shore, I can confidently state: it all comes down to communication, and a lack of communication not only dooms telecommuting, but it's a strong indicator of longer term failure in the parent company.

If ideas, thoughts and facts cannot be clearly captured and/or communicated in a facile fashion, any complex project is risking higher failure rates. In-person buffering is a crutch at best.

Not sure why this got down voted to negative points. This is a good point, but one I guess a lot of startups don't want to hear. :-/

I'm really excited to have people in that first situation (the 10 people there and one person far away) try using our robot (anybots.com) That is exactly the problem we are trying to solve.

"The level of success probably depends pretty heavily on the type of product you're trying to build and the resulting level of communication that's required. For enterprise software (or perhaps I should say "domain-specific apps" or something), you really need a customer proxy/subject matter expert on hand that you're talking to on a fairly constant basis, because the developers themselves aren't really experts in the domain; as a result, you want your development setup optimized for high-bandwidth communication."

I totally agree with this. I work in this kind of environment, where I need to collaborate with about a half-dozen (non-software) engineers on the product design, and working with them when they are/I am offsite is much more difficult than when we are all in the office. I inevitably spend most of the day reading and writing e-mails and on conference calls when this is the case, and most of the day working on the product when it is not. Five minutes sitting around a whiteboard in person dissecting a problem can often replace an hour-long conference call or thousands of words of e-mail correspondence.

I've been bitten by the lack of progress measurement and having "agile" requirements before. In most cases my physical presence is a crutch for a bad process, it allows people to make ad hoc decisions because they can grab me and talk in the hall for 10 minutes.

If people being physically present is no longer a given then some level of structure has to be put around decision making and disseminating the results of that to the rest of the company. Too many times I've lost days of work because X was changed to Y and I wasn't at my desk when people were herded together to make that decision.

Having people geographically distributed forces you to deal with communication up front. People are trained to use mailing lists, IM, bug trackers, commit messages etc. properly rather than assuming that if someone wants to know wtf just happened they can shout at you across a room. You hit problems like Mike being the only keeper of process Z early rather than on day 1 of Mike's 2 week vacation to somewhere with no cell reception...

I once worked for a company that adamantly forbid telecommuting. Our city's transit system shut down due to a strike, in the middle of the cold and dark Canadian Winter. The snow and the flood of cars on the roads, ground the city to a halt.

My 1 hour daily commute took 3-4 hours total,... the entire team was tired and demoralized from sitting in traffic for so long.

Yet our CEO completely forbid telecommuting. He wanted to see asses in chairs, even if it meant wasting our energy in traffic. We were forced to work in the office, and everyone directed their grumpiness and anger to their job. It made the cultural environment toxic, and people left as soon as they could.

It demoralized me, and I had animosity towards the company. My performance suffered and I cared less about my work.

Eventually the CEO almost drove the company into the ground, until he quit before he could get sued for not completing his fiduciary duties.

He eventually fired me, and it was probably one of the best things to happen to my career.

TL;DR: anectdotally I can agree that companies that can't trust their employees to telecommute are toxic places to be avoided.

Sorry if this sounds blunt, but

a) Why did you join in the first place?

b) Why didn't you find another job before getting fired?

a) When I joined it seemed like a genuinely interesting and good place to work. I joined leaving somewhere worse; and at first it was a great place to work. I did not even think of asking "does this job offer telecommuting?", as I never telecommuted in the past. I had only been out of school for a year, and the company had a lot of cool things going for it, like beer Friday meetings and an office in the "hip" part of town.

b) I was trying to find another job. It just happened that I got fired before I could find one, this was also happening at the height of the recession and in my neck of the woods the opportunities were slim.

It worked out really well in the end. We had our first child that year, and I got to spend 3 months with my family before finding a much better paying job that had a healthier environment. Sometimes leaving one job is the only way to get a raise.

Ten years from now people who dismiss telecommuters are going to look like flat earthers. There are a range of forces which mean that telecommuting and telerobotic working will become more common, such as rising energy prices, environmental regulations and changes in demographics.

Agreed. The demand for gasoline and oil and cars themselves should go way down if there's a massive drop in the automobile commuting demographic. And air pollution drops. Wear and tear on roads drops, so less money spent on maintaining that, so less pressure on local government budgets. Less road accidents, so less costs spent on police and ambulance related to that, plus less health care costs and car damage and loss of life. Less traffic/gridlock during the rush hour periods of the day. Many benefits from an increase in telecommuting.

With the aging workforce in Japan, Europe and North America telecommuting and telerobotics will mean that people who have physical mobility impairments will still be able to continue in active employment for longer than would previously have been the case.

I agree with the author's point. An organization that dismisses telecommute as an option, is closing doors on a whole bunch of "10X" programmers. Which probably means that the current lot is not "10X".

I wouldn't want to work for a supervisor (and a team) that needs to "see" the team members everyday to make sure they are doing their job. The military Command and Control management style doesn't work on programmers.

One comment I do have is that author shold run spell check on the atricle and correct some of the grammer. But the point is well taken.

One comment I do have is that author shold run spell check on the atricle and correct some of the grammer

"grammer" -> "grammar"

"everyday" -> "every day"

". Which" -> ", which"

(just to name a few)

Yes also "shold" and "atricle". I am the only one thinking that sentence was written with errors intentionally? No other has that amount of errors.

Supporting telecommuting workers from out of state can be a big financial hassle as it may be enough to establish nexus in the state, which will force your company to collect sales tax there.

Might be a cultural thing, but I've worked for multiple companies out of California that did not set up in other states. I know because I had to pay nearly 90% of the normal California income tax, and the income tax of the state I was living in.

Agreed it can be an issue, but one that a lot of Valley companies seem to be ignoring.

I require all of my programmers to be on site, not because of any need to monitor what they're doing (Pivotal Tracker, source control, IM, and email take care of most of that for us, even while we're in the office) but to have the kind of conversations that can only happen when you have a bunch of engineers around a white board trying to solve a hard problem (no, IRC is not the same thing).

I still haven't come across a tool that allows telecommuters to replicate this process.

Couple of questions for you then:

* Do you do this every day?

* If so, do you get anything done?

I only being slightly facetious. I agree that there's a lot to be said for brainstorming in person. I'd also argue that there's a lot to be said for brainstorming out of your normal environment (i.e., office). But you don't do this every day. You code every day. Why not rent out some office/conference space for an afternoon every few weeks as you ramp up on your next iteration and save the money on the office space all the while allowing your programmers to be more productive?

Yes, discussions between programmers about how to best implement things happen every day.

We work in an open work space, and I can't even count the number of times that someone has jumped into a discussion with a better idea of how to implement something. If that saves the original people a couple of hours (or days, etc) then we've immediately increased productivity.

I don't buy into the idea that being "more productive" means sitting by yourself in your home office cranking out code.

It takes at least 15 minutes for people to get back into a productive working state after being interrupted.

If you interrupt an office of 8 and one person has an idea that saves 2 hours, you are only breaking even.

I worked in an open space before and it drove me nuts until I finally left. It was fine when there was just a few of us but as they started adding more people, the number of interruptions started to go up exponentially until some days it seemed like I was being interrupted all the time.

I hate open plan offices especially when they're shared across multiple work groups, functional areas (e.g. devs sharing with phone ad sales!), or even worse, companies.

I think the happy medium is some flexibility among telecommuting, private offices, group work areas (taking over a conference room, or something less formal), and informal mixing areas. There is no single office environment which is best for all tasks.

I'm at my most productive by telecommuting from home one day a week, and daily from 0600 to 1000 (not always on the main company project); then working in the office, meeting with clients outside, etc. from 1000 to 1800, and then whatever team building, client events, etc. from 1800 to 0000.

Like most things in life, it depends. Just because it didn't work in your case doesn't mean it never works, that it's never a good idea, and that it's always a waste of time. For us, it's turned out to work really well, and we feel like the benefits outweigh the costs. Your mileage will vary.

For some reason, though, this is a subject on which many people feel qualified to make pronouncements about the wisdom of what other people are doing. I have, for example, had a candidate come in for an interview, look at the office layout, lecture me for 15 minutes about how we must be idiots because we're killing our productivity with our open layout, and then leave because he'd refuse to work in a place like that. At least it saved me the other 45 minutes I would have had to spend interviewing the guy.

There's a cynical side in me which makes me wonder if companies that embrace all of open floor plan, fixed working hours (implicit requirement due to practices such as daily 9:30 stand-up meetings), required physical presence are specifically trying to make sure that engineers aren't solving any difficult problems: to make sure the engineers are interchangeable components, as well as that the company adds as little value as possible to their customers (while still wringing profit out of them).

Incidentally, no sane software company that I know off is rigorous about enforcing all three in all circumstances. The places I've seen hailed as successes of upper-case-A Agile, on the other hand, are typically gluing together software other people have written (without modifying the software itself, unlike legitimate open source companies) with very little value being added.

Disclaimer: I have nothing against lower-case-a agile, that is developing software iteratively and ensuring a large suite of tests to allow for rapid refactoring; it's the right tool for many (but not all) problems. Upper-case-A Agile (Scrum, XP, etc...) and "TDD", on the other hand, just smell wrong.

> to make sure the engineers are interchangeable components, as well as that the company adds as little value as possible to their customers (while still wringing profit out of them).

Wow, you actually describe the place I worked pretty accurately according to what I witnessed there.

It takes at least 15 minutes for people to get back into a productive working state after being interrupted.

In my (somewhat limited) experience, it's actually "up to 15 minutes", depending on what I was doing. If it's something relatively mindless, I'll be back to work in maybe 30 seconds to 2 minutes; if it's more involved I'll go over my notes (some of which I wrote down immediately at the start of the interruption) and pick up about where I was after 5-10 minutes.

If it takes you 15+ minutes to swap back in after an interruption, you're trying to keep entirely too much state only in your head.

Perhaps instead of down-voting this you can simply reply to it.

Unless of course you don't think that discussions happen everyday or that it's not ultimately saving us time.

Discussions like that can happen on IRC. @mattm is correct, you're taking the whole team for a few hours (or maybe days) saved, you're on the raw end of the deal. There's nothing saying that type of conversation requires high-bandwidth communication. It's often more efficient to have one programmer waiting on a response in IRC rather than interrupting the entire group.

You're optimizing for the 5% instead of the 95%. I think this is a case of a survivor bias---you remember all of the times having people in the same space saved time and forget all the ideas that went nowhere and interruptions that pulled someone out of the groove.

I solve hard problems better when I have quiet time where I can think through the problem. Some people do think by talking but I imagine most engineers do not fall into this category.

Many companies, software (Facebook) and otherwise (Toyota) have open layouts to encourage problem solving in groups.

Most of the good engineers I know are just as adept at hashing out a solution on a whiteboard as they are doing it quietly by themselves, and, given the sample set that I've seen over the years, I've found that the collaborative solutions tends to be better.

Effectiveness of group brainstorming was disproven years ago.

Do you have a reference for this? I'd be interested in reading it.

If you can find a copy of 59 Seconds, by Richard Wiseman, it's mentioned in there (with references, if I remember correctly). I don't have my copy handy.

Problem solving is not the same thing as brainstorming. Brainstorming is deliberately loosely structured and undirected. A group of engineers huddled around a whiteboard or a monitor are exactly the opposite: highly focused on the details of a single problem.

Frankly, I hate those open layouts. And please understand: this is not an either/or equation. I agree that group problem solving can be very effective. But a company with good workflow will have large rooms devoted to group work like that. If I'm working as a programmer or engineer, I want a real office with a door that closes. Under normal circumstances, lack of interruption in your work environment is the biggest factor I've found in increasing productivity.

Being a 'real' in-person employee doesn't mean you don't have quiet time to think through problems.

I 100% agree with you. I've both telecommuted and worked in-person, and there is nothing that beats face to face interaction. Period.

The 'oh I need alone time to solve problems' excuse is as awful and trite a cliché as 'programmers drink Mt. Dew and live in the basement'.

Being an in-person employee does not mean you're working in an mega-corporate shackled environment damaging to your fragile hacker self -- it means you are simply able to directly and immediately converse with your coworkers. Excited hackers stammering out 'HOLY CRAP GUYS I FIGURED OUT THE CACHING PROBLEM What do you think about XYZ?' and the ensuing flurry of discussion is not something duplicated via IRC/email.

Overwhelmingly, I have found that the thought process I use to solve technical problems is utterly crippled by any sort of interaction with other people.

When I've tried collaborative sessions of this sort, they have become prolonged debates over some mediocre solution. Often, a superior solution starts to take shape in my mind, but I'm too distracted by the conversation to develop it. If I bring my unformed idea into the conversation, I'm bombarded with questions that I can't answer yet, and I'm still too distracted to do the actual thinking I would need to answer them. Whatever solution comes out of this, I will inevitably end up improving it dramatically when I have a chance to reflect on it in solitude.

My realtime creative thought process just does not scale to multiple brains.

However, I can certainly collaborate in non-realtime. That is, through email, or some other asynchronous medium that gives me unlimited time for solitary thought.

I don't want to seem like a megalomaniac, but this really is how it works for me, based on a decade of experience. And I don't think I'm an anomaly among programmers, at least not good ones.

Posts that are written this poorly do not inspire confidence in the author's conclusions.

Patches welcome: http://github.com/tswicegood/travisswicegood.com/

It's your responsibility to argue your position rationally and eloquently. Your opinions are not a public good that others aught to participate in perfecting.

s/aught/ought

:-)

Irony alert: you probably meant "ought"

I agree with the first sentence entirely. The second sentence is not so hot, disabusing people of their misconceptions and reinforcing their logical positions is absolutely something that should be considered a public good.

This is the root of the sunlight is the best disinfectant argument; that no matter how offensive or absurd the position presented, at least it has the opportunity to be subject to peer review.

Requiring someone be in a certain place for a certain amount of time is pretty stupid, but it's worth pointing out that it's very difficult to point to successful startups where the founders were telecommuting in the early days.

I only care about output, but I think you get significantly more output in certain situations by being in the same room and informally bouncing ideas around or asking for help.

I think it depends on what level of position you're looking for. I wouldn't hire a rookie for a telecommute job. I want to be able to mentor that person in person.

I think he addressed that implicitly in his emphasis on hiring the best, e.g. "Hiring someone good is important, but hiring the best you can afford isn’t."

When you hire a rookie, you're trying to create the best through mentoring, providing experience, etc. It's a great and very productive thing to do if you can afford it but it's not the sort of position he's talking about.

I would add this caveat though. If I'm hiring a rookie and I wouldn't trust them to be able to get up to speed and be able to contribute without constant supervision, I would pass. Yes, when someone's just starting out that person-to-person interaction is great, but that can be accomplished with an open Skype/iChat video window and some desktop sharing.

hga hit the nail on the head though - I'm not talking about every hire, I'm talking about bringing someone onto a team that can "hit the ground running" with a "large and evolved codebase" or any other of the number of things tech companies/recruiters talk about.

I recently talked to one fairly established company out of Chicago who was looking for a new lead dev for a re-architect they were doing of their system because their in-house guy botched it. The second I said that moving wasn't high on my list of things to do they were gone. They wanted a "rock star", so long as they set the terms.

How about that they are a government contractor and have to comply with federal regulations regarding work schedule? Uncle Sam wants to see asses in seats for at least 40 hours/week, according to some fixed schedule, which schedule must be approved by a certain government agency. If you are such a contractor, your options are to require that all employees be in the office between X o'clock and Y o'clock, or lose the contract.

Or said government contractor could be forbidden from using any kind of telecommuting technology because employees are not allowed to remove sensitive data from the premises.

Yes, the author of this post clearly has no idea about enterprise/government security policies -- they exist for security and for contractual compliance. He used the example of Manning in Iraq (who was allegedly inside a SCIF, but consciously violated security policy, whether or not you think what he did was right) -- the purpose of all of that is to make sure your honest and trustworthy employees aren't accidentally compromising sensitive information, and to protect from outsiders. You don't body cavity search your own cleared engineers because that is not generally the threat, and it's highly invasive.

There is information protected against willful disclosure by trusted individuals, and that information is kept inside a hardware security module and/or is never accessible to individuals. e.g. nuclear weapons have a "no lone zone" around them, such that if any person (even the commander of the base) is in that space alone, he is presumed to be doing something evil, and is supposed to be stopped (using lethal force if necessary) on sight.

That level of security just isn't warranted for most things, but "work on material in a secure room, and the information doesn't leave the room except by defined channels" is a pretty good level of security. DoD has a lot of security vulnerabilities, but security would not be improved by allowing telecommuting!

It's not that companies regard it as a technical challenge, telecommuting is a communications challenge.

When people are in your office and they are part of your team, decisions get made much faster and everybody feels the energy.

We have done both, and our best productivity came from people being in our office.

The author isn't factoring in HOW the company writes software...it's not just about what language a company uses. That's a small piece of the puzzle.

What if the company uses an agile approach to development? Maybe they pair program. That would be a little tough for someone to participate in while telecommuting...sure, technically it can be accomplished but that's not really how pair programming is done.

But this broad brush used to paint companies that simply say they don't telecommute as "not getting it" is a little lame.

I disagree here (obviously). Hiding behind agile (in any flavor) as a reason to not allow telecommuting is just that, hiding. I've known plenty of teams who have successfully pair programmed trans-continent.

It can be done. Maybe it is more challenging, but I don't think "agile" automatically rules it out.

> It can be done. Maybe it is more challenging [...]

The only thing that's challenging about it is that you have to take some time to meet in person so people get a feeling for each others sense of humor, etc. We do this 3-4 times a year--rent a vacation home for a week and work in person for a while just to gel the team. Once you have a team that knows each other it works great.

Completely agree. A lot of MBA types (sorry for the overly broad generalization here) seem to have gotten the idea that every day should be a team building exercise and you can obviously only do those on site where you can take foam bats to each other and have the best ideas rise to the top.

Seriously though, that's what a lot of these arguments sound like to me.

The author isn't factoring in HOW the company writes software...it's not just about what language a company uses. That's a small piece of the puzzle.

Did we read different articles? Because I didn't see any arguments based on what language a company uses having anything to do with the ability to telecommute.

I made an aside to Django vs Drupal and a few people have seized on it. My bad, I took a cheap shot that detracted from the overall point. :-/

I'd be interested to hear more about this though.

> What if the company uses an agile approach to development? Maybe they pair program.

I pair program every day over voip and tmux. It works great; there's absolutely nothing about being remote that precludes pairing as long as you have a stable 'net connection.

Pair programming is worth discussing.

I've tried pair programming in person, and it's almost impossible for me. I have vision problems, and I just really need my own monitor, configured how I want it, with me sitting squarely in front of it. But even beyond that issue, I'm enough of an introvert that I have a whole set up thoughts running through my head when I'm in a social situation, monitoring myself for the image I'm presenting, and the other person for how they're reacting. I can still work, but it definitely takes up some bandwidth, kind of like if I'm working while speaking a foreign language.

But the experience of remote paired work has been surprisingly good, for more than just the vision reason. I'm started recently on a completely-remote development job, with the team spread across multiple continents. No pair programming yet, but I just got off a call a few hours ago where I worked with another developer for more than an hour, troubleshooting build issues.

- Whoever is driving shares their screen, but we both still have access to our own computers, so there's no "hang on, lemme run back to my PC to double-check my notes there...".

- You're never forced to code with someone else's computer/keyboard/monitor/mouse/system setup/chair/etc.

- No awkwardly bumping knees or elbows, no worries about the other programmer having overpowering coffee breath or odd physical tics, being distractingly unattractive or attractive, etc..

So YMMV, but personally I'd rather do pair programming this way even if I was at the office.

Side note: I am simply unavailable for jobs that don't allow telecommuting; that's been the case for years now.

> So YMMV, but personally I'd rather do pair programming this way even if I was at the office.

After a year or so of remote pairing I strongly agree. Among other things, no more dvorak/qwerty conflict is great.

Reply on news.ycombinator.com