Deciding you want to try this sets you up for your first set of decisions as a company - to wit, are we talking about full on Working-From-The-Other-Side-of-the-Country or are we talking about the ability to work from home a few days of the week, yet based in a local office?
There is a difference because the former requires a complete building of the infrastructure of your company, its culture and how it does things day-to-day around the concept of telecommuting, whereas the latter usually means tagging on of some extra processes so someone can get some stuff done at home a few times a month - which is not the same thing at all
Either way, some face time will be required at some point - especially when collaborative tasks are undertaken - but there's a need to understand the subtle but very crucial difference of being remote full time and on site occasionally, and the reverse. Tom Arundel of Introversion has this comment -
"We have an office in London which acts as the 'mother-ship'. Whilst we're generally fairly flexible about hours and location everyone gravitates there for meetings and code jams for fixed periods.
Clearly working from home can offer some lifestyle benefits (so long as you have a decent space; for example, I have an attic-office in Germany (I'm here now) / Chris has his dev room in Cambridge kitted out with lots of toys) but it can also hinder the ability to teamwork, hence the requirement for week long intense coding sessions (code jams) where everyone's locked (metaphorically) into a room."
So assuming it's an all-out Working-From-Home decision, on to the next point. Note: some of these points are just as valid even if you aren't going to the full-on Home-Based Development route.
A major idea shift is the understanding that this remote working issue will pervade every part of your development process. Like multiplayer, this is not something you can just tack on as an addition to how you do business currently. To be able to successfully allow people to work from home it has to be part of the core tenets of how you develop, built in from the get-go. There has to be buy in on this approach from everyone.
Working remotely produces a new set of problems that traditional "show up to the office" development just doesn't have, and often it can provide frustration on the part of both the employees as well as the management when something goes off the rails.
This happens and will continue to happen until the company becomes better versed in how to do this properly. However, if this is entered into halfheartedly, then it just gives those who aren't behind it a reason to moan rather than an opportunity to find new ways to make it work.
Something else to consider is the understanding that this is not for everyone. And that goes doubly for managers. To work remotely, successfully, takes a specific frame of mind. You can't just close the office tomorrow, have an infrastructure in place and assume everyone will just do dandy.
There are those who can work remotely and there are those who find it hard - and that's no reflection on those people. It's just simple recognition of the fact that there are people for whom this will not work.
There are those who want to be in an office interacting with people all day and cannot function any other way. However, you need to be able to identify those people when interviewing so you can pass on them if you are 100% working remotely - it'll become very apparent fairly quickly anyway, providing you set up your metrics for measuring effectiveness correctly.
Management is especially hard remotely, particularly if you have people who require micromanaging in order to make progress.
The next thing to think about is the appreciation that the hourly based work day is basically getting tossed out. If you are a manager who likes to know you have a body sitting working hard for eight hours because you are there making sure they are, then this is not going to work for you. Working remotely is all about the results and never about the bum in chair.
Sure, there are ways to ensure that people are actually working for the time they say they are, but you aren't there and you have no idea if they are really spending the last hour working or playing solitaire or whatever. Ultimately the whole concept of clock watching has to go - your metrics (i.e. that which is measurable about what people get done) is about what they get done, not how long they spend doing it.
Another aspect of being remote is the ability to see the wood for the trees, which is a constant seeing-nothing-but-the-office problem. Sometimes it's hard to know what problems are, or how to solve them simply because you are too close to them. Working remotely can help with that. Thomas Arundel again:
"I quite welcome the chance to have some flexibility - it means I can spend some quality time with my kids who live in Germany. Also whilst I'm there, there's an opportunity to get some 'thinking time' - a valuable commodity these days which I rarely get when I'm in London. In building a company there's a lot of scrabbling around in the weeds - a lot of details that you need to get right and sometimes changing location for a bit can help take a different view of where you should be focusing your effort..."