Gamasutra: The Art & Business of Making Gamesspacer
Working Remotely: Yes, It Sounds Good, But How Do You Actually Do It?

Printer-Friendly VersionPrinter-Friendly Version
View All     RSS
April 25, 2014
arrowPress Releases
April 25, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM TechWeb sites:


 
Working Remotely: Yes, It Sounds Good, But How Do You Actually Do It?

July 24, 2008 Article Start Previous Page 2 of 4 Next
 

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


Article Start Previous Page 2 of 4 Next

Related Jobs

Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States
[04.24.14]

Principal / Lead Rendering Engineer
Gearbox Software
Gearbox Software — Plano, Texas, United States
[04.24.14]

Graphics Programmer
Turtle Beach
Turtle Beach — San Diego, California, United States
[04.24.14]

SENIOR C# SOFTWARE ENGINEER
SOAR Inc.
SOAR Inc. — Mountain View, California, United States
[04.24.14]

Unity 3D MiniGame Programmer (and Designer)






Comments


Anonymous
profile image
Overall i thought this article was ok, and made a few valid points, but really much of the author's attitude was so "corporate antiquated-biased" it was hard not to laugh. For example:



/ in response to #3 - metrics for remote workers /

"make most of the measurement metrics for getting stuff done very public and understood, as well as the measurements you expect from people. "

&

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



You're "pre-gaming" employees so they don't "game"? So you justify your manipulation of others to prevent manipulation by others? Which school of math did you learn that in?



When will companies learn that satisfied employees don't try to cheat and won't try to "game the system"? I guess when companies stop treating workers like cattle & slaves instead of treating them as the people who do most of the work in the company (and I'm not just talking about giving lip-service, I'm talking equal profits as to the so-called managers & leaders).



Capitalist double-speak at it's finest.



/ in response to #10 - documentation /

"Huge amounts of well organized documentation are a must."



No they're not actually. Tight focused game designs are a must. Smaller documents with more concise and clear information are a must (heard of a Wiki?). But don't make work just to work; more than half the workers won't read it all anyway.



/ in response to #16 - communication /

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



Don't make workers do this, they have enough to do. How about this instead: Have the Producers seek and get this information with a eye to minimizing the disruption to the staff.



It's a crazy idea... you know, Producers who actually do something useful instead of pomping around like they're the leader who makes the difference (hint; they're not). Producers: if you need your team to email you everything to know what is going on, then you're not doing your job well enough.





Here's another article:

You want good workers remote or otherwise, follow these steps:



A) hire Adults - you know, those "other" workers that have "some" refined sense of professionalism, not the typical naive / cheap college grads who will work for nothing. You want to save on money by hiring kids, then you spend it all implementing antiquated systems designed to keep the "kids" in line. Sounds bass-ackwards doesn't it?



B) Keep the focus on the work output, not on the time put in. Try dropping that BS notion that you have to drive workers to the brink of exhaustion before you get any value out of them.



C) Be polite and courtesy to the worker's time needs. Real professionals manage their own time and if you encourage and empower them to do so, you'll get it back double (how else will your workers who don't manage time so well, learn to do so?)



Really, If they're getting their work done, then there should be no question, even if they're not chained to the desk on your beck & call. So next time, if they're not there after you send an IM every 10 minutes for an hour, it's not cause for punishment. Grow up and realize that workers are adults (if you've hired adults that is, see item A) and they'll get back to you (just like Mr. Manager would get back to you on his time, when deciding not to answer the phone for a little while).



D) Share the wealth; the teams that do successful games, and contribute the most should be paid at least as much as the managers on up.



There is no "I" in team right? Oh how quickly managers forget that when it comes time to divvy up the profits. Don't exploit your workers, work with them and everybody wins.





In short, stop treating workers like children, communicate clearly, respectfully and without manipulation (unless you want it in return), and you'll get a lot more out of them.



And if you don't believe me, if you think you've got it all figured out already because some school of business taught you otherwise, just try it... you'll become a believer (I did).



-- game maker who has worked remotely for over 6 years

B N
profile image
Your hire adults point is not practical because if the college grads don't get a job in the industry then they'll never become those professionals you speak of. It might work for you to hire like that, but to put it in a step by step guide to tell everyone to do it doesn't make much sense. The rest of your points are things that could be applied forever to any team and all teams and they would be beneficial so they're good for a guide.

Ondrej Spanel
profile image
We are doing some remote work, but are still missing some decent environment to allow us "shared" drawing / document editing / desktop sharing. Some tools look promising, but each we have tried so far proved not mature enough to be usable at all.



When reading "board sharing mechanism (more on this later)" I hoped I may learn something about some such tool, but unfortunately this was not mentioned any more.

Douglas Walker
profile image
Try http://www.mimio.com. This is a nice little product that really does work. It's around US$900, though, so you may not be able to afford one for each remote worker.

Maurício Gomes
profile image
I am a student, and I am running a team of people over the internet (mostly because I can not pay to them move, neither I can move away from the university), and it works well...



About the anonymous post: Children in team? I never found one on mine, even me allowing anyone to join!



People that do not get their things done? Indeed, that exists, but I do not give anything to them until they deliver what they need to do, the secret is to assign to them things that are not necessary to others (ie: like assign to a concept artist, a concept art that you will use way later, or of a secondary character)



Believing that people will not try to cheat you even when they are happy? Common, humans are natural cheaters, I see everyday people cheating employers here, what the employers need to do is minimize the cheating, and minize the damage done (ex: I knew a company that made the employees really happy, paying them much more than other companies, everyone wanted to work there, and the first month they had bizarrely huge profits with such motivated people doing great work... On the first day after the first pay, NOONE showed up... The employer went around asking why, and discovered: He paid so much to his employees, that they got the money and went to do something else (like plainly not working until the money ran out, or using the money to set-up a small local store))

Sebastian Bender
profile image
The article seems to be written by someone who already failed bad with working remotely. But the hints are appreciated since I myself encounter some of the mentioned problems working with a team of students. There's a huge difference from professionals to students but I highly doubt that every professional really works professionally. At least I see proof in other industries.

One bullet bugs me though: #16 states that weekly "status reports" are necessary. I have to agree to Anonymous that this causes lots of overhead for workers. A better solution may be to break down tasks into tiniest bits and have an estimation on working time given by the proper worker. Even when working remotely you have to claim a certain amount of labor time. So when the estimate on the task is due or the task is done the worker reports status to the producer, otherwise the producer asks for it. If estimates exceed i.e 16 hours of working time, set the report interval at every iteration of 16 hours labor time.

Anonymous
profile image
To an extent, much of the tidbits overlay with agile and Scrum development. This makes sense as the practices of agile and Scrum rely heavily on independent, self-motivated teams working on small chunks which then are handed into a bigger plan.



Now, for some replies.



Anon 1, Point 1: True, I agree... but you must consider that not all employees, even satisfied ones, are not above gaming the system. Some do so unintentionally - a person who is a little bit of a lone wolf may not intend to scoop up other people's work, oblivious that it is someone elses work. Others, may do so simply out of self-interest - they don't see it as harming anyone or at least, the company (and it may not in any way beyond how they work with others); someone may see the work as, incorrectly, a competition and thus may jump the gun and appear better than what they are, forcing others to cover the details. Gaming systems happen even with the best of intentions and the best of employees; it's just most is little white lies. You plan time off not based on what your company wants but what you want - that's gaming the system too. Capitalist companies are ultimately built from people - you can't fault a company on a people problem nor can you rely upon pure systems to fix a people problem. People problems require people.



Anon 1, point 2: You're both making the same point. The point is that information should both be plentiful (people shouldn't be left with too many questions as to what they're to do, how to do it, and who they can talk to) and readily available. Just as too much information can clog the system, too much conciseness or generalness can too - as the article mentions, giving someone the broad task of "Make better camera system" doesn't mean much beyond a general idea of what to work on. It says nothing about what others in the company think needs improving (it's too loose), what the current status of the camera system is (we haven't finalized it so try a variety of things to see what works), and what have you.



Anon 1, Point 3: Yes, you're right; higher ups should be proactive in getting information so they know where they can help. But you're also wrong - higher ups should be able to trust their employees to be responsible adults and be able to say "Here's what I did this week" without humming and hawing. Likewise, some people may work better without feeling like the higher up is always watching over their shoulder - having higher ups always ask "What's going on" can be just as detrimental. If nothing else, it makes it look like they -don't- know what's going on or are just nosy. The point is, that communication is a two-way street. Higher ups don't just talk at underlings and then wander off... but neither should underlings not say anything at all and then feel like they're working in isolation. The point is, people need to let everyone know what they're doing, how they're doing, and what others can do to help. Not communication just creates obstacles - if the producer doesn't know what kind of problems the sound team is having or the sound team doesn't let anyone know, then that causes problems.



People need ways of getting information as well as networking with others in the company and seeing what the entirety of the product is. Too self-contained and people end up missing the forest for the trees. Whether a weekly formal report, a weekly quick email, a daily To do, or whatever, such a thing is as helpful to the employee as it is to higher ups. It helps keep things in perspective and realize progress within context of a greater whole. And it helps the employees feel like they're a part of something - they're telling other people what they did not other people telling them they didn't do something. And yes, this can go to the extreme and be bad too - the key is to find a good balance (for everyone) between too much time spent working on meetings and reports (even informal ones) and too little time keeping everyone up to date.



Anon 1, Hire Adults: Invalid argument. 'Adults' can be equally as disruptive as 'kids' and 'kids' can be just as productive and professional as 'adults'. You don't need to be 40 with 20 years of work experience to be a hard working person. And you don't need to be a 22 year old with a dream to be a dick (or just lacking in some way). Again, people are people - some are naturally bad apples, some are naturally good ones. And just because someone enjoys playing ping pong on breaks doesn't mean they aren't extremely professional when on the job for the other 23 hours of the day.



Anon 1, Point B: That's pretty much what the article talked about. Results.



Anon 1, Point C: Again, that's exactly what the article said. Giving people the tools and allowing them to handle things on their own while at the same time expecting results (Point B). The article didn't say to chain people to a virtual desk. It just said to make sure that when you ask someone to do a task, they'll do it as a adult individual and in a timely manner. Not running around in their underwear and then cramming it in at the end of the work week.



Anon 1, Point D: Ditto; see previous.



Anon 1, Overall Re: True - respect, trust, and what not go hand in hand with good company culture. But, like anything, that takes work and, more importantly, that is something fairly unique to each company. The article isn't saying to manipulate people (at least, not intentionally) - rather, the article is saying that companies and everyone in it need to make sure that they're working hard AT BEING A COMPANY together. That's the same thing you're saying too.



Filho: If the person has a history of not getting things done and taking way too much time, why are you keeping them around? You said yourself that they're working on things that aren't of importance. Why not get someone else who -will- get things done and do so on time that you can then have help out with important things and allow the smaller things to be spread more evenly among everyone? All that retaining that employee does is create procrastination.



Bender (Heh... Bender): That's a part of what makes agile and Scrum development work. Big things are broken down into small things that can be done in a known X time (4 weeks for instance). Workers (and teams) pick what they want to work on and work on that; they then report on what they did so that everyone else knows. Thus, at any given time, anyone can see what's being worked on and where the project is. If something goes wrong, it's easy to find out where and ask what can be done to help (or, if needed, re-iterate and re-try again in the next sprint).

Anonymous
profile image
I've never worked for a company that didn't do some type of remote work, and in today's industry it's a must, but I feel that having a bulk of your work force remote is foolish.



1. Communication: First off remote communication skills will never be as good as face-to-face. Normally companies start out w/ e-mail and messengers to communicate then they learn they are missing out on subltle timing, and tone of speach so they upgrade to VOIP until they realize body language is also essential. Eventually your communication is so complicated you've spent more time, and money on it than you ever could at the office.



2. Bandwidth: I tend to use 30 gigs of bandwidth on a heavy day, and probably closer to 6 gigs on my light days. Now I'm probably not the most efficient person with what I grab, but in the game industry you tend to need a lot of large files fast. So a domestic ISP tends to be out of the question, and buying commercial quality bandwidth for about 30+ employees is out of the question.



Time Zones: Ok it may not seem like a big deal, and for some it's actually not, but for others it's a major problem. If your team is spread across the nation you tend to have your east coast people staying late, or ducking out before work is done, and you end up waiting on the west coast people all the time. This tends to add some stress on certain employees who aren't geared for a flexible schedule.



Problems: Every project runs into problems, and the smart companies have plans for them. Unfortunately with remote working problems are harder to report, find, and fix until it's too late. What may only be a tiny problem at the office turns into a major problem remotely.



Work ethic: Even in the office it's hard to tell who is actually working hard and who is slacking off a bit. Good management can normally tell the best, and the worst, but as for everybody in the middle they are pretty much lost. The main problem is time estimates are often hard to predict. What seems like an easy job ends up being very hard, and what was seemingly a hard job actually ends up a breeze. After a while you're promoting bad employees while hindering the good ones.

Roberto Alfonso
profile image
I don't work in the gaming industry, but am also a software developer. Fortunately, I can work from home whenever I want (rainy or very cold days, for example). After being almost six years in the same company, I can say you work much more relaxed than at the office. However, there are synchronization problems. It is best when every team member knows exactly what is needed (for example, the API is already finished and you actually only need to code the implementation). However, design cannot be made remotely, you must be there to discuss.



At least, that is my personal experience. I am two hours and a half away from the office, so working from home saves me 5 hours which, while not completely used for working, gives me an extra objective finished per day.

Anonymous
profile image
Anon 26 Jul: Article mentions this and strongly advises voice communication with video. The ready available of webcams and voice chat makes this easy. While it may not be exactly face-to-face, it covers a good bit of ground. This also isn't to say that face-to-face doesn't have it's advantages - which is why the article also strongly suggests regular face-to-face meetings.



Likewise, the article suggests either automated updating when no one is working (overnight) or regular physical mailings (DVDs) to compensate for the size.



The article also notes that not everyone works well in a remote environment even if they are good workers themselves. The needs of a remote environment tend to change the idea of sitting all together for 8 hours - it's fine, basically, that everyone has different schedules so long as things get done and everyone is up to date.



To be fair, office problems can be equally big and remote can negate some of the bigger ones. Office problems can just as easily go unrecognized. Problems arise no matter what or how you work - it takes the people to recognize that and prevent that from occurring.



The article also notes on the matter of work ethics, touching on the need for metrics and looking for results, among other things. As for the idea of time estimates themselves, this is not a problem with remote work itself but rather development practices (as far as video games go) - and this is where better practices (which work for office or remote alike) come in to play. As the article mentions, giving out a task like "Make a camera" isn't something you can time estimate. You can, strictly speaking, but you won't be any where near accurate. Instead, small easily estimated tasks are required - "Come up with an idea for a new camera system and provide pseudo code that meets X requirements" or "Provide six temporary textures for Monster Y so we can see how the new model reacts in game"; these are tasks that can be measured (for productivity), provide manageable time estimates (anyone with even basic experience in a discipline should be able to guess very accurately how long a basic task will take), and are basic enough that easy/hard are much smaller in scale.



Alfonso: Article suggests that; very strongly in fact that some things, like design or code jams, are best done face to face.



Again, though, the article suggests doing so in a efficient way

Chris Oltyan
profile image
Having worked with a completely remote team the past 8 months, I'll happily tell the naysayers that it can indeed work. We've successfully delivered milestones on complicated projects (an MMO) even though we encountered any number of blockers and bizarre problems.



Furthermore, we were able to be Agile in our development by opening communication bandwidth on a variety of channels. Video, we found, actually was a hindrance in some instances and collaborative workspace tools gave us the real "face to face" that we needed to identify and solve problems. It took a few months to work out the kinks, but at the end we had a very organized, communicative, and collaborative team producing quality content on a regular and predictable schedule.

Anne Toole
profile image
As game writers, we almost always work remotely, so I am intimate with the problems discussed. In response to the required weekly e-mails communication, in our experience it's best to find out what works best for each person. Some developers want to hear from us a lot -- others, not so much. Some want us to ask questions as we come across them via e-mail, while others want us to save questions up for a phone conference. It's important to have these expectations laid out, whatever they may be, and adjust them as needed.



I write frequently for developers outsourcing and working with remote writers. These tips will easily apply to other remote workers. Here's part of a series on outsourcing specifically about communication with remote workers:

http://writerscabal.wordpress.com/2007/03/21/helping-the-writer-g
et-it-part-3/ Tell us how this works for you!

Jake Simpson
profile image
As the original author there are a couple of comments I would make.



"When reading "board sharing mechanism (more on this later)" I hoped I may learn something about some such tool, but unfortunately this was not mentioned any more."

You are 100% correct and that was my omission. Mimeo was one such tool, as is www.gotomeeting.com. I completely missed that I had omitted these. Apologies.



For those that are naysayers, I would point out that far from being 'foolish' this can work. Linden Lab does it every day, using exactly the kinds of approaches outlined in the article; indeed it is derived from my working day. Far from failing miserably at working remotely (which is such a strange thing to say? I mean I write an article saying It Can Work And This Is How It Can Work, and I'm told I fail miserably at it?? Really??), it's been a great experience. Sure there are stumbling blocks, but that's what is great about it, learning and figuring out solutions so it can work better.



It's possible. I am doing it. It is working. Therefore I don't honestly believe the description 'foolish' is applicable. It's only foolish if you walk into it expecting it to be like normal development. It's not, hence the point out it being a mindset. If you have the wrong managers trying to manage people like they are in an office then yes, it won't work. But that's about mangers, not about the approach.



If you've been part of something like this that has failed in the past, what do you do? If you have network code that hasn't worked for you in the past, do you go online and comment on articles about network code and say "This is foolish, it can't work"? No, you go learn how it *can* work, hence the article itself.



In terms of hiring 'adults' well yes, I would hope everywhere does. However that isn't the case and virtually it's no different. It does take a specific view point to make virtual working work out, but I think the point has been made that this isn't for everyone, any more than working in an office is for tour de france riders, hence the requirement for a probationary period.



Working remotely is about what you want to put into it. Quite a lot of whats necessary to make it work is the same as what you'd need with people in an office. Tracking metrics need to be there regardless of whether you have bums on seats in proximity to you or not. They are just highlighted as a requirement when most are virtual.

Tom Henderson
profile image
As a general case I don't think working remotely is a good fit for game development, although I'm sure their are specific teams and specific roles that are more amenable to it. I don't think I'm a "naysayer" although I may be an old fogey, I just don't see how you could get the high level of easy constant interaction between your designers, prgorammers and artists that is so important to the process. My (asmittedly limted) experience with collabaration communication software leads me to believe its a poor substituite for being able to grab a few people and jump on a idea, or work a really tough bug through.



I understand there are all kinds of collabaritive communication softwar


none
 
Comment: