[Can the game industry make telecommuting work for its employees? Midway and Maxis veteran Simpson looks in detail at how game developers can set up a remote working-friendly ethos - and make better games along the way.]

It sounds like Nirvana, everyone working where they want to, being productive and happy in their personal environments. It's long been touted as the wave of the future, the way we will all work in the 2010s and 2020s.

Some companies even have it going on and working. Or do they? There's much talk about "telecommuting", but what, when it gets down to it, does it actually mean? And is it something you can set up too?

There are several things to consider when talking about setting this situation up, so let's ask some of those questions.

Why Even Work from Home?

The first thing to do is weigh up the pros and cons of this approach to development - why do you want to do it (beyond the cool factor of "being on the edge" and being in Wired)?

There are several reasons for - you may be cash-strapped and moving the talent you need from across the country may be beyond you. It's entirely possible that where you are physically based makes sense for some reasons, but not from the talent pool approach - building a game development studio in Oklahoma may make sense from an office overhead point of view, but in terms of local talent, less so. The games industry is full of specialization these days - finding that right rendering guy out in Idaho who can't move might be exactly what you need.

There's also the aspect of making your employees happy - making them take a day off because the cable guy is going to show up blows from the employee's point of view. Plus, there's the commute factor, which in big cities can add hours to your day.

Maybe you are just boot strapping a company and need people who are not local to you, and can't afford an office - or maybe you want to use contractors and this is the first step in setting up an environment where remote contractors can work for you.

Lastly the idea of working from home actually promotes extra work because people who work at home - if they are engaged - typically don't clock watch and you'll find you get way more out of them than otherwise, particularly if they are single. That's a bit of a cynical reason to decide to go with the remote option, but it is a reality.

There are many reasons why you might want to do this. However, there are as many cons as pros. You - as an employer - may just not believe in this approach, preferring to have your people present and correct day-in, day-out. You may be doing stuff that requires a high degree of constant and local collaboration - something being remote always makes much harder.

You may have other companies want to visit or send people in to help out, or you just might have a group of employees how just can't be trusted to get stuff done without immediate and physical oversight. Epic Games - of Unreal and Gears of War fame - started out as a virtual company back in the early 90's. Head Honcho Tim Sweeney had this to say about their experiments in being virtual:

"We were a "virtual company" with developers spread all over the world from 1992-1997. We started building Unreal that way. The initial core team was James Schmalz in Ontario, Cliff [Bleszinski] in California, me in Maryland. By 1997, the team was up to 18 or so people (including Steve Polge, writing the AI and gameplay code from North Carolina), and the coordination overhead was unworkably high.

What had worked for three people had proven unscalable, especially in regards to coordinating programmers and level designers. When we actually finished the game 12 months later, we realized we needed to set up shop somewhere permanently. "

So obviously it doesn't work for everyone, at least not back in the mid '90s, with their two-slice toasters!

But can it actually work? Tim Sweeney again -

"We've had good experience outsourcing artwork all around the world, so I have no doubt that some job functions work well remotely. Areas that require intense coordination among individuals are less efficient. Certainly, that could be mitigated somewhat by a combination of technology and company processes, which we markedly lacked back in 1997."

Linden Lab (Second Life) operates about 30% of its 200 people remotely, Introversion (Darwinia, Defcon) also operates a loose work-at-home program internally, and Wideload (Stubbs the Zombie, Hail to the Chimp) builds all content via remote contractors, so it's definitely possible.

All In?

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.

Everything or Nothing

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.

Not Me, Guv'nor!

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.

Workin' 9 to 5

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..."

OK, we've spent a lot of time talking about the implications of remote working, how about some practical advice?

Here are some bullet points that will aid in your construction of a remote-friendly infrastructure.

1) Make it available to all. Everyone the company, from the CEO down, should be able to avail themselves of this option should you make it available. If you do it on a case-by-case basis you'll inevitably run into water cooler mutterings and it will implode once people complain that they can't do it too.

