Opening my X-Team eyes

Learning to work remotely

When I started working with X-Team I was excited and impressed about the idea they had, about the way it would be possible to work on big projects from where I wanted. I had been wanting to work in a way that would allow me more freedom to travel and learn about different cultures the way that you can't do on a short vacation. But the X-Team ideology is bigger than that, bigger than just finding the best people in the world who knows what needs to be done and knows how to do it. Bigger than competent developers world wide.

Seeing the projects that X-Team was working on at the time I was brought in, honestly it impressed me. It was high profile, sites with lots of exposure and well known names - who wouldn't want to work on projects like that right? I came from the i-gaming business being a new but well established industry, going to the office with schedules, lunch meetings, scrum meetings, after work and all those location-dependant day-to-day things. I'm a confident and well organized person, but I did not quite anticipate (working remotely) the level of discipline needed, flexibility, communication and structure - all these things really got put to the test for me as I joined X-Team, coming from the comfortable office environment where many of these things are already in place and comes naturally.

Working remotely is not for everyone - far from it. The first months, living in Europe but having collegues in LA mostly, my days usually started at 19:00 and went on until the small hours. A schedule like that is in the long run just not healthy and I admit that I was considering if I was really cut out for this.

I would like to share with you the solution as it was for me.

Get better at communicating

When you're not working at the same time as your collegues - how can you get the answers/feedback from them than you need? That is true, sometimes you just have to talk to someone about something that blocks you from continuing your work but think about it - can that be prevented? Getting better at communicating doesn't just mean that you should talk more, send more updates, be responsive and all that. It also means that you need to be to-the-point and proactive. Think about what you communicate.

What I mean by that is, giving updates about what you're doing is good and answering people's questions is as well. But also make sure that you're asking the right questions. If you're working on a project with two other developers, one from Kansas and another from Japan, you're (if you're in Europe) rarely going to be working the same hours as they do. Make sure that your questions are to the point and doesn't require an immediate answer, but rather make educated guesses and let them know how you're planning to proceed. For instance, here's an e-mail to the team and beneath it there's the same e-mail but written with a better approach.

Hi Team,

I've run into a problem where I can't get the proper response from the save function in form.rb
If we can have a quick meeting about this I'd appreciate it.

Also Mark, I checked out your JS bug and I think I have an idea, lets talk about that then as well.

Br, André

Compare that to this..

Hi team,

I've run into a problem where I'm not getting the expected response from the save function in form.rb

Here's the details of my problem: attached txt or gist link.

I will be working on this the first thing in the morning, if you've got some time to investigate what might be wrong I would appreciate it. If not then I'm going to solve it this way [write optional solution].

