|
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
|
Printer-Friendly Version
/ 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
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.
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))
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.
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).
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.
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.
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
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.
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-get-it-part-3/ Tell us how this works for you!
"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.
I understand there are all kinds of collabaritive communication softwar