2) Make participation and continued employment very much based on results. Sure, you can work from home - however, if you don't get at least as much done from home as you did from the office, then the exercise is over. Working from home comes with responsibility to actually get stuff done.

3) Continuing on from point 2, make most of the measurement metrics for getting stuff done very public and understood, as well as the measurements you expect from people. It is not enough to tell them you are watching their Achievement and Objective emails, you need to tell them what you expect in those emails. If you don't check in for 3 weeks, employees will be asking why.

I say "most" because you don't want every metric made apparent. Once an employee feels he has the measure of the metrics, they are open to gaming. Some hidden metrics - analysis of the check-in frequency or some such - will be necessary to catch those who are gaming your system. And that will happen, by the way. Mark McCubbin, who has been a remote contractor working in the games industry for over 11 years has this to say:

"One thing always difficult is measuring performance of offsite developers, not that in reality they are much different that those bodies sitting in the office warming the seats, however, it's the nature of the beast that being out of sight, there will be some suspicion on hours invested in a given task, and certainly for programmers it rather difficult to control exactly where their time goes. There are two things that have helped smooth this side of things immensely in the past; one is person-to-person video conferencing, even just once or twice a week, and focusing more on macro-goal-based tasking!"

4) Frequent and candid feedback from a manager. When working remotely, you do tend to work in a bit of a vacuum and it can feel very much like you have no idea whether you are doing a good job or not, unless you get lots of feedback. A quarterly review and a weekly virtual meeting with your manager is the least that will be required.

5) Give people what they need to get the job done - don't skimp on buying them a PC and a dev kit for use at home, and pay for things like internet connection and cell phones. Give them no excuse to not be working.

6) Agree on core hours and have some method whereby everyone has to be virtually present for those core hours - AIM, ICQ, IRC, Skype, whatever. You have to be visibly online and available for discussion when you are supposed to be, and there need to be consequences if you aren't (beyond the obvious like physical meetings or bathroom breaks or lunch).

Whatever communications methodology you settle on, it has to have voice and, if possible, some desktop / grease board sharing mechanism (more on this later). The core hour concept can get a bit tricky when it comes to real time zone differences, but generally people who are working remotely do tend to want it to work, so they'll deal with them fairly well.

7) Do your due diligence in both task planning and in technical documentation. Just like in traditional development you need to understand what and how you are going to do it, only this is even more required for remote development.

The individual doing the work needs as much back ground on the task he is going to do because chances are he's not going to spend as much time talking to other people about it as he would if he was onsite, regardless of the good intentions everyone has about "staying in communication". The reality is that the individual is going to make a lot more decisions in a vacuum than you really want, so having as much background as they can is necessary so at least the decisions are as good as they can be.

8) In terms of project task management, tasks that are undertaken by those remotely need to be as stand alone as possible - dependence on other people who are remote is harder to mange (it's possible though) so if there are obvious floating tasks, remote people get those first.

9) Despite point 8, the reality is that some tasks (particularly the building of new systems - for example, a streaming system) will be beyond the scope of one person to design and implement themselves. Obviously collaboration is required.

Realistically, while some of it can be done virtually (using the aforementioned communication systems) some of it will be better off done while in physical proximity to each other - at least at the design stage.

Having a central location where people can come and mingle is a necessity for successful remote working. It's just going to be necessary for people to physically meet for many reasons, if only to get the measure of the people they are working with.

As anyone who's been on a discussion forum knows, a foible of human nature is that if you get an ambiguous message (one that could be intended negatively or positively) from someone you don't know, the natural urge is to take it as a negative and respond in kind. However, if you know that person and have met them and understand how they conduct themselves, it's much easier to understand what the intent was in the first place.

Having static physical contact at some point is both desirable and necessary. How often you do communal get-togethers depends on your requirements and ability to absorb the costs of the travel for everyone. At the very least, it needs to happen at least twice a year

10) Huge amounts of well organized documentation are a must. Given that everyone is remote and while they are supposed to be available to you, they may not be, you need to have static methods of gaining information you require to do your job. A well organized (and up to date) documentation pool (wiki, SharePoint, etc.) is a must, and it must become part of the company culture that everyone spends time on this and updates regularly.

It needs to be the first point of contact for any fact finding, to avoid people complaining that X is not around because they were at a parent/teacher conference. Documenting everything (from game/technical designs, who does what - a real problem about remote is the lack of casual conversations where you learn who everyone is and what they do - to the cheapest hotels around the central office or Person X's house) needs to become a core responsibility for everyone.

11) Have some ability to foster social interactions with your remote workers aside from pure work - a humor mailing list, a love machine (a web based app where one person can send another 'love' - for a particular act above and beyond the call of duty. Every quarter these can be tallied and given as bonus dollars as a small "let me buy you a beer" kind of thing from one employee to another), a book club, regular multiplayer gaming sessions etc.

12) Have a stable and effective task tracking and code library system in place. You need to be able to track what people are doing beyond simple emails, and nothing cuts productivity faster than Perforce / the wiki being down or slow. Being able to know at a glance what everyone is doing - and why - means you can judge their rate of work and also judge how much of the project is actually done.

13) Find as many ways (through tools, pipeline, asset organization, etc.) that you can so that everyone working remotely does NOT require a massive asset dump every time they re-synch. Game assets are traditionally large, so taking an hour to re-get assets every time you do a content synch is a not a good way to spend everyone's time. If need be, set up systems that auto dump new content to a remote PC overnight, or, if a bit low tech, do a weekly DVD mailing. Obviously this does require that all code be backwards tolerant of older asset formats.

14) Have a process code / art / assets / content creation goes through in terms of quality review. Be it code review, art review, whatever. And make sure you do it as soon as is possible from the code / art / whatever is checked in - there's nothing worse than someone coming back to you six months from when you did something saying, "We just looked at this model / texture / sound and it's not what we needed / good enough / high enough quality." The bar of what's expected and what's below that bar needs to be set immediately, and without fail, for everyone, so they know what's expected of them.

15) Fire when you need to, and be open and honest about it. The reality is that not everyone is cut out to be a self-driven individual working from home, and if they aren't performing, they need to be informed of this - and then let go if it persists. While you are giving everyone a metric crapload of space and flexibility to work in, the understanding has to be that in return that which needs to get done does get done. Progress in video games tends to be very visually driven, so be sure that what is being farmed out to remote workers is something you can tell has been completed.

16) You need weekly emails that make everything your employees are working on (and why) completely transparent, plus a follow up email stating what they actually got done and what obstacles they hit and why. It's all very well firing people for not getting stuff done, but you do actually need to know what they are doing and why in order to be able to judge that.

It needs to become company culture that these Achievement and Objective emails are written in such a way that what's being discussed is something traceable and provable. It's not enough to write "Make the camera better" - that's too subjective. Better would be "Try and check in three new camera control methods". That gives a tangible provable task the results of which you can document in your emails.

17) Foster a Write, Think, Re-write method of email communication. When lots of communication is done with simple writing, it's very easy to take stuff out of context and take an offhand comment personally. Emails that might have any controversy or conflict in them need to be written at least twice before they are sent.

And finally...

18) When you hire someone new, have a well thought out "new hire" process to bring them through so they can understand how you work and what's expected of them. For most people this kind of remote working will be a shock to the system, and they will flounder a bit until they understand who does what and how and when they can talk to people.

Working out the processes of a company where you can't lean over a cube and ask someone something is harder than it sounds. So having a good process where there is a mentor for the new employee and a process to follow to get them up to speed as to how things are done and what the level of expectation is (with examples), is an absolute must. Otherwise you'll find yourself losing people very early, and probably end up with some badmouthing around the industry.

---

Photos by eyeliam, Shane Adams, and Eric Schmuttenmaer, used under Creative Commons license.