@Mark: I believe your js bug is located on line 726 in somefile.js. Try reading this [link] for more info. If the problem persists, I know @jason (CC'd) has seen this problem before.

My next task for tomorrow will be [some task] - @Mark could you send me a link to the documentation on that project, and also add me to repository so I have correct access. Thank you.

Br, André

In the first e-mail, I'm halting work to have a meeting that may not be necessary. The JS note to Mark doesn't really help Mark himself but he has to wait for me before he can continue.

In the latter e-mail, I'm adding a link to what actually went wrong so that when I am asleep they can investigate what the issue may be and have an answer for me when I start my day, and they can look at it when they have time without having to stop what they are doing to answer my question. If everyone is busy and can't investigate this issue, then at least they know what I will be doing about it the day after, possibly that would have been their solution all along.

Always try to answer your own question before asking it, you might have it just right

Mark's JS problem is something I didn't have time to fix, but I looked at it and I think I found the problem. Instead of just saying that I think I know the problem, in the latter e-mail I enable Mark to look at the problem himself and to read the link where I found the answer. If he doesn't find it - deligating him to Jason makes sure that he doesn't have to wait for me to wake up, but he can continue solving the problem with the help of Jason.

Something that was omitted completely in the first e-mail is what will happen with the next project. This is something I haven't even started yet, but I know that I will need some things - why not make sure I have them in the morning? I'll surely have questions about it, possibly the documentation can answer them for me. Try not to ask for things when you need it, ask before that - as soon as you know that you'll need them, it will mean that you won't need to wait for things.

Ok, enough of disecting e-mails.

The idea is thinking ahead this way and providing alternatives, deligating, being proactive about what problems may occur tomorrow - that is what has enabled me to have my regular working hours back and it also helps my co-workers in their job.

Simpler questions

If you need a quick answer through a chat or a phone call - try to formulate your question so that it can be answered with a yes/no answer (or at least a short answer). In an office environment this is especially important since you always can ask someone who's sitting right beside you. Instead of trying to explain your task, solution and why you need his/her oppinion, is it possible that you can ask something much simpler and then continue your work? In my experience it always pays off to have this mindset for a couple of reasons:

  1. Asking questions means you're interrupting someone else. If you interrupt that person for 30 seconds or less, then he'll have no problem returning to his thoughts and being productive. If you're taking up too much of someone's time it means that their thoughts will be on your problem instead - try to avoid that.
  2. When you form a question in a way that it can be answered by yes/no, you will realize if it's possible for you to just find the answer yourself instead.

Here's an example

André, I'm writing an Ajax call and I can't get this response in the right format, would you take a look when you have time?

Compare that to:

André, is there a way I can ensure what format I'm getting my XHR response in?

The latter question means I can just say yes and attach a link. In fact, it would be fine to just put it in Google's search field to get the answer.

As a side note about internal code; if you can't answer such a question with a Yes/No and a link - then you probably need to write some documentation on it.


Get involved in the company

Keep Calm image

This might seem like an odd ball. Trust me, it's not. Engaging yourself in how the company works and what the plan for the future is - the ideology - it creates a sense of attachment between you and your work. When you know for what you work and what the future goal is, then you have the ability to make better decicions, even if they are small. Everything you do, everything you write on the web, everytime you talk about your work - it will be a gospel to get one step further to that goal. In order to have that fire in you, you need to understand the company and where the company is heading. Talk to your collegues, talk to your bosses, get involved.

On my previous job, being a team lead, this was defacto a part of my job description and it was such a great feeling when you realize that there's someone else in the team who's taking an interest in the bigger picture, reaching higher and trying to take everyone else and the company with him. That is truly inspiring and that is more important than ever in a remote environment. It builds up a connection between you and your work, something that you can put your heart into.

Know your build, know it well

A couple of months ago I read Ryan's article about becoming a great remote developer (see below, it's a good read!), one point in his article is particularly important for many developers. Instead of referencing a hedgehog, I will be referencing a quote of Day[9] from the Starcraft2 scene.

If you know 10 different, advanced builds pretty well - you're a pretty good player.
If you know 1 build extremely well - you're an extremely good player.

What this means is that you should find your area of expertise and focus on that as much as you can. If you're trying to master Sass authoring, Backbone, Python backend, MySQL and Angular - then you're going to have too much of a split focus and you're not going to master any of them. That means that you may be on many different projects, but you will not be perfect for any of them. My suggestion is for you to select a few areas that really interest you, work hard and learn it well. You will feel like you're giving up on things but what you're really doing is to focus and to specialize yourself. You're becoming an expert, nobody is an expert in everything.

Who would you choose if you're looking for a Sass specialist?

After a while people will be referring to you when looking for expertise in a certain area.

To have that recognition from your co-workers is a rewarding feeling and it integrates you in the network you're working in, making the distances between you and your team smaller.

Sass Mixin bug? Oh I think you should talk with André, that's his thing.
Sorry I don't have time at the moment, I know André loves tinkering with Ruby helpers - check with him!

That's a wrap

Thanks for tuning in, I hope this will be of some help when trying to acclimatize yourself to a remote working environment.

I chose the title "Opening my X-Team eyes" for this article because it would have been easy for me to start looking for another on-location type job and then not need to tackle these difficult changes but X-Team being fully aware of what kind of challenges a remote worker is met with, has built up a work culture that really helps in making a developer's job a fun, challenging, rewarding and interesting job. The points you've just read about and the inspiring X-Culture is what has helped me make my job the job I dreamed of.

Thanks to the great people and attitude in this environment, I believe in what X-Team is - Superheroes changing the world from anywhere.