Over the last 6 months, I’ve been experimenting with a new lifestyle. I’ve been working on freelancers and a startup, while spending the majority of my time traveling. We already built an amazing game, Card Stories, within a team of people distributed across Europe and South America… All of it while visiting amazing countries like Thailand, France, Brazil, Canada…
When people hear me saying this, it usually raises a few eyebrows:
– “You mean you’re going on holidays, right?”
– “Have fun, but this is going to make communication difficult – you’ll lose focus and go slower”
– “How can you afford this?”
The truth is, it took us a while to figure out how to make this work well. You just can’t expect to work like in a “normal” office – some habits have to be re-learned. But you also get a lot from it. And the usual glittering I see in many eyes when I talk about my lifestyle tells me more people would love to do this. I hope this series can inspire you to do the same : )
In this first post, I’ll focus on some of the methods we used to tackle the issues associated with remote working, especially regarding the communication.
This is one thing I believe we did right from the start – we have (almost) absolute transparency. We realized that compartmentalization of information is counter-productive. It forces you to repeat things, you have to remember who you gave which information to, and it can easily block those who don’t have the information they need if you’re not around.
The beauty of working online is that you don’t need to repeat yourself. CTRL-C CTRL-V does the job for you. And if everything is in the open from the start, you don’t even need to copy it – the person who needs a given information can simply look it up.
Need to remember why we decided to not display ads in the game? Just search the IRC log. Want to know what’s coming up in the development schedule? Just have a look at the backlog on Redmine. Wondering if the latest feature improved player retention? Just browse the stats. If someone has had the information you’re looking for at some point, chances are that you can find it on your own.
This isn’t something only virtual offices benefit from, but it’s much easier when most of the communication happens in written form. I also believe this is one of the main reasons why it’s easier to work remotely when everyone else in the team is also working remotely – when a part of the team is physically at the same place, sometimes it looks like too much effort to write things down. This may seem like a gain of time on the short term, but it also makes it harder to access that information, and also likely increase the amount of communication you’ll need to provide in the future.
A bit like technical debt – you’re trading a short-term time gain for a series of repetitive annoyances and distractions in the future.
Workflow & Communication
This is the point we originally struggled the most with. We had experience with free software projects, we were part of global teams in previous jobs, and I used to do community management for online communities, so we weren’t starting from scratch. But matching the efficiency we take for granted in an office is difficult, especially across different timezones.
An issue when working remotely is that you feel the pain of disorganization much more quickly. When you’re in the same room, adjustments are easier – you can just talk to people around you and figure out what’s needed now.
But when you’re working remotely, what do you do when the people you’d need to talk to are not online? How do you notice when someone is losing motivation or is falling behind? How do you make sure you can take decisions quickly when people are on different timezones and don’t always work at the same time?
Turns out, those are actually very good problems to worry about from the start. We’ve all seen enough dysfunctional workplaces to know that being physically present doesn’t magically make things work efficiently, and at least with a distributed team you feel it very quickly when the organization is faulty – you slow down and stall. It forced us to be well organized.
Scrum was a great source of solutions here. While we don’t apply it strictly everywhere, it has some principles that have proven very helpful to make us efficient:
- Daily meeting: every day at 1:30pm GMT, we meet in the chat and provide a status update to eve, our beloved IRC bot. In 3-4 lines, we say what we worked on over the last day, what we’ll be working on the next day, and if anything is blocking our progress. The whole meeting usually lasts about 10-15 minutes, sometimes a bit more when a subject shows up and requires to find a solution. The great advantage is that you quickly get an insight into what everyone is doing, you feel proud when you can announce a lot of work done, and you get instant feedback on a daily basis. It creates a rhythm, without the need for strict business hours, and you avoid a lot of long “coordination” meetings.
- Weekly sprint: every week, we schedule a set of stories to be done during the week. I won’t go through the details as this would be redundant with most of the SCRUM tutorials, but again this is important to get a rhythm. It also helps making sure that things are written down, correctly explained from the user point of view, with enough information for each contributor to work on his own with few blockers.
We also heavily focus on deliverables (as in freelancing work), rather than attendance (as in employment). Nobody knows how many hours you’ve been working one day, and nobody cares if you wake up late, as long as you deliver. It’s also a very good indicator when something is wrong – if someone fails to deliver over a period of time, everyone notices very quickly, and it’s possible to discuss it.
Another important point: working with good, serious and experienced people. Don’t expect to make this work with cheap coders who struggle all the time. You need to chose people who are good communicators, highly autonomous and who get things done.
Here, we went through quite a few tries before finding what works for us:
This one seemed pretty natural for hackers, but proved to be difficult to use by non-technically minded people. We’re working on a game, so we need to work not only among coders, but also with graphic designers, game designers, story-tellers… A lot of them struggle to handle the flow of emails that a mailing-list generate, even with proper filters configured, and end up not seeing important information.
Plus, emails seem to have a tendency to produce long texts, especially during debates. There is such a thing as too much communication – we wanted to try something that would push us to be more brief.
A social network-like forum based on WordPress, Buddypress is pretty rough around the edges. But when we switched from the mailing list to it, we found that he had the advantage of feeling much more familiar to non-techies, and communicating by status updates encourages short and straight-to-the-point communication.
Archives are easier to access for newcomers, and everyone can finely control his email notification flow without any technical knowledge. It can get a bit messy for longer threads, but bbPress provides the features of a standard forum to take care of the longer discussions, all in one place.
We originally greatly underestimated the importance of the chat. Asynchronous discussions in emails & forums are more thoughtful, and chat discussions can quickly eat a lot of time. It seemed chatting should be the edge case, and in the interest of efficiency only used when asynchronous communication would fail.
Today, it’s our main communication channel, and we use it more than all the other tools combined, maybe with the exception of the ticket tracker. It turns out that asynchronous discussions are missing two key elements – rhythm and feeling of presence.
We can quickly forget about this when we spend our days sending emails in an office – your coworkers are there, around you. When you remove the physical presence, it suddenly becomes much harder to feel the collective effort being pulled by the team.
When we started using IRC more intensively, we quickly felt the change. Having everyone in the chat at the same time gives this warm fuzzy feeling. Reading live discussions between other team member allows you to jump in with the same type of spontaneity you’d find at the water cooler (minus the petty politics).
What’s all that for?
In itself, decentralization and remote working can be very rewarding – you cut down on the superfluous and focus on what matters. When something doesn’t work, it is apparent more quickly once you have the right processes in place.
You also get to get more done, as it favors long uninterrupted sessions of work. You get less politics, and more time to think and work on the big problems. You have a greater latitude on how to mix your personal and professional life. And, last but not least, you become much less tied to a geographical location – you get to chose your physical environment, and what you get to see of the world.
This part only came progressively as we developed the model, but I would have a hard time living without now. It’s hard to express the beauty of the feeling you get from mixing work and travel. The mind of the traveler is constantly surprised and intrigued by the cultural and visual contrast offered by the countries you get to discover. When you get to work on great problems while the mind is in this state, you get into flow much more easily. Like if the constant amazement and infinite possibilities of code had suddenly expanded to the world, echoing each other in a sort of virtuous circle.
If you should only keep one thing from this post, it should be this. With the right methods, getting rid of the office building works, and it works well.
Try it. Take a freelancer, and go work on it from the beach or the country-side of a country you’ve never visited. Chances are you won’t come back.
- Running with the seagulls by Ed Schipul, CC-BY-SA 2.0
- Alvaro siza, institut für architektur by seier+seier, CC-BY 2.0
- Scrum Hell by Enrique Fernandez, CC-BY 2.0
- Tools by zzpza, CC-BY 2.0
- Curious Look by Ernst Vikne, CC-BY-SA 2.0
- This blog post is released under the CC-BY-SA 2